CANEVAS DES DOCUMENTS DU PROJET

# Canevas 5 — Architecture système  Conception globale

# Canevas 5 — Architecture système / Conception globale

## 1. Objet du document

### 1.1 Finalité du document d’architecture système

Cette partie précise l’objectif du document.

Le document d’architecture système, ou dossier de conception globale, décrit l’organisation générale de la solution retenue pour répondre à la spécification globale. Il ne décrit pas encore le détail interne de chaque composant, mais il explique comment le système est découpé en sous-systèmes, comment les fonctions sont réparties, quelles interfaces existent entre les blocs et quels choix structurants ont été retenus.

Il constitue le lien entre la spécification système et les conceptions détaillées hardware, software, infrastructure, réseau, interfaces et tests.

**Exemple :**

> Le présent document a pour objectif de décrire l’architecture générale du système, son découpage en sous-systèmes, l’allocation des fonctions, les interfaces principales, les flux de données, les flux de commande, les choix techniques structurants et les principes d’intégration retenus pour la réalisation du système.

### 1.2 Positionnement dans le cycle en V

Cette partie situe l’architecture système dans le cycle en V.

Le document d’architecture système est produit après la spécification globale et avant les spécifications détaillées et les conceptions détaillées. Il permet de transformer les exigences système en une organisation technique cohérente.

Il sert de base à :

```text

- la spécification détaillée hardware ;

- la spécification détaillée software embarqué ;

- la spécification détaillée serveur / application ;

- la spécification détaillée des interfaces ;

- la conception détaillée hardware ;

- la conception détaillée software ;

- la conception détaillée infrastructure ;

- les plans d’intégration ;

- les tests d’intégration système ;

- les tests système.

```

Dans le cycle en V, l’architecture système est principalement vérifiée par les **tests d’intégration système** et les **tests système**.

```text

Spécification globale / système

        ↓

Architecture système / conception globale

        ↓

Spécifications détaillées des sous-systèmes

        ↓

Conceptions détaillées

        ↓

Réalisation / codage / assemblage / configuration

        ↑

Tests unitaires

        ↑

Tests d’intégration sous-systèmes

        ↑

Tests d’intégration système

        ↑

Tests système / validation globale

```

### 1.3 Différence avec la spécification globale

Cette partie précise la différence entre la spécification globale et l’architecture système.

La spécification globale décrit **ce que le système doit faire**.

L’architecture système décrit **comment le système est organisé pour le faire**.

**Exemple :**

```text

Spécification globale :

Le système doit permettre la surveillance distante d’un équipement installé sur site.

Architecture système :

La surveillance distante est assurée par :

- un équipement embarqué chargé d’acquérir les mesures ;

- un module de communication chargé de transmettre les données ;

- un serveur applicatif chargé de recevoir et traiter les données ;

- une base de données chargée de conserver les historiques ;

- une interface web chargée d’afficher les états et alarmes.

```

### 1.4 Différence avec la conception détaillée

Cette partie précise la frontière avec les documents de conception détaillée.

L’architecture système décrit les grands blocs, leurs responsabilités, leurs interfaces et leurs interactions. La conception détaillée décrira ensuite comment chaque bloc est effectivement réalisé : schémas électroniques, cartes, modules logiciels, classes, API, base de données, scripts, configuration réseau, procédures de déploiement, etc.

**Exemple :**

```text

Architecture système :

Le sous-système embarqué communique avec le serveur applicatif via une liaison IP sécurisée.

Conception détaillée :

Le firmware utilise un client MQTT/TLS. Les messages sont publiés sur les topics equipment/{id}/telemetry et equipment/{id}/alarm. Les certificats sont stockés dans une zone mémoire protégée.

```

### 1.5 Responsabilités de rédaction et d’approbation

Cette partie précise qui rédige, relit et approuve le document.

L’architecture système doit être rédigée par le responsable technique ou l’ingénieur système, avec les contributions des responsables hardware, software embarqué, infrastructure, réseau, cybersécurité, tests, exploitation et maintenance.

**Exemple :**

```text

Rédaction : ingénieur système / architecte système / responsable technique

Contributions : hardware, software embarqué, serveur, infrastructure, réseau, cybersécurité, validation

Relecture : chef de projet, qualité, responsables de lots techniques

Approbation : responsable technique fournisseur et client si le document est contractuel

```

---

## 2. Références et documents applicables

### 2.1 Documents d’entrée

Cette partie liste les documents utilisés pour définir l’architecture.

L’architecture ne doit pas être inventée indépendamment des besoins. Elle doit dériver de documents d’entrée identifiés et versionnés.

**Exemples :**

