CANEVAS DES DOCUMENTS DU PROJET

# Canevas 7B — Spécification détaillée software embarqué

## 1. Objet du document

### 1.1 Finalité de la spécification détaillée software embarqué

Cette partie précise l’objectif du document.

La spécification détaillée software embarqué décrit les exigences applicables au logiciel exécuté dans l’équipement embarqué : acquisition des données, traitement local, gestion des modes de fonctionnement, gestion des alarmes, communication avec le serveur, stockage local, diagnostic, configuration, mise à jour, sécurité, journalisation et testabilité.

Elle constitue la déclinaison logicielle embarquée de la spécification globale, de l’architecture système, du dossier des modes de fonctionnement et de la spécification détaillée hardware.

Elle doit rester une spécification, c’est-à-dire décrire **ce que le logiciel embarqué doit faire**. Elle ne doit pas encore décrire en détail les classes, fonctions, structures de données, fichiers sources, algorithmes internes ou choix d’implémentation détaillés. Ces éléments relèveront du dossier de conception détaillée software embarqué.

**Exemple :**

> Le présent document a pour objectif de spécifier les exigences détaillées applicables au logiciel embarqué. Il décrit les fonctions d’acquisition, de traitement, de communication, de stockage local, de gestion des modes, de gestion des alarmes, de diagnostic, de configuration, de mise à jour et de sécurité que le logiciel embarqué doit assurer.

### 1.2 Positionnement dans le cycle en V

Cette partie situe la spécification détaillée software embarqué dans le cycle en V.

Elle est produite après la spécification globale, l’architecture système, le dossier des modes de fonctionnement et la spécification détaillée hardware. Elle sert d’entrée à la conception détaillée software, au codage, aux tests unitaires logiciels, aux tests d’intégration hardware/software et aux tests système.

```text

Spécification globale

        ↓

Architecture système / conception globale

        ↓

Dossier des modes de fonctionnement

        ↓

Spécification détaillée hardware

        ↓

Spécification détaillée software embarqué

        ↓

Conception détaillée software embarqué

        ↓

Codage / configuration firmware

        ↑

Tests unitaires software

        ↑

Tests d’intégration hardware/software

        ↑

Tests système

        ↑

Validation client

```

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

Cette partie précise la différence entre la spécification globale et la spécification détaillée software embarqué.

La spécification globale décrit le comportement attendu du système complet. La spécification détaillée software embarqué décrit ce que le logiciel embarqué doit réaliser pour contribuer à ce comportement.

**Exemple :**

```text

Spécification globale :

Le système doit continuer à acquérir les données en cas de perte de communication serveur.

Spécification détaillée software embarqué :

Le logiciel embarqué doit détecter la perte de communication avec le serveur.

Le logiciel embarqué doit poursuivre l’acquisition des mesures configurées.

Le logiciel embarqué doit enregistrer localement les données non transmises.

Le logiciel embarqué doit déclencher une resynchronisation lorsque la communication est rétablie.

```

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

Cette partie précise la frontière entre la spécification et la conception.

La spécification détaillée software indique **le comportement attendu**.

La conception détaillée software indique **comment ce comportement sera réalisé techniquement**.

**Exemple :**

```text

Spécification détaillée software :

Le logiciel embarqué doit conserver localement les données non transmises pendant une perte de communication.

Conception détaillée software :

Les données non transmises sont stockées dans une file persistante gérée par le module LocalStorageManager. Chaque enregistrement contient un identifiant, un horodatage, un type de message, un statut et un compteur de tentatives de transmission.

```

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

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

La spécification détaillée software embarqué est généralement rédigée par le responsable logiciel embarqué, avec contribution de l’ingénieur système, du responsable hardware, du responsable serveur, du responsable intégration, du responsable validation, de la maintenance et de la cybersécurité.

**Exemple :**

```text

Rédaction    : responsable software embarqué / ingénieur firmware

Contribution : ingénieur système, hardware, serveur, infrastructure, cybersécurité, validation

Relecture    : architecte système, responsable tests, responsable qualité

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 rédiger la spécification software embarqué.

Ces documents doivent être identifiés avec leur référence, leur version et leur statut, afin d’éviter que le logiciel soit spécifié à partir d’une version obsolète du besoin ou de l’architecture.

**Exemples :**

```text

- Cahier des charges / expression du besoin

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

- Dossier des modes de fonctionnement

- Architecture système / conception globale

- Spécification détaillée hardware

- Spécification des interfaces

- Dossier infrastructure

- Dossier de validation client

- Analyse de risques

- Contraintes cybersécurité

- Contraintes d’exploitation

- Contraintes de maintenance

```

### 2.2 Documents applicables

Cette partie liste les documents que le logiciel embarqué doit respecter.

**Exemples :**

```text

- standard de développement logiciel ;

- règles de codage ;

- règles de gestion de configuration ;

- règles de cybersécurité ;

- règles de journalisation ;

- contraintes temps réel ;

- contraintes de sûreté de fonctionnement ;

- contraintes de testabilité ;

- normes ou standards sectoriels applicables ;

- protocole de communication imposé ;

- règles de versionnement firmware.

