CANEVAS DES DOCUMENTS DU PROJET

# Canevas 4 — Dossier des modes de fonctionnement

## 1. Objet du document

### 1.1 Finalité du dossier des modes de fonctionnement

Cette partie précise l’objectif du document.

Le dossier des modes de fonctionnement décrit les différents états dans lesquels le système peut se trouver au cours de sa vie opérationnelle : arrêt, démarrage, initialisation, fonctionnement nominal, maintenance, diagnostic, mode dégradé, mode secours, mise à jour, arrêt contrôlé, arrêt d’urgence, etc.

Il précise, pour chaque mode, les fonctions actives, les fonctions inhibées, les conditions d’entrée, les conditions de sortie, les événements déclencheurs, les alarmes associées, les actions autorisées et les comportements attendus.

Ce document est essentiel pour les systèmes comportant du hardware, du software embarqué, une infrastructure serveur, des communications réseau et des interactions opérateur. Il permet d’éviter les ambiguïtés sur le comportement du système dans les cas non nominaux.

**Exemple :**

> Le présent document a pour objectif de décrire les modes de fonctionnement du système, les transitions entre modes, les conditions d’entrée et de sortie de chaque mode, ainsi que le comportement attendu en fonctionnement nominal, dégradé, maintenance, secours et arrêt.

### 1.2 Positionnement dans le cycle en V

Cette partie situe le dossier des modes dans le cycle en V.

Le dossier des modes est issu de la spécification globale. Il alimente les spécifications détaillées, la conception logicielle, la conception hardware, les procédures de test d’intégration et le dossier de validation.

Il est particulièrement important pour préparer :

```text

- les machines d’états du logiciel embarqué ;

- les séquences de démarrage et d’arrêt ;

- les comportements en cas de défaut ;

- les modes dégradés ;

- les tests d’intégration hardware/software ;

- les scénarios de validation client ;

- les procédures de maintenance et diagnostic.

```

Dans le cycle en V, ce document est vérifié par les tests d’intégration, les tests système et les scénarios de validation associés aux modes nominaux et dégradés.

```text

Spécification globale

        ↓

Dossier des modes de fonctionnement

        ↓

Spécifications détaillées

        ↓

Conception software / hardware / infrastructure

        ↓

Réalisation

        ↑

Tests unitaires

        ↑

Tests d’intégration

        ↑

Tests système

        ↑

Validation des modes nominaux et dégradés

```

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

Cette partie précise la différence entre la spécification globale et le dossier des modes.

La spécification globale identifie les modes principaux et formule les exigences générales. Le dossier des modes décrit précisément le comportement attendu dans chaque mode.

**Exemple :**

```text

Spécification globale :

Le système doit fonctionner en mode dégradé en cas de perte de communication avec le serveur.

Dossier des modes :

Le mode dégradé communication est activé lorsque le système ne reçoit plus d’acquittement serveur pendant plus de 120 secondes.

Dans ce mode, l’acquisition locale reste active, les données sont stockées localement, une alarme est affichée à l’opérateur, les commandes distantes sont interdites et la resynchronisation est déclenchée automatiquement au retour de la communication.

```

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

Cette partie précise que le dossier des modes ne décrit pas encore nécessairement la solution logicielle interne.

Le dossier des modes décrit le comportement attendu du système. La conception détaillée expliquera ensuite comment ce comportement est réalisé techniquement : machine d’états, modules logiciels, flags internes, timers, files d’événements, tables de transitions, services de communication, etc.

**Exemple :**

```text

Dossier des modes :

Le système doit passer en mode maintenance lorsqu’un utilisateur habilité en fait la demande et qu’aucune commande critique n’est en cours.

Conception détaillée :

La transition NOMINAL → MAINTENANCE est gérée par le module ModeManager.

Elle nécessite le droit ROLE_MAINTENANCE, l’état CommandManager.IDLE et la confirmation utilisateur.

```

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

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

Le dossier des modes est généralement rédigé par l’ingénieur système ou le responsable fonctionnel, avec contribution des responsables logiciel embarqué, hardware, infrastructure, sécurité, maintenance et validation.

**Exemple :**

```text

Rédaction    : ingénieur système / responsable fonctionnel

Contribution : logiciel embarqué, hardware, infrastructure, maintenance, validation, cybersécurité

Relecture    : chef de projet technique, qualité, responsable tests

Approbation  : fournisseur et client si le document est contractuel ou critique pour la recette

```

---

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

### 2.1 Documents d’entrée

Cette partie liste les documents utilisés pour établir les modes de fonctionnement.