```text

- Cahier des charges / expression du besoin

- Dossier de validation client

- Spécification globale / spécification système

- Dossier des modes de fonctionnement

- Analyse de risques préliminaire

- Contraintes d’exploitation

- Contraintes de maintenance

- Contraintes d’installation

- Contraintes de cybersécurité

- Contraintes d’infrastructure client

- Contraintes réglementaires

- Études de faisabilité

```

### 2.2 Documents applicables

Cette partie liste les documents que l’architecture doit impérativement respecter.

**Exemples :**

```text

- normes électriques applicables ;

- règles de cybersécurité client ;

- référentiel réseau client ;

- référentiel d’hébergement ;

- standard de développement logiciel ;

- standard de câblage ;

- standard de nommage des équipements ;

- règles de gestion de configuration ;

- exigences contractuelles.

```

### 2.3 Documents produits à partir de l’architecture

Cette partie liste les documents qui seront dérivés de l’architecture système.

**Exemples :**

```text

- spécification détaillée hardware ;

- spécification détaillée software embarqué ;

- spécification détaillée serveur / application ;

- spécification détaillée des interfaces ;

- dossier d’infrastructure ;

- dossier de conception détaillée hardware ;

- dossier de conception détaillée software ;

- dossier de conception réseau ;

- plan d’intégration ;

- plan de vérification ;

- procédures de tests d’intégration.

```

### 2.4 Gestion des évolutions de l’architecture

Cette partie précise comment les changements d’architecture seront maîtrisés.

Une modification d’architecture peut avoir des impacts importants sur les exigences, les interfaces, la conception, les tests, la validation, les coûts, les délais et la maintenance.

**Exemple :**

> Toute modification affectant le découpage des sous-systèmes, les interfaces principales, le choix des protocoles, les principes de déploiement ou l’allocation hardware/software doit faire l’objet d’une analyse d’impact et d’une validation par le responsable technique.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

Cette partie définit les termes utilisés dans le document.

**Exemples :**

```text

Architecture système :

Organisation générale du système en sous-systèmes, composants, interfaces, flux et responsabilités.

Sous-système :

Ensemble cohérent de fonctions, matériels, logiciels ou services assurant une responsabilité identifiée dans le système.

Interface :

Point d’échange entre deux éléments du système ou entre le système et son environnement.

Allocation :

Affectation d’une fonction ou d’une exigence à un sous-système, un composant, un logiciel, un matériel, une infrastructure ou une procédure.

Flux :

Échange de données, de commandes, d’événements, d’énergie ou d’informations entre composants.

```

### 3.2 Acronymes

Cette partie liste les acronymes employés.

**Exemples :**

```text

API : Application Programming Interface

BMS : Battery Management System

CPU : Central Processing Unit

IHM : Interface Homme-Machine

LAN : Local Area Network

SAS : Zone ou serveur d’échange contrôlé

VPN : Virtual Private Network

VM : Machine virtuelle

```

### 3.3 Conventions de représentation

Cette partie précise les conventions utilisées pour les schémas, diagrammes et tableaux.

**Exemple :**

```text

Les blocs matériels sont représentés par des rectangles à bord continu.

Les blocs logiciels sont représentés par des rectangles à bord pointillé.

Les flux de données sont représentés par des flèches pleines.

Les flux de commande sont représentés par des flèches en pointillés.

Les flux d’administration ou de maintenance sont représentés séparément.

Les interfaces externes sont identifiées par le préfixe IF-EXT.

Les interfaces internes sont identifiées par le préfixe IF-INT.

```

### 3.4 Convention de nommage des composants

Cette partie définit comment les composants seront nommés dans le document.

**Exemple :**

```text

HW-CTRL : carte de contrôle principale

HW-COM : module de communication

SW-EMB : logiciel embarqué

SRV-APP : serveur applicatif

DB-HIST : base de données historique

IHM-OPS : interface opérateur

INF-BKP : service de sauvegarde

NET-LAN : réseau local

```

---

## 4. Vue d’ensemble de l’architecture

### 4.1 Présentation générale de l’architecture retenue

Cette partie donne une vue d’ensemble de la solution.

Elle doit permettre de comprendre immédiatement l’organisation générale du système : quels sont les grands blocs, où ils se trouvent, comment ils communiquent, quels rôles ils jouent et quelles responsabilités leur sont attribuées.

**Exemple :**

> Le système est organisé autour d’un équipement embarqué installé sur site, chargé d’acquérir les données et de piloter les fonctions locales. Cet équipement communique avec un serveur applicatif chargé de centraliser les données, de gérer les historiques et de fournir une interface opérateur. L’infrastructure comprend également une base de données, un serveur de sauvegarde, un réseau local sécurisé et des moyens de maintenance.