```

### 2.3 Documents produits à partir de cette spécification

Cette partie liste les documents qui seront dérivés de la spécification software embarqué.

**Exemples :**

```text

- dossier de conception détaillée software embarqué ;

- plan de tests unitaires software ;

- procédures de tests unitaires ;

- procédures de tests d’intégration hardware/software ;

- procédures de tests de communication ;

- procédures de tests des modes dégradés ;

- dossier de configuration firmware ;

- manuel de maintenance logicielle ;

- procédure de mise à jour firmware ;

- rapport de tests software.

```

### 2.4 Gestion des versions

Cette partie précise que les versions software doivent être identifiées et maîtrisées.

Une modification du firmware peut avoir des impacts sur le matériel, le serveur, les interfaces, les modes de fonctionnement, les tests, la validation et la maintenance.

**Exemple :**

> Toute modification d’une fonction d’acquisition, d’un protocole de communication, d’une règle d’alarme, d’une gestion de mode, d’un format de stockage local ou d’une procédure de mise à jour doit faire l’objet d’une analyse d’impact sur les tests unitaires, les tests d’intégration, la documentation de maintenance et la configuration livrée.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

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

**Exemples :**

```text

Firmware :

Logiciel embarqué exécuté sur le matériel de l’équipement.

Cycle d’acquisition :

Séquence périodique consistant à lire une ou plusieurs entrées, valider les données, les traiter puis les rendre disponibles au reste du système.

Mode dégradé :

Mode dans lequel le firmware maintient certaines fonctions malgré la perte d’une ressource, par exemple communication serveur, capteur ou stockage.

Alarme locale :

Alarme générée par le firmware à partir d’un état ou d’une mesure détectée localement.

File locale :

Mécanisme de stockage temporaire des données ou événements non transmis au serveur.

Watchdog :

Mécanisme de surveillance permettant de détecter un blocage logiciel et de provoquer une action de reprise.

```

### 3.2 Acronymes

**Exemples :**

```text

ADC  : Analog-to-Digital Converter

API  : Application Programming Interface

BMS  : Battery Management System

CRC  : Cyclic Redundancy Check

GPIO : General Purpose Input/Output

IHM  : Interface Homme-Machine

NTP  : Network Time Protocol

RTC  : Real-Time Clock

RTOS : Real-Time Operating System

TLS  : Transport Layer Security

UART : Universal Asynchronous Receiver Transmitter

```

### 3.3 Convention d’identification des exigences software embarqué

Cette partie définit la codification des exigences.

**Exemple :**

```text

SW-BOOT-001 : exigence de démarrage

SW-MODE-001 : exigence de gestion des modes

SW-ACQ-001  : exigence d’acquisition

SW-TRT-001  : exigence de traitement

SW-ALM-001  : exigence de gestion des alarmes

SW-COM-001  : exigence de communication

SW-STO-001  : exigence de stockage local

SW-CFG-001  : exigence de configuration

SW-DIAG-001 : exigence de diagnostic

SW-MAJ-001  : exigence de mise à jour

SW-SEC-001  : exigence de sécurité

SW-TEST-001 : exigence de testabilité

```

### 3.4 Convention de formulation des exigences

Cette partie rappelle qu’une exigence doit être claire, vérifiable et non ambiguë.

**Exemples :**

```text

Correct :

SW-ACQ-001 — Le logiciel embarqué doit lire la mesure de température toutes les 10 secondes en mode nominal.

Incorrect :

Le logiciel doit lire régulièrement la température.

Correct :

SW-COM-004 — Le logiciel embarqué doit considérer la communication serveur comme perdue si aucun acquittement valide n’est reçu pendant plus de 120 secondes.

Incorrect :

Le logiciel doit bien gérer les pertes réseau.

```

### 3.5 Convention de criticité

Cette partie peut définir une criticité pour les exigences.

**Exemple :**

```text

Critique :

exigence liée à la sécurité, à l’état sûr, à l’arrêt d’urgence ou à une fonction indispensable.

Élevée :

exigence affectant une fonction majeure du système.

Moyenne :

exigence importante mais dont le défaut n’empêche pas totalement l’exploitation.

Faible :

exigence de confort, d’ergonomie, d’optimisation ou de diagnostic secondaire.

```

---

## 4. Vue générale du logiciel embarqué

### 4.1 Présentation générale

Cette partie décrit le rôle du logiciel embarqué dans le système.

Elle doit permettre à un lecteur de comprendre ce que le firmware assure localement et comment il interagit avec le hardware, le serveur et les utilisateurs.

**Exemple :**

> Le logiciel embarqué assure l’acquisition des signaux matériels, le traitement local des données, la surveillance des seuils, la génération des alarmes locales, la gestion des modes de fonctionnement, le stockage temporaire des données, la communication avec le serveur applicatif et les fonctions de diagnostic et de maintenance locale.

### 4.2 Fonctions principales du logiciel embarqué

Cette partie liste les grandes fonctions logicielles.

**Exemples :**

```text

- démarrage et initialisation ;

- gestion des modes ;

- acquisition des entrées ;

- commande des sorties ;

- traitement des mesures ;