**Exemples :**

```text

- Cahier des charges / expression du besoin

- Dossier de validation client

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

- Analyse de risques préliminaire

- Architecture système préliminaire

- Contraintes d’exploitation

- Contraintes de maintenance

- Contraintes de sécurité et sûreté

- Contraintes cybersécurité

- Documentation des équipements tiers

```

### 2.2 Documents applicables

Cette partie liste les documents que le dossier des modes doit respecter.

**Exemples :**

```text

- Référentiel qualité projet

- Normes de sécurité applicables

- Procédures client d’exploitation

- Procédures client de maintenance

- Exigences réglementaires

- Exigences contractuelles

- Référentiel de codification des alarmes

```

### 2.3 Documents produits à partir de ce dossier

Cette partie liste les documents qui utiliseront le dossier des modes comme entrée.

**Exemples :**

```text

- Spécification détaillée logiciel embarqué

- Spécification détaillée interface opérateur

- Spécification détaillée serveur

- Architecture système

- Conception logicielle détaillée

- Plan de vérification

- Procédures de tests d’intégration

- Procédures de tests système

- Dossier de validation client

- Manuel utilisateur

- Manuel maintenance

```

### 2.4 Gestion des versions

Cette partie précise que toute modification d’un mode peut avoir un impact important.

Une modification dans les modes de fonctionnement peut entraîner des changements dans les spécifications détaillées, la conception, les tests et la validation. Elle doit donc être gérée sous configuration.

**Exemple :**

> Toute modification d’une condition de transition entre modes doit faire l’objet d’une analyse d’impact sur la conception logicielle, les procédures de tests d’intégration, les scénarios de validation et les procédures de maintenance.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

Cette partie définit les termes utilisés pour décrire les modes.

**Exemples :**

```text

Mode :

État stable ou transitoire du système dans lequel un ensemble défini de fonctions est actif, inhibé ou modifié.

Mode nominal :

Mode dans lequel le système remplit l’ensemble de ses fonctions principales dans des conditions normales.

Mode dégradé :

Mode dans lequel le système conserve une partie de ses fonctions malgré la perte, la défaillance ou l’indisponibilité d’une ressource.

Mode secours :

Mode destiné à maintenir ou atteindre un état sûr lorsque les conditions nominales ne sont plus garanties.

Transition :

Passage d’un mode à un autre à la suite d’un événement, d’une condition ou d’une commande.

État sûr :

État dans lequel le système ne présente pas de risque inacceptable pour les personnes, les biens, l’environnement ou les données critiques.

```

### 3.2 Acronymes

Cette partie liste les acronymes utilisés.

**Exemples :**

```text

IHM : Interface Homme-Machine

API : Application Programming Interface

BMS : Battery Management System

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

VPN : Virtual Private Network

CEM : Compatibilité électromagnétique

```

### 3.3 Convention d’identification des modes

Cette partie définit la codification des modes.

**Exemple :**

```text

MOD-ARRET-001    : mode arrêt

MOD-DEM-001      : mode démarrage

MOD-INIT-001     : mode initialisation

MOD-NOM-001      : mode nominal

MOD-MAINT-001    : mode maintenance

MOD-DIAG-001     : mode diagnostic

MOD-DEG-COM-001  : mode dégradé communication

MOD-DEG-CAPT-001 : mode dégradé capteur

MOD-SECOURS-001  : mode secours

MOD-MAJ-001      : mode mise à jour

MOD-AU-001       : mode arrêt d’urgence

```

### 3.4 Convention d’identification des transitions

Cette partie définit la codification des transitions.

**Exemple :**

```text

TR-001 : arrêt vers démarrage

TR-002 : démarrage vers initialisation

TR-003 : initialisation vers nominal

TR-004 : nominal vers dégradé communication

TR-005 : dégradé communication vers nominal

TR-006 : nominal vers maintenance

TR-007 : maintenance vers nominal

TR-008 : nominal vers arrêt contrôlé

TR-009 : tout mode vers arrêt d’urgence

```

### 3.5 Convention de description d’un mode

Cette partie précise le format utilisé pour décrire chaque mode.

Chaque mode devrait être décrit selon une structure constante :

```text

- identifiant du mode ;

- nom du mode ;

- objectif ;

- conditions d’entrée ;

- conditions de sortie ;

- fonctions actives ;

- fonctions inhibées ;

- actions autorisées ;

- actions interdites ;

- alarmes associées ;

- données enregistrées ;

- comportement des interfaces ;

- conditions de retour au nominal ;

- tests associés.

```

