Canevas 7B — Spécification détaillée software embarqué » History » Revision 1
Revision 1/3
| Next »
Redmine Admin, 06/19/2026 04:26 AM
Canevas 7B — Spécification détaillée software embarqué¶
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.
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 :
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 :
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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
- 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 :
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 :
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 :
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 :
- 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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
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 :
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 :
- 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 :
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 :
- 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 :
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 :
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 :
- 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 :
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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
- 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 :
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 :
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 :
- 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 :
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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
- 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 :
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.
12.4 Gestion de la saturation¶
Cette partie décrit le comportement lorsque la mémoire locale est pleine ou proche de l’être.
Exemples :
SW-STO-SAT-001 — Le logiciel embarqué doit détecter une saturation prochaine du stockage local.
SW-STO-SAT-002 — Le logiciel embarqué doit générer une alarme lorsque le stockage local dépasse le seuil défini.
SW-STO-SAT-003 — En cas de saturation, le logiciel embarqué doit appliquer la politique de conservation définie : blocage, écrasement contrôlé, priorité aux données critiques ou passage en mode dégradé stockage.
12.5 Priorité des données¶
Cette partie décrit les données à conserver en priorité.
Exemple :
Priorité 1 :
- alarmes critiques ;
- événements de sécurité ;
- commandes ;
- défauts système.
Priorité 2 :
- mesures importantes ;
- événements de fonctionnement ;
- données de resynchronisation.
Priorité 3 :
- logs détaillés ;
- statistiques ;
- traces de debug.
12.6 Intégrité des données locales¶
Cette partie décrit comment éviter ou détecter la corruption des données.
Exemples :
SW-STO-INT-001 — Le logiciel embarqué doit détecter toute incohérence majeure des données locales si le support de stockage permet ce contrôle.
SW-STO-INT-002 — Le logiciel embarqué doit éviter la perte silencieuse de données critiques.
SW-STO-INT-003 — En cas de corruption détectée, le logiciel embarqué doit générer un défaut de stockage.
12.7 Tests associés¶
Exemples :
- stockage local en perte réseau ;
- retransmission après retour réseau ;
- saturation progressive ;
- priorité données critiques ;
- redémarrage avec données non transmises ;
- corruption simulée ;
- suppression contrôlée ;
- alarme stockage.
13. Exigences de configuration¶
13.1 Objet de la configuration¶
Cette partie décrit les paramètres utilisés par le firmware pour fonctionner.
La configuration peut inclure des seuils, périodicités, identifiants, paramètres réseau, modes autorisés, paramètres de diagnostic, options hardware, niveaux d’alarme ou informations de serveur.
13.2 Paramètres configurables¶
Exemples :
- identifiant équipement ;
- adresse serveur ;
- port de communication ;
- fréquence d’acquisition ;
- seuils d’alarme ;
- hystérésis ;
- temporisations ;
- activation ou désactivation d’une fonction ;
- durée de stockage local ;
- niveaux de logs ;
- paramètres de mise à jour ;
- options hardware installées.
13.3 Chargement de configuration¶
Cette partie décrit comment le firmware charge la configuration.
Exemples :
SW-CFG-001 — Le logiciel embarqué doit charger sa configuration au démarrage.
SW-CFG-002 — Le logiciel embarqué doit vérifier la validité de la configuration avant de l’appliquer.
SW-CFG-003 — En cas de configuration invalide, le logiciel embarqué doit refuser le passage en mode nominal si la configuration est nécessaire au fonctionnement.
13.4 Modification de configuration¶
Cette partie décrit les règles de modification.
Exemples :
SW-CFG-MOD-001 — Le logiciel embarqué doit accepter une modification de configuration uniquement si son origine est autorisée.
SW-CFG-MOD-002 — Toute modification d’un paramètre critique doit être journalisée.
SW-CFG-MOD-003 — Le logiciel embarqué doit vérifier la cohérence d’une nouvelle configuration avant application.
SW-CFG-MOD-004 — Une configuration invalide doit être rejetée avec un motif identifiable.
13.5 Version de configuration¶
Cette partie décrit la gestion des versions de configuration.
Exemples :
SW-CFG-VER-001 — La configuration active doit comporter un identifiant ou une version.
SW-CFG-VER-002 — Le logiciel embarqué doit pouvoir fournir la version de configuration active au serveur ou à l’outil de diagnostic.
SW-CFG-VER-003 — Après mise à jour de configuration, l’ancienne version doit être conservée si un retour arrière est requis.
13.6 Configuration par défaut¶
Cette partie décrit le comportement en absence de configuration spécifique.
Exemples :
SW-CFG-DEF-001 — Le logiciel embarqué peut disposer d’une configuration par défaut uniquement si cette configuration est explicitement validée.
SW-CFG-DEF-002 — La configuration par défaut ne doit pas permettre une commande critique non maîtrisée.
SW-CFG-DEF-003 — L’utilisation d’une configuration par défaut doit être signalée ou journalisée.
13.7 Tests associés¶
Exemples :
- chargement configuration valide ;
- configuration absente ;
- configuration corrompue ;
- modification seuil autorisée ;
- modification seuil refusée ;
- configuration incompatible hardware ;
- retour arrière configuration ;
- lecture version configuration.
14. Exigences de diagnostic et journalisation¶
14.1 Objet du diagnostic logiciel embarqué¶
Cette partie décrit les informations que le firmware doit fournir pour permettre l’exploitation, le support technique, la maintenance et l’analyse d’incidents.
14.2 Informations de diagnostic¶
Exemples :
- version firmware ;
- version hardware détectée ;
- configuration active ;
- mode courant ;
- dernier défaut ;
- cause du dernier redémarrage ;
- état communication ;
- niveau stockage local ;
- état entrées/sorties ;
- compteurs d’erreurs ;
- état de synchronisation ;
- historique de transitions de mode ;
- état watchdog.
14.3 Logs locaux¶
Cette partie décrit les journaux produits localement.
Exemples :
SW-LOG-001 — Le logiciel embarqué doit journaliser les événements significatifs.
SW-LOG-002 — Le logiciel embarqué doit journaliser les défauts critiques.
SW-LOG-003 — Le logiciel embarqué doit journaliser les transitions de mode.
SW-LOG-004 — Le logiciel embarqué doit journaliser les commandes critiques.
SW-LOG-005 — Le logiciel embarqué ne doit pas stocker de secret sensible en clair dans les journaux.
14.4 Niveaux de logs¶
Exemples :
DEBUG :
informations détaillées pour diagnostic avancé.
INFO :
événement normal significatif.
WARNING :
situation anormale non bloquante.
ERROR :
erreur fonctionnelle ou technique.
CRITICAL :
défaut critique, sécurité, état sûr ou arrêt d’urgence.
14.5 Export des logs¶
Cette partie décrit comment les logs peuvent être récupérés.
Exemples :
- transmission serveur ;
- export via port maintenance ;
- export via commande diagnostic ;
- export automatique après défaut critique ;
- export manuel par technicien habilité.
Exemple d’exigence :
SW-LOG-EXP-001 — Le logiciel embarqué doit permettre l’export des journaux de diagnostic selon les moyens prévus dans l’architecture.
14.6 Limitation des volumes de logs¶
Cette partie décrit la rotation ou la purge.
Exemples :
SW-LOG-ROT-001 — Le logiciel embarqué doit limiter la taille des journaux afin d’éviter la saturation du stockage local.
SW-LOG-ROT-002 — Les événements critiques doivent être conservés prioritairement par rapport aux traces de debug.
SW-LOG-ROT-003 — Le niveau de log doit pouvoir être configuré si cette fonction est prévue.
14.7 Tests associés¶
Exemples :
- génération log démarrage ;
- génération log défaut ;
- génération log transition mode ;
- export logs ;
- saturation logs ;
- absence de secret dans logs ;
- conservation log critique ;
- lecture version firmware.
15. Exigences de mise à jour firmware¶
15.1 Objet de la mise à jour firmware¶
Cette partie décrit les exigences relatives au remplacement ou à l’évolution du logiciel embarqué.
La mise à jour firmware est sensible : elle peut immobiliser l’équipement, modifier son comportement, introduire des incompatibilités ou rendre l’équipement inutilisable en cas d’échec.
15.2 Conditions d’autorisation de mise à jour¶
Exemples :
SW-MAJ-001 — La mise à jour firmware doit être autorisée uniquement dans les conditions prévues par le dossier des modes.
SW-MAJ-002 — Le logiciel embarqué ne doit pas lancer de mise à jour si une commande critique est en cours.
SW-MAJ-003 — La mise à jour doit être déclenchée uniquement par une source autorisée.
SW-MAJ-004 — La version cible doit être vérifiée avant installation si le mécanisme le permet.
15.3 Vérification du paquet de mise à jour¶
Cette partie décrit les contrôles préalables.
Exemples :
- compatibilité version hardware ;
- intégrité du paquet ;
- authenticité ;
- taille ;
- version cible ;
- dépendances ;
- espace disponible ;
- état d’alimentation ;
- mode courant.
15.4 Déroulement de mise à jour¶
Cette partie décrit les étapes attendues au niveau comportemental.
Exemple :
SW-MAJ-010 — Le logiciel embarqué doit passer dans un mode de mise à jour avant de modifier le firmware.
SW-MAJ-011 — Le logiciel embarqué doit journaliser le début et la fin de la mise à jour.
SW-MAJ-012 — Après mise à jour, le logiciel embarqué doit redémarrer ou réinitialiser les composants nécessaires selon la procédure définie.
SW-MAJ-013 — Après mise à jour, le logiciel embarqué doit exposer la nouvelle version installée.
15.5 Échec de mise à jour¶
Cette partie décrit le comportement attendu en cas d’échec.
Exemples :
SW-MAJ-ERR-001 — En cas d’échec de mise à jour, le logiciel embarqué doit signaler l’échec.
SW-MAJ-ERR-002 — En cas d’échec, le système doit rester dans un état maîtrisé.
SW-MAJ-ERR-003 — Si un mécanisme de retour arrière est prévu, le logiciel embarqué doit revenir à la dernière version valide.
SW-MAJ-ERR-004 — L’échec de mise à jour doit être journalisé.
15.6 Tests associés¶
Exemples :
- mise à jour nominale ;
- paquet invalide ;
- version incompatible ;
- coupure pendant mise à jour ;
- espace insuffisant ;
- retour arrière ;
- lecture nouvelle version ;
- journalisation mise à jour.
16. Exigences de sécurité et cybersécurité embarquée¶
16.1 Objet de la sécurité software embarqué¶
Cette partie décrit les exigences visant à protéger le firmware, les données locales, les commandes, la configuration et les communications.
16.2 Contrôle des commandes¶
Exemples :
SW-SEC-CMD-001 — Le logiciel embarqué doit refuser toute commande non autorisée.
SW-SEC-CMD-002 — Le logiciel embarqué doit vérifier que le mode courant autorise la commande reçue.
SW-SEC-CMD-003 — Les commandes critiques doivent être journalisées.
SW-SEC-CMD-004 — Une commande invalide ou mal formée ne doit pas provoquer de comportement non maîtrisé.
16.3 Protection de la configuration¶
Exemples :
SW-SEC-CFG-001 — Le logiciel embarqué doit vérifier la validité d’une configuration avant application.
SW-SEC-CFG-002 — Le logiciel embarqué doit refuser une configuration non autorisée ou incohérente.
SW-SEC-CFG-003 — Les paramètres sensibles doivent être protégés contre une modification non maîtrisée.
16.4 Protection des secrets¶
Cette partie concerne les mots de passe, clés, certificats, jetons ou identifiants techniques.
Exemples :
SW-SEC-SECRET-001 — Le logiciel embarqué ne doit pas exposer les secrets techniques dans les logs.
SW-SEC-SECRET-002 — Les secrets techniques doivent être stockés selon les moyens de protection disponibles.
SW-SEC-SECRET-003 — Les secrets doivent pouvoir être renouvelés selon une procédure définie si cette exigence est applicable.
16.5 Robustesse face aux données invalides¶
Cette partie décrit la résistance aux messages ou entrées invalides.
Exemples :
SW-SEC-ROB-001 — Le logiciel embarqué doit rejeter les messages mal formés.
SW-SEC-ROB-002 — Le logiciel embarqué ne doit pas se bloquer en cas de réception d’une donnée invalide.
SW-SEC-ROB-003 — Les erreurs répétées de communication doivent être journalisées et éventuellement signalées.
16.6 Sécurité des mises à jour¶
Cette partie décrit les exigences liées à la mise à jour firmware.
Exemples :
SW-SEC-MAJ-001 — Le logiciel embarqué doit vérifier l’intégrité du paquet de mise à jour avant installation.
SW-SEC-MAJ-002 — Le logiciel embarqué doit refuser une mise à jour incompatible avec la version hardware.
SW-SEC-MAJ-003 — Une mise à jour ne doit pas être possible depuis une source non autorisée.
16.7 Tests associés¶
Exemples :
- commande non autorisée ;
- commande mal formée ;
- configuration invalide ;
- paquet mise à jour invalide ;
- tentative de modification paramètre critique ;
- absence de secret dans logs ;
- message réseau corrompu ;
- saturation par messages invalides.
17. Exigences temporelles et performances¶
17.1 Objet des exigences temporelles¶
Cette partie décrit les contraintes de temps, fréquence, délai, latence ou ordre d’exécution applicables au firmware.
Dans un logiciel embarqué, les contraintes temporelles peuvent être aussi importantes que les fonctions elles-mêmes.
17.2 Fréquences d’acquisition¶
Exemples :
SW-PERF-ACQ-001 — Le logiciel embarqué doit acquérir les mesures critiques avec la périodicité définie.
SW-PERF-ACQ-002 — La périodicité d’acquisition doit rester respectée en mode nominal dans les conditions de charge prévues.
SW-PERF-ACQ-003 — En mode dégradé, les acquisitions critiques doivent être maintenues si les ressources le permettent.
17.3 Délais de réaction¶
Cette partie décrit les temps maximaux avant réaction.
Exemples :
SW-PERF-REACT-001 — Le logiciel embarqué doit détecter un défaut critique dans le délai maximal défini.
SW-PERF-REACT-002 — Le logiciel embarqué doit placer les sorties critiques en état sûr dans le délai requis après détection d’un défaut critique.
SW-PERF-REACT-003 — Une perte de communication doit être détectée après le timeout configuré.
17.4 Délais de communication¶
Exemples :
SW-PERF-COM-001 — Le logiciel embarqué doit transmettre les messages périodiques selon la fréquence définie lorsque la communication est disponible.
SW-PERF-COM-002 — Après retour réseau, le logiciel embarqué doit lancer la resynchronisation dans le délai prévu.
SW-PERF-COM-003 — La resynchronisation ne doit pas empêcher le traitement des fonctions critiques locales.
17.5 Charge CPU et mémoire¶
Cette partie décrit les exigences de marge.
Exemples :
SW-PERF-RES-001 — Le logiciel embarqué doit fonctionner avec une marge de mémoire compatible avec les évolutions prévues.
SW-PERF-RES-002 — Le logiciel embarqué doit éviter toute fuite mémoire détectable sur une durée de fonctionnement représentative.
SW-PERF-RES-003 — Les buffers de communication doivent être dimensionnés pour les cas de charge prévus.
17.6 Tests associés¶
Exemples :
- fréquence acquisition ;
- délai défaut critique ;
- délai état sûr ;
- charge communication ;
- resynchronisation volumineuse ;
- fonctionnement prolongé ;
- mémoire stable ;
- saturation contrôlée.
18. Exigences de robustesse et sûreté de fonctionnement¶
18.1 Objet de la robustesse¶
Cette partie décrit le comportement du firmware face aux erreurs, défauts, données invalides, ressources indisponibles ou situations inattendues.
18.2 Gestion des erreurs récupérables¶
Exemples :
SW-ROB-001 — Le logiciel embarqué doit détecter les erreurs récupérables et poursuivre le fonctionnement lorsque cela est autorisé.
SW-ROB-002 — Une erreur récupérable doit être journalisée si elle est significative.
SW-ROB-003 — Les erreurs récupérables répétées doivent pouvoir être escaladées en défaut plus critique selon les règles définies.
18.3 Gestion des erreurs non récupérables¶
Exemples :
SW-ROB-CRIT-001 — En cas d’erreur non récupérable, le logiciel embarqué doit rejoindre un état sûr ou déclencher un redémarrage contrôlé selon les règles définies.
SW-ROB-CRIT-002 — Le logiciel embarqué doit éviter tout comportement indéfini en cas d’erreur critique.
SW-ROB-CRIT-003 — Les erreurs critiques doivent être historisées si possible.
18.4 Watchdog¶
Cette partie décrit l’usage du watchdog.
Exemples :
SW-WDG-001 — Le logiciel embarqué doit activer le mécanisme watchdog si celui-ci est prévu dans l’architecture.
SW-WDG-002 — Le logiciel embarqué doit rafraîchir le watchdog uniquement lorsque les fonctions critiques sont exécutées correctement.
SW-WDG-003 — Après déclenchement watchdog, le logiciel embarqué doit signaler un redémarrage anormal si cette information est disponible.
18.5 Reprise après erreur¶
Cette partie décrit les mécanismes de reprise.
Exemples :
- reprise communication ;
- reprise stockage ;
- reprise après reset ;
- reprise après défaut capteur ;
- reprise après configuration corrigée ;
- reprise après saturation ;
- retour au mode nominal sous conditions.
18.6 Tests associés¶
Exemples :
- erreur communication répétée ;
- donnée invalide ;
- saturation mémoire ;
- déclenchement watchdog ;
- redémarrage après watchdog ;
- stockage indisponible ;
- défaut capteur critique ;
- retour au nominal après correction.
19. Exigences d’interfaces avec le hardware¶
19.1 Objet des interfaces hardware/software¶
Cette partie décrit les interfaces entre le firmware et le matériel.
Elle sert de base commune entre l’équipe hardware et l’équipe software.
19.2 Liste des interfaces hardware utilisées¶
Exemple :
Interface | Usage | Type | Module software concerné
GPIO-IN-001 | contact porte | entrée numérique | InputManager
ADC-001 | température | entrée analogique | AcquisitionManager
GPIO-OUT-001 | relais commande | sortie numérique | OutputManager
UART-001 | module communication | série | CommunicationManager
NVM-001 | stockage configuration | mémoire non volatile | ConfigurationManager
RTC-001 | horodatage | horloge | TimeManager
WDG-001 | watchdog | périphérique sécurité | WatchdogManager
19.3 Lecture des entrées¶
Exemples :
SW-HW-IN-001 — Le logiciel embarqué doit lire les entrées matérielles selon la périodicité ou l’événement défini.
SW-HW-IN-002 — Le logiciel embarqué doit interpréter la polarité des entrées conformément à la spécification hardware.
SW-HW-IN-003 — Le logiciel embarqué doit gérer les états invalides ou incohérents des entrées.
19.4 Commande des sorties¶
Exemples :
SW-HW-OUT-001 — Le logiciel embarqué doit commander les sorties matérielles selon les règles de mode et de sécurité.
SW-HW-OUT-002 — Le logiciel embarqué doit appliquer l’état sûr défini pour chaque sortie critique.
SW-HW-OUT-003 — Le logiciel embarqué doit éviter toute activation intempestive lors du démarrage.
19.5 Gestion des périphériques¶
Exemples :
- ADC ;
- GPIO ;
- UART ;
- SPI ;
- I2C ;
- CAN ;
- Ethernet ;
- mémoire non volatile ;
- horloge RTC ;
- watchdog ;
- module radio.
19.6 Compatibilité versions hardware¶
Exemples :
SW-HW-COMP-001 — Le logiciel embarqué doit être compatible avec les versions hardware définies.
SW-HW-COMP-002 — Si plusieurs versions hardware sont supportées, le logiciel embarqué doit pouvoir identifier ou recevoir l’information de version hardware.
SW-HW-COMP-003 — Une version hardware non supportée doit être signalée.
19.7 Tests associés¶
Exemples :
- lecture GPIO ;
- lecture ADC ;
- commande relais ;
- inversion polarité ;
- périphérique absent ;
- version hardware incompatible ;
- état sortie au boot ;
- watchdog matériel.
20. Exigences d’interfaces avec le serveur et les systèmes externes¶
20.1 Objet des interfaces externes¶
Cette partie décrit les interactions du firmware avec le serveur applicatif, l’infrastructure, les équipements tiers ou les outils de maintenance.
20.2 Interface serveur¶
Exemples :
- transmission mesures ;
- transmission alarmes ;
- réception acquittements ;
- réception configuration ;
- transmission diagnostics ;
- synchronisation horaire ;
- mise à jour firmware ;
- commandes distantes.
20.3 Interface équipement tiers¶
Cette partie décrit les échanges avec un équipement tiers connecté au firmware.
Exemples :
- BMS ;
- automate ;
- capteur intelligent ;
- module communication ;
- afficheur ;
- convertisseur ;
- compteur ;
- système de sécurité.
Exemple d’exigence :
SW-EXT-001 — Le logiciel embarqué doit lire les données de l’équipement tiers selon le protocole défini dans la spécification des interfaces.
20.4 Interface maintenance locale¶
Cette partie décrit les fonctions accessibles via port local ou outil de diagnostic.
Exemples :
SW-MNT-IF-001 — Le logiciel embarqué doit permettre la consultation de son état courant via l’interface de maintenance prévue.
SW-MNT-IF-002 — Le logiciel embarqué doit permettre l’export des logs via l’interface de maintenance si cette fonction est prévue.
SW-MNT-IF-003 — Les commandes de maintenance critiques doivent être protégées contre un accès non autorisé.
20.5 Gestion des erreurs d’interface¶
Exemples :
- message mal formé ;
- timeout ;
- protocole incompatible ;
- version interface incorrecte ;
- donnée incohérente ;
- équipement tiers silencieux ;
- serveur indisponible.
20.6 Tests associés¶
Exemples :
- message serveur valide ;
- message serveur invalide ;
- acquittement absent ;
- protocole tiers silencieux ;
- données équipement tiers incohérentes ;
- outil maintenance connecté ;
- commande maintenance refusée.
21. Exigences de testabilité software embarqué¶
21.1 Objet de la testabilité¶
Cette partie décrit les exigences permettant de tester le firmware de manière efficace.
Un logiciel embarqué difficile à tester devient difficile à intégrer, maintenir et valider. La testabilité doit être prévue dès la spécification.
21.2 Observabilité¶
Cette partie décrit les informations que le firmware doit rendre observables.
Exemples :
- mode courant ;
- état communication ;
- état stockage ;
- état alarmes ;
- valeurs acquises ;
- dernière erreur ;
- compteurs ;
- version ;
- état des sorties ;
- état des entrées ;
- résultat de commande.
Exemple d’exigence :
SW-TEST-OBS-001 — Le logiciel embarqué doit permettre d’observer les états nécessaires aux tests d’intégration.
21.3 Commandabilité en test¶
Cette partie décrit les capacités nécessaires pour déclencher certains comportements en environnement de test.
Exemples :
- forcer une perte communication simulée ;
- injecter une mesure simulée ;
- déclencher un défaut capteur simulé ;
- déclencher une saturation stockage simulée ;
- passer en mode maintenance ;
- exporter les logs ;
- réinitialiser les compteurs ;
- lancer un autotest.
Exemple d’exigence :
SW-TEST-CMD-001 — Le logiciel embarqué doit permettre de déclencher certains autotests en mode maintenance, sans activer de commande dangereuse.
21.4 Tests unitaires software¶
Cette partie décrit les fonctions qui doivent pouvoir être testées isolément.
Exemples :
- conversion de mesure ;
- filtrage ;
- comparaison seuil ;
- gestion hystérésis ;
- création alarme ;
- validation configuration ;
- gestion file locale ;
- traitement message serveur ;
- décision de transition de mode ;
- formatage message de sortie.
21.5 Tests d’intégration hardware/software¶
Cette partie décrit les besoins de test avec le matériel.
Exemples :
- lecture entrée réelle ;
- commande sortie réelle ;
- défaut capteur ;
- perte alimentation ;
- watchdog ;
- stockage local réel ;
- port de maintenance ;
- module communication ;
- version hardware détectée.
21.6 Tests de non-régression¶
Cette partie décrit les exigences permettant de vérifier qu’une évolution ne casse pas des fonctions existantes.
Exemples :
SW-TEST-NR-001 — Toute évolution du firmware doit permettre l’exécution d’un ensemble minimal de tests de non-régression.
SW-TEST-NR-002 — Les fonctions critiques doivent être incluses dans les tests de non-régression.
SW-TEST-NR-003 — Les résultats de tests doivent être associés à la version firmware testée.
21.7 Tests associés¶
Exemples :
- tests unitaires conversion ;
- tests unitaires alarmes ;
- tests unitaires configuration ;
- tests unitaires stockage ;
- tests intégration entrées/sorties ;
- tests intégration communication ;
- tests non-régression après mise à jour.
22. Exigences de configuration, versionnement et livraison firmware¶
22.1 Objet de la gestion de configuration firmware¶
Cette partie décrit comment identifier, livrer et tracer les versions du logiciel embarqué.
22.2 Identification de version¶
Exemples :
SW-VER-001 — Le logiciel embarqué doit exposer sa version firmware.
SW-VER-002 — Le logiciel embarqué doit permettre d’identifier la version de configuration active.
SW-VER-003 — La version firmware doit être incluse dans les informations de diagnostic.
SW-VER-004 — La version firmware doit être transmise au serveur si cette fonction est prévue.
22.3 Compatibilité firmware / hardware¶
Cette partie décrit les contraintes de compatibilité.
Exemples :
SW-VER-COMP-001 — La version firmware doit être compatible avec les versions hardware définies.
SW-VER-COMP-002 — Une incompatibilité détectée entre firmware et hardware doit empêcher le fonctionnement nominal si elle peut provoquer un comportement dangereux.
SW-VER-COMP-003 — Les compatibilités firmware/hardware doivent être documentées.
22.4 Livraison firmware¶
Cette partie décrit les éléments livrés.
Exemples :
- fichier binaire firmware ;
- checksum ;
- signature si applicable ;
- note de version ;
- procédure d’installation ;
- procédure de retour arrière ;
- liste des corrections ;
- liste des exigences couvertes ;
- liste des tests exécutés ;
- configuration associée.
22.5 Note de version¶
Cette partie décrit le contenu attendu d’une release note.
Exemple :
Version :
Date :
Compatibilité hardware :
Nouvelles fonctions :
Corrections :
Anomalies connues :
Procédure de mise à jour :
Procédure de retour arrière :
Tests réalisés :
Restrictions :
22.6 Tests associés¶
Exemples :
- lecture version firmware ;
- compatibilité hardware ;
- livraison paquet firmware ;
- contrôle checksum ;
- installation version ;
- retour arrière ;
- vérification note de version.
23. Traçabilité¶
23.1 Traçabilité avec la spécification globale¶
Cette partie relie les exigences firmware aux exigences système.
Exemple :
Exigence système :
SYS-COM-004 — En cas de perte de communication serveur, le système doit maintenir les fonctions locales critiques et conserver les données nécessaires.
Exigences software embarqué associées :
SW-COM-LOSS-001 — Détecter la perte communication.
SW-MODE-COM-002 — Maintenir les acquisitions locales.
SW-STO-001 — Conserver localement les données critiques.
SW-COM-SYNC-001 — Retransmettre les messages au retour réseau.
23.2 Traçabilité avec l’architecture système¶
Cette partie relie les exigences firmware aux blocs d’architecture.
Exemple :
Bloc architecture :
SS-SW-001 — logiciel embarqué.
Exigences associées :
SW-ACQ-001, SW-MODE-001, SW-COM-001, SW-STO-001, SW-ALM-001, SW-DIAG-001.
23.3 Traçabilité avec le hardware¶
Cette partie relie les exigences firmware aux interfaces matérielles.
Exemple :
SW-HW-IN-001 — Lecture entrée contact porte
Interface hardware associée :
HW-IN-001 — entrée numérique isolée.
Test associé :
TEST-INT-HW-SW-001 — changement d’état contact et lecture firmware.
23.4 Traçabilité vers les tests¶
Cette partie relie chaque exigence logicielle à un ou plusieurs tests.
Exemple :
SW-ALM-001 — Génération alarme
Tests associés :
TEST-SW-ALM-001 — création alarme sur seuil.
TEST-INT-ALM-001 — transmission alarme au serveur.
TEST-SYS-ALM-001 — affichage alarme dans l’IHM.
23.5 Matrice de traçabilité software embarqué¶
Structure recommandée :
ID exigence software
Exigence système source
Interface hardware concernée
Interface serveur concernée
Élément de conception
Test unitaire
Test intégration
Test système
Statut
Commentaire
24. Contraintes, risques et points ouverts¶
24.1 Contraintes techniques¶
Cette partie liste les contraintes connues.
Exemples :
- mémoire limitée ;
- CPU limité ;
- stockage local limité ;
- fréquence acquisition imposée ;
- protocole serveur imposé ;
- hardware déjà défini ;
- absence de système d’exploitation ;
- RTOS imposé ;
- contraintes de consommation ;
- contraintes de temps réel ;
- impossibilité d’accès distant permanent ;
- compatibilité avec plusieurs versions hardware.
24.2 Risques software embarqué¶
Cette partie identifie les risques.
Exemples :
- saturation mémoire ;
- perte de données en coupure réseau ;
- doublons après resynchronisation ;
- mauvais état des sorties au démarrage ;
- temporisation mal dimensionnée ;
- watchdog déclenché à tort ;
- configuration invalide acceptée ;
- logs trop volumineux ;
- mise à jour échouée ;
- incompatibilité firmware/hardware ;
- mauvaise gestion d’un capteur critique.
24.3 Mesures de réduction des risques¶
Exemples :
- tests unitaires des fonctions critiques ;
- tests de coupure réseau ;
- tests de saturation stockage ;
- tests de démarrage ;
- tests watchdog ;
- simulation de capteur absent ;
- analyse de compatibilité firmware/hardware ;
- revue de code ;
- tests de non-régression ;
- journalisation des erreurs critiques.
24.4 Points ouverts¶
Cette partie liste les décisions non encore prises.
Exemple :
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-SW-001 | Timeout serveur | Durée exacte avant perte communication à confirmer | Système/client | avant conception | communication/modes | ouvert
PO-SW-002 | Stockage local | Politique en cas de saturation à confirmer | Système | avant conception | stockage/tests | ouvert
PO-SW-003 | Mise à jour | Mécanisme de retour arrière requis ou non | Client/fournisseur | avant conception | update/sécurité | ouvert
PO-SW-004 | Logs | Durée et volume de conservation locale | Maintenance | avant conception | diagnostic/stockage | ouvert
25. Critères d’acceptation de la spécification software embarqué¶
25.1 Complétude¶
Cette partie définit les critères permettant de considérer la spécification comme complète.
Exemples :
La spécification détaillée software embarqué est considérée comme complète si :
- les fonctions de démarrage sont décrites ;
- les modes de fonctionnement sont déclinés ;
- les acquisitions sont listées ;
- les traitements locaux sont spécifiés ;
- les commandes de sorties sont spécifiées ;
- les alarmes sont spécifiées ;
- les communications serveur sont décrites ;
- le stockage local est décrit ;
- la configuration est décrite ;
- le diagnostic est décrit ;
- la mise à jour est décrite ;
- les exigences de sécurité sont décrites ;
- les exigences de testabilité sont décrites ;
- les exigences critiques sont reliées à des tests.
25.2 Cohérence¶
Cette partie définit les critères de cohérence.
Exemples :
Le document ne doit pas contenir :
- d’exigence contradictoire avec le dossier des modes ;
- d’exigence incompatible avec le hardware ;
- de comportement non défini en cas de défaut critique ;
- de commande critique sans condition d’autorisation ;
- de donnée critique sans règle de stockage ;
- de perte réseau sans comportement de resynchronisation ;
- de configuration modifiable sans contrôle ;
- de mise à jour sans comportement en cas d’échec ;
- d’exigence non vérifiable.
25.3 Testabilité¶
Cette partie vérifie que la spécification permet de construire les tests.
Exemples :
La spécification est testable si :
- chaque exigence critique possède une méthode de vérification ;
- les entrées peuvent être simulées ou injectées ;
- les sorties peuvent être observées ;
- les modes peuvent être déclenchés ;
- les défauts principaux peuvent être simulés ;
- les logs permettent le diagnostic ;
- les tests unitaires et d’intégration peuvent être définis.
25.4 Maintenabilité¶
Cette partie vérifie que le firmware pourra être maintenu.
Exemples :
La spécification prend correctement en compte la maintenance si :
- la version firmware est identifiable ;
- les logs sont exportables ;
- les défauts sont diagnostiquables ;
- la configuration est consultable ;
- les mises à jour sont maîtrisées ;
- les incompatibilités hardware/software sont détectables ;
- les fonctions critiques sont documentées.
25.5 Validation du document¶
Cette partie précise les revues nécessaires.
Exemple :
La spécification détaillée software embarqué doit être relue par :
- le responsable software embarqué ;
- l’ingénieur système ;
- le responsable hardware ;
- le responsable serveur/application ;
- le responsable intégration ;
- le responsable validation ;
- le responsable cybersécurité ;
- le responsable maintenance ;
- le représentant client si le comportement embarqué impacte la recette.
26. Annexes¶
26.1 Liste complète des exigences software embarqué¶
Cette annexe peut contenir la liste tabulaire complète des exigences.
Exemple :
ID | Catégorie | Libellé | Criticité | Vérification | Statut
SW-BOOT-001 | démarrage | initialiser ressources | élevée | test | à faire
SW-ACQ-001 | acquisition | lire mesure périodique | élevée | test | à faire
SW-COM-LOSS-001 | communication | détecter perte serveur | élevée | test | à faire
SW-STO-001 | stockage | conserver données non transmises | élevée | test | à faire
SW-MAJ-001 | mise à jour | mise à jour autorisée uniquement | moyenne | test | à faire
26.2 Liste des données acquises¶
Cette annexe reprend toutes les mesures, états et événements acquis par le firmware.
26.3 Liste des alarmes embarquées¶
Cette annexe décrit les alarmes générées localement.
Exemple :
ID alarme | Condition | Criticité | Mode associé | Transmission serveur
ALM-TEMP-HIGH | température > seuil | majeure | nominal/dégradé | oui
ALM-COM-LOSS | perte serveur | majeure | dégradé communication | oui au retour
ALM-STO-SAT | stockage > seuil | majeure | dégradé stockage | oui
ALM-CFG-ERR | configuration invalide | critique | arrêt/maintenance | oui si possible
26.4 Liste des commandes¶
Cette annexe liste les commandes que le firmware peut exécuter.
Exemple :
Commande | Origine | Mode autorisé | Condition | Criticité
CMD-RESET | serveur/maintenance | maintenance | utilisateur habilité | élevée
CMD-SET-CONFIG | serveur | maintenance/nominal limité | config valide | élevée
CMD-OUTPUT-TEST | maintenance | maintenance | sortie non critique | moyenne
26.5 Liste des messages serveur¶
Cette annexe peut contenir la liste synthétique des messages échangés.
26.6 Liste des paramètres de configuration¶
Cette annexe reprend tous les paramètres configurables.
26.7 Matrice software / hardware¶
Cette annexe relie les fonctions firmware aux interfaces matérielles.
26.8 Matrice exigences / tests¶
Cette annexe reprend la matrice de vérification.
26.9 Glossaire software embarqué¶
Cette annexe définit les termes spécifiques au firmware.
26.10 Historique des décisions software¶
Cette annexe conserve les décisions importantes.
Exemple :
DEC-SW-001 :
La détection des alarmes critiques est réalisée localement dans le firmware.
Justification :
garantir la détection même en cas de perte communication serveur.
Impact :
nécessite des règles d’alarme embarquées, une configuration locale, un stockage local et des tests de synchronisation.
Updated by Redmine Admin 3 months ago · 3 revisions