### 4.2 Synoptique général

Cette partie doit présenter un schéma global.

À défaut de schéma graphique, une représentation textuelle peut être utilisée.

**Exemple :**

```text

+---------------------+

| Capteurs / Entrées  |

+----------+----------+

           |

           v

+---------------------+        +---------------------+

| Équipement embarqué | <----> | Module communication|

| HW + Firmware       |        | Ethernet / 4G / VPN |

+----------+----------+        +----------+----------+

           |                              |

           |                              v

           |                    +---------------------+

           |                    | Réseau local / WAN  |

           |                    +----------+----------+

           |                              |

           v                              v

+---------------------+        +---------------------+

| Actionneurs / Sorties|       | Serveur applicatif  |

+---------------------+        +----------+----------+

                                          |

                                          v

                                +---------------------+

                                | Base de données     |

                                +----------+----------+

                                          |

                                          v

                                +---------------------+

                                | Interface opérateur |

                                +---------------------+

```

### 4.3 Principes généraux d’architecture

Cette partie décrit les grands principes retenus.

**Exemples :**

```text

- séparation entre fonctions embarquées critiques et fonctions serveur ;

- maintien local des fonctions essentielles en cas de perte réseau ;

- centralisation des historiques sur serveur ;

- journalisation des événements importants ;

- séparation des environnements test, validation et production ;

- accès administrateur limité aux utilisateurs habilités ;

- sauvegarde régulière des données et configurations ;

- possibilité de diagnostic local et distant selon les droits.

```

### 4.4 Hypothèses structurantes

Cette partie liste les hypothèses techniques ou organisationnelles sur lesquelles repose l’architecture.

**Exemples :**

```text

- le site dispose d’une alimentation électrique conforme aux prérequis ;

- une liaison réseau est disponible entre l’équipement et le serveur ;

- les équipements embarqués doivent continuer à fonctionner localement en cas de perte serveur ;

- les opérateurs utilisent une interface web depuis un poste client ;

- l’hébergement serveur est assuré sur une infrastructure client ;

- les sauvegardes sont réalisées sur un serveur distinct.

```

### 4.5 Contraintes structurantes

Cette partie liste les contraintes qui ont fortement influencé les choix d’architecture.

**Exemples :**

```text

- impossibilité d’utiliser un cloud public ;

- obligation d’utiliser le réseau client ;

- fonctionnement local obligatoire en cas de perte réseau ;

- nécessité de maintenir une traçabilité complète des événements ;

- contraintes de cybersécurité ;

- contraintes de maintenance par technicien non développeur ;

- contraintes de disponibilité ;

- environnement industriel sévère ;

- impossibilité d’accès physique fréquent à l’équipement.

```

---

## 5. Découpage en sous-systèmes

### 5.1 Objectif du découpage

Cette partie explique pourquoi le système est découpé en sous-systèmes.

Le découpage permet de répartir les responsabilités, de maîtriser la complexité, de faciliter les spécifications détaillées, de séparer les métiers techniques, de préparer l’intégration et de définir les interfaces.

**Exemple :**

> Le système est découpé en sous-systèmes afin de distinguer les fonctions embarquées, les fonctions serveur, les fonctions d’exploitation, les fonctions de communication, les fonctions de sauvegarde et les fonctions de maintenance.

### 5.2 Liste des sous-systèmes

Cette partie liste les sous-systèmes identifiés.

**Exemple :**

```text

SS-HW-001 : sous-système matériel embarqué

SS-SW-001 : sous-système logiciel embarqué

SS-COM-001 : sous-système communication

SS-SRV-001 : sous-système serveur applicatif

SS-DB-001 : sous-système base de données

SS-IHM-001 : sous-système interface opérateur

SS-INF-001 : sous-système infrastructure informatique

SS-BKP-001 : sous-système sauvegarde / restauration

SS-MNT-001 : sous-système maintenance / diagnostic

SS-SEC-001 : sous-système sécurité / cybersécurité

```

### 5.3 Description synthétique de chaque sous-système

Cette partie décrit le rôle principal de chaque sous-système.

**Exemple :**

```text

SS-HW-001 — Matériel embarqué :

assure l’interface physique avec les capteurs, les actionneurs, l’alimentation et les moyens de communication.

SS-SW-001 — Logiciel embarqué :

assure l’acquisition, les traitements locaux, la gestion des états, les alarmes locales, le stockage temporaire et la communication avec le serveur.

SS-SRV-001 — Serveur applicatif :

assure la réception des données, la gestion des équipements, la centralisation des alarmes, les API et les services applicatifs.

SS-DB-001 — Base de données :

assure le stockage des mesures, alarmes, événements, configurations et journaux.

SS-IHM-001 — Interface opérateur :

permet la consultation des états, des alarmes, des historiques, des configurations et des fonctions autorisées.

SS-BKP-001 — Sauvegarde / restauration :

assure la sauvegarde des données et configurations critiques, ainsi que les procédures de restauration.

```