---

## 4. Vue générale des modes de fonctionnement

### 4.1 Liste générale des modes

Cette partie liste tous les modes identifiés pour le système.

**Exemple :**

```text

MOD-ARRET-001      : mode arrêt

MOD-DEM-001        : mode démarrage

MOD-INIT-001       : mode initialisation

MOD-NOM-001        : mode nominal

MOD-MAINT-001      : mode maintenance

MOD-DIAG-001       : mode diagnostic

MOD-DEG-COM-001    : mode dégradé communication

MOD-DEG-CAPT-001   : mode dégradé capteur

MOD-DEG-STOCK-001  : mode dégradé stockage

MOD-SECOURS-001    : mode secours

MOD-MAJ-001        : mode mise à jour

MOD-ARRET-CTRL-001 : mode arrêt contrôlé

MOD-AU-001         : mode arrêt d’urgence

```

### 4.2 Classification des modes

Cette partie classe les modes selon leur nature.

**Exemple :**

```text

Modes opérationnels :

- mode nominal ;

- mode maintenance ;

- mode diagnostic.

Modes transitoires :

- mode démarrage ;

- mode initialisation ;

- mode arrêt contrôlé ;

- mode mise à jour.

Modes dégradés :

- perte communication ;

- capteur indisponible ;

- stockage saturé ;

- serveur indisponible ;

- perte de synchronisation horaire.

Modes de sécurité :

- mode secours ;

- arrêt d’urgence ;

- état sûr.

```

### 4.3 Diagramme général des modes

Cette partie doit contenir un diagramme d’états ou un synoptique.

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

**Exemple :**

```text

[Arrêt]

   ↓ commande démarrage

[Démarrage]

   ↓ contrôles OK

[Initialisation]

   ↓ configuration valide

[Nominal]

   ├── perte réseau → [Dégradé communication]

   ├── défaut capteur → [Dégradé capteur]

   ├── demande habilitée → [Maintenance]

   ├── demande diagnostic → [Diagnostic]

   ├── demande arrêt → [Arrêt contrôlé]

   └── défaut critique → [Secours / état sûr]

[Dégradé communication]

   ↓ communication rétablie + synchronisation OK

[Nominal]

[Maintenance]

   ↓ fin maintenance + contrôles OK

[Nominal]

[Tout mode]

   ↓ événement critique

[Arrêt d’urgence / état sûr]

```

### 4.4 Priorité entre modes

Cette partie décrit les règles de priorité lorsque plusieurs conditions sont vraies simultanément.

Cette section est très importante pour éviter les comportements ambigus.

**Exemple :**

```text

Priorité décroissante :

1. Arrêt d’urgence

2. État sûr / mode secours

3. Défaut critique

4. Mode maintenance

5. Mode dégradé

6. Mode nominal

7. Mode diagnostic

8. Mode mise à jour

```

**Exemple explicatif :**

> Si une demande de maintenance est active mais qu’un défaut critique est détecté, le système doit donner priorité au passage en état sûr. La sécurité prime sur les opérations de maintenance.

---

## 5. Mode arrêt

### 5.1 Objectif du mode arrêt

Cette partie décrit la finalité du mode arrêt.

Le mode arrêt correspond à l’état dans lequel le système n’exécute pas ses fonctions opérationnelles principales. Il peut néanmoins conserver certaines fonctions minimales : alimentation de veille, mémoire persistante, horloge, surveillance minimale ou capacité de démarrage.

**Exemple :**

> En mode arrêt, le système ne réalise ni acquisition opérationnelle, ni commande active, ni transmission périodique. Il conserve toutefois sa configuration persistante et reste capable de démarrer si les conditions nécessaires sont satisfaites.

### 5.2 Conditions d’entrée en mode arrêt

Cette partie décrit les situations conduisant au mode arrêt.

**Exemples :**

```text

- absence d’alimentation principale ;

- commande d’arrêt utilisateur ;

- arrêt contrôlé terminé ;

- première mise sous tension avant démarrage ;

- arrêt après maintenance ;

- défaut bloquant nécessitant une intervention manuelle.

```

### 5.3 Fonctions actives en mode arrêt

Cette partie précise les fonctions éventuellement maintenues.

**Exemples :**

```text

- conservation de la configuration ;

- conservation des journaux ;

- maintien de l’horloge si alimentation de secours ;

- détection d’une commande de démarrage ;

- surveillance minimale d’alimentation ;

- affichage local d’un état arrêté si prévu.

```

