Architecture du système

Quatre notions permettent de comprendre l’architecture de JelinaOS : double système, racine en lecture seule, données indépendantes et collaboration cloud. Elles constituent ensemble le socle de sa fiabilité, de sa facilité de maintenance et de son administration.

Organisation des partitions

JelinaOS utilise une organisation claire des partitions de stockage, chacune ayant un rôle unique, sans interférence avec les autres. Les partitions sont identifiées par des étiquettes fixes (Label), identiques sur toutes les plateformes. Quels que soient les noms des périphériques sous-jacents (sda/nvme sur x86, mmcblk sur ARM), le système les retrouve par leur étiquette :

┌────────────────────────────────────────────────┐
│ jelina-boot     Partition de démarrage : chargeur et environnement │
│ jelina-kernel-1 Noyau 1, redondant avec 2, lecture seule  │
│ jelina-kernel-2 Noyau 2                         │
│ jelina-system-1 Système 1, lecture seule, état d’usine       │
│ jelina-system-2 Système 2                         │
│ jelina-data     Partition de données : toutes les données et écritures utilisateur   │
│ jelina-recv     Partition de récupération : réparation et réinitialisation d’usine   │
└────────────────────────────────────────────────┘

Partitions A/B : le noyau et le système disposent chacun de deux copies complètes servant de sauvegarde mutuelle ;
Montage en lecture seule : les partitions système sont montées en lecture seule pendant l’exécution et aucun programme ne peut en modifier le contenu ;
Partition de données indépendante : toutes les données utilisateur, configurations et écritures d’exécution sont stockées dans la partition Data.

Séquence de démarrage

Quelle que soit la plateforme matérielle, JelinaOS suit la même logique de démarrage :

Firmware matériel → Chargeur de démarrage → Sélection de la partition A/B → Chargement du noyau → Assemblage du système → Démarrage des applications métier
    │            │              │
Dépendant de la plateforme     Dépendant de la plateforme   Indépendant de la plateforme, suite identique sur toutes les plateformes

Le micrologiciel matériel et le chargeur d’amorçage initialisent la plateforme ; les différences entre plateformes sont transparentes pour l’utilisateur ;
Le chargeur lit la stratégie de démarrage, choisit la partition A ou B et vérifie l’état du système ;
Après le démarrage du noyau, le système assemble la partition système en lecture seule et la partition de données inscriptible dans une vue d’exécution unifiée ;
Les services système et les applications métier démarrent successivement, puis l’équipement devient opérationnel.

Les mises à jour suivent la même chaîne : la nouvelle version est écrite sur la partition de secours, vérifiée automatiquement après basculement, et un retour arrière est effectué en cas d’échec. Les sites à bande passante limitée peuvent utiliser les mises à jour incrémentales, qui ne transfèrent que les différences.

Ce processus garantit que la mise à jour ne touche que la partition de secours, sans affecter le système en cours d’exécution ; le contrôle est automatique au démarrage, avec basculement automatique en cas d’anomalie.

Flux et isolation des données

Pendant l’exécution, les flux internes suivent des règles d’isolation strictes :

        ┌────────────────────────────┐
        │ Couche applications : conteneurs / applications natives  │
        └──────────────┬─────────────┘
                       │ Lecture : système en lecture seule
                       │ Écriture : partition de données
        ┌──────────────┴─────────────┐
        │ Couche système : lecture seule, non modifiable   │
        ├────────────────────────────┤
        │ Partition de données : toutes les écritures utilisateur   │
        └────────────────────────────┘

Les applications peuvent lire le contenu du système, mais pas le modifier ;
Toutes les écritures sont redirigées vers la partition de données, complètement isolée du système ;
La restauration des paramètres d’usine remet le système et les écritures utilisateur à leur état d’usine. Sauvegardez préalablement les données importantes.

Collaboration cloud

L’agent intégré permet à l’équipement de collaborer avec la plateforme JelinaCloud :

┌──────────┐       Remontée d’état / journaux       ┌─────────────┐
│ Équipement edge │ ─────────────────────────▶ │ JelinaCloud │
│ JelinaOS │ ◀───────────────────────── │  Plateforme cloud   │
└──────────┘     Diffusion des mises à jour / maintenance distante     └─────────────┘

Flux montant : l’état de l’équipement, les indicateurs d’exécution et les journaux sont remontés en continu et visibles en temps réel dans le cloud ;
Flux descendant : mises à jour système, versions applicatives et stratégies de configuration sont orchestrées de manière centralisée ;
Canal sécurisé : en mode production, l’équipement communique avec le cloud uniquement par un canal chiffré, sans exposer sa maintenance à Internet.

Vue d’ensemble de l’architecture

Couche	Composants	Responsabilités
Application	Applications conteneurisées et natives	Exécution de la logique métier
Exécution	Moteur de conteneurs, gestion des services, agent d’équipement	Orchestration applicative, services système et collaboration cloud
Système	Système en lecture seule (Debian / Ubuntu / Kylin, etc.)	Socle stable et non modifiable
Matériel	ARM64 (Allwinner / Rockchip / NXP i.MX), x86_64	Adaptation unifiée à plusieurs plateformes

Cette architecture offre un système plus sûr, des mises à jour plus fiables et une maintenance plus simple : c’est la réponse de JelinaOS aux besoins de l’edge industriel.