### 5.4 Responsabilités principales par sous-système

Cette partie permet d’éviter les ambiguïtés.

**Exemple :**

```text

Fonction : détection d’une perte réseau

Responsabilité embarquée :

détecter l’absence d’acquittement serveur, passer en mode dégradé communication et stocker localement les données.

Responsabilité serveur :

détecter l’absence de remontée d’un équipement et afficher son état non joignable.

Responsabilité IHM :

afficher l’état de communication dégradée à l’opérateur.

Responsabilité infrastructure :

assurer les moyens réseau nécessaires et journaliser les incidents réseau si applicable.

```

### 5.5 Sous-systèmes externes

Cette partie liste les systèmes qui interagissent avec le système mais ne font pas partie du périmètre livré.

**Exemples :**

```text

- réseau Internet du client ;

- système de supervision tiers ;

- ERP ou GMAO client ;

- équipement industriel tiers ;

- serveur d’authentification client ;

- service de messagerie ;

- système de sauvegarde externe ;

- alimentation générale du bâtiment.

```

### 5.6 Responsabilités client / fournisseur

Cette partie clarifie qui fournit, installe, configure et maintient chaque élément.

**Exemple :**

```text

Équipement embarqué : fourni par le fournisseur

Capteurs : fournis par le client ou fournisseur selon contrat

Serveur applicatif : fourni/configuré par le fournisseur

Infrastructure physique serveur : fournie par le client

Réseau local : fourni par le client

Base de données : installée et configurée par le fournisseur

Sauvegarde : configurée par le fournisseur, exploitée par le client

Postes opérateurs : fournis par le client

```

---

## 6. Allocation des fonctions

### 6.1 Objectif de l’allocation fonctionnelle

Cette partie explique l’objectif de l’allocation.

L’allocation fonctionnelle consiste à affecter chaque grande fonction du système à un ou plusieurs sous-systèmes. Elle permet de passer des exigences globales à une architecture réalisable.

**Exemple :**

> La fonction de surveillance des seuils est allouée au logiciel embarqué pour permettre une réaction locale en cas de perte réseau, tandis que l’historisation longue durée est allouée au serveur et à la base de données.

### 6.2 Liste des fonctions à allouer

Cette partie reprend les grandes fonctions issues de la spécification globale.

**Exemples :**

```text

FCT-001 : acquisition des mesures

FCT-002 : surveillance des seuils

FCT-003 : génération des alarmes

FCT-004 : stockage local temporaire

FCT-005 : transmission serveur

FCT-006 : affichage opérateur

FCT-007 : configuration

FCT-008 : diagnostic

FCT-009 : maintenance

FCT-010 : sauvegarde / restauration

FCT-011 : gestion des utilisateurs

FCT-012 : journalisation

```

### 6.3 Matrice d’allocation fonctionnelle

Cette partie présente une matrice associant fonctions et sous-systèmes.

**Exemple :**

```text

Fonction | HW embarqué | SW embarqué | Serveur | Base données | IHM | Infrastructure | Procédure

Acquisition mesures | X | X |   |   |   |   |  

Surveillance seuils |   | X | X |   | X |   |  

Alarmes locales | X | X |   |   | X |   |  

Historisation longue durée |   |   | X | X | X | X |  

Stockage local en perte réseau |   | X |   |   |   |   |  

Resynchronisation |   | X | X | X | X | X |  

Sauvegarde |   |   | X | X |   | X | X

Maintenance | X | X | X |   | X |   | X

```

### 6.4 Justification des allocations importantes

Cette partie explique pourquoi certaines fonctions sont placées à tel endroit.

**Exemple :**

```text

Fonction : surveillance des seuils critiques

Allocation retenue :

surveillance locale dans le logiciel embarqué.

Justification :

la détection des seuils critiques doit rester possible en cas de perte de communication serveur. Le traitement ne peut donc pas être exclusivement réalisé côté serveur.

```

**Autre exemple :**

```text

Fonction : historisation longue durée

Allocation retenue :

serveur applicatif et base de données.

Justification :

les données historiques doivent être consultables par plusieurs utilisateurs, sauvegardées régulièrement et conservées sur une durée supérieure à la capacité de stockage de l’équipement embarqué.

```