### 5.4 Fonctions inhibées en mode arrêt

Cette partie liste les fonctions désactivées.

**Exemples :**

```text

- acquisition périodique ;

- commande automatique ;

- transmission périodique ;

- génération d’alarmes non critiques ;

- synchronisation serveur ;

- actions opérateur avancées.

```

### 5.5 Conditions de sortie du mode arrêt

Cette partie décrit les conditions permettant de quitter le mode arrêt.

**Exemple :**

```text

Le système peut quitter le mode arrêt si :

- l’alimentation principale est disponible ;

- aucune condition d’arrêt d’urgence n’est active ;

- une commande de démarrage valide est reçue ;

- la configuration minimale nécessaire est disponible.

```

### 5.6 Tests associés

Cette partie indique les tests permettant de vérifier le mode arrêt.

**Exemples :**

```text

- test de conservation de configuration après arrêt ;

- test d’absence de commande active en mode arrêt ;

- test de démarrage depuis le mode arrêt ;

- test de comportement après coupure puis retour alimentation.

```

---

## 6. Mode démarrage

### 6.1 Objectif du mode démarrage

Cette partie décrit le rôle du mode démarrage.

Le mode démarrage correspond à la séquence initiale permettant de passer d’un état arrêté ou hors tension à un état initialisé. Il permet de vérifier les préconditions nécessaires au fonctionnement.

**Exemple :**

> Le mode démarrage permet au système d’initialiser les ressources matérielles et logicielles nécessaires, de vérifier la configuration, de contrôler l’état minimal des interfaces et de préparer le passage en mode nominal ou en mode dégradé.

### 6.2 Conditions d’entrée en mode démarrage

**Exemples :**

```text

- mise sous tension ;

- commande de démarrage utilisateur ;

- redémarrage logiciel ;

- redémarrage après mise à jour ;

- redémarrage après coupure d’alimentation.

```

### 6.3 Séquence attendue de démarrage

Cette partie décrit les étapes attendues.

**Exemple :**

```text

1. Détection de l’alimentation.

2. Initialisation du hardware.

3. Initialisation du logiciel embarqué.

4. Chargement de la configuration.

5. Vérification de la configuration.

6. Initialisation des interfaces de communication.

7. Vérification des capteurs essentiels.

8. Vérification du stockage local.

9. Publication de l’état de démarrage.

10. Passage vers initialisation, nominal ou dégradé selon les résultats.

```

### 6.4 Contrôles réalisés au démarrage

Cette partie précise les vérifications à effectuer.

**Exemples :**

```text

- validité de la configuration ;

- disponibilité mémoire ;

- état du stockage local ;

- cohérence de l’horloge ;

- état des capteurs critiques ;

- disponibilité du module de communication ;

- version logicielle ;

- intégrité des paramètres critiques ;

- état des sorties de commande.

```

### 6.5 Défauts détectables au démarrage

Cette partie liste les défauts pouvant être détectés dès le démarrage.

**Exemples :**

```text

- configuration absente ou invalide ;

- capteur critique absent ;

- stockage local inaccessible ;

- version logicielle incohérente ;

- erreur d’initialisation communication ;

- défaut matériel bloquant ;

- alimentation hors plage ;

- mémoire insuffisante.

```

### 6.6 Sorties possibles du mode démarrage

Cette partie décrit les modes vers lesquels le système peut basculer.

**Exemples :**

```text

Démarrage → Initialisation :

si les contrôles minimaux sont satisfaits.

Démarrage → Nominal :

si l’initialisation est incluse dans la séquence de démarrage et que tout est valide.

Démarrage → Dégradé :

si un défaut non bloquant est détecté.

Démarrage → État sûr :

si un défaut critique est détecté.

Démarrage → Arrêt :

si les conditions minimales de fonctionnement ne sont pas satisfaites.

```

### 6.7 Tests associés

**Exemples :**

```text

- démarrage avec configuration valide ;

- démarrage avec configuration invalide ;

- démarrage avec capteur critique absent ;

- démarrage sans serveur disponible ;

- démarrage après coupure d’alimentation ;

- démarrage après mise à jour logicielle.

```

---

## 7. Mode initialisation

### 7.1 Objectif du mode initialisation

Cette partie décrit la différence entre démarrage et initialisation.

Le démarrage correspond à l’entrée en fonctionnement du système. L’initialisation correspond à la préparation fonctionnelle du système : chargement des paramètres, mise en état des modules, synchronisation éventuelle, vérification des interfaces, préparation des buffers, initialisation des communications et des états internes.

