Canevas 4 — Dossier des modes de fonctionnement » History » Revision 1
Revision 1/7
| Next »
Redmine Admin, 06/18/2026 09:37 PM
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 :
- 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.
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 :
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 :
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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
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 :
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 :
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 :
- 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 :
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 :
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 :
[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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
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 :
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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
- 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 :
Le retour au mode nominal ne peut être autorisé que si :
- le défaut critique est levé ;
- une intervention ou vérification a été réalisée si nécessaire ;
- les fonctions critiques sont disponibles ;
- l’état du système est cohérent ;
- l’événement est historisé ;
- un utilisateur habilité confirme le retour au fonctionnement.
14.7 Tests associés¶
Exemples :
- défaut critique simulé ;
- vérification de l’inhibition des commandes dangereuses ;
- vérification de l’alarme critique ;
- vérification de l’absence de retour automatique non autorisé ;
- retour au nominal après intervention ;
- export des logs après passage en état sûr.
15. Mode mise à jour¶
15.1 Objectif du mode mise à jour¶
Cette partie décrit le fonctionnement lors d’une mise à jour logicielle, firmware, configuration ou base de données.
Exemple :
Le mode mise à jour permet d’installer une nouvelle version logicielle ou une nouvelle configuration dans des conditions maîtrisées, avec identification des versions, contrôle de cohérence, journalisation et vérification post-mise à jour.
15.2 Conditions d’entrée¶
Exemples :
- demande d’un utilisateur habilité ;
- version de mise à jour disponible ;
- absence d’action critique en cours ;
- sauvegarde préalable réalisée si nécessaire ;
- vérification de l’intégrité du paquet de mise à jour ;
- confirmation explicite.
15.3 Fonctions suspendues pendant la mise à jour¶
Exemples :
- commandes opérationnelles ;
- acquisition non critique ;
- synchronisation automatique ;
- modification concurrente de configuration ;
- redémarrage non maîtrisé ;
- accès utilisateur non nécessaire.
15.4 Étapes de mise à jour¶
Exemple :
1. Vérification des droits utilisateur.
2. Identification de la version actuelle.
3. Sauvegarde de la configuration.
4. Contrôle du paquet de mise à jour.
5. Passage en mode mise à jour.
6. Installation.
7. Redémarrage si nécessaire.
8. Vérification post-installation.
9. Journalisation du résultat.
10. Retour au mode nominal ou maintenance.
15.5 Échec de mise à jour¶
Cette partie décrit le comportement en cas d’échec.
Exemples :
- arrêt de la procédure ;
- restauration de la version précédente si possible ;
- génération d’une alarme ;
- maintien en mode maintenance ;
- interdiction du mode nominal si l’intégrité n’est pas garantie ;
- export des logs de mise à jour.
15.6 Tests associés¶
Exemples :
- mise à jour nominale ;
- mise à jour avec paquet invalide ;
- interruption pendant mise à jour ;
- retour arrière ;
- vérification des versions ;
- vérification de la configuration après mise à jour.
16. Mode arrêt contrôlé¶
16.1 Objectif du mode arrêt contrôlé¶
Cette partie décrit la séquence permettant d’arrêter proprement le système.
L’arrêt contrôlé doit éviter les pertes de données, les commandes incomplètes, les corruptions de configuration ou les états physiques non maîtrisés.
Exemple :
Le mode arrêt contrôlé permet d’arrêter le système en terminant les opérations en cours, en sauvegardant les informations nécessaires, en plaçant les sorties dans un état défini et en journalisant l’arrêt.
16.2 Conditions d’entrée¶
Exemples :
- commande d’arrêt utilisateur ;
- arrêt programmé ;
- demande de maintenance ;
- perte d’alimentation anticipée si détection possible ;
- ordre externe autorisé.
16.3 Séquence attendue¶
Exemple :
1. Refus ou mise en attente de nouvelles commandes.
2. Fin ou interruption maîtrisée des opérations en cours.
3. Sauvegarde des données nécessaires.
4. Transmission des derniers événements si communication disponible.
5. Mise en état sûr des sorties.
6. Journalisation de l’arrêt.
7. Passage en mode arrêt.
16.4 Conditions d’échec¶
Exemples :
- impossibilité de sauvegarder les données ;
- commande physique bloquée ;
- défaut critique pendant l’arrêt ;
- perte brutale d’alimentation ;
- timeout d’arrêt dépassé.
16.5 Tests associés¶
Exemples :
- arrêt contrôlé depuis mode nominal ;
- arrêt contrôlé depuis maintenance ;
- arrêt avec transmission finale ;
- arrêt sans réseau ;
- arrêt avec données en attente ;
- redémarrage après arrêt contrôlé.
17. Mode arrêt d’urgence¶
17.1 Objectif du mode arrêt d’urgence¶
Cette partie décrit le comportement attendu lorsqu’une situation impose un arrêt immédiat ou une mise en sécurité prioritaire.
L’arrêt d’urgence prime sur les autres modes.
Exemple :
L’arrêt d’urgence permet de placer immédiatement le système dans un état sûr en cas de condition critique. Il est prioritaire sur les demandes opérateur, les opérations de maintenance, les mises à jour et les traitements en cours.
17.2 Conditions d’entrée¶
Exemples :
- activation d’un bouton d’arrêt d’urgence ;
- défaut critique de sécurité ;
- commande externe d’urgence ;
- détection d’une condition dangereuse ;
- perte de maîtrise d’une commande ;
- dépassement d’un seuil critique de sécurité.
17.3 Comportement attendu¶
Exemples :
- inhibition immédiate des commandes dangereuses ;
- coupure ou mise en sécurité des sorties concernées ;
- génération d’une alarme critique ;
- journalisation de l’événement si possible ;
- information opérateur ;
- interdiction de retour automatique au nominal.
17.4 Retour après arrêt d’urgence¶
Cette partie précise les conditions de retour.
Exemple :
Le retour après arrêt d’urgence nécessite :
- levée physique ou logique de la condition d’urgence ;
- vérification de l’état du système ;
- intervention d’un utilisateur habilité ;
- confirmation explicite ;
- historisation de l’événement ;
- exécution éventuelle d’une procédure de redémarrage.
17.5 Tests associés¶
Exemples :
- déclenchement d’arrêt d’urgence ;
- vérification de priorité sur tous les modes ;
- vérification de l’état sûr ;
- vérification de l’alarme ;
- vérification de l’absence de retour automatique ;
- procédure de réarmement.
18. Transitions entre modes¶
18.1 Objet de la description des transitions¶
Cette partie décrit les passages autorisés entre modes.
Une transition doit être explicitement décrite si elle modifie le comportement du système, les fonctions actives, les droits utilisateur, les alarmes ou les conditions de sécurité.
18.2 Tableau des transitions¶
Cette partie présente un tableau de synthèse.
Structure recommandée :
ID transition
Mode source
Mode cible
Événement déclencheur
Conditions nécessaires
Actions réalisées
Alarmes générées ou clôturées
Utilisateur requis
Tests associés
Exemple :
TR-004
Source : mode nominal
Cible : mode dégradé communication
Déclencheur : absence d’acquittement serveur > 120 secondes
Conditions : système en fonctionnement local correct
Actions : activer stockage local, générer alarme communication, interdire commandes distantes
Alarme : ALM-COM-001
Utilisateur requis : aucun
Tests associés : TEST-INT-COM-002, VAL-COM-002
18.3 Transitions interdites¶
Cette partie précise les transitions non autorisées.
Exemples :
- arrêt d’urgence vers nominal sans réarmement ;
- mise à jour vers nominal sans vérification post-mise à jour ;
- maintenance vers nominal sans réactivation des fonctions inhibées ;
- dégradé capteur critique vers nominal sans correction du défaut ;
- secours vers nominal sans intervention habilitée.
18.4 Transitions automatiques¶
Cette partie décrit les transitions déclenchées automatiquement par le système.
Exemples :
- nominal vers dégradé communication après timeout réseau ;
- dégradé communication vers nominal après resynchronisation ;
- démarrage vers état sûr en cas de défaut critique ;
- nominal vers dégradé stockage en cas de saturation proche.
18.5 Transitions manuelles¶
Cette partie décrit les transitions déclenchées par un utilisateur.
Exemples :
- nominal vers maintenance ;
- maintenance vers nominal ;
- nominal vers arrêt contrôlé ;
- maintenance vers mise à jour ;
- secours vers diagnostic ;
- arrêt vers démarrage.
18.6 Tests des transitions¶
Cette partie définit les tests associés aux transitions.
Exemples :
- test de chaque transition nominale ;
- test de refus d’une transition interdite ;
- test de priorité arrêt d’urgence ;
- test de retour au nominal après défaut corrigé ;
- test de transition automatique après timeout ;
- test de transition manuelle avec droits insuffisants.
19. Comportement des interfaces selon les modes¶
19.1 Interface opérateur¶
Cette partie décrit ce que l’opérateur voit selon le mode.
Exemples :
Mode nominal :
affichage des états, alarmes, mesures et commandes autorisées.
Mode maintenance :
affichage clair du mode maintenance, fonctions de diagnostic, actions techniques.
Mode dégradé :
affichage de l’état dégradé, de la cause, des fonctions indisponibles et des actions possibles.
Mode secours :
affichage d’une alarme critique, limitation des commandes, instructions d’intervention.
19.2 Interface serveur¶
Cette partie décrit le comportement des échanges avec le serveur selon les modes.
Exemples :
Mode nominal :
transmission périodique des données.
Mode dégradé communication :
stockage local, tentatives de reconnexion, resynchronisation différée.
Mode maintenance :
transmission possible des événements de maintenance, mais suspension de certaines données opérationnelles si nécessaire.
Mode mise à jour :
suspension contrôlée de certains services.
19.3 Interface maintenance¶
Cette partie décrit les fonctions accessibles aux techniciens.
Exemples :
- export des logs ;
- diagnostic communication ;
- consultation des versions ;
- test entrées/sorties ;
- restauration de configuration ;
- redémarrage contrôlé ;
- vérification stockage.
19.4 Interface hardware¶
Cette partie décrit le comportement des entrées/sorties physiques selon les modes.
Exemples :
Mode arrêt :
sorties en état défini.
Mode nominal :
sorties pilotées selon les règles fonctionnelles.
Mode maintenance :
sorties testables sous conditions.
Mode secours :
sorties dangereuses inhibées.
Arrêt d’urgence :
sorties placées immédiatement en état sûr.
20. Alarmes et événements associés aux modes¶
20.1 Objet de la gestion des alarmes par mode¶
Cette partie décrit les alarmes générées lors des entrées, sorties ou défauts de mode.
Chaque passage dans un mode anormal ou dégradé doit être historisé si cela est nécessaire à l’exploitation ou à la maintenance.
20.2 Alarmes d’entrée en mode dégradé¶
Exemples :
ALM-COM-001 : perte communication serveur
ALM-CAPT-001 : capteur critique indisponible
ALM-STO-001 : stockage proche saturation
ALM-HOR-001 : synchronisation horaire indisponible
ALM-SRV-001 : serveur applicatif indisponible
20.3 Événements de changement de mode¶
Exemples :
EVT-MOD-001 : passage en mode nominal
EVT-MOD-002 : passage en mode maintenance
EVT-MOD-003 : passage en mode dégradé
EVT-MOD-004 : retour au mode nominal
EVT-MOD-005 : passage en arrêt contrôlé
EVT-MOD-006 : arrêt d’urgence déclenché
20.4 Acquittement des alarmes de mode¶
Cette partie précise quelles alarmes peuvent être acquittées et dans quelles conditions.
Exemple :
Une alarme de perte communication peut être acquittée par un opérateur, mais elle reste active tant que la communication n’est pas rétablie.
Une alarme d’arrêt d’urgence ne peut être clôturée qu’après levée de la condition d’urgence et réarmement par un utilisateur habilité.
20.5 Historisation¶
Cette partie décrit les informations à conserver.
Exemples :
- mode source ;
- mode cible ;
- déclencheur ;
- date et heure ;
- utilisateur si transition manuelle ;
- défaut associé ;
- durée du mode dégradé ;
- conditions de retour au nominal ;
- résultat de la transition.
21. Données et configuration selon les modes¶
21.1 Données acquises selon les modes¶
Cette partie précise si l’acquisition continue, s’arrête ou est limitée selon les modes.
Exemples :
Mode nominal :
acquisition complète.
Mode dégradé communication :
acquisition locale maintenue.
Mode maintenance :
acquisition limitée ou contrôlée selon l’intervention.
Mode secours :
acquisition minimale de diagnostic si possible.
Mode arrêt :
pas d’acquisition opérationnelle.
21.2 Données transmises selon les modes¶
Exemples :
Mode nominal :
transmission périodique.
Mode dégradé communication :
transmission suspendue, stockage local.
Mode maintenance :
transmission des événements de maintenance.
Mode mise à jour :
transmission suspendue sauf événements critiques.
Mode secours :
transmission d’alarme critique si communication disponible.
21.3 Configuration modifiable selon les modes¶
Cette partie décrit quand les paramètres peuvent être modifiés.
Exemples :
Mode nominal :
modification limitée aux paramètres non critiques.
Mode maintenance :
modification des paramètres autorisés par profil.
Mode mise à jour :
modification contrôlée de configuration.
Mode secours :
modification interdite sauf procédure spéciale.
Mode arrêt :
modification impossible ou réservée à un outil externe.
21.4 Sauvegarde de configuration¶
Cette partie précise si une sauvegarde est requise lors de certaines transitions.
Exemple :
Une sauvegarde de configuration doit être réalisée avant :
- mise à jour logicielle ;
- restauration ;
- modification de paramètres critiques ;
- remplacement d’un module ;
- changement de mode impliquant une modification persistante.
22. Matrice fonctions / modes¶
22.1 Objectif de la matrice¶
Cette partie explique l’intérêt de la matrice.
La matrice fonctions / modes permet de vérifier que le comportement de chaque fonction est défini pour chaque mode. Elle évite les oublis, notamment dans les modes dégradés.
22.2 Structure recommandée¶
Exemple :
Fonction | Arrêt | Démarrage | Nominal | Maintenance | Dégradé com. | Secours | Mise à jour
Acquisition | Non | Initialisation | Oui | Partiel | Oui local | Minimal | Non
Communication serveur | Non | Test | Oui | Oui limité | Tentatives | Si possible | Non
Commande actionneur | Non | Non | Oui | Test sous contrôle | Selon sécurité | Non | Non
Alarmes | Non | Défauts init | Oui | Partiel | Oui | Critiques | Oui limité
Stockage local | Conservation | Test | Oui | Oui | Oui renforcé | Minimal | Sauvegarde
IHM | État arrêt | État démarrage | Complet | Maintenance | Dégradé visible | Critique | Mise à jour
22.3 Règles de lecture¶
Cette partie précise les conventions utilisées dans la matrice.
Exemple :
Oui :
fonction pleinement active.
Non :
fonction inactive.
Partiel :
fonction active avec restrictions.
Minimal :
fonction limitée aux besoins de sécurité ou diagnostic.
Sous contrôle :
fonction accessible uniquement à un utilisateur habilité ou dans une procédure définie.
23. Matrice modes / tests¶
23.1 Objectif de la matrice¶
Cette partie relie les modes aux tests associés.
Chaque mode important doit être couvert par au moins un test d’intégration, un test système ou un scénario de validation.
23.2 Structure recommandée¶
Exemple :
Mode | Test unitaire | Test intégration | Test système | Validation client
Arrêt | TU-MOD-001 | TI-MOD-001 | TS-MOD-001 | VAL-MOD-001
Démarrage | TU-MOD-002 | TI-MOD-002 | TS-MOD-002 | VAL-MOD-002
Nominal | TU-FCT-* | TI-NOM-001 | TS-NOM-001 | VAL-NOM-001
Dégradé communication | TU-COM-* | TI-COM-002 | TS-COM-002 | VAL-COM-002
Maintenance | TU-ROLE-* | TI-MAINT-001 | TS-MAINT-001 | VAL-MAINT-001
Secours | TU-SAFE-* | TI-SAFE-001 | TS-SAFE-001 | VAL-SAFE-001
23.3 Couverture minimale attendue¶
Exemple :
Tous les modes nominaux doivent être testés.
Tous les modes dégradés identifiés doivent être testés.
Toutes les transitions critiques doivent être testées.
L’arrêt d’urgence et l’état sûr doivent être validés si applicables.
Les modes non testables doivent faire l’objet d’une justification.
24. Points ouverts et cas à confirmer¶
24.1 Objet des points ouverts¶
Cette partie recense les questions non encore tranchées concernant les modes.
Un point ouvert peut concerner une condition de transition, une priorité entre modes, un comportement en cas de défaut, une responsabilité opérateur ou une contrainte de sécurité.
24.2 Exemple de tableau des points ouverts¶
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-MOD-001 | Durée perte réseau | Définir le timeout exact avant passage en mode dégradé communication | Fournisseur / client | Avant spéc. détaillée | Software + tests | Ouvert
PO-MOD-002 | Retour automatique | Confirmer si le retour au nominal après perte capteur peut être automatique | Client | Avant validation architecture | Sécurité + validation | Ouvert
PO-MOD-003 | Inhibition alarme | Définir la durée maximale d’inhibition en maintenance | Client / maintenance | Avant dossier validation | IHM + tests | Ouvert
24.3 Règle de clôture¶
Cette partie précise comment clôturer un point ouvert.
Exemple :
Un point ouvert est clôturé lorsqu’une décision est formalisée, intégrée dans le dossier des modes, reportée si nécessaire dans les spécifications détaillées et prise en compte dans les tests associés.
25. Critères d’acceptation du dossier des modes¶
25.1 Complétude¶
Cette partie définit les critères permettant de considérer le dossier comme complet.
Exemples :
Le dossier est considéré comme complet si :
- tous les modes principaux sont identifiés ;
- les conditions d’entrée et de sortie sont décrites ;
- les fonctions actives et inhibées sont précisées ;
- les transitions autorisées sont définies ;
- les transitions interdites sont identifiées ;
- les modes dégradés sont décrits ;
- les priorités entre modes sont définies ;
- les alarmes associées sont identifiées ;
- les tests associés sont référencés ;
- les points ouverts sont listés.
25.2 Cohérence¶
Cette partie précise les critères de cohérence.
Exemples :
Le dossier ne doit pas contenir :
- deux modes incompatibles actifs simultanément sans règle de priorité ;
- une transition sans condition d’entrée ;
- un mode dégradé sans condition de sortie ;
- une alarme critique sans comportement associé ;
- une fonction critique sans état défini dans chaque mode ;
- un retour automatique non justifié depuis un état sûr.
25.3 Validation du document¶
Cette partie précise les revues nécessaires.
Exemple :
Le dossier des modes doit être relu par :
- l’ingénieur système ;
- le responsable logiciel embarqué ;
- le responsable hardware ;
- le responsable validation ;
- le responsable maintenance ;
- le responsable sécurité / sûreté si applicable ;
- le représentant client si les modes impactent la recette.
26. Annexes¶
26.1 Liste complète des modes¶
Cette annexe reprend l’ensemble des modes identifiés avec leurs identifiants.
26.2 Liste complète des transitions¶
Cette annexe reprend toutes les transitions autorisées et interdites.
26.3 Diagrammes d’états¶
Cette annexe contient les diagrammes graphiques, si disponibles.
Exemples de diagrammes possibles :
- diagramme général des modes ;
- diagramme des modes dégradés ;
- diagramme du démarrage ;
- diagramme de maintenance ;
- diagramme de mise à jour ;
- diagramme d’arrêt d’urgence.
26.4 Matrice fonctions / modes¶
Cette annexe contient la matrice complète.
26.5 Matrice modes / tests¶
Cette annexe contient la correspondance entre modes et tests.
26.6 Glossaire¶
Cette annexe reprend les termes spécifiques aux modes de fonctionnement.
26.7 Historique des décisions¶
Cette annexe peut conserver les décisions importantes relatives aux modes.
Exemple :
DEC-MOD-001 :
Le retour au mode nominal après perte communication sera automatique après resynchronisation complète.
DEC-MOD-002 :
Le retour au mode nominal après arrêt d’urgence nécessitera une action manuelle d’un utilisateur habilité.
DEC-MOD-003 :
L’inhibition d’alarme en maintenance sera limitée à 2 heures et journalisée.
Updated by Redmine Admin 3 months ago · 7 revisions