### 6.5 Fonctions partagées entre plusieurs sous-systèmes

Cette partie identifie les fonctions réparties.

Une fonction partagée doit être décrite avec attention, car elle crée des dépendances d’intégration.

**Exemple :**

```text

Fonction : gestion des alarmes

Partie embarquée :

détection locale, génération d’événement, stockage temporaire.

Partie serveur :

réception, historisation, consolidation, diffusion.

Partie IHM :

affichage, filtrage, acquittement.

Partie base de données :

conservation de l’historique.

Partie procédure :

règles d’exploitation et traitement des alarmes.

```

---

## 7. Allocation hardware / software / infrastructure

### 7.1 Objectif de l’allocation technique

Cette partie explique comment les exigences sont réparties entre matériel, logiciel, infrastructure et procédures.

L’allocation technique est essentielle pour les systèmes mixtes hardware/software. Elle permet d’identifier ce qui sera réalisé par du matériel, par du logiciel embarqué, par une application serveur, par un opérateur ou par une procédure.

### 7.2 Allocation vers le hardware

Cette partie décrit les fonctions ou exigences portées par le matériel.

**Exemples :**

```text

- acquisition physique des signaux ;

- adaptation électrique ;

- protection contre surtension ;

- isolement galvanique ;

- interface avec capteurs ;

- interface avec actionneurs ;

- alimentation ;

- connectique ;

- voyants locaux ;

- bouton arrêt d’urgence ;

- stockage mémoire embarqué si matériel dédié.

```

**Exemple d’allocation :**

```text

Exigence :

Le système doit détecter l’état d’un contact sec.

Allocation hardware :

entrée numérique isolée sur la carte de contrôle.

Allocation software :

lecture périodique de l’entrée, filtrage anti-rebond et publication de l’état.

```

### 7.3 Allocation vers le software embarqué

Cette partie décrit les fonctions portées par le firmware ou le logiciel embarqué.

**Exemples :**

```text

- acquisition périodique ;

- filtrage des mesures ;

- gestion des états ;

- détection de défauts ;

- stockage local ;

- communication serveur ;

- gestion des alarmes locales ;

- watchdog logiciel ;

- diagnostic local ;

- mise à jour firmware ;

- gestion des configurations locales.

```

### 7.4 Allocation vers le serveur applicatif

Cette partie décrit les fonctions portées par le serveur.

**Exemples :**

```text

- réception des données ;

- centralisation des historiques ;

- gestion des utilisateurs ;

- API applicative ;

- consolidation multi-équipements ;

- règles d’agrégation ;

- notifications ;

- rapports ;

- supervision globale ;

- synchronisation avec systèmes tiers.

```

### 7.5 Allocation vers l’infrastructure

Cette partie décrit les fonctions portées par l’environnement informatique.

**Exemples :**

```text

- hébergement serveur ;

- réseau ;

- résolution DNS ;

- pare-feu ;

- VPN ;

- sauvegarde ;

- stockage ;

- supervision technique ;

- logs système ;

- gestion des certificats ;

- séparation test / production.

```

### 7.6 Allocation vers les procédures humaines

Certaines fonctions ne sont pas automatisées et doivent être assumées par des procédures.

**Exemples :**

```text

- remplacement d’un module ;

- vérification périodique d’un équipement ;

- restauration après incident majeur ;

- mise en service ;

- validation après intervention ;

- contrôle visuel ;

- consignation électrique ;

- validation de retour au nominal.

```

### 7.7 Matrice d’allocation exigences / composants

Cette partie propose une matrice de synthèse.

**Exemple :**

```text

Exigence | Hardware | SW embarqué | Serveur | IHM | Infrastructure | Procédure

SYS-FCT-001 Acquisition | X | X |   |   |   |  

SYS-COM-004 Perte réseau |   | X | X | X | X |  

SYS-ALM-002 Affichage alarme |   | X | X | X |   |  

SYS-SAV-001 Sauvegarde |   |   | X |   | X | X

SYS-MNT-021 Export logs |   | X | X | X |   | X

```

---

## 8. Architecture matérielle globale

### 8.1 Objet de l’architecture matérielle globale

Cette partie décrit les grands choix matériels sans entrer dans les schémas électroniques détaillés.

Elle doit donner une vision claire des cartes, modules, alimentations, capteurs, actionneurs, coffrets, interfaces et moyens de raccordement.

### 8.2 Éléments matériels principaux

**Exemples :**

```text

- coffret ou boîtier ;

- carte de contrôle principale ;

- carte d’extension d’entrées/sorties ;

- alimentation ;

- module de communication ;

- capteurs ;

- actionneurs ;

- connecteurs ;

- fusibles / protections ;

- relais / contacteurs ;

- afficheur local ;

- boutons ou voyants ;

- support de stockage local ;

- port de maintenance.

```