**Exemple :**

> Le mode initialisation permet de préparer le système à son fonctionnement opérationnel en configurant les modules, en initialisant les états internes et en vérifiant les ressources nécessaires au mode nominal.

### 7.2 Conditions d’entrée

**Exemples :**

```text

- démarrage terminé ;

- redémarrage logiciel ;

- retour après mise à jour ;

- réinitialisation demandée par un utilisateur habilité ;

- sortie d’un état sûr après intervention.

```

### 7.3 Actions réalisées

**Exemples :**

```text

- chargement des seuils ;

- initialisation de l’état des alarmes ;

- synchronisation horaire ;

- initialisation de la file locale de stockage ;

- vérification des communications ;

- lecture des versions des modules ;

- remise à zéro contrôlée de variables temporaires ;

- préparation de l’interface opérateur.

```

### 7.4 Conditions de succès

**Exemples :**

```text

- configuration chargée ;

- modules critiques initialisés ;

- stockage accessible ;

- état des entrées/sorties connu ;

- horodatage disponible ou état d’horloge dégradé déclaré ;

- communication disponible ou mode dégradé communication activé.

```

### 7.5 Conditions d’échec

**Exemples :**

```text

- configuration absente ;

- corruption des paramètres critiques ;

- initialisation impossible d’un module essentiel ;

- défaut matériel critique ;

- stockage local inaccessible si nécessaire au fonctionnement ;

- impossibilité de garantir un état sûr.

```

### 7.6 Tests associés

**Exemples :**

```text

- initialisation nominale ;

- initialisation avec serveur indisponible ;

- initialisation avec horloge non synchronisée ;

- initialisation avec stockage presque saturé ;

- initialisation après restauration de configuration.

```

---

## 8. Mode nominal

### 8.1 Objectif du mode nominal

Cette partie décrit le fonctionnement normal du système.

Le mode nominal est le mode dans lequel le système réalise l’ensemble des fonctions principales prévues : acquisition, traitement, communication, affichage, journalisation, gestion des alarmes et supervision.

**Exemple :**

> En mode nominal, le système acquiert les données prévues, surveille les seuils, génère les alarmes nécessaires, transmet les informations au serveur, met à jour l’interface opérateur et conserve les historiques prévus.

### 8.2 Conditions d’entrée en mode nominal

**Exemples :**

```text

- initialisation réussie ;

- configuration valide ;

- absence de défaut bloquant ;

- ressources critiques disponibles ;

- conditions de sécurité satisfaites ;

- communication disponible si elle est obligatoire pour le nominal ;

- retour d’un mode dégradé après correction du défaut.

```

### 8.3 Fonctions actives

**Exemples :**

```text

- acquisition des mesures ;

- surveillance des seuils ;

- génération des alarmes ;

- transmission serveur ;

- stockage local temporaire ;

- affichage opérateur ;

- journalisation ;

- diagnostic de base ;

- supervision de communication ;

- sauvegarde selon périodicité prévue.

```

### 8.4 Fonctions interdites ou limitées

Même en mode nominal, certaines fonctions peuvent être interdites ou réservées à des profils particuliers.

**Exemples :**

```text

- modification de seuils critiques sans habilitation ;

- arrêt d’un équipement sans confirmation ;

- accès aux diagnostics avancés sans rôle maintenance ;

- mise à jour logicielle pendant une commande critique ;

- restauration de configuration sans passage préalable en maintenance.

```

### 8.5 Comportement attendu

Cette partie décrit le comportement opérationnel attendu.

**Exemple :**

```text

En mode nominal :

- les mesures sont acquises selon la périodicité définie ;

- les données sont horodatées ;

- les seuils sont surveillés ;

- les alarmes sont générées si nécessaire ;

- les données sont transmises au serveur ;

- l’IHM affiche l’état courant ;

- les événements significatifs sont journalisés ;

- les commandes opérateur autorisées sont exécutées sous contrôle.

```

### 8.6 Événements pouvant provoquer une sortie du mode nominal

**Exemples :**

```text

- perte de communication serveur ;

- défaut capteur ;

- défaut matériel ;

- saturation du stockage ;

- demande de maintenance ;

- demande de diagnostic ;

- demande de mise à jour ;

- commande d’arrêt ;

- défaut critique ;

- arrêt d’urgence.

```

### 8.7 Tests associés

**Exemples :**

```text

- test d’acquisition nominale ;

- test de génération d’alarme sur seuil ;

- test de transmission serveur ;

- test d’affichage opérateur ;

- test de journalisation ;

- test de commande autorisée ;

- test de refus de commande non autorisée.

```