- surveillance des seuils ;

- gestion des alarmes ;

- communication avec le serveur ;

- stockage local ;

- resynchronisation ;

- diagnostic ;

- gestion de configuration ;

- mise à jour firmware ;

- journalisation ;

- sécurité et contrôle d’accès local si applicable.

```

### 4.3 Frontières du logiciel embarqué

Cette partie précise ce qui relève du firmware et ce qui relève d’autres sous-systèmes.

**Exemple :**

```text

Inclus dans le logiciel embarqué :

- lecture des entrées matérielles ;

- commande des sorties matérielles ;

- détection des défauts locaux ;

- stockage temporaire des données ;

- communication avec le serveur ;

- gestion des modes locaux.

Externe au logiciel embarqué :

- affichage web côté serveur ;

- stockage longue durée centralisé ;

- gestion globale des utilisateurs si assurée par le serveur ;

- sauvegarde serveur ;

- administration réseau ;

- base de données centrale.

```

### 4.4 Interactions avec le hardware

Cette partie décrit les interactions entre le logiciel et le matériel.

**Exemples :**

```text

- lecture d’entrées numériques ;

- lecture d’entrées analogiques ;

- commande de sorties relais ;

- lecture d’un bus de communication ;

- gestion d’un module 4G ou Ethernet ;

- lecture de l’état d’alimentation ;

- utilisation d’une mémoire non volatile ;

- utilisation d’une horloge temps réel ;

- interaction avec un watchdog matériel.

```

### 4.5 Interactions avec le serveur

Cette partie décrit les interactions avec la partie serveur.

**Exemples :**

```text

- envoi périodique de mesures ;

- envoi événementiel d’alarmes ;

- réception d’acquittements ;

- réception de configuration ;

- envoi de journaux ;

- synchronisation horaire ;

- resynchronisation après coupure réseau ;

- notification de changement de mode.

```

### 4.6 Interactions avec l’opérateur ou la maintenance

Cette partie décrit les interactions locales éventuelles.

**Exemples :**

```text

- voyant d’état ;

- bouton local ;

- port de maintenance ;

- commande de diagnostic ;

- export de logs ;

- mode maintenance ;

- indication de défaut ;

- retour d’état local.

```

---

## 5. Exigences de démarrage et d’initialisation

### 5.1 Objet des exigences de démarrage

Cette partie décrit le comportement attendu du firmware lors de la mise sous tension, du redémarrage ou du retour après mise à jour.

Le démarrage est une phase critique, car le logiciel doit établir un état cohérent du système avant d’autoriser le fonctionnement nominal.

### 5.2 Séquence de démarrage

Cette partie décrit les étapes attendues au démarrage.

**Exemple :**

```text

SW-BOOT-001 — Au démarrage, le logiciel embarqué doit initialiser les ressources matérielles nécessaires à son fonctionnement.

SW-BOOT-002 — Au démarrage, le logiciel embarqué doit charger la configuration locale.

SW-BOOT-003 — Au démarrage, le logiciel embarqué doit vérifier la cohérence de la configuration chargée.

SW-BOOT-004 — Au démarrage, le logiciel embarqué doit initialiser les communications nécessaires.

SW-BOOT-005 — Au démarrage, le logiciel embarqué doit déterminer le mode initial du système.

```

### 5.3 Vérifications au démarrage

Cette partie liste les contrôles que le firmware doit réaliser.

**Exemples :**

```text

- validité de la configuration ;

- disponibilité du stockage local ;

- état des entrées critiques ;

- état des sorties ;

- version hardware ;

- version firmware ;

- état du module communication ;

- état de l’horloge ;

- cause du dernier redémarrage ;

- disponibilité des ressources mémoire ;

- état du watchdog.

```

### 5.4 Gestion des défauts au démarrage

Cette partie décrit le comportement en cas d’anomalie détectée dès le démarrage.

**Exemple :**

```text

SW-BOOT-010 — Si la configuration locale est absente ou invalide, le logiciel embarqué doit empêcher le passage en mode nominal et signaler un défaut de configuration.

SW-BOOT-011 — Si un capteur critique est indisponible au démarrage, le logiciel embarqué doit appliquer la règle définie dans le dossier des modes : mode dégradé, état sûr ou arrêt.

SW-BOOT-012 — Si la communication serveur est indisponible au démarrage, le logiciel embarqué doit appliquer le mode dégradé communication si les fonctions locales peuvent être maintenues.

```

### 5.5 État initial des sorties

Cette partie précise comment le firmware doit gérer les sorties au démarrage.

**Exemples :**

```text

SW-BOOT-020 — Les sorties critiques doivent rester dans leur état sûr jusqu’à ce que les conditions de fonctionnement soient validées.

SW-BOOT-021 — Le logiciel embarqué ne doit pas générer de commande intempestive lors du démarrage.

SW-BOOT-022 — Toute activation de sortie après démarrage doit être conditionnée par la validation du mode et des règles de sécurité applicables.

```

### 5.6 Redémarrage après incident

Cette partie décrit le comportement après un reset, watchdog ou coupure d’alimentation.

**Exemples :**

```text