### 8.3 Synoptique matériel

Cette partie doit fournir une représentation des liens matériels.

**Exemple textuel :**

```text

Alimentation site

      ↓

Protection électrique

      ↓

Alimentation système

      ↓

Carte de contrôle principale

      ├── Entrées capteurs

      ├── Sorties relais

      ├── Module communication

      ├── Stockage local

      ├── Port maintenance

      └── Voyants / afficheur local

```

### 8.4 Interfaces électriques principales

Cette partie décrit les interfaces électriques au niveau global.

**Exemples :**

```text

- alimentation 230 VAC ou 24 VDC ;

- entrées numériques ;

- sorties relais ;

- entrées analogiques ;

- communication RS485 ;

- Ethernet ;

- USB maintenance ;

- entrée arrêt d’urgence ;

- sortie défaut général.

```

### 8.5 Contraintes environnementales

Cette partie indique les contraintes qui influencent l’architecture matérielle.

**Exemples :**

```text

- température de fonctionnement ;

- humidité ;

- vibrations ;

- poussière ;

- environnement extérieur ;

- contraintes CEM ;

- niveau de protection IP ;

- refroidissement ;

- accessibilité maintenance ;

- durée de vie attendue.

```

### 8.6 Principes de sécurité matérielle

Cette partie décrit les principes retenus pour limiter les risques matériels.

**Exemples :**

```text

- protection contre inversion de polarité ;

- protection contre surtension ;

- isolement des entrées ;

- fusibles ou disjoncteurs ;

- mise à la terre ;

- arrêt d’urgence câblé ;

- relais à état sûr ;

- watchdog matériel ;

- séparation puissance / commande.

```

### 8.7 Éléments renvoyés à la conception détaillée hardware

Cette partie précise ce qui ne sera pas détaillé ici.

**Exemples :**

```text

- schémas électroniques ;

- routage PCB ;

- nomenclature détaillée ;

- calculs thermiques ;

- calculs de dimensionnement ;

- choix finaux de composants ;

- plans mécaniques détaillés ;

- procédures de fabrication.

```

---

## 9. Architecture logicielle globale embarquée

### 9.1 Objet de l’architecture logicielle embarquée

Cette partie décrit l’organisation générale du logiciel embarqué.

Elle ne détaille pas encore les classes, fonctions ou algorithmes, mais elle présente les grands modules logiciels et leurs responsabilités.

### 9.2 Modules logiciels embarqués principaux

**Exemples :**

```text

- BootManager : gestion du démarrage ;

- ModeManager : gestion des modes de fonctionnement ;

- AcquisitionManager : acquisition des mesures ;

- AlarmManager : gestion des alarmes ;

- CommunicationManager : communication serveur ;

- LocalStorageManager : stockage local ;

- ConfigurationManager : gestion de configuration ;

- DiagnosticManager : diagnostic local ;

- UpdateManager : mise à jour firmware ;

- WatchdogManager : surveillance interne ;

- SecurityManager : gestion des droits ou secrets techniques.

```

### 9.3 Responsabilités des modules

Cette partie décrit le rôle de chaque module.

**Exemple :**

```text

ModeManager :

assure la gestion des modes arrêt, démarrage, nominal, maintenance, dégradé, secours et mise à jour. Il applique les règles de transition définies dans le dossier des modes.

CommunicationManager :

assure l’établissement de la communication avec le serveur, l’envoi des données, la réception des acquittements, la détection de perte de communication et la reprise après retour réseau.

LocalStorageManager :

assure le stockage temporaire des données non transmises, la gestion de la saturation et la restitution des données à resynchroniser.

```

### 9.4 Principes d’exécution

Cette partie décrit les principes généraux d’exécution du logiciel embarqué.

**Exemples :**

```text

- exécution cyclique ;

- tâches temps réel ;

- interruptions matérielles ;

- ordonnanceur ;

- système d’exploitation embarqué ;

- boucle principale ;

- événements asynchrones ;

- priorités de traitement ;

- watchdog logiciel.

```

### 9.5 Gestion des erreurs embarquées

Cette partie décrit la stratégie globale en cas d’erreur.

**Exemples :**

```text

- erreur récupérable : génération d’un événement et poursuite du fonctionnement ;

- erreur de communication : passage en mode dégradé communication ;

- erreur capteur non critique : alarme et maintien partiel ;

- erreur capteur critique : passage en état sûr ;

- erreur mémoire ou stockage : alarme, limitation fonctionnelle ou état sûr selon criticité.

```