---

## 9. Mode maintenance

### 9.1 Objectif du mode maintenance

Cette partie décrit la finalité du mode maintenance.

Le mode maintenance permet à un technicien habilité de réaliser des opérations de diagnostic, de configuration, de remplacement, de test ou de remise en service. Il peut modifier temporairement le comportement du système, par exemple en inhibant certaines alarmes ou en suspendant certaines commandes automatiques.

**Exemple :**

> Le mode maintenance permet l’exécution d’opérations techniques contrôlées sans générer de comportements intempestifs ou d’alarmes non pertinentes. Il doit rester visible, limité aux utilisateurs habilités et entièrement journalisé.

### 9.2 Conditions d’entrée en mode maintenance

**Exemples :**

```text

- demande d’un utilisateur habilité ;

- absence de commande critique en cours ;

- confirmation explicite de passage en maintenance ;

- conditions de sécurité satisfaites ;

- identification de l’opération de maintenance ;

- consignation éventuelle de l’équipement.

```

### 9.3 Fonctions actives en maintenance

**Exemples :**

```text

- diagnostic ;

- consultation des versions ;

- export des journaux ;

- test des entrées/sorties ;

- remplacement ou déclaration de module ;

- consultation de configuration ;

- modification contrôlée de certains paramètres ;

- redémarrage contrôlé ;

- restauration de configuration si autorisée.

```

### 9.4 Fonctions inhibées ou limitées

**Exemples :**

```text

- commandes automatiques dangereuses ;

- génération de certaines alarmes non pertinentes ;

- transmission de certains états opérationnels ;

- actions opérateur non compatibles avec la maintenance ;

- mise à jour serveur non autorisée ;

- retour automatique au nominal sans contrôle.

```

### 9.5 Journalisation des actions de maintenance

Cette partie décrit les événements à tracer.

**Exemples :**

```text

- identité de l’utilisateur ;

- date et heure d’entrée en maintenance ;

- motif de maintenance ;

- fonctions inhibées ;

- tests réalisés ;

- paramètres modifiés ;

- fichiers exportés ;

- date et heure de sortie de maintenance ;

- résultat du retour au nominal.

```

### 9.6 Conditions de sortie du mode maintenance

**Exemples :**

```text

- demande de sortie par utilisateur habilité ;

- fin de procédure de maintenance ;

- vérification des paramètres critiques ;

- réactivation des fonctions inhibées ;

- absence de défaut bloquant ;

- confirmation du retour au mode nominal ;

- génération d’un événement de fin maintenance.

```

### 9.7 Tests associés

**Exemples :**

```text

- passage en maintenance par utilisateur autorisé ;

- refus de passage en maintenance par utilisateur non autorisé ;

- inhibition temporaire d’une alarme ;

- export des logs ;

- test d’une entrée/sortie ;

- retour au mode nominal ;

- vérification de la journalisation complète.

```

---

## 10. Mode diagnostic

### 10.1 Objectif du mode diagnostic

Cette partie décrit la finalité du mode diagnostic.

Le mode diagnostic permet d’observer ou de tester certaines fonctions afin d’identifier une anomalie. Il peut être distinct du mode maintenance si le diagnostic est accessible à un niveau d’habilitation différent ou s’il ne modifie pas l’état du système.

**Exemple :**

> Le mode diagnostic permet de consulter les informations techniques nécessaires à l’analyse d’un défaut sans modifier le comportement opérationnel du système, sauf action explicitement autorisée.

### 10.2 Conditions d’entrée

**Exemples :**

```text

- demande utilisateur habilité ;

- alarme active nécessitant une analyse ;

- intervention de maintenance ;

- procédure de support technique ;

- analyse après incident.

```

### 10.3 Informations disponibles

**Exemples :**

```text

- versions matérielles et logicielles ;

- état des capteurs ;

- état des communications ;

- niveau de stockage ;

- état des services serveur ;

- derniers défauts ;

- logs embarqués ;

- logs applicatifs ;

- configuration active ;

- état des files d’attente de transmission.

```

### 10.4 Actions autorisées

**Exemples :**

```text

- consulter les états internes ;

- exporter les journaux ;

- lancer un auto-test non intrusif ;

- vérifier la communication ;

- vérifier l’espace disque ;

- consulter les versions ;

- générer un rapport de diagnostic.

```

### 10.5 Actions interdites

**Exemples :**

