Canevas 5 — Architecture système Conception globale » History » Revision 7
Revision 6 (Redmine Admin, 06/19/2026 02:49 AM) → Revision 7/10 (Redmine Admin, 06/19/2026 02:51 AM)
# 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.
### 13.2 Environnements prévus
**Exemples :**
```text
- environnement de développement ;
- environnement d’intégration ;
- environnement de test ;
- environnement de validation ;
- environnement de préproduction ;
- environnement de production ;
- environnement de maintenance ;
- environnement de sauvegarde / restauration.
```
### 13.3 Rôle des environnements
Cette partie précise l’usage de chaque environnement.
**Exemple :**
```text
Développement :
utilisé par les développeurs pour construire et tester localement les composants.
Intégration :
utilisé pour assembler les composants hardware, software et serveur.
Validation :
utilisé pour exécuter les procédures de validation fournisseur et client.
Production :
utilisé pour l’exploitation réelle du système.
Maintenance :
utilisé pour diagnostiquer, reproduire ou corriger des anomalies sans impacter la production.
```
### 13.4 Serveurs principaux
**Exemples :**
```text
SRV-APP : serveur applicatif
SRV-DB : serveur base de données
SRV-BKP : serveur de sauvegarde
SRV-MON : serveur de supervision
SRV-SAS : serveur ou zone d’échange contrôlée
SRV-TEST : serveur de test
SRV-PROD : serveur de production
```
### 13.5 Postes utilisateurs
Cette partie décrit les postes utilisés par les opérateurs, administrateurs ou mainteneurs.
**Exemples :**
```text
- poste opérateur local ;
- poste administrateur ;
- poste maintenance ;
- PC portable de diagnostic ;
- terminal industriel ;
- tablette si applicable.
```
### 13.6 Sauvegarde et restauration
Cette partie décrit les principes globaux.
**Exemples :**
```text
- sauvegarde de la base de données ;
- sauvegarde des fichiers de configuration ;
- sauvegarde des journaux critiques ;
- sauvegarde avant mise à jour ;
- restauration testée périodiquement ;
- séparation entre données opérationnelles et sauvegardes ;
- journalisation des sauvegardes.
```
### 13.7 Supervision infrastructure
Cette partie décrit la surveillance technique.
**Exemples :**
```text
- disponibilité serveur ;
- espace disque ;
- charge CPU / mémoire ;
- état des services applicatifs ;
- disponibilité base de données ;
- succès ou échec des sauvegardes ;
- état réseau ;
- certificats expirants ;
- erreurs applicatives.
```
### 13.8 Éléments renvoyés au dossier infrastructure détaillé
**Exemples :**
```text
- dimensionnement serveur ;
- système d’exploitation ;
- configuration des services ;
- scripts de déploiement ;
- schémas réseau détaillés ;
- règles de sauvegarde ;
- procédures de restauration ;
- supervision technique ;
- plan de reprise ;
- gestion des comptes.
```
---
## 14. Architecture des interfaces
### 14.1 Objet de la section interfaces
Cette partie identifie les interfaces principales du système.
Une interface doit être clairement définie dès l’architecture globale afin d’éviter les zones floues entre sous-systèmes ou entre responsabilités client/fournisseur.
### 14.2 Interfaces hardware
**Exemples :**
```text
IF-HW-001 : alimentation principale
IF-HW-002 : entrée capteur température
IF-HW-003 : entrée contact sec
IF-HW-004 : sortie relais
IF-HW-005 : port maintenance
IF-HW-006 : interface arrêt d’urgence
```
### 14.3 Interfaces software
**Exemples :**
```text
IF-SW-001 : API de réception des mesures
IF-SW-002 : API de consultation des alarmes
IF-SW-003 : API de configuration
IF-SW-004 : interface d’authentification
IF-SW-005 : export de données
IF-SW-006 : interface de diagnostic
```
### 14.4 Interfaces réseau
**Exemples :**
```text
IF-NET-001 : liaison équipement vers serveur
IF-NET-002 : liaison poste opérateur vers serveur
IF-NET-003 : liaison serveur vers sauvegarde
IF-NET-004 : accès administrateur distant
IF-NET-005 : liaison vers supervision externe
```
### 14.5 Interfaces utilisateur
**Exemples :**
```text
IF-IHM-001 : tableau de bord opérateur
IF-IHM-002 : écran alarmes
IF-IHM-003 : écran historique
IF-IHM-004 : écran configuration
IF-IHM-005 : écran maintenance
IF-IHM-006 : écran diagnostic
```
### 14.6 Interfaces documentaires ou fichiers
**Exemples :**
```text
IF-DOC-001 : fichier de configuration
IF-DOC-002 : fichier d’export des mesures
IF-DOC-003 : rapport d’alarmes
IF-DOC-004 : fichier de sauvegarde
IF-DOC-005 : rapport de diagnostic
```
### 14.7 Tableau de synthèse des interfaces
**Exemple :**
```text
ID interface | Source | Destination | Type | Description | Document détaillé
IF-NET-001 | Équipement | Serveur | Réseau | Transmission mesures/alarmes | Dossier interfaces
IF-HW-004 | Carte contrôle | Relais | Hardware | Commande sortie relais | Spéc. hardware
IF-SW-003 | IHM | Serveur | API | Modification configuration | Spéc. serveur/API
IF-DOC-004 | Serveur | Sauvegarde | Fichier | Export sauvegarde | Dossier infrastructure
```
---
## 15. Architecture de sécurité, sûreté et cybersécurité
### 15.1 Objet de l’architecture sécurité
Cette partie décrit les grands principes retenus pour assurer la sécurité des personnes, la sûreté de fonctionnement et la cybersécurité.
Elle ne remplace pas une analyse de risques détaillée, mais elle montre comment l’architecture prend en compte ces contraintes.
### 15.2 Principes de sécurité physique
**Exemples :**
```text
- état sûr en cas de défaut critique ;
- inhibition des commandes dangereuses ;
- arrêt d’urgence prioritaire ;
- séparation puissance / commande ;
- protections électriques ;
- accès physique limité aux zones sensibles ;
- procédure de consignation.
```
### 15.3 Principes de sûreté de fonctionnement
**Exemples :**
```text
- détection des défauts critiques ;
- journalisation des défauts ;
- modes dégradés ;
- maintien local de fonctions critiques ;
- watchdog matériel ou logiciel ;
- redémarrage contrôlé ;
- absence de perte silencieuse de données critiques ;
- retour au nominal sous conditions maîtrisées.
```
### 15.4 Principes de cybersécurité
**Exemples :**
```text
- authentification des utilisateurs ;
- gestion des rôles ;
- chiffrement des communications sensibles ;
- limitation des accès administrateur ;
- journalisation des actions sensibles ;
- séparation des environnements ;
- mise à jour contrôlée ;
- gestion des secrets ;
- sauvegarde protégée ;
- filtrage réseau.
```
### 15.5 Zones de confiance
Cette partie décrit les zones logiques ou physiques.
**Exemple :**
```text
Zone embarquée :
équipement installé sur site, accès physique restreint, communication limitée vers le serveur.
Zone serveur :
services applicatifs, base de données, sauvegardes, administration.
Zone opérateur :
postes utilisateurs accédant à l’interface via des droits limités.
Zone maintenance :
accès spécifique pour diagnostic, mise à jour ou intervention.
Zone externe :
réseau client, Internet, systèmes tiers.
```
### 15.6 Flux sensibles
Cette partie identifie les flux qui nécessitent une protection particulière.
**Exemples :**
```text
- identifiants utilisateurs ;
- commandes distantes ;
- modification de configuration ;
- mises à jour logicielles ;
- exports de données ;
- sauvegardes ;
- logs de sécurité ;
- données d’incident.
```
### 15.7 Exigences renvoyées aux documents détaillés
**Exemples :**
```text
- règles de mot de passe ;
- configuration TLS ;
- règles pare-feu ;
- gestion des certificats ;
- politique de logs ;
- gestion des rôles ;
- sécurisation des mises à jour ;
- procédures d’administration.
```
---
## 16. Architecture des modes de fonctionnement
### 16.1 Objet de cette section
Cette partie relie l’architecture système au dossier des modes de fonctionnement.
Elle explique quels sous-systèmes sont impliqués dans chaque mode et comment l’architecture permet les transitions.
### 16.2 Modes supportés par l’architecture
**Exemples :**
```text
- arrêt ;
- démarrage ;
- initialisation ;
- nominal ;
- maintenance ;
- diagnostic ;
- dégradé communication ;
- dégradé capteur ;
- dégradé stockage ;
- secours / état sûr ;
- mise à jour ;
- arrêt contrôlé ;
- arrêt d’urgence.
```
### 16.3 Responsabilités des sous-systèmes par mode
**Exemple :**
```text
Mode dégradé communication :
Software embarqué :
détecte la perte serveur, stocke localement les données, maintient les fonctions locales critiques.
Serveur :
marque l’équipement comme non joignable, historise l’événement.
IHM :
affiche l’état de perte communication.
Infrastructure :
fournit les moyens de diagnostic réseau.
Maintenance :
applique la procédure si la perte est prolongée.
```
### 16.4 Transitions supportées par l’architecture
Cette partie indique comment les transitions sont prises en charge.
**Exemple :**
```text
Transition nominal → dégradé communication :
- détection par CommunicationManager ;
- bascule d’état dans ModeManager ;
- activation du stockage local ;
- génération d’une alarme locale ;
- affichage côté serveur si absence prolongée ;
- retour automatique après resynchronisation complète.
```
### 16.5 Points d’attention architecturaux
**Exemples :**
```text
- éviter qu’un mode serveur indisponible bloque les fonctions locales critiques ;
- garantir que les commandes dangereuses restent inhibées en mode secours ;
- empêcher une mise à jour en cours de commande critique ;
- conserver les données nécessaires pendant un mode dégradé ;
- éviter les retours automatiques non maîtrisés depuis un état sûr.
```
---
## 17. Stratégie d’intégration
### 17.1 Objet de la stratégie d’intégration
Cette partie décrit comment les sous-systèmes seront assemblés progressivement.
La stratégie d’intégration doit être cohérente avec l’architecture. Elle évite de découvrir trop tard que les composants ne communiquent pas ou que les interfaces sont mal définies.
### 17.2 Ordre d’intégration proposé
**Exemple :**
```text
1. Intégration hardware de base.
2. Intégration firmware minimal.
3. Intégration capteurs / entrées.
4. Intégration sorties / actionneurs.
5. Intégration communication embarqué / serveur.
6. Intégration stockage local.
7. Intégration serveur / base de données.
8. Intégration IHM.
9. Intégration sauvegarde / restauration.
10. Intégration modes dégradés.
11. Intégration sécurité et droits.
12. Intégration système complet.
```
### 17.3 Bancs et environnements d’intégration
Cette partie décrit les moyens nécessaires.
**Exemples :**
```text
- banc hardware ;
- simulateur de capteurs ;
- charges simulées ;
- serveur de test ;
- base de données de test ;
- réseau isolé ;
- outil de capture réseau ;
- outil de génération d’événements ;
- environnement de validation ;
- jeu de données de test.
```
### 17.4 Interfaces critiques à intégrer en priorité
**Exemples :**
```text
- interface équipement / serveur ;
- interface firmware / capteurs ;
- interface firmware / stockage local ;
- interface serveur / base de données ;
- interface serveur / IHM ;
- interface sauvegarde / restauration ;
- interface droits utilisateurs / actions sensibles.
```
### 17.5 Critères d’entrée en intégration
**Exemples :**
```text
- composants identifiés et versionnés ;
- interfaces spécifiées ;
- environnement d’intégration disponible ;
- configuration de test définie ;
- tests unitaires de base réalisés ;
- anomalies bloquantes connues traitées ;
- moyens de mesure disponibles.
```
### 17.6 Critères de sortie d’intégration
**Exemples :**
```text
- interfaces principales vérifiées ;
- flux nominaux fonctionnels ;
- modes dégradés principaux testés ;
- anomalies bloquantes corrigées ;
- versions intégrées identifiées ;
- rapport d’intégration produit ;
- passage possible aux tests système.
```
---
## 18. Stratégie de vérification de l’architecture
### 18.1 Objectif de la vérification d’architecture
Cette partie décrit comment on vérifiera que l’architecture répond aux exigences.
Il ne s’agit pas encore de tester chaque détail, mais de vérifier que l’organisation retenue est cohérente, complète et testable.
### 18.2 Revues d’architecture
**Exemples de points à vérifier :**
```text
- toutes les exigences système importantes sont allouées ;
- les interfaces principales sont identifiées ;
- les responsabilités des sous-systèmes sont claires ;
- les modes dégradés sont supportés ;
- les contraintes de sécurité sont prises en compte ;
- les besoins de maintenance sont couverts ;
- les environnements de test et production sont identifiés ;
- les données critiques sont protégées ;
- les flux réseau nécessaires sont connus.
```
### 18.3 Prototypage ou preuve de concept
Cette partie indique si certains choix doivent être validés par expérimentation.
**Exemples :**
```text
- test de communication embarqué / serveur ;
- test de stockage local en perte réseau ;
- test de performance d’acquisition ;
- test de débit réseau ;
- test de sauvegarde / restauration ;
- test de mise à jour firmware ;
- test de compatibilité avec un équipement tiers.
```
### 18.4 Tests d’intégration associés
Cette partie relie l’architecture aux tests.
**Exemple :**
```text
Choix architectural :
maintien local des fonctions critiques en cas de perte serveur.
Test associé :
couper la communication avec le serveur et vérifier que l’équipement continue l’acquisition, conserve les données localement et resynchronise au retour réseau.
```
### 18.5 Critères d’acceptation de l’architecture
**Exemples :**
```text
L’architecture est acceptable si :
- elle couvre toutes les exigences critiques ;
- elle identifie tous les sous-systèmes principaux ;
- elle définit les interfaces majeures ;
- elle permet les modes nominaux et dégradés prévus ;
- elle est compatible avec les contraintes d’exploitation ;
- elle est testable ;
- elle est maintenable ;
- elle est documentée de manière suffisante pour lancer les conceptions détaillées.
```
---
## 19. Matrices de synthèse
### 19.1 Matrice exigences / sous-systèmes
Cette matrice relie les exigences aux sous-systèmes chargés de les satisfaire.
**Exemple :**
```text
Exigence | HW | SW embarqué | Serveur | DB | IHM | Infra | Procédure
SYS-FCT-001 | X | X | | | | |
SYS-COM-004 | | X | X | X | X | X |
SYS-ALM-002 | | X | X | X | X | |
SYS-SAV-001 | | | X | X | | X | X
```
### 19.2 Matrice fonctions / interfaces
Cette matrice relie les fonctions aux interfaces nécessaires.
**Exemple :**
```text
Fonction | Interfaces nécessaires
Acquisition mesures | IF-HW-002, IF-HW-003
Transmission serveur | IF-NET-001, IF-SW-001
Affichage alarmes | IF-SW-002, IF-IHM-002
Configuration | IF-SW-003, IF-IHM-004
Sauvegarde | IF-DOC-004, IF-NET-003
```
### 19.3 Matrice modes / sous-systèmes
Cette matrice indique quels sous-systèmes sont impliqués dans chaque mode.
**Exemple :**
```text
Mode | HW | SW embarqué | Serveur | IHM | Infrastructure | Procédure
Nominal | X | X | X | X | X |
Dégradé communication | X | X | X | X | X | X
Maintenance | X | X | X | X | | X
Secours | X | X | | X | | X
Mise à jour | | X | X | X | X | X
```
### 19.4 Matrice interfaces / responsabilités
Cette matrice clarifie les responsabilités.
**Exemple :**
```text
Interface | Responsable source | Responsable destination | Responsable spécification | Responsable test
IF-NET-001 | équipe embarqué | équipe serveur | architecte système | équipe intégration
IF-HW-004 | équipe hardware | équipe intégration | responsable hardware | équipe test hardware
IF-SW-003 | équipe IHM | équipe serveur | responsable applicatif | équipe test logiciel
```
### 19.5 Matrice choix architecturaux / justification
Cette matrice documente les décisions importantes.
**Exemple :**
```text
Choix | Justification | Alternative rejetée | Impact | Validation prévue
Stockage local embarqué | fonctionnement en perte réseau | stockage serveur seul | mémoire embarquée | test coupure réseau
Serveur centralisé | historisation multi-équipements | fichiers locaux | infrastructure serveur | test charge / sauvegarde
Interface web | accès multi-postes | application lourde | navigateur requis | test ergonomie
```
---
## 20. Choix architecturaux structurants
### 20.1 Objet de cette section
Cette partie documente les décisions importantes prises pendant la conception globale.
Il est important de conserver la justification des choix, car elle permettra de comprendre plus tard pourquoi une solution a été retenue plutôt qu’une autre.
### 20.2 Choix hardware structurants
**Exemples :**
```text
- utilisation d’une carte embarquée dédiée ;
- séparation entrées/sorties critiques ;
- ajout d’un stockage local ;
- alimentation secourue ;
- choix d’un coffret industriel ;
- ajout d’un port de maintenance.
```
**Exemple rédigé :**
> Un stockage local est intégré à l’équipement afin de garantir la conservation des données en cas de perte de communication avec le serveur. Ce choix permet de satisfaire l’exigence de fonctionnement dégradé communication.
### 20.3 Choix software structurants
**Exemples :**
```text
- architecture modulaire ;
- gestion centralisée des modes ;
- séparation acquisition / communication / stockage ;
- journalisation systématique ;
- watchdog ;
- file de messages persistante ;
- protocole de communication avec acquittement ;
- gestion de configuration versionnée.
```
### 20.4 Choix infrastructure structurants
**Exemples :**
```text
- séparation test / production ;
- base de données centralisée ;
- sauvegarde automatisée ;
- serveur applicatif distinct du serveur de sauvegarde ;
- accès administrateur via VPN ;
- supervision des services ;
- journalisation centralisée.
```
### 20.5 Alternatives étudiées
Cette partie décrit les alternatives importantes qui ont été écartées.
**Exemple :**
```text
Alternative :
traiter toutes les alarmes uniquement côté serveur.
Raison du rejet :
en cas de perte de communication, les alarmes critiques ne seraient plus détectées localement.
Choix retenu :
détection locale des alarmes critiques dans le logiciel embarqué, consolidation serveur pour l’historisation et l’affichage.
```
### 20.6 Impacts des choix retenus
Cette partie décrit les conséquences des choix d’architecture.
**Exemples :**
```text
- augmentation de la mémoire embarquée nécessaire ;
- nécessité de tests de resynchronisation ;
- besoin d’une procédure de sauvegarde ;
- création d’interfaces supplémentaires ;
- besoin d’un outil de diagnostic ;
- complexité accrue de l’intégration ;
- meilleure robustesse en mode dégradé.
```
---
## 21. Contraintes, limites et points ouverts
### 21.1 Contraintes techniques connues
Cette partie liste les contraintes à respecter dans la suite du projet.
**Exemples :**
```text
- capacité mémoire embarquée limitée ;
- bande passante réseau limitée ;
- impossibilité d’accès Internet direct ;
- serveur imposé par le client ;
- protocole imposé par un équipement tiers ;
- température d’installation élevée ;
- faible disponibilité des techniciens sur site.
```
### 21.2 Limites de l’architecture
Cette partie précise les limites acceptées.
**Exemples :**
```text
- pas de redondance serveur dans la première version ;
- autonomie locale limitée par la capacité de stockage embarquée ;
- nombre maximal d’équipements connectés ;
- maintenance distante limitée à certaines opérations ;
- restauration nécessitant une intervention administrateur.
```
### 21.3 Risques architecturaux
Cette partie identifie les risques liés à l’architecture.
**Exemples :**
```text
- protocole tiers non stabilisé ;
- volume de données supérieur aux hypothèses ;
- stockage local insuffisant en cas de coupure longue ;
- performances serveur insuffisantes ;
- contraintes cybersécurité non encore validées ;
- difficultés d’intégration hardware/software ;
- indisponibilité d’un composant matériel.
```
### 21.4 Mesures de réduction des risques
**Exemples :**
```text
- prototype de communication ;
- test de charge serveur ;
- test de coupure réseau longue durée ;
- validation précoce du protocole tiers ;
- choix d’un stockage local dimensionné avec marge ;
- revue cybersécurité ;
- banc d’intégration hardware/software.
```
### 21.5 Points ouverts
Cette partie liste les décisions non encore prises.
**Exemple :**
```text
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-ARCH-001 | Protocole final | MQTT ou HTTPS à confirmer | Architecte / client | Avant spéc. interfaces | Communication | Ouvert
PO-ARCH-002 | Hébergement | Serveur client ou serveur fournisseur | Client | Avant dossier infrastructure | Déploiement | Ouvert
PO-ARCH-003 | Durée stockage local | Durée minimale en perte réseau à confirmer | Client | Avant choix mémoire | Hardware / software | Ouvert
```
---
## 22. Traçabilité
### 22.1 Traçabilité avec la spécification globale
Cette partie montre que l’architecture couvre les exigences système.
**Exemple :**
```text
SYS-COM-004 — Maintien local en perte réseau
Éléments architecturaux associés :
- logiciel embarqué ;
- stockage local ;
- CommunicationManager ;
- LocalStorageManager ;
- serveur applicatif ;
- IHM d’état communication ;
- procédure de resynchronisation.
```
### 22.2 Traçabilité vers les spécifications détaillées
Cette partie indique quels documents détailleront les éléments d’architecture.
**Exemple :**
```text
Élément architectural :
stockage local embarqué.
Documents dérivés :
- spécification détaillée software embarqué ;
- conception détaillée software ;
- spécification hardware si support mémoire spécifique ;
- procédures de tests d’intégration communication ;
- dossier des modes dégradés communication.
```
### 22.3 Traçabilité vers les tests
Cette partie relie l’architecture aux tests d’intégration et système.
**Exemple :**
```text
Choix architectural :
séparation entre équipement embarqué et serveur applicatif.
Tests associés :
- test interface équipement / serveur ;
- test perte serveur ;
- test resynchronisation ;
- test affichage état non joignable ;
- test stockage local ;
- test reprise après redémarrage.
```
### 22.4 Matrice de traçabilité architecture
**Structure recommandée :**
```text
Exigence système
Élément architectural
Sous-système responsable
Interface concernée
Document détaillé
Test d’intégration
Test système
Commentaire
```
---
## 23. Critères d’acceptation du document d’architecture
### 23.1 Complétude
Cette partie définit les critères permettant de considérer le document comme complet.
**Exemples :**
```text
Le document d’architecture est considéré comme complet si :
- tous les sous-systèmes principaux sont identifiés ;
- les responsabilités de chaque sous-système sont décrites ;
- les fonctions principales sont allouées ;
- les interfaces principales sont identifiées ;
- les flux majeurs sont décrits ;
- les modes de fonctionnement sont supportés ;
- les choix structurants sont justifiés ;
- les contraintes d’infrastructure sont prises en compte ;
- les besoins de tests d’intégration sont identifiés ;
- les points ouverts sont listés.
```
### 23.2 Cohérence
Cette partie définit les critères de cohérence.
**Exemples :**
```text
Le document ne doit pas contenir :
- de fonction non allouée ;
- d’interface majeure non identifiée ;
- de responsabilité ambiguë ;
- de mode dégradé non supporté ;
- de choix technique contradictoire avec la spécification globale ;
- de dépendance non maîtrisée ;
- de flux réseau non justifié ;
- d’exigence critique sans solution architecturale.
```
### 23.3 Testabilité
Cette partie vérifie que l’architecture pourra être testée.
**Exemples :**
```text
L’architecture est testable si :
- les interfaces sont identifiables ;
- les sous-systèmes peuvent être intégrés progressivement ;
- les flux critiques peuvent être observés ;
- les modes dégradés peuvent être simulés ;
- les journaux nécessaires au diagnostic existent ;
- les tests d’intégration peuvent être définis à partir des interfaces.
```
### 23.4 Maintenabilité
Cette partie vérifie que l’architecture permet l’exploitation et la maintenance.
**Exemples :**
```text
L’architecture est maintenable si :
- les composants sont identifiables ;
- les versions peuvent être connues ;
- les logs sont accessibles ;
- les configurations sont sauvegardables ;
- les composants remplaçables sont identifiés ;
- les procédures de diagnostic sont possibles ;
- les environnements de test et production sont distingués.
```
### 23.5 Validation du document
Cette partie précise les revues nécessaires.
**Exemple :**
```text
Le document d’architecture doit être relu par :
- l’ingénieur système ;
- le responsable hardware ;
- le responsable logiciel embarqué ;
- le responsable serveur / application ;
- le responsable infrastructure ;
- le responsable cybersécurité ;
- le responsable intégration ;
- le responsable validation ;
- le représentant client si l’architecture est contractuelle.
```
---
## 24. Annexes
### 24.1 Synoptiques d’architecture
Cette annexe contient les schémas d’architecture générale.
**Exemples :**
```text
- synoptique système ;
- synoptique hardware ;
- synoptique software embarqué ;
- synoptique serveur ;
- synoptique réseau ;
- synoptique sauvegarde ;
- synoptique maintenance.
```
### 24.2 Liste des sous-systèmes
Cette annexe reprend la liste complète des sous-systèmes avec leur identifiant, rôle et responsable.
**Exemple :**
```text
ID | Nom | Rôle | Responsable | Document détaillé
SS-SW-001 | Logiciel embarqué | Acquisition, modes, communication | Équipe firmware | Spéc. SW embarqué
SS-SRV-001 | Serveur applicatif | Réception, API, traitement | Équipe backend | Spéc. serveur
SS-INF-001 | Infrastructure | Serveurs, réseau, sauvegarde | Équipe infra | Dossier infrastructure
```
### 24.3 Liste des interfaces
Cette annexe reprend la liste complète des interfaces identifiées.
### 24.4 Matrices d’allocation
Cette annexe regroupe les matrices d’allocation exigences / fonctions / sous-systèmes.
### 24.5 Liste des flux
Cette annexe reprend la liste des flux réseau, données, commande, maintenance et sauvegarde.
### 24.6 Liste des choix architecturaux
Cette annexe centralise les décisions importantes et leurs justifications.
### 24.7 Liste des points ouverts
Cette annexe reprend tous les points ouverts, responsables et échéances.
### 24.8 Glossaire
Cette annexe définit les termes spécifiques à l’architecture.
### 24.9 Historique des décisions
Cette annexe conserve les décisions structurantes.
**Exemple :**
```text
DEC-ARCH-001 :
La détection des alarmes critiques est réalisée localement dans l’équipement embarqué.
Justification :
maintien de la capacité de détection en cas de perte de communication serveur.
Impact :
nécessite une logique d’alarme embarquée, un stockage local et des tests de resynchronisation.
```