### 9.6 Données persistantes embarquées

Cette partie décrit les informations qui doivent être conservées localement.

**Exemples :**

```text

- configuration locale ;

- seuils ;

- identifiant équipement ;

- données non transmises ;

- alarmes non acquittées ;

- logs critiques ;

- version logicielle ;

- compteurs de fonctionnement ;

- informations de diagnostic.

```

### 9.7 Éléments renvoyés à la conception détaillée software

**Exemples :**

```text

- description des structures de données ;

- algorithmes ;

- machine d’états détaillée ;

- API internes ;

- gestion mémoire ;

- fichiers de configuration ;

- protocole exact d’échange ;

- implémentation des tâches ;

- stratégie de tests unitaires.

```

---

## 10. Architecture serveur et applicative globale

### 10.1 Objet de l’architecture serveur

Cette partie décrit l’organisation générale de la partie serveur et applicative.

Elle précise les services applicatifs, les bases de données, les API, les interfaces utilisateurs et les mécanismes d’administration.

### 10.2 Composants applicatifs principaux

**Exemples :**

```text

- service de réception des données ;

- service de traitement des alarmes ;

- service d’historisation ;

- API applicative ;

- service d’authentification ;

- interface opérateur ;

- interface administrateur ;

- service de reporting ;

- service de notification ;

- service de supervision technique ;

- service de sauvegarde.

```

### 10.3 Architecture logique applicative

**Exemple textuel :**

```text

Équipement embarqué

      ↓

API de réception / broker de messages

      ↓

Service de traitement

      ↓

Base de données

      ↓

API applicative

      ↓

Interface opérateur

```

### 10.4 Responsabilités du serveur applicatif

**Exemples :**

```text

- recevoir les mesures et événements ;

- vérifier la cohérence des messages ;

- enregistrer les données ;

- consolider les alarmes ;

- gérer les utilisateurs ;

- fournir les données à l’IHM ;

- produire des rapports ;

- journaliser les actions ;

- exposer des API ;

- communiquer avec des systèmes tiers si applicable.

```

### 10.5 Gestion des utilisateurs et droits

Cette partie décrit le principe général de contrôle d’accès.

**Exemple :**

```text

Profils prévus :

- opérateur ;

- maintenance ;

- administrateur ;

- superviseur ;

- lecture seule ;

- support technique.

Principe :

chaque fonction sensible est associée à un droit. Les modifications de configuration, les restaurations et les actions de maintenance sont réservées aux profils habilités.

```

### 10.6 Gestion des erreurs côté serveur

**Exemples :**

```text

- message reçu invalide : rejet, journalisation, alarme technique si répétition ;

- base de données indisponible : mise en erreur du service et alerte supervision ;

- équipement non joignable : affichage état non connecté ;

- échec de sauvegarde : alarme administrateur ;

- tentative d’accès non autorisée : journalisation sécurité.

```

### 10.7 Éléments renvoyés à la conception détaillée serveur

**Exemples :**

```text

- endpoints API ;

- schéma de base de données ;

- modèles de données ;

- règles de validation des messages ;

- architecture logicielle interne ;

- scripts de déploiement ;

- configuration des services ;

- gestion des sessions ;

- stratégies de pagination et archivage.

```

---

## 11. Architecture des données

### 11.1 Objet de l’architecture des données

Cette partie décrit les grandes familles de données manipulées par le système.

Elle ne remplace pas le modèle de données détaillé, mais elle donne une vision globale des données produites, stockées, transmises et consultées.

### 11.2 Familles de données

**Exemples :**

```text

- données de configuration ;

- données d’identification des équipements ;

- mesures ;

- états ;

- alarmes ;

- événements ;

- logs techniques ;

- utilisateurs ;

- droits ;

- historiques ;

- données de maintenance ;

- sauvegardes ;

- fichiers d’export.

```

### 11.3 Cycle de vie des données

Cette partie décrit le parcours des données.

**Exemple :**

```text

1. Acquisition par l’équipement embarqué.

2. Horodatage local.

3. Traitement local.

4. Stockage temporaire si nécessaire.

5. Transmission au serveur.

6. Validation côté serveur.

7. Enregistrement en base de données.

8. Consultation par l’IHM.

9. Archivage.

10. Sauvegarde.

11. Suppression ou purge selon règles définies.

```

### 11.4 Données critiques

Cette partie identifie les données qui nécessitent une attention particulière.

**Exemples :**

```text

- alarmes critiques ;

- événements de sécurité ;

- commandes opérateur ;

- modifications de configuration ;

- données nécessaires à l’analyse d’un incident ;

- données non transmises pendant une coupure réseau ;

- informations d’identification et d’authentification.

```