```text

- modification d’un paramètre critique ;

- commande physique d’un actionneur ;

- suppression de logs ;

- restauration de configuration ;

- mise à jour logicielle ;

- inhibition d’alarmes critiques.

```

### 10.6 Tests associés

**Exemples :**

```text

- accès au diagnostic par profil autorisé ;

- refus d’accès par profil non autorisé ;

- export de logs ;

- consultation des versions ;

- consultation de l’état communication ;

- génération d’un rapport diagnostic.

```

---

## 11. Mode dégradé communication

### 11.1 Objectif du mode dégradé communication

Cette partie décrit le comportement attendu en cas de perte de communication.

Le mode dégradé communication est activé lorsque l’équipement embarqué ou le système ne peut plus communiquer avec le serveur, une supervision externe ou un autre composant essentiel.

**Exemple :**

> En mode dégradé communication, le système doit maintenir les fonctions locales critiques, conserver les données nécessaires et signaler à l’opérateur que la communication avec le serveur est indisponible.

### 11.2 Conditions d’entrée

**Exemples :**

```text

- absence d’acquittement serveur pendant plus de 120 secondes ;

- perte du lien réseau ;

- serveur indisponible ;

- erreur répétée de transmission ;

- échec d’authentification technique ;

- rupture VPN ;

- perte de liaison avec une supervision externe.

```

### 11.3 Fonctions maintenues

**Exemples :**

```text

- acquisition locale ;

- surveillance des seuils locaux ;

- génération d’alarmes locales ;

- stockage local des mesures ;

- journalisation ;

- maintien des commandes locales critiques si autorisées ;

- diagnostic de communication.

```

### 11.4 Fonctions suspendues ou limitées

**Exemples :**

```text

- transmission serveur ;

- commandes distantes ;

- synchronisation horaire distante ;

- consultation temps réel depuis le serveur ;

- export automatique vers système tiers ;

- mise à jour distante.

```

### 11.5 Alarmes associées

**Exemples :**

```text

ALM-COM-001 : perte communication serveur

ALM-COM-002 : transmission impossible

ALM-COM-003 : retard de synchronisation

ALM-COM-004 : file locale proche saturation

```

### 11.6 Comportement au retour de communication

Cette partie décrit la reprise.

**Exemple :**

```text

Lorsque la communication est rétablie :

1. le système vérifie la stabilité de la liaison ;

2. il transmet les données stockées localement ;

3. il conserve l’horodatage d’origine des données ;

4. il clôture ou historise l’alarme de perte communication ;

5. il repasse en mode nominal si aucune autre condition dégradée n’est active.

```

### 11.7 Tests associés

**Exemples :**

```text

- coupure réseau de courte durée ;

- coupure réseau prolongée ;

- redémarrage pendant coupure réseau ;

- saturation progressive de file locale ;

- retour réseau et resynchronisation ;

- vérification de l’affichage opérateur ;

- vérification de l’historique des données.

```

---

## 12. Mode dégradé capteur ou entrée/sortie

### 12.1 Objectif du mode

Cette partie décrit le comportement attendu lorsqu’un capteur, une entrée, une sortie ou un actionneur devient indisponible ou incohérent.

**Exemple :**

> En cas d’indisponibilité d’un capteur non critique, le système doit signaler l’anomalie, suspendre les traitements dépendants de cette mesure si nécessaire et maintenir les fonctions non affectées.

### 12.2 Conditions d’entrée

**Exemples :**

```text

- mesure absente ;

- mesure hors plage physique ;

- capteur non joignable ;

- incohérence entre plusieurs mesures ;

- défaut de retour d’état ;

- sortie commandée sans retour attendu ;

- erreur de calibration.

```

### 12.3 Classification du défaut

Cette partie précise que tous les capteurs ou sorties n’ont pas la même criticité.

**Exemple :**

```text

Capteur critique :

son indisponibilité impose un état sûr ou un arrêt fonctionnel.

Capteur important :

son indisponibilité impose un mode dégradé avec restriction fonctionnelle.

Capteur informatif :

son indisponibilité génère une alarme mais n’empêche pas le fonctionnement principal.

```

### 12.4 Fonctions maintenues

**Exemples :**

```text

- fonctions indépendantes du capteur défaillant ;

- affichage de l’état général ;

- journalisation ;

- communication serveur ;

- diagnostic ;

- fonctions de sécurité non affectées.

```

### 12.5 Fonctions interdites ou limitées

**Exemples :**

```text

- commande dépendant d’une mesure invalide ;

- calcul utilisant une donnée incohérente ;

- retour automatique au nominal sans validation ;

- masquage silencieux du défaut ;

- acquittement sans historisation.

```