SW-BOOT-030 — Le logiciel embarqué doit enregistrer ou exposer la cause du dernier redémarrage si cette information est disponible.

SW-BOOT-031 — Après un redémarrage non planifié, le logiciel embarqué doit vérifier l’intégrité des données locales avant reprise.

SW-BOOT-032 — Après un redémarrage watchdog, le logiciel embarqué doit signaler un événement de redémarrage anormal.

```

### 5.7 Tests associés

Cette partie indique les tests à prévoir.

**Exemples :**

```text

- démarrage nominal ;

- démarrage avec configuration absente ;

- démarrage avec configuration corrompue ;

- démarrage sans serveur ;

- démarrage avec stockage local indisponible ;

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

- démarrage après watchdog ;

- vérification de l’état initial des sorties.

```

---

## 6. Exigences de gestion des modes de fonctionnement

### 6.1 Objet de la gestion des modes

Cette partie décrit comment le logiciel embarqué doit gérer les modes définis dans le dossier des modes de fonctionnement.

Le firmware doit connaître le mode courant du système, appliquer les fonctions autorisées ou interdites dans ce mode, gérer les transitions et signaler les changements de mode.

### 6.2 Modes supportés

Cette partie liste les modes que le firmware doit gérer.

**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.

```

### 6.3 Mode nominal

Cette partie décrit le comportement logiciel attendu en mode nominal.

**Exemple :**

```text

SW-MODE-NOM-001 — En mode nominal, le logiciel embarqué doit exécuter les fonctions d’acquisition, de traitement, de surveillance, de communication et de journalisation définies.

SW-MODE-NOM-002 — En mode nominal, le logiciel embarqué doit signaler tout défaut détecté selon les règles d’alarme définies.

SW-MODE-NOM-003 — En mode nominal, le logiciel embarqué doit maintenir la communication serveur si celle-ci est disponible.

```

### 6.4 Mode maintenance

Cette partie décrit le comportement logiciel en mode maintenance.

**Exemples :**

```text

SW-MODE-MNT-001 — Le passage en mode maintenance doit être déclenché uniquement dans les conditions définies par le dossier des modes.

SW-MODE-MNT-002 — En mode maintenance, le logiciel embarqué doit permettre les fonctions de diagnostic et de test autorisées.

SW-MODE-MNT-003 — Les actions réalisées en mode maintenance doivent être journalisées.

SW-MODE-MNT-004 — Le retour au mode nominal doit réactiver les fonctions inhibées, sauf exception explicitement prévue.

```

### 6.5 Mode diagnostic

Cette partie décrit les fonctions de diagnostic accessibles.

**Exemples :**

```text

SW-MODE-DIAG-001 — En mode diagnostic, le logiciel embarqué doit permettre la consultation des états internes autorisés.

SW-MODE-DIAG-002 — En mode diagnostic, le logiciel embarqué doit permettre l’export des journaux techniques si cette fonction est prévue.

SW-MODE-DIAG-003 — Le mode diagnostic ne doit pas autoriser de commande physique dangereuse sans passage par un mode approprié.

```

### 6.6 Mode dégradé communication

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

**Exemple :**

```text

SW-MODE-COM-001 — Le logiciel embarqué doit passer en mode dégradé communication lorsque les critères de perte serveur sont atteints.

SW-MODE-COM-002 — En mode dégradé communication, le logiciel embarqué doit poursuivre les acquisitions locales autorisées.

SW-MODE-COM-003 — En mode dégradé communication, le logiciel embarqué doit stocker localement les données non transmises.

SW-MODE-COM-004 — En mode dégradé communication, le logiciel embarqué doit interdire ou ignorer les commandes distantes indisponibles.

```

### 6.7 Mode dégradé capteur

Cette partie décrit le comportement attendu en cas de capteur absent, incohérent ou défaillant.

**Exemples :**

```text

SW-MODE-CAPT-001 — Le logiciel embarqué doit détecter l’indisponibilité d’un capteur critique si le hardware permet cette détection.

SW-MODE-CAPT-002 — En cas de défaut capteur non critique, le logiciel embarqué doit maintenir les fonctions non dépendantes de ce capteur.

SW-MODE-CAPT-003 — En cas de défaut capteur critique, le logiciel embarqué doit appliquer le comportement défini dans le dossier des modes.

```

### 6.8 Mode secours ou état sûr

Cette partie décrit le comportement logiciel en cas de situation critique.

**Exemples :**

```text

SW-MODE-SAFE-001 — Le logiciel embarqué doit placer les sorties critiques dans un état sûr lorsque les conditions d’état sûr sont réunies.

SW-MODE-SAFE-002 — Le logiciel embarqué ne doit pas autoriser un retour automatique au mode nominal depuis un état sûr si une intervention est requise.

SW-MODE-SAFE-003 — Le logiciel embarqué doit journaliser l’entrée en état sûr si les ressources nécessaires sont disponibles.

```

### 6.9 Transitions entre modes

Cette partie précise les règles de transition.

**Exemple :**

```text

SW-MODE-TR-001 — Le logiciel embarqué doit autoriser uniquement les transitions définies dans le dossier des modes.

SW-MODE-TR-002 — Le logiciel embarqué doit refuser toute transition interdite.

SW-MODE-TR-003 — Le logiciel embarqué doit journaliser les transitions de mode significatives.

SW-MODE-TR-004 — Les transitions critiques doivent être protégées contre les déclenchements intempestifs.

```

### 6.10 Tests associés

**Exemples :**

```text

- passage démarrage vers nominal ;

- passage nominal vers maintenance ;

- refus maintenance utilisateur non autorisé ;

- passage nominal vers dégradé communication ;

- retour dégradé communication vers nominal ;

- passage nominal vers état sûr ;

- refus retour automatique depuis arrêt d’urgence ;

- journalisation des transitions.

```

---

## 7. Exigences d’acquisition des données

### 7.1 Objet des fonctions d’acquisition

Cette partie décrit comment le firmware doit lire les signaux provenant du matériel : entrées numériques, entrées analogiques, bus, capteurs intelligents, états internes ou informations de diagnostic.

### 7.2 Liste des données acquises

Cette partie liste les données que le logiciel doit acquérir.

**Exemple :**

```text

Donnée        | Source hardware      | Type       | Périodicité     | Criticité

TEMP_INT      | capteur température  | analogique | 10 s            | élevée

V_BATT        | mesure tension       | analogique | 10 s            | élevée

DOOR_STATE    | contact porte        | numérique  | événement / 1 s | moyenne

BMS_STATE     | bus RS485/CAN        | message    | 5 s             | élevée

COM_LINK      | module communication | état       | 10 s            | élevée

STORAGE_LEVEL | mémoire locale       | interne    | 60 s            | élevée

```

### 7.3 Acquisition périodique

Cette partie décrit les acquisitions réalisées à intervalle régulier.

**Exemples :**

```text

SW-ACQ-001 — Le logiciel embarqué doit acquérir les mesures périodiques selon la fréquence définie pour chaque donnée.

SW-ACQ-002 — Le logiciel embarqué doit horodater les mesures acquises.

SW-ACQ-003 — Le logiciel embarqué doit distinguer une donnée acquise valide d’une donnée invalide.

SW-ACQ-004 — Le logiciel embarqué doit signaler l’absence d’une donnée attendue si cette absence est détectable.

```

### 7.4 Acquisition événementielle

Cette partie décrit les acquisitions déclenchées par changement d’état ou événement.

**Exemples :**

```text

- changement d’état d’une entrée numérique ;

- apparition d’un défaut ;

- activation d’un bouton ;

- réception d’un message bus ;

- franchissement d’un seuil ;

- retour d’un capteur ;

- perte d’un capteur.

```

**Exemple d’exigence :**

```text

SW-ACQ-EVT-001 — Le logiciel embarqué doit détecter les changements d’état des entrées identifiées comme événementielles.

```

### 7.5 Validation des données acquises

Cette partie décrit les règles permettant de déterminer si une donnée est valide.

**Exemples :**

```text

- plage physique acceptable ;

- cohérence entre plusieurs mesures ;

- absence de valeur impossible ;

- contrôle CRC ou checksum ;

- horodatage cohérent ;

- compteur de messages ;

- état capteur disponible ;

- absence de timeout.

```

**Exemple :**

```text

SW-ACQ-VAL-001 — Le logiciel embarqué doit marquer comme invalide toute mesure analogique située hors de la plage physique définie.

```

### 7.6 Filtrage et anti-rebond logiciel

Cette partie décrit les traitements de stabilisation des signaux.

**Exemples :**

```text

SW-ACQ-FILT-001 — Le logiciel embarqué doit appliquer un anti-rebond logiciel aux entrées numériques qui le nécessitent.

SW-ACQ-FILT-002 — Le filtrage logiciel ne doit pas masquer un événement critique au-delà du délai maximal acceptable.

SW-ACQ-FILT-003 — Les règles de filtrage doivent être compatibles avec les contraintes temporelles du système.

```

### 7.7 Gestion des défauts d’acquisition

Cette partie décrit ce qui se passe lorsqu’une acquisition échoue.

**Exemples :**

```text

- capteur absent ;

- bus silencieux ;

- donnée hors plage ;

- message corrompu ;

- timeout ;

- valeur figée ;

- incohérence entre capteurs ;

- erreur ADC ;

- défaut hardware.

```

**Exemple d’exigence :**

```text

SW-ACQ-ERR-001 — En cas d’échec répété d’acquisition d’une donnée critique, le logiciel embarqué doit générer un défaut et appliquer le mode de fonctionnement associé.

```

### 7.8 Tests associés

**Exemples :**

```text

- acquisition d’une valeur nominale ;

- acquisition d’une valeur limite ;

- valeur hors plage ;

- capteur débranché ;

- signal instable ;

- changement d’état rapide ;

- message bus invalide ;

- timeout capteur ;

- vérification horodatage.

```

---

## 8. Exigences de traitement local

### 8.1 Objet des traitements locaux

Cette partie décrit les traitements réalisés par le firmware avant transmission ou action.

Le traitement local peut inclure la conversion de mesures, le filtrage, la comparaison à des seuils, la détection d’anomalies, l’agrégation, la génération d’états ou le calcul d’indicateurs.

### 8.2 Conversion des mesures

Cette partie décrit les conversions nécessaires entre signal brut et valeur exploitable.

**Exemples :**

```text

SW-TRT-CONV-001 — Le logiciel embarqué doit convertir les valeurs brutes des entrées analogiques en unités physiques lorsque cette conversion est nécessaire.

SW-TRT-CONV-002 — Les coefficients de conversion doivent être définis par configuration ou par constante validée.

SW-TRT-CONV-003 — Toute erreur de conversion ou valeur impossible doit être signalée comme donnée invalide.

```

**Exemple :**

```text

Valeur brute ADC → tension mesurée → température calculée → comparaison au seuil.

```

### 8.3 Surveillance des seuils

Cette partie décrit la comparaison des mesures à des seuils.

**Exemples :**

```text

SW-TRT-SEUIL-001 — Le logiciel embarqué doit comparer les mesures surveillées aux seuils configurés.

SW-TRT-SEUIL-002 — Le logiciel embarqué doit distinguer les seuils d’information, d’alerte et de défaut critique si ces niveaux sont définis.

SW-TRT-SEUIL-003 — Le franchissement d’un seuil doit générer un événement ou une alarme selon les règles définies.

```

### 8.4 Hystérésis et temporisation

Cette partie décrit les mécanismes évitant les alarmes instables.

**Exemple :**

```text

SW-TRT-HYST-001 — Lorsqu’une hystérésis est définie, le logiciel embarqué doit appliquer des seuils distincts d’apparition et de disparition de l’alarme.

SW-TRT-TEMP-001 — Lorsqu’une temporisation est définie, le logiciel embarqué doit générer l’alarme uniquement si la condition reste vraie pendant la durée prévue.

```

**Exemple explicatif :**

> Si la température dépasse 70 °C, une alarme peut être déclenchée après 30 secondes de dépassement continu. Elle ne sera clôturée qu’après retour sous 65 °C, afin d’éviter les oscillations autour du seuil.

### 8.5 Agrégation ou synthèse d’état

Cette partie décrit la construction d’un état global à partir de plusieurs informations.

**Exemples :**

```text

SW-TRT-ETAT-001 — Le logiciel embarqué doit produire un état global de l’équipement à partir des défauts, alarmes, modes et états de communication.

SW-TRT-ETAT-002 — L’état global doit distinguer au minimum : nominal, dégradé, maintenance, défaut critique et arrêt.

SW-TRT-ETAT-003 — L’état global doit être transmis au serveur et rendu disponible au diagnostic local.

```

### 8.6 Priorités de traitement

Cette partie décrit les traitements prioritaires.

**Exemples :**

```text

Priorité haute :

- sécurité ;

- arrêt d’urgence ;

- état sûr ;

- défaut critique ;

- watchdog ;

- commandes critiques.

Priorité moyenne :

- acquisition ;

- alarmes ;

- communication ;

- stockage.

Priorité basse :

- diagnostics détaillés ;

- logs verbeux ;

- statistiques ;

- opérations non critiques.

```

### 8.7 Tests associés

**Exemples :**

```text

- conversion d’une mesure ;

- franchissement d’un seuil ;

- retour sous seuil avec hystérésis ;

- temporisation avant alarme ;

- agrégation d’état global ;

- priorité défaut critique ;

- traitement d’une donnée invalide.

```

---

## 9. Exigences de commande des sorties

### 9.1 Objet des commandes

Cette partie décrit les sorties que le firmware peut commander : relais, sorties numériques, sorties analogiques, voyants, afficheurs, modules de communication, actionneurs ou signaux vers un équipement tiers.

### 9.2 Liste des sorties commandées

**Exemple :**

```text

Sortie      | Usage               | Commandée par | Mode autorisé       | Criticité

OUT_RELAY_1 | commande contacteur | firmware      | nominal/maintenance | critique

LED_STATUS  | état système        | firmware      | tous modes          | faible

OUT_FAULT   | défaut général      | firmware      | tous modes          | élevée

BUZZER      | alarme locale       | firmware      | nominal/défaut      | moyenne

```

### 9.3 Conditions d’autorisation des commandes

Cette partie décrit les conditions nécessaires avant d’activer une sortie.

**Exemples :**

```text

SW-CMD-001 — Le logiciel embarqué doit vérifier les conditions de sécurité avant d’activer une sortie critique.

SW-CMD-002 — Une commande critique ne doit être autorisée que dans les modes prévus.

SW-CMD-003 — Une commande critique doit être refusée si un défaut incompatible est actif.

SW-CMD-004 — Toute commande critique doit être journalisée.

```

### 9.4 État initial et état sûr

Cette partie décrit l’état des sorties au démarrage, en défaut et à l’arrêt.

**Exemples :**

```text

SW-CMD-SAFE-001 — Au démarrage, les sorties critiques doivent rester dans leur état sûr jusqu’à validation du mode courant.

SW-CMD-SAFE-002 — En cas de défaut critique, le logiciel embarqué doit placer les sorties concernées dans leur état sûr.

SW-CMD-SAFE-003 — En mode arrêt d’urgence, le logiciel embarqué ne doit pas réactiver une sortie critique sans procédure de réarmement.

```

### 9.5 Commandes locales et commandes distantes

Cette partie distingue les commandes issues du firmware, d’un opérateur local ou du serveur.

**Exemples :**

```text

Commande locale automatique :

déclenchée par le firmware selon une règle interne.

Commande distante :

reçue du serveur ou de l’IHM.

Commande maintenance :

déclenchée localement par un technicien habilité.

Commande de sécurité :

déclenchée par un événement critique ou une entrée de sécurité.

```

**Exemple d’exigence :**

```text

SW-CMD-DIST-001 — Le logiciel embarqué doit refuser toute commande distante si la communication n’est pas authentifiée ou si le mode courant ne l’autorise pas.

```

### 9.6 Confirmation de commande

Cette partie décrit comment le firmware confirme ou refuse une commande.

**Exemples :**

```text

SW-CMD-ACK-001 — Le logiciel embarqué doit produire un retour d’exécution après réception d’une commande.

SW-CMD-ACK-002 — Le retour d’exécution doit indiquer si la commande a été acceptée, refusée, exécutée ou échouée.

SW-CMD-ACK-003 — En cas de refus, le motif doit être identifiable.

```

### 9.7 Tests associés

**Exemples :**

```text

- commande sortie autorisée ;

- commande sortie refusée par mode incompatible ;

- commande refusée par défaut actif ;

- état sûr au démarrage ;

- état sûr après défaut critique ;

- retour d’exécution ;

- journalisation de commande ;

- refus commande distante non autorisée.

```

---

## 10. Exigences de gestion des alarmes et événements

### 10.1 Objet de la gestion des alarmes

Cette partie décrit comment le firmware doit générer, maintenir, clôturer, historiser et transmettre les alarmes.

Les alarmes peuvent être locales ou transmises au serveur. Elles peuvent concerner un défaut capteur, une perte de communication, un dépassement de seuil, un défaut matériel, un défaut logiciel, un état de sécurité ou une erreur de configuration.

### 10.2 Types d’événements

**Exemples :**

```text

- mesure hors seuil ;

- défaut capteur ;

- défaut communication ;

- défaut stockage ;

- redémarrage ;

- passage de mode ;

- commande opérateur ;

- défaut configuration ;

- mise à jour ;

- watchdog ;

- arrêt d’urgence.

```

### 10.3 Niveaux de criticité

Cette partie décrit les niveaux d’alarme.

**Exemple :**

```text

Information :

événement utile mais sans impact opérationnel direct.

Mineure :

défaut non critique, surveillance à prévoir.

Majeure :

défaut impactant une fonction importante.

Critique :

défaut pouvant affecter la sécurité, la disponibilité ou l’état sûr.

```

### 10.4 Création d’une alarme

Cette partie décrit les informations minimales associées à une alarme.

**Exemples :**

```text

SW-ALM-001 — Toute alarme générée par le logiciel embarqué doit comporter un identifiant unique ou un type d’alarme.

SW-ALM-002 — Toute alarme doit comporter un horodatage.

SW-ALM-003 — Toute alarme doit comporter un niveau de criticité.

SW-ALM-004 — Toute alarme doit indiquer l’origine du défaut lorsque cette origine est connue.

SW-ALM-005 — Toute alarme doit être journalisée localement si la ressource de stockage est disponible.

```

### 10.5 Cycle de vie d’une alarme

Cette partie décrit les états possibles d’une alarme.

**Exemple :**

```text

- apparue ;

- active ;

- acquittée ;

- disparue ;

- clôturée ;

- historisée ;

- retransmise au serveur ;

- non transmise en attente de synchronisation.

```

### 10.6 Acquittement d’alarme

Cette partie décrit les règles d’acquittement.

**Exemples :**

```text

SW-ALM-ACK-001 — Le logiciel embarqué doit accepter l’acquittement d’une alarme uniquement si cette fonction est autorisée pour le type d’alarme.

SW-ALM-ACK-002 — L’acquittement d’une alarme ne doit pas masquer le défaut si la condition d’apparition est toujours présente.

SW-ALM-ACK-003 — L’acquittement doit être journalisé avec son origine lorsque cette information est disponible.

```

### 10.7 Transmission des alarmes au serveur

Cette partie décrit l’envoi des alarmes.

**Exemples :**

```text

SW-ALM-COM-001 — Le logiciel embarqué doit transmettre les alarmes au serveur lorsque la communication est disponible.

SW-ALM-COM-002 — En cas de perte de communication, les alarmes non transmises doivent être conservées localement selon la politique de stockage.

SW-ALM-COM-003 — Au retour de communication, les alarmes non transmises doivent être retransmises avec leur horodatage d’origine.

```

### 10.8 Tests associés

**Exemples :**

```text

- génération d’une alarme sur seuil ;

- génération d’une alarme capteur absent ;

- alarme critique et passage état sûr ;

- acquittement autorisé ;

- acquittement refusé ;

- conservation alarme en perte réseau ;

- retransmission alarme après retour réseau ;

- clôture alarme après disparition défaut.

```

---

## 11. Exigences de communication avec le serveur

### 11.1 Objet de la communication serveur

Cette partie décrit les échanges entre le firmware et le serveur applicatif.

Le firmware peut transmettre des mesures, alarmes, événements, états, logs ou diagnostics. Il peut recevoir des acquittements, configurations, commandes, demandes de diagnostic ou mises à jour.

### 11.2 Types de messages transmis

**Exemples :**

```text

- mesures périodiques ;

- alarmes ;

- événements ;

- état courant ;

- informations de diagnostic ;

- version firmware ;

- configuration active ;

- logs ;

- résultats de commande ;

- état de synchronisation.

```

### 11.3 Types de messages reçus

**Exemples :**

```text

- acquittements ;

- configuration ;

- commande distante ;

- demande de diagnostic ;

- demande de mise à jour ;

- demande de resynchronisation ;

- synchronisation horaire ;

- changement de seuils.

```

### 11.4 Établissement de communication

Cette partie décrit les conditions de connexion.

**Exemples :**

```text

SW-COM-001 — Le logiciel embarqué doit tenter d’établir la communication avec le serveur selon la configuration active.

SW-COM-002 — Le logiciel embarqué doit signaler l’état de communication : connecté, déconnecté, dégradé, en erreur.

SW-COM-003 — Le logiciel embarqué doit identifier le serveur cible à partir de la configuration validée.

```

### 11.5 Acquittements

Cette partie décrit la gestion des acquittements.

**Exemples :**

```text

SW-COM-ACK-001 — Le logiciel embarqué doit considérer un message comme transmis uniquement après réception d’un acquittement valide si le protocole retenu l’exige.

SW-COM-ACK-002 — En absence d’acquittement, le logiciel embarqué doit conserver le message à retransmettre si ce message est critique.

SW-COM-ACK-003 — Les acquittements invalides ou incohérents doivent être rejetés.

```

### 11.6 Détection de perte de communication

Cette partie décrit les critères de perte serveur.

**Exemples :**

```text

SW-COM-LOSS-001 — Le logiciel embarqué doit détecter une perte de communication si aucun acquittement valide n’est reçu pendant la durée définie.

SW-COM-LOSS-002 — La perte de communication doit déclencher le mode dégradé communication.

SW-COM-LOSS-003 — La perte de communication doit être journalisée localement.

```

### 11.7 Reconnexion et resynchronisation

Cette partie décrit le retour au nominal.

**Exemples :**

```text

SW-COM-SYNC-001 — Au retour de la communication, le logiciel embarqué doit tenter de retransmettre les messages non acquittés.

SW-COM-SYNC-002 — Les messages retransmis doivent conserver leur horodatage d’origine.

SW-COM-SYNC-003 — Le logiciel embarqué doit éviter les doublons de transmission lorsque le protocole permet leur détection.

SW-COM-SYNC-004 — Le retour au mode nominal ne doit être autorisé qu’après satisfaction des critères définis dans le dossier des modes.

```

### 11.8 Sécurité de communication

Cette partie décrit les exigences de protection des échanges.

**Exemples :**

```text

SW-COM-SEC-001 — Le logiciel embarqué doit utiliser les mécanismes de sécurité définis pour authentifier ou protéger les échanges avec le serveur.

SW-COM-SEC-002 — Le logiciel embarqué ne doit pas accepter une commande distante provenant d’une source non autorisée.

SW-COM-SEC-003 — Les erreurs de sécurité de communication doivent être journalisées et signalées selon leur criticité.

```

### 11.9 Tests associés

**Exemples :**

```text

- connexion serveur nominale ;

- transmission mesure ;

- transmission alarme ;

- réception acquittement ;

- absence acquittement ;

- coupure réseau ;

- retour réseau ;

- retransmission messages ;

- message serveur invalide ;

- commande distante autorisée ;

- commande distante refusée.

```

---

## 12. Exigences de stockage local

### 12.1 Objet du stockage local

Cette partie décrit les données que le firmware doit conserver localement.

Le stockage local est souvent nécessaire pour gérer les pertes réseau, conserver les configurations, journaliser les défauts, permettre le diagnostic et protéger certaines données avant transmission.

### 12.2 Données stockées localement

**Exemples :**

```text

- configuration active ;

- mesures non transmises ;

- alarmes non transmises ;

- événements critiques ;

- logs de diagnostic ;

- dernier état connu ;

- cause du dernier redémarrage ;

- version firmware ;

- compteurs d’erreurs ;

- informations de maintenance.

```

### 12.3 Stockage des données non transmises

Cette partie décrit la conservation des données en perte communication.

**Exemples :**

```text

SW-STO-001 — Le logiciel embarqué doit conserver localement les données critiques non transmises au serveur.

SW-STO-002 — Les données stockées localement doivent conserver leur horodatage d’origine.

SW-STO-003 — Les données stockées localement doivent être retransmissibles après retour de communication.

SW-STO-004 — Le logiciel embarqué doit distinguer les données transmises, non transmises et acquittées si le protocole le nécessite.