### 11.5 Données temporaires et persistantes

Cette partie distingue les données temporaires des données devant être conservées.

**Exemple :**

```text

Données temporaires :

- état courant ;

- valeurs instantanées ;

- buffers de communication ;

- sessions utilisateur.

Données persistantes :

- configuration ;

- historiques ;

- alarmes ;

- journaux ;

- données de maintenance ;

- versions livrées ;

- rapports.

```

### 11.6 Données locales et données centralisées

Cette partie précise quelles données restent dans l’équipement et quelles données sont centralisées.

**Exemple :**

```text

Données locales embarquées :

- configuration locale ;

- données non transmises ;

- logs critiques ;

- état courant ;

- informations de diagnostic.

Données centralisées :

- historiques complets ;

- alarmes consolidées ;

- comptes utilisateurs ;

- rapports ;

- sauvegardes ;

- configuration globale si applicable.

```

### 11.7 Éléments renvoyés à la conception détaillée des données

**Exemples :**

```text

- MCD / modèle conceptuel des données ;

- modèle logique relationnel ;

- schéma SQL ;

- dictionnaire de données ;

- règles de purge ;

- règles d’archivage ;

- formats d’échange ;

- indexation ;

- contraintes d’intégrité.

```

---

## 12. Architecture réseau et communication

### 12.1 Objet de l’architecture réseau

Cette partie décrit l’organisation générale des communications entre les composants.

Elle doit identifier les réseaux utilisés, les flux nécessaires, les protocoles, les contraintes de sécurité et les comportements en cas de perte de communication.

### 12.2 Composants réseau

**Exemples :**

```text

- réseau local site ;

- switch industriel ;

- routeur ;

- modem 4G ;

- VPN ;

- pare-feu ;

- serveur applicatif ;

- équipement embarqué ;

- poste opérateur ;

- serveur de sauvegarde ;

- SAS d’échange ;

- supervision externe.

```

### 12.3 Flux réseau principaux

Cette partie liste les flux nécessaires.

**Exemple :**

```text

Flux | Source | Destination | Protocole | Sens | Usage

F-NET-001 | Équipement | Serveur | HTTPS/MQTT | montant | mesures et alarmes

F-NET-002 | Serveur | Équipement | HTTPS/MQTT | descendant | configuration / acquittement

F-NET-003 | Poste opérateur | Serveur | HTTPS | montant/descendant | interface utilisateur

F-NET-004 | Serveur | Sauvegarde | SSH/rsync/API | montant | sauvegarde

F-NET-005 | Admin | Serveur | VPN/SSH | montant | administration

```

### 12.4 Principes de communication embarqué / serveur

**Exemples :**

```text

- transmission périodique des mesures ;

- transmission événementielle des alarmes ;

- acquittement serveur ;

- resynchronisation après perte réseau ;

- conservation de l’horodatage d’origine ;

- contrôle de cohérence des messages ;

- limitation des commandes descendantes ;

- fonctionnement local en cas de perte de communication.

```

### 12.5 Comportement en cas de perte réseau

Cette partie reprend les principes du dossier des modes, appliqués à l’architecture.

**Exemple :**

```text

En cas de perte de réseau :

- l’équipement embarqué détecte la perte de communication ;

- il passe en mode dégradé communication ;

- il conserve localement les données ;

- le serveur affiche l’équipement comme non joignable ;

- l’IHM signale l’état à l’opérateur ;

- la resynchronisation est lancée au retour réseau.

```

### 12.6 Sécurité réseau

Cette partie décrit les principes de sécurité réseau.

**Exemples :**

```text

- limitation des ports ouverts ;

- filtrage par pare-feu ;

- chiffrement des communications ;

- VPN pour l’administration distante ;

- séparation réseau test / production ;

- interdiction d’accès direct à la base de données depuis les postes opérateurs ;

- journalisation des connexions administratives.

```

### 12.7 Éléments renvoyés au dossier infrastructure

**Exemples :**

```text

- adresses IP ;

- VLAN ;

- règles pare-feu détaillées ;

- certificats ;

- configuration VPN ;

- ports exacts ;

- schémas réseau détaillés ;

- procédures d’exploitation réseau ;

- supervision réseau.

```

---

## 13. Architecture infrastructure, serveurs et environnements

### 13.1 Objet de l’architecture infrastructure

Cette partie décrit les grands choix d’infrastructure nécessaires au fonctionnement du système.

Elle couvre les serveurs, environnements, postes utilisateurs, stockage, sauvegarde, supervision, déploiement et exploitation.