### 12.6 Tests associés

**Exemples :**

```text

- débranchement d’un capteur ;

- simulation d’une valeur hors plage ;

- simulation d’un retour d’état incohérent ;

- vérification de l’alarme ;

- vérification des fonctions maintenues ;

- vérification des fonctions interdites ;

- retour au nominal après correction.

```

---

## 13. Mode dégradé stockage

### 13.1 Objectif du mode

Cette partie décrit le comportement attendu lorsque le stockage local ou serveur est indisponible, saturé ou en erreur.

**Exemple :**

> Le mode dégradé stockage permet d’éviter une perte silencieuse de données ou un blocage non maîtrisé du système lorsque l’espace disponible devient insuffisant ou que le support de stockage devient inaccessible.

### 13.2 Conditions d’entrée

**Exemples :**

```text

- espace disque inférieur à un seuil défini ;

- file locale saturée ;

- base de données indisponible ;

- erreur d’écriture ;

- corruption détectée ;

- support de stockage inaccessible ;

- échec répété d’archivage.

```

### 13.3 Comportement attendu

**Exemples :**

```text

- génération d’une alarme ;

- arrêt de certaines fonctions non critiques ;

- conservation prioritaire des données critiques ;

- blocage des acquisitions non essentielles ;

- passage en stratégie d’écrasement contrôlée si autorisée ;

- journalisation de l’incident ;

- information de l’opérateur.

```

### 13.4 Politique de conservation prioritaire

Cette partie décrit quelles données doivent être conservées en priorité.

**Exemples :**

```text

Priorité 1 :

- alarmes critiques ;

- événements de sécurité ;

- défauts système ;

- commandes opérateur.

Priorité 2 :

- mesures techniques ;

- historiques périodiques ;

- logs de diagnostic.

Priorité 3 :

- données statistiques ;

- traces détaillées de debug ;

- exports temporaires.

```

### 13.5 Conditions de sortie

**Exemples :**

```text

- espace de stockage libéré ;

- base de données redevenue disponible ;

- support de stockage remplacé ;

- archivage réalisé ;

- redémarrage contrôlé réussi ;

- validation de l’intégrité des données.

```

### 13.6 Tests associés

**Exemples :**

```text

- saturation progressive du stockage ;

- indisponibilité temporaire de la base de données ;

- erreur d’écriture locale ;

- retour à la normale après libération d’espace ;

- vérification de la conservation des données critiques.

```

---

## 14. Mode secours / état sûr

### 14.1 Objectif du mode secours

Cette partie décrit la finalité du mode secours ou état sûr.

Le mode secours est activé lorsqu’une condition empêche de garantir le fonctionnement nominal ou dégradé acceptable. Il doit permettre d’éviter une situation dangereuse, une perte de maîtrise ou une aggravation du défaut.

**Exemple :**

> Le mode secours a pour objectif de placer le système dans un état maîtrisé lorsque les conditions de fonctionnement ne permettent plus de garantir la sécurité, la sûreté ou l’intégrité des données critiques.

### 14.2 Conditions d’entrée

**Exemples :**

```text

- défaut critique matériel ;

- défaut logiciel non récupérable ;

- incohérence critique de configuration ;

- capteur critique indisponible ;

- commande physique non maîtrisée ;

- défaut d’alimentation ;

- erreur interne répétée ;

- défaut compromettant la sécurité des personnes ou des biens.

```

### 14.3 Comportement attendu

**Exemples :**

```text

- arrêt ou inhibition des commandes dangereuses ;

- maintien ou activation d’un état sûr ;

- journalisation de l’événement ;

- génération d’une alarme critique ;

- information opérateur ;

- interdiction de retour automatique au nominal si intervention requise ;

- maintien des fonctions minimales de diagnostic si possible.

```

### 14.4 Fonctions autorisées

**Exemples :**

```text

- consultation de l’état ;

- export des journaux ;

- diagnostic restreint ;

- acquittement contrôlé d’alarme ;

- arrêt contrôlé ;

- intervention maintenance habilitée.

```

### 14.5 Fonctions interdites

**Exemples :**

```text

- commande automatique ;

- redémarrage automatique sans contrôle ;

- modification de paramètres critiques ;

- masquage d’alarme critique ;

- retour au nominal sans levée de défaut ;

- mise à jour non contrôlée.

```

### 14.6 Retour depuis le mode secours

Cette partie décrit les conditions de sortie.

**Exemple :**