Canevas 7D — Spécification détaillée des interfaces¶

1. Objet du document¶

1.1 Finalité de la spécification détaillée des interfaces¶

Cette partie précise l’objectif du document.

La spécification détaillée des interfaces décrit l’ensemble des points d’échange entre les composants du système ou entre le système et son environnement. Elle formalise les interfaces hardware, software, réseau, API, fichiers, IHM, maintenance, supervision, sauvegarde, systèmes tiers et procédures associées.

Ce document est essentiel dès qu’un projet comporte plusieurs sous-systèmes ou plusieurs équipes : hardware, software embarqué, serveur, infrastructure, réseau, IHM, maintenance, validation, client, fournisseur ou sous-traitants. Il permet d’éviter les zones floues entre les responsabilités et de garantir que chaque composant pourra effectivement communiquer ou interagir avec les autres.

Exemple :

Le présent document a pour objectif de spécifier de manière détaillée les interfaces internes et externes du système, incluant les interfaces matérielles, logicielles, réseau, API, fichiers, IHM, maintenance, supervision et systèmes tiers. Il précise pour chaque interface les responsabilités, les données échangées, les formats, les protocoles, les conditions d’utilisation, les erreurs possibles, les exigences de sécurité et les tests associés.

1.2 Positionnement dans le cycle en V¶

Cette partie situe le document dans le cycle en V.

La spécification détaillée des interfaces est produite à partir de la spécification globale, de l’architecture système, du dossier infrastructure et des spécifications détaillées des sous-systèmes. Elle sert d’entrée à la conception détaillée, au développement, au câblage, à l’intégration, aux tests d’interfaces, aux tests d’intégration et à la validation système.

Elle est particulièrement importante pour les tests d’intégration, car une grande partie des anomalies d’intégration provient d’interfaces incomplètes, ambiguës ou interprétées différemment par les équipes.

Spécification globale
        ↓
Architecture système / conception globale
        ↓
Spécifications détaillées hardware / software / serveur / infrastructure
        ↓
Spécification détaillée des interfaces
        ↓
Conceptions détaillées et réalisation
        ↑
Tests unitaires
        ↑
Tests d’interfaces
        ↑
Tests d’intégration
        ↑
Tests système
        ↑
Validation client

1.3 Différence avec l’architecture système¶

Cette partie précise la frontière avec le dossier d’architecture.

L’architecture système identifie les interfaces principales et leur rôle.
La spécification détaillée des interfaces décrit précisément leur contenu, leur format, leur comportement, leurs contraintes, leurs erreurs possibles et leurs critères de test.

Exemple :

Architecture système :
L’équipement embarqué communique avec le serveur applicatif via une interface réseau sécurisée.

Spécification détaillée des interfaces :
L’interface IF-NET-001 utilise HTTPS ou MQTT/TLS. Elle transporte des messages de type MEASURE, ALARM, STATE et DIAGNOSTIC. Chaque message contient un identifiant équipement, un horodatage, un type de message, une version de protocole, un identifiant de message et une charge utile. Le serveur retourne un acquittement ACCEPTED, REJECTED ou RETRY.

1.4 Différence avec les spécifications détaillées des sous-systèmes¶

Cette partie explique pourquoi un document spécifique aux interfaces est utile.

Les spécifications détaillées hardware, software embarqué et serveur décrivent les exigences propres à chaque sous-système. Le document d’interfaces décrit ce qui est partagé entre eux. Il constitue donc un contrat entre sous-systèmes.

Exemple :

Spécification software embarqué :
Le firmware doit transmettre les mesures au serveur.

Spécification serveur :
Le serveur doit recevoir les mesures transmises par les équipements.

Spécification d’interface :
Le message MEASURE doit contenir les champs equipment_id, message_id, timestamp_device, measure_type, value, unit, quality et protocol_version. Le serveur doit répondre par un acquittement contenant message_id, status et optional_error_code.

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

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

La spécification d’interfaces doit être rédigée par l’ingénieur système ou l’architecte, avec les contributions des responsables hardware, software embarqué, serveur, infrastructure, réseau, cybersécurité, validation, maintenance et systèmes tiers.

Exemple :

Rédaction : ingénieur système / architecte système / responsable intégration
Contribution : hardware, firmware, backend, frontend, infrastructure, réseau, cybersécurité, validation
Relecture : responsables de sous-systèmes, qualité, exploitation, maintenance
Approbation : responsable technique fournisseur et client si les interfaces sont contractuelles ou impliquent le SI client

---

2. Références et documents applicables¶

2.1 Documents d’entrée¶

Cette partie liste les documents utilisés pour définir les interfaces.

Exemples :

- Cahier des charges / expression de besoin
- Spécification globale / système
- Architecture système / conception globale
- Dossier des modes de fonctionnement
- Dossier infrastructure informatique / réseau / sauvegarde
- Spécification détaillée hardware
- Spécification détaillée software embarqué
- Spécification détaillée serveur / application
- Spécification cybersécurité
- Contraintes réseau client
- Documentation des équipements tiers
- Documentation des API externes
- Procédures d’exploitation et de maintenance

2.2 Documents applicables¶

Cette partie liste les standards, normes ou contraintes à respecter.

Exemples :

- standard de câblage client ;
- standard de connectique ;
- référentiel réseau client ;
- politique cybersécurité ;
- standard API REST ou MQTT ;
- format d’échange imposé ;
- politique de nommage des équipements ;
- règles de journalisation ;
- politique d’authentification ;
- contraintes RGPD si données personnelles ;
- règles de versionnement des interfaces.

2.3 Documents produits à partir de cette spécification¶

Cette partie liste les documents qui utiliseront cette spécification.

Exemples :

- conception détaillée hardware ;
- conception détaillée software embarqué ;
- conception détaillée serveur ;
- conception détaillée réseau ;
- conception API ;
- schémas de câblage ;
- dictionnaire de données ;
- procédures de tests d’interfaces ;
- procédures de tests d’intégration ;
- simulateurs d’équipements ;
- simulateurs serveur ;
- manuel d’installation ;
- manuel maintenance ;
- dossier de validation.

2.4 Gestion des versions d’interface¶

Cette partie précise comment les évolutions d’interface sont maîtrisées.

Une interface est souvent partagée par plusieurs équipes. Sa modification peut donc provoquer des incompatibilités. Les versions doivent être identifiées et les évolutions incompatibles doivent être explicitement tracées.

Exemple :

Toute modification d’un format de message, d’un connecteur, d’un brochage, d’un protocole, d’un endpoint API, d’un champ obligatoire, d’un code erreur ou d’un comportement d’acquittement doit faire l’objet d’une analyse d’impact sur les sous-systèmes concernés et sur les tests d’intégration.

---

3. Définitions, acronymes et conventions¶

3.1 Définitions¶

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

Exemples :

Interface :
Point d’échange entre deux composants, deux sous-systèmes ou entre le système et un élément externe.

Interface interne :
Interface entre deux composants appartenant au système.

Interface externe :
Interface entre le système et un élément hors périmètre : réseau client, équipement tiers, utilisateur, système externe.

Protocole :
Ensemble de règles définissant la manière dont deux composants échangent des informations.

Message :
Unité d’échange structurée transportant des données, une commande, un événement, une alarme ou un acquittement.

Acquittement :
Réponse confirmant qu’un message a été reçu, accepté, rejeté ou devra être retransmis.

Contrat d’interface :
Ensemble des règles que les deux parties d’une interface doivent respecter.

3.2 Acronymes¶

Exemples :

API : Application Programming Interface
CAN : Controller Area Network
CSV : Comma-Separated Values
GPIO : General Purpose Input/Output
HTTP : HyperText Transfer Protocol
HTTPS : HyperText Transfer Protocol Secure
IHM : Interface Homme-Machine
JSON : JavaScript Object Notation
MQTT : Message Queuing Telemetry Transport
REST : Representational State Transfer
RS485 : Bus série différentiel
TLS : Transport Layer Security
VPN : Virtual Private Network
XML : eXtensible Markup Language

3.3 Convention d’identification des interfaces¶

Cette partie définit une codification claire.

Exemple :

IF-HW-001 : interface matérielle
IF-SW-001 : interface logicielle interne
IF-NET-001 : interface réseau
IF-API-001 : API applicative
IF-IHM-001 : interface utilisateur
IF-DOC-001 : interface fichier ou document
IF-MNT-001 : interface maintenance
IF-SUP-001 : interface supervision
IF-TIERS-001 : interface système tiers

3.4 Convention de description d’une interface¶

Cette partie définit le format standard de description.

Chaque interface devrait être décrite avec une structure constante.

Identifiant interface :
Nom :
Type :
Source :
Destination :
Responsable source :
Responsable destination :
Sens d’échange :
Usage :
Données échangées :
Format :
Protocole :
Fréquence :
Criticité :
Sécurité :
Gestion des erreurs :
Logs associés :
Tests associés :
Commentaires :

3.5 Convention de criticité des interfaces¶

Cette partie permet de prioriser les interfaces.

Exemple :

Critique :
interface liée à la sécurité, aux commandes critiques, aux alarmes critiques ou à l’état sûr.

Élevée :
interface nécessaire au fonctionnement principal du système.

Moyenne :
interface importante pour l’exploitation, la maintenance ou le confort d’usage.

Faible :
interface secondaire, optionnelle ou non bloquante.

---

4. Vue générale des interfaces du système¶

4.1 Présentation générale¶

Cette partie donne une vue d’ensemble des interfaces du système.

Elle doit permettre de comprendre rapidement quels composants échangent avec quels autres composants et pour quel usage.

Exemple :

Le système comporte des interfaces entre l’équipement embarqué et les capteurs, entre le firmware et le hardware, entre l’équipement et le serveur, entre le serveur et la base de données, entre l’application et l’IHM, entre le serveur et les systèmes tiers, entre les administrateurs et les fonctions de maintenance, ainsi qu’entre l’application et les mécanismes de sauvegarde et supervision.

4.2 Liste synthétique des interfaces¶

Cette partie liste toutes les interfaces identifiées.

Exemple :

ID           | Nom                        | Type             | Source            | Destination        | Criticité
IF-HW-001    | alimentation équipement    | hardware         | alimentation site | équipement         | critique
IF-HW-002    | entrée capteur température | hardware         | capteur           | carte contrôle     | élevée
IF-SW-001    | lecture entrée numérique   | software interne | hardware          | firmware           | élevée
IF-NET-001   | équipement vers serveur    | réseau/API       | équipement        | serveur            | élevée
IF-API-001   | API mesures                | API              | équipement        | serveur            | élevée
IF-IHM-001   | tableau de bord            | IHM              | utilisateur       | serveur            | moyenne
IF-DOC-001   | export CSV mesures         | fichier          | serveur           | utilisateur        | faible/moyenne
IF-MNT-001   | port maintenance local     | maintenance      | technicien        | équipement         | élevée
IF-TIERS-001 | export supervision         | système tiers    | serveur           | supervision client | moyenne

4.3 Synoptique des interfaces¶

Cette partie doit contenir un schéma général.

Exemple textuel :

Capteurs / Actionneurs
        ↕ IF-HW
Équipement hardware
        ↕ IF-SW-HW
Firmware embarqué
        ↕ IF-NET / IF-API
Serveur applicatif
        ↕ IF-DB
Base de données
        ↕ IF-IHM
Interface utilisateur
        ↕ IF-TIERS
Systèmes externes

4.4 Interfaces internes et externes¶

Cette partie distingue les interfaces internes au système et celles avec l’extérieur.

Exemple :

Interfaces internes :
- firmware / hardware ;
- firmware / stockage local ;
- serveur / base de données ;
- backend / frontend ;
- serveur / supervision applicative.

Interfaces externes :
- équipement / capteurs externes ;
- équipement / réseau client ;
- serveur / système tiers ;
- application / utilisateur ;
- serveur / annuaire client ;
- serveur / outil de sauvegarde externe.

4.5 Interfaces critiques¶

Cette partie identifie les interfaces dont une défaillance a un impact fort.

Exemples :

- interface arrêt d’urgence ;
- interface commande relais critique ;
- interface équipement / serveur ;
- interface alarmes ;
- interface base de données ;
- interface configuration ;
- interface mise à jour ;
- interface authentification ;
- interface sauvegarde / restauration.

---

5. Interfaces hardware¶

5.1 Objet des interfaces hardware¶

Cette partie décrit les interfaces physiques entre le matériel du système et les éléments externes ou internes : alimentation, capteurs, actionneurs, connecteurs, borniers, ports, bus, boutons, voyants, arrêts d’urgence et signaux électriques.

5.2 Liste des interfaces hardware¶

Exemple :

ID        | Nom                     | Type              | Source            | Destination    | Usage              | Criticité
IF-HW-001 | alimentation principale | électrique        | alimentation site | équipement     | alimentation       | critique
IF-HW-002 | capteur température     | analogique        | capteur           | carte contrôle | mesure température | élevée
IF-HW-003 | contact porte           | numérique         | contact sec       | entrée carte   | état porte         | moyenne
IF-HW-004 | sortie relais           | relais            | carte contrôle    | actionneur     | commande           | critique
IF-HW-005 | Ethernet                | connecteur réseau | équipement        | réseau site    | communication      | élevée
IF-HW-006 | port maintenance        | USB/UART/Ethernet | technicien        | équipement     | diagnostic         | élevée

5.3 Description d’une interface d’alimentation¶

Cette partie décrit les interfaces d’alimentation.

Exemple :

Identifiant : IF-HW-001
Nom : alimentation principale
Type : électrique
Source : alimentation site
Destination : équipement
Usage : fournir l’énergie nécessaire au fonctionnement
Tension nominale : 24 VDC
Plage admissible : à définir selon projet
Protection : fusible, protection inversion, surtension si applicable
Criticité : critique
Défauts possibles : absence alimentation, sous-tension, surtension, inversion polarité
Comportement attendu : arrêt contrôlé ou état sûr selon possibilités
Tests associés : TEST-HW-ALIM-001, TEST-HW-ALIM-002

5.4 Description d’une interface capteur¶

Cette partie décrit les interfaces entre un capteur et l’équipement.

Exemple :

Identifiant : IF-HW-002
Nom : capteur température
Type : entrée analogique
Source : capteur température
Destination : carte de contrôle
Usage : mesurer la température interne ou externe
Donnée produite : température
Unité : °C
Plage attendue : selon capteur
Défauts détectables : capteur absent, valeur hors plage, court-circuit, rupture
Criticité : élevée
Traitement associé : acquisition, conversion, surveillance seuil
Tests associés : TEST-HW-CAPT-001, TEST-SW-ACQ-001, TEST-INT-CAPT-001

5.5 Description d’une interface actionneur ou relais¶

Cette partie décrit les sorties commandées.

Exemple :

Identifiant : IF-HW-004
Nom : sortie relais de commande
Type : sortie relais
Source : carte de contrôle
Destination : actionneur externe
Usage : commander une action physique
État au repos : ouvert
État sûr : ouvert
Commande autorisée en mode : nominal, maintenance sous conditions
Commande interdite en mode : arrêt, secours, arrêt d’urgence
Défauts possibles : relais bloqué, charge absente, retour d’état incohérent
Criticité : critique
Tests associés : TEST-HW-REL-001, TEST-INT-CMD-001, TEST-SAFE-001

5.6 Brochage et connectique¶

Cette partie décrit les connecteurs, broches et câblages.

Exemple :

Connecteur J1 — alimentation
Broche 1 : +24 VDC
Broche 2 : 0 V
Broche 3 : terre fonctionnelle si applicable

Connecteur J2 — entrées numériques
Broche 1 : IN1 contact porte
Broche 2 : IN2 défaut externe
Broche 3 : commun
Broche 4 : réserve

5.7 Contraintes de câblage¶

Cette partie décrit les règles à respecter pour le câblage.

Exemples :

- séparation puissance / signaux faibles ;
- blindage des câbles sensibles ;
- longueur maximale ;
- section minimale ;
- repérage des câbles ;
- détrompage connecteur ;
- rayon de courbure ;
- mise à la terre ;
- protection mécanique ;
- passage en presse-étoupe.

5.8 Erreurs et défauts hardware à gérer¶

Cette partie liste les défauts possibles sur les interfaces hardware.

Exemples :

- capteur absent ;
- court-circuit ;
- rupture de câble ;
- inversion de câblage ;
- tension hors plage ;
- relais bloqué ;
- contact instable ;
- perte alimentation ;
- connecteur débranché ;
- module communication absent.

5.9 Tests associés aux interfaces hardware¶

Exemples :

- test alimentation nominale ;
- test entrée capteur nominale ;
- test capteur hors plage ;
- test contact sec ouvert/fermé ;
- test sortie relais ;
- test état sûr relais ;
- test connecteur débranché ;
- test port maintenance ;
- test défaut câblage.

---

6. Interfaces firmware / hardware¶

6.1 Objet des interfaces firmware / hardware¶

Cette partie décrit les interfaces logiques entre le logiciel embarqué et le matériel : entrées lues, sorties commandées, périphériques utilisés, bus internes, mémoire, horloge, watchdog, stockage et modules de communication.

Ces interfaces sont importantes car elles font le lien direct entre la spécification hardware et la spécification software embarqué.

6.2 Liste des interfaces firmware / hardware¶

Exemple :

ID | Nom | Type | Hardware | Firmware | Usage
IF-SW-HW-001 | lecture entrée porte | GPIO | entrée numérique | InputManager | état porte
IF-SW-HW-002 | lecture température | ADC/I2C/SPI | capteur température | AcquisitionManager | mesure
IF-SW-HW-003 | commande relais | GPIO | sortie relais | OutputManager | commande
IF-SW-HW-004 | watchdog | périphérique sécurité | watchdog matériel | WatchdogManager | surveillance
IF-SW-HW-005 | stockage local | mémoire | mémoire non volatile | StorageManager | données locales
IF-SW-HW-006 | horloge RTC | RTC | horloge locale | TimeManager | horodatage

6.3 Lecture des entrées par le firmware¶

Cette partie décrit comment les entrées matérielles sont exposées au logiciel.

Exemples d’éléments à préciser :

- nom logique de l’entrée ;
- polarité ;
- état actif ;
- état au repos ;
- fréquence de lecture ;
- filtrage logiciel ;
- défaut détectable ;
- criticité ;
- mode dans lequel l’entrée est utilisée.

Exemple :

Interface : IF-SW-HW-001
Nom : lecture contact porte
Type : GPIO entrée numérique
Polarité : actif à 1
Fréquence lecture : 1 seconde ou événement
Filtrage : anti-rebond logiciel 100 ms
Défaut détectable : incohérence si état impossible selon mode
Traitement : mise à jour état porte, génération événement si changement

6.4 Commande des sorties par le firmware¶

Cette partie décrit la manière dont le firmware commande les sorties.

Exemples :

Interface : IF-SW-HW-003
Nom : commande relais principal
Type : GPIO sortie
État actif : 1
État sûr : 0
État au démarrage : 0
Modes autorisés : nominal, maintenance contrôlée
Modes interdits : arrêt, secours, arrêt d’urgence
Retour d’état : oui/non selon hardware
Test associé : TEST-INT-OUT-001

6.5 Accès au stockage local¶

Cette partie décrit l’interface entre firmware et mémoire locale.

Exemples :

- type de mémoire ;
- usage ;
- données stockées ;
- taille disponible ;
- comportement en saturation ;
- détection d’erreur ;
- intégrité ;
- nombre d’écritures ;
- effacement ;
- format logique ;
- tests associés.

6.6 Accès à l’horloge¶

Cette partie décrit l’interface avec une horloge temps réel ou une référence temporelle.

Exemples :

- lecture date/heure ;
- synchronisation serveur ;
- maintien en absence réseau ;
- dérive acceptable ;
- état horloge incertain ;
- défaut batterie RTC ;
- horodatage des événements.

6.7 Watchdog¶

Cette partie décrit l’interface avec le watchdog matériel ou logiciel.

Exemples :

- activation watchdog ;
- période de rafraîchissement ;
- conditions de rafraîchissement ;
- comportement en expiration ;
- cause du reset ;
- journalisation au redémarrage ;
- tests associés.

6.8 Tests associés aux interfaces firmware / hardware¶

Exemples :

- lecture entrée nominale ;
- lecture entrée bruitée ;
- commande sortie ;
- état sûr au démarrage ;
- mémoire locale écriture/lecture ;
- saturation mémoire ;
- horloge absente ;
- synchronisation horaire ;
- watchdog déclenché ;
- version hardware lue par firmware.

---

7. Interfaces équipement embarqué / serveur¶

7.1 Objet de l’interface équipement / serveur¶

Cette partie décrit l’interface principale entre les équipements embarqués et le serveur applicatif.

Elle est généralement critique, car elle permet la transmission des mesures, alarmes, événements, diagnostics, états et éventuellement la réception de configurations ou commandes.

7.2 Nature de l’interface¶

Cette partie précise le type d’interface utilisé.

Exemples :

- HTTPS REST ;
- MQTT/TLS ;
- WebSocket ;
- TCP propriétaire ;
- UDP ;
- fichier déposé dans un SAS ;
- liaison série via passerelle ;
- protocole industriel.

Exemple d’exigence :

IF-NET-001 — L’équipement embarqué doit communiquer avec le serveur applicatif via le protocole défini pour l’interface équipement / serveur.

7.3 Messages équipement vers serveur¶

Cette partie liste les messages montants.

Exemples :

- MEASURE : transmission de mesure ;
- ALARM : transmission d’alarme ;
- EVENT : transmission d’événement ;
- STATE : transmission d’état courant ;
- DIAGNOSTIC : transmission d’informations de diagnostic ;
- LOG : transmission de logs ;
- VERSION : transmission des versions ;
- SYNC_DATA : retransmission de données après perte réseau.

7.4 Messages serveur vers équipement¶

Cette partie liste les messages descendants.

Exemples :

- ACK : acquittement ;
- CONFIG : configuration ;
- COMMAND : commande ;
- TIME_SYNC : synchronisation horaire ;
- UPDATE_REQUEST : demande de mise à jour ;
- DIAG_REQUEST : demande de diagnostic ;
- RESET_REQUEST : demande de redémarrage contrôlé ;
- NACK / REJECT : rejet de message.

7.5 Structure commune des messages¶

Cette partie définit les champs communs.

Exemple :

Champ | Description | Obligatoire | Exemple
protocol_version | version du protocole | oui | 1.0
message_id | identifiant unique du message | oui | MSG-20260703-0001
equipment_id | identifiant équipement | oui | EQP-001
message_type | type de message | oui | MEASURE
timestamp_device | horodatage équipement | oui si disponible | 2026-07-03T14:02:10Z
timestamp_server | horodatage serveur | non, ajouté à réception | 2026-07-03T14:02:15Z
payload | contenu spécifique | oui | selon type

7.6 Exemple de message de mesure¶

Cette partie donne un exemple concret.

Exemple JSON indicatif :

{
  "protocol_version": "1.0",
  "message_id": "MSG-000123",
  "equipment_id": "EQP-001",
  "message_type": "MEASURE",
  "timestamp_device": "2026-07-03T14:02:10Z",
  "payload": {
    "measure_type": "temperature",
    "value": 42.5,
    "unit": "degC",
    "quality": "valid"
  }
}

7.7 Exemple de message d’alarme¶

{
  "protocol_version": "1.0",
  "message_id": "MSG-000124",
  "equipment_id": "EQP-001",
  "message_type": "ALARM",
  "timestamp_device": "2026-07-03T14:03:00Z",
  "payload": {
    "alarm_code": "TEMP_HIGH",
    "severity": "major",
    "status": "active",
    "description": "Temperature above configured threshold"
  }
}

7.8 Acquittements¶

Cette partie décrit les réponses du serveur.

Exemple :

{
  "protocol_version": "1.0",
  "message_id": "MSG-000124",
  "ack_id": "ACK-000985",
  "status": "ACCEPTED",
  "timestamp_server": "2026-07-03T14:03:02Z"
}

Statuts possibles :

ACCEPTED :
message accepté et pris en compte.

REJECTED :
message rejeté, non pris en compte.

RETRY :
message non traité, retransmission demandée.

DUPLICATE :
message déjà reçu et déjà traité.

UNAUTHORIZED :
équipement ou message non autorisé.

7.9 Gestion des erreurs de communication¶

Cette partie décrit les erreurs possibles.

Exemples :

- serveur non joignable ;
- timeout ;
- acquittement absent ;
- acquittement invalide ;
- message rejeté ;
- version protocole incompatible ;
- équipement non autorisé ;
- certificat invalide ;
- message dupliqué ;
- message trop volumineux ;
- erreur de format.

7.10 Resynchronisation après perte réseau¶

Cette partie décrit le comportement après une coupure.

Exemple :

Lorsqu’une communication est rétablie :
1. l’équipement vérifie l’accessibilité du serveur ;
2. l’équipement transmet les messages stockés localement ;
3. le serveur conserve l’horodatage d’origine ;
4. le serveur détecte les doublons éventuels ;
5. les messages acceptés sont acquittés ;
6. l’équipement marque les messages comme transmis ;
7. l’état de communication repasse au nominal si les conditions sont satisfaites.

7.11 Sécurité de l’interface¶

Cette partie décrit les protections.

Exemples :

- chiffrement TLS ;
- authentification équipement ;
- certificat client ;
- jeton ;
- signature de message ;
- contrôle d’intégrité ;
- contrôle de version protocole ;
- filtrage IP ;
- journalisation des erreurs de sécurité.

7.12 Tests associés¶

Exemples :

- transmission mesure nominale ;
- transmission alarme ;
- réception acquittement ACCEPTED ;
- réception REJECTED ;
- serveur indisponible ;
- coupure réseau ;
- retour réseau ;
- retransmission messages ;
- doublon ;
- message invalide ;
- équipement inconnu ;
- protocole incompatible ;
- certificat invalide.

---

8. Interfaces serveur / base de données¶

8.1 Objet de l’interface serveur / base de données¶

Cette partie décrit les échanges entre l’application serveur et la base de données.

Elle est essentielle pour l’historisation, les alarmes, la configuration, les utilisateurs, les droits, les rapports et la restauration.

8.2 Données écrites en base¶

Exemples :

- mesures ;
- alarmes ;
- événements ;
- états équipements ;
- utilisateurs ;
- rôles ;
- configurations ;
- commandes ;
- logs applicatifs ;
- exports ;
- rapports ;
- informations de maintenance.

8.3 Données lues depuis la base¶

Exemples :

- configuration active ;
- liste équipements ;
- historique mesures ;
- alarmes actives ;
- droits utilisateurs ;
- paramètres applicatifs ;
- rapports ;
- données de tableau de bord ;
- état système ;
- historique d’audit.

8.4 Contraintes d’intégrité¶

Cette partie décrit les règles à respecter.

Exemples :

- une mesure doit être associée à un équipement ;
- une alarme doit être associée à une source ;
- une action utilisateur doit être associée à un utilisateur connu ou à un compte système ;
- une configuration appliquée doit être versionnée ;
- les historiques ne doivent pas être supprimés lors de la désactivation d’un équipement ;
- une suppression doit être contrôlée et journalisée si elle concerne des données critiques.

8.5 Transactions et cohérence¶

Cette partie décrit les opérations qui doivent être cohérentes.

Exemple :

Lors de la réception d’une alarme :
1. le message est validé ;
2. l’alarme est créée ou mise à jour ;
3. l’événement associé est historisé ;
4. l’état équipement est mis à jour ;
5. l’acquittement serveur est préparé.

Ces actions doivent être cohérentes : il ne doit pas y avoir une alarme créée sans événement associé si cette association est obligatoire.

8.6 Gestion des erreurs base de données¶

Exemples :

- connexion impossible ;
- timeout ;
- contrainte d’intégrité violée ;
- espace disque saturé ;
- migration incomplète ;
- écriture refusée ;
- lecture incohérente ;
- verrouillage prolongé ;
- corruption détectée.

8.7 Tests associés¶

Exemples :

- écriture mesure ;
- écriture alarme ;
- lecture historique ;
- contrainte équipement inexistant ;
- base indisponible ;
- transaction interrompue ;
- migration base ;
- restauration base ;
- performance requête ;
- purge contrôlée.

---

9. Interfaces backend / frontend / IHM¶

9.1 Objet de l’interface backend / frontend¶

Cette partie décrit les échanges entre la partie serveur backend et l’interface utilisateur.

Elle peut être interne à l’application, mais doit être spécifiée si l’IHM est développée séparément, si des API sont exposées, ou si l’intégration doit être testée formellement.

9.2 Fonctions accessibles par l’IHM¶

Exemples :

- authentification ;
- consultation tableau de bord ;
- liste équipements ;
- détail équipement ;
- alarmes actives ;
- historique alarmes ;
- historique mesures ;
- acquittement alarme ;
- configuration ;
- administration utilisateurs ;
- exports ;
- diagnostic ;
- supervision.

9.3 Données affichées¶

Cette partie décrit les informations transmises à l’IHM.

Exemple :

Écran tableau de bord :
- nombre d’équipements actifs ;
- nombre d’équipements en défaut ;
- nombre d’équipements non joignables ;
- nombre d’alarmes critiques ;
- dernières alarmes ;
- état global système.

Écran équipement :
- identifiant ;
- nom ;
- site ;
- mode courant ;
- dernière communication ;
- alarmes actives ;
- mesures récentes ;
- version firmware ;
- configuration active.

9.4 Actions déclenchées depuis l’IHM¶

Exemples :

- acquitter une alarme ;
- modifier un paramètre ;
- lancer un export ;
- consulter des logs ;
- créer un utilisateur ;
- désactiver un équipement ;
- demander un diagnostic ;
- envoyer une commande ;
- lancer une restauration si autorisée ;
- lancer une mise à jour si autorisée.

9.5 Gestion des erreurs IHM¶

Cette partie décrit ce que l’utilisateur voit lorsqu’une action échoue.

Exemples :

- message d’erreur clair ;
- absence d’exposition de détails techniques sensibles ;
- indication de l’action non autorisée ;
- indication de session expirée ;
- indication de serveur indisponible ;
- indication de donnée introuvable ;
- possibilité de réessayer si pertinent.

9.6 Contrôle des droits côté IHM et backend¶

Cette partie précise que l’IHM ne suffit pas à sécuriser une action.

Exemple :

L’IHM peut masquer un bouton à un utilisateur non autorisé, mais le backend doit également refuser l’action si elle est appelée directement par API.

Exigences typiques :

IF-IHM-SEC-001 — Le backend doit contrôler les droits pour chaque action sensible.

IF-IHM-SEC-002 — L’IHM doit présenter uniquement les actions compatibles avec le profil utilisateur lorsque cela est possible.

IF-IHM-SEC-003 — Une action refusée doit produire un message compréhensible et être journalisée si nécessaire.

9.7 Tests associés¶

Exemples :

- affichage tableau de bord ;
- consultation équipement ;
- filtre historique ;
- acquittement alarme ;
- action refusée par droits insuffisants ;
- session expirée ;
- backend indisponible ;
- erreur API ;
- message utilisateur ;
- cohérence affichage backend.

---

10. Interfaces utilisateurs physiques ou locales¶

10.1 Objet des interfaces utilisateur locales¶

Cette partie décrit les interfaces physiques ou locales disponibles sur l’équipement : voyants, boutons, afficheur, buzzer, port maintenance, écran local, interrupteurs ou sélecteurs.

10.2 Voyants et signalisation¶

Exemples :

Voyant alimentation :
- allumé fixe : alimentation présente ;
- éteint : absence alimentation.

Voyant communication :
- allumé fixe : communication serveur OK ;
- clignotant : tentative connexion ;
- éteint : communication absente.

Voyant défaut :
- éteint : aucun défaut ;
- allumé fixe : défaut actif ;
- clignotant : défaut critique.

10.3 Boutons ou commandes locales¶

Cette partie décrit les commandes physiques.

Exemples :

- bouton démarrage ;
- bouton arrêt ;
- bouton reset ;
- bouton test ;
- bouton acquittement local ;
- bouton arrêt d’urgence ;
- sélecteur maintenance ;
- bouton export diagnostic.

Exemple de description :

Identifiant : IF-LOCAL-001
Nom : bouton reset local
Type : bouton physique
Usage : demander un redémarrage contrôlé
Conditions d’utilisation : mode maintenance ou défaut non critique
Effet attendu : redémarrage logiciel contrôlé
Actions interdites : reset en commande critique active
Journalisation : oui si possible
Tests associés : TEST-LOCAL-RESET-001

10.4 Afficheur local¶

Cette partie est utile si l’équipement possède un écran ou afficheur.

Exemples d’informations affichables :

- état système ;
- code défaut ;
- adresse IP ;
- mode courant ;
- niveau batterie ;
- état communication ;
- version firmware ;
- instructions maintenance ;
- progression mise à jour.

10.5 Buzzer ou signal sonore¶

Cette partie décrit les signaux sonores éventuels.

Exemples :

- alarme critique ;
- défaut technique ;
- confirmation action ;
- fin de test ;
- erreur utilisateur ;
- durée maximale d’activation ;
- inhibition en maintenance.

10.6 Tests associés¶

Exemples :

- voyant alimentation ;
- voyant communication ;
- voyant défaut ;
- bouton reset ;
- bouton test ;
- afficheur code défaut ;
- buzzer alarme ;
- inhibition signalisation en maintenance ;
- état au démarrage.

---

11. Interfaces de maintenance et diagnostic¶

11.1 Objet des interfaces maintenance¶

Cette partie décrit les moyens permettant à un technicien ou à un administrateur de diagnostiquer, configurer, tester, mettre à jour ou restaurer un composant.

Les interfaces de maintenance peuvent être locales ou distantes. Elles doivent être contrôlées, sécurisées et documentées.

11.2 Types d’interfaces de maintenance¶

Exemples :

- port USB local ;
- port série ;
- port Ethernet local ;
- interface web maintenance ;
- accès SSH ;
- outil de diagnostic ;
- API diagnostic ;
- export logs ;
- écran maintenance ;
- console administrateur ;
- serveur SAS ;
- VPN d’administration.

11.3 Fonctions accessibles en maintenance¶

Exemples :

- consulter les versions ;
- consulter l’état courant ;
- exporter les logs ;
- tester une entrée ;
- tester une sortie ;
- lire la configuration ;
- charger une configuration ;
- lancer un autotest ;
- redémarrer un service ;
- mettre à jour un firmware ;
- vérifier la connectivité ;
- lancer une sauvegarde ;
- restaurer une configuration.

11.4 Sécurité de l’interface maintenance¶

Cette partie est critique car les interfaces de maintenance donnent souvent accès à des fonctions sensibles.

Exemples d’exigences :

IF-MNT-SEC-001 — L’accès aux fonctions de maintenance doit être réservé aux utilisateurs ou techniciens habilités.

IF-MNT-SEC-002 — Les actions de maintenance critiques doivent être journalisées.

IF-MNT-SEC-003 — Une interface de maintenance ne doit pas permettre de contourner les règles de sécurité du système.

IF-MNT-SEC-004 — Les accès distants de maintenance doivent respecter les contraintes réseau et cybersécurité définies.

11.5 Export de diagnostic¶

Cette partie décrit les fichiers ou informations exportables.

Exemples :

- version hardware ;
- version firmware ;
- version serveur ;
- état des entrées/sorties ;
- derniers défauts ;
- logs locaux ;
- logs serveur ;
- configuration active ;
- état stockage ;
- état communication ;
- cause dernier redémarrage ;
- rapport de santé système.

11.6 Tests associés¶

Exemples :

- accès maintenance autorisé ;
- accès maintenance refusé ;
- export logs ;
- consultation version ;
- test entrée ;
- test sortie ;
- redémarrage contrôlé ;
- mise à jour firmware ;
- action critique journalisée ;
- accès distant via VPN.

---

12. Interfaces fichiers et exports¶

12.1 Objet des interfaces fichiers¶

Cette partie décrit les fichiers échangés, importés, exportés ou conservés par le système.

Les interfaces fichiers peuvent concerner la configuration, les historiques, les rapports, les logs, les sauvegardes, les mises à jour, les diagnostics ou les échanges avec des systèmes tiers.

12.2 Types de fichiers¶

Exemples :

- fichier de configuration ;
- export CSV ;
- export JSON ;
- rapport PDF ;
- fichier log ;
- fichier diagnostic ;
- fichier de sauvegarde ;
- paquet de mise à jour ;
- fichier d’import ;
- fichier d’échange système tiers ;
- fichier de mapping équipements.

12.3 Description d’un fichier de configuration¶

Exemple :

Identifiant : IF-DOC-001
Nom : fichier de configuration équipement
Format : JSON / YAML / XML / CSV selon choix
Usage : définir les paramètres applicables à un équipement
Producteur : serveur ou outil de configuration
Consommateur : firmware embarqué
Champs principaux :
- equipment_id ;
- acquisition_period ;
- thresholds ;
- communication_settings ;
- enabled_features ;
- version ;
- checksum.
Sécurité : contrôle d’intégrité, accès restreint
Tests associés : TEST-CFG-IMPORT-001, TEST-CFG-INVALID-001

12.4 Description d’un export CSV¶

Exemple :

Identifiant : IF-DOC-002
Nom : export historique mesures
Format : CSV
Producteur : serveur applicatif
Consommateur : utilisateur / outil externe
Séparateur : point-virgule ou virgule selon convention
Encodage : UTF-8
Colonnes :
- equipment_id ;
- timestamp_device ;
- timestamp_server ;
- measure_type ;
- value ;
- unit ;
- quality.
Filtres : équipement, période, type de mesure
Tests associés : TEST-EXP-CSV-001

12.5 Description d’un rapport PDF¶

Exemples d’informations à définir :

- titre du rapport ;
- période couverte ;
- équipement ou site ;
- synthèse ;
- alarmes ;
- mesures ;
- événements ;
- commentaires ;
- date de génération ;
- utilisateur générateur ;
- version de l’application ;
- mentions ou pied de page.

12.6 Fichiers de logs¶

Cette partie décrit les fichiers de journaux.

Exemples :

- format texte ou JSON ;
- horodatage ;
- niveau de log ;
- identifiant composant ;
- rotation ;
- compression ;
- durée conservation ;
- export ;
- protection contre modification ;
- absence de secrets en clair.

12.7 Fichiers de mise à jour¶

Cette partie décrit les paquets firmware ou applicatifs.

Exemples :

- nom du fichier ;
- version ;
- cible hardware/software ;
- checksum ;
- signature ;
- taille maximale ;
- date ;
- compatibilité ;
- procédure de contrôle ;
- procédure de rejet.

12.8 Tests associés¶

Exemples :

- import configuration valide ;
- import configuration invalide ;
- export CSV ;
- export volumineux ;
- encodage caractères spéciaux ;
- génération PDF ;
- fichier log sans secret ;
- paquet mise à jour invalide ;
- checksum incorrect ;
- fichier absent.

---

13. Interfaces réseau¶

13.1 Objet des interfaces réseau¶

Cette partie décrit les flux réseau nécessaires au fonctionnement du système.

Elle complète le dossier infrastructure en précisant les flux liés aux interfaces applicatives, aux équipements, aux utilisateurs, à la maintenance, à la sauvegarde et aux systèmes tiers.

13.2 Liste des flux réseau¶

Exemple :

ID flux | Source | Destination | Protocole | Port | Usage | Criticité
F-NET-001 | équipement | serveur applicatif | HTTPS/MQTT | 443/8883 | mesures/alarmes | élevée
F-NET-002 | poste opérateur | serveur applicatif | HTTPS | 443 | IHM | élevée
F-NET-003 | serveur applicatif | base données | TCP | selon DB | données | critique
F-NET-004 | serveur | sauvegarde | SSH/API | selon choix | backup | élevée
F-NET-005 | admin | serveur | VPN/SSH | selon choix | administration | élevée
F-NET-006 | serveur | système tiers | HTTPS/API | 443 | export | moyenne

13.3 Description détaillée d’un flux¶

Modèle :

ID flux :
Source :
Destination :
Sens :
Protocole :
Port :
Fréquence :
Données transportées :
Chiffrement :
Authentification :
Journalisation :
Comportement en cas d’échec :
Responsable réseau :
Tests associés :

13.4 Flux interdits¶

Cette partie liste les flux explicitement non autorisés.

Exemples :

- poste opérateur vers base de données ;
- équipement vers base de données ;
- accès Internet direct depuis base de données ;
- accès administrateur hors VPN ;
- accès SSH depuis un poste non autorisé ;
- transfert direct de fichier vers production sans SAS ;
- communication non chiffrée si interdite par politique sécurité.

13.5 Comportement en cas de perte réseau¶

Cette partie décrit l’impact fonctionnel.

Exemples :

Perte réseau équipement / serveur :
- passage firmware en mode dégradé communication ;
- stockage local ;
- équipement marqué non joignable côté serveur ;
- alarme communication ;
- resynchronisation au retour.

Perte réseau poste opérateur / serveur :
- utilisateur déconnecté ou IHM indisponible ;
- aucune perte de données côté équipement si serveur reste accessible.

Perte réseau serveur / base :
- application en erreur critique ;
- réception impossible ou limitée ;
- alerte infrastructure.

13.6 Tests associés¶

Exemples :

- flux équipement vers serveur autorisé ;
- flux poste vers IHM autorisé ;
- flux poste vers base bloqué ;
- coupure réseau équipement ;
- coupure réseau base ;
- retour réseau ;
- latence élevée ;
- perte paquets ;
- certificat réseau expiré ;
- accès admin hors VPN refusé.

---

14. Interfaces avec systèmes tiers¶

14.1 Objet des interfaces systèmes tiers¶

Cette partie décrit les échanges avec des systèmes externes au périmètre principal.

Ces interfaces doivent être formalisées car elles impliquent souvent d’autres équipes, d’autres contrats, d’autres contraintes de sécurité ou des dépendances externes.

14.2 Liste des systèmes tiers¶

Exemple :

Système tiers | Usage | Sens | Responsable | Criticité
Annuaire client | authentification | serveur ↔ annuaire | client IT | élevée
GMAO | création ticket maintenance | serveur → GMAO | client exploitation | moyenne
Supervision client | état système | serveur → supervision | client IT | moyenne
ERP | référentiel sites | ERP → serveur | client métier | faible/moyenne
Messagerie | notification email | serveur → SMTP | client IT | moyenne

14.3 Données échangées avec un système tiers¶

Exemples :

- identifiant équipement ;
- état équipement ;
- alarme critique ;
- rapport incident ;
- demande intervention ;
- utilisateur ;
- site ;
- zone ;
- date ;
- commentaire ;
- statut ticket ;
- fichier export.

14.4 Exemple d’interface GMAO¶

Identifiant : IF-TIERS-001
Nom : interface GMAO
Source : serveur applicatif
Destination : GMAO client
Usage : créer une demande d’intervention lors d’une alarme critique
Sens : serveur vers GMAO
Protocole : API REST HTTPS ou fichier selon choix
Données :
- equipment_id ;
- alarm_code ;
- severity ;
- timestamp ;
- description ;
- site ;
- suggested_action.
Réponse attendue :
- ticket_id ;
- status ;
- message.
Erreur :
- GMAO indisponible ;
- authentification refusée ;
- format rejeté.
Tests associés :
- création ticket nominal ;
- GMAO indisponible ;
- rejet format ;
- doublon alarme.

14.5 Exemple d’interface annuaire¶

Identifiant : IF-TIERS-002
Nom : interface annuaire utilisateur
Source : serveur applicatif
Destination : annuaire client
Usage : authentifier les utilisateurs
Protocole : LDAP / SSO / OAuth2 / OpenID Connect selon choix
Données :
- identifiant utilisateur ;
- groupe ;
- rôle ;
- statut compte.
Erreur :
- annuaire indisponible ;
- utilisateur inconnu ;
- mot de passe invalide ;
- groupe non mappé.
Tests associés :
- connexion nominale ;
- utilisateur inconnu ;
- groupe sans rôle ;
- annuaire indisponible.

14.6 Gestion des indisponibilités de systèmes tiers¶

Cette partie décrit le comportement lorsque le système externe est indisponible.

Exemples :

- mise en file d’attente ;
- rejet contrôlé ;
- alerte technique ;
- fonctionnement local maintenu ;
- mode dégradé ;
- nouvelle tentative périodique ;
- journalisation ;
- intervention manuelle.

14.7 Tests associés¶

Exemples :

- échange nominal ;
- système tiers indisponible ;
- réponse invalide ;
- authentification refusée ;
- timeout ;
- doublon ;
- reprise après retour ;
- journalisation erreur ;
- alerte supervision.

---

15. Interfaces de supervision¶

15.1 Objet des interfaces de supervision¶

Cette partie décrit les interfaces permettant de surveiller l’état du système, des services, des équipements, des sauvegardes, des flux ou des performances.

La supervision peut être interne à l’application ou connectée à un outil externe.

15.2 Données de supervision exposées¶

Exemples :

- état serveur applicatif ;
- état base de données ;
- état des équipements ;
- nombre d’alarmes actives ;
- nombre de messages reçus ;
- nombre de messages rejetés ;
- temps de réponse API ;
- état des sauvegardes ;
- espace disque ;
- version applicative ;
- état file d’attente ;
- état système tiers.

15.3 Healthcheck¶

Cette partie décrit les points de contrôle de santé.

Exemple :

Identifiant : IF-SUP-001
Nom : healthcheck applicatif
Source : outil supervision
Destination : serveur applicatif
Protocole : HTTPS
Réponse attendue :
- status global ;
- état base ;
- état application ;
- version ;
- timestamp.
Statuts :
- OK ;
- DEGRADED ;
- ERROR.

15.4 Alertes supervision¶

Cette partie décrit les alertes générées ou exposées.

Exemples :

- serveur indisponible ;
- base indisponible ;
- sauvegarde échouée ;
- disque presque plein ;
- certificat expirant ;
- taux de rejet messages élevé ;
- équipement non joignable ;
- file d’attente saturée ;
- service tiers indisponible.

15.5 Interface avec outil de supervision externe¶

Exemples :

- endpoint HTTP ;
- agent local ;
- export métriques ;
- fichiers logs ;
- SNMP ;
- webhook ;
- email ;
- API supervision.

15.6 Tests associés¶

Exemples :

- healthcheck OK ;
- healthcheck base KO ;
- arrêt service ;
- alerte sauvegarde échouée ;
- alerte disque ;
- équipement non joignable ;
- outil supervision indisponible ;
- retour au nominal.

---

16. Interfaces de sauvegarde et restauration¶

16.1 Objet des interfaces sauvegarde/restauration¶

Cette partie décrit les interfaces utilisées pour sauvegarder et restaurer les données, configurations, bases, fichiers applicatifs, logs ou états système.

Elle complète le dossier infrastructure en précisant les formats, composants et responsabilités d’échange.

16.2 Éléments sauvegardés via interface¶

Exemples :

- base de données ;
- fichiers de configuration ;
- fichiers de logs critiques ;
- exports ;
- rapports ;
- fichiers de paramétrage ;
- certificats si politique autorisée ;
- scripts de déploiement ;
- versions applicatives ;
- configuration équipement.

16.3 Interface de sauvegarde base de données¶

Exemple :

Identifiant : IF-BKP-001
Nom : sauvegarde base de données
Source : serveur base de données
Destination : serveur sauvegarde
Usage : sauvegarde périodique des données applicatives
Fréquence : quotidienne ou selon politique
Format : dump SQL / archive compressée / snapshot selon choix
Sécurité : accès restreint, chiffrement si nécessaire
Contrôle : code retour, taille fichier, intégrité
Tests associés : TEST-BKP-DB-001, TEST-REST-DB-001

16.4 Interface de restauration¶

Exemple :

Identifiant : IF-REST-001
Nom : restauration base de données
Source : serveur sauvegarde
Destination : environnement cible
Usage : restaurer une base après incident ou test
Préconditions :
- sauvegarde identifiée ;
- environnement disponible ;
- services arrêtés si nécessaire ;
- droits administrateur.
Résultat attendu :
- base restaurée ;
- application redémarrée ;
- cohérence vérifiée.
Tests associés : TEST-REST-DB-001

16.5 Erreurs de sauvegarde/restauration¶

Exemples :

- sauvegarde absente ;
- sauvegarde incomplète ;
- fichier corrompu ;
- espace disque insuffisant ;
- droits insuffisants ;
- restauration incompatible version ;
- service actif empêchant restauration ;
- échec contrôle intégrité.

16.6 Tests associés¶

Exemples :

- sauvegarde manuelle ;
- sauvegarde planifiée ;
- sauvegarde avec espace insuffisant ;
- restauration sur environnement de test ;
- restauration configuration ;
- restauration après mise à jour ;
- sauvegarde corrompue refusée ;
- alerte échec sauvegarde.

---

17. Interfaces de configuration¶

17.1 Objet des interfaces de configuration¶

Cette partie décrit les interfaces permettant de créer, modifier, transmettre, appliquer ou restaurer une configuration.

La configuration peut concerner le firmware, le serveur, les équipements, les seuils, les utilisateurs, les droits, les paramètres réseau ou les règles d’alarme.

17.2 Types de configuration¶

Exemples :

- configuration équipement ;
- configuration firmware ;
- configuration serveur ;
- configuration IHM ;
- configuration alarmes ;
- configuration utilisateurs ;
- configuration droits ;
- configuration réseau ;
- configuration sauvegarde ;
- configuration supervision.

17.3 Interface serveur vers équipement pour configuration¶

Exemple :

Identifiant : IF-CFG-001
Nom : transmission configuration équipement
Source : serveur applicatif
Destination : firmware embarqué
Usage : transmettre une configuration validée à l’équipement
Données :
- equipment_id ;
- config_version ;
- thresholds ;
- acquisition_periods ;
- communication_settings ;
- enabled_features.
Sécurité :
- source autorisée ;
- contrôle d’intégrité ;
- version ;
- journalisation.
Réponse attendue :
- configuration acceptée ;
- configuration rejetée ;
- motif rejet.
Tests associés :
- configuration valide ;
- configuration invalide ;
- version incompatible ;
- acquittement équipement.

17.4 Interface d’import/export configuration¶

Exemples :

- export configuration actuelle ;
- import configuration depuis fichier ;
- comparaison deux configurations ;
- validation avant application ;
- historique modifications ;
- retour arrière.

17.5 Gestion des conflits de configuration¶

Cette partie décrit les situations où deux configurations divergent.

Exemples :

- configuration attendue serveur différente de la configuration déclarée équipement ;
- configuration modifiée localement ;
- configuration obsolète ;
- équipement non synchronisé ;
- tentative d’application d’une ancienne version ;
- conflit entre deux modifications concurrentes.

17.6 Tests associés¶

Exemples :

- export configuration ;
- import configuration valide ;
- import configuration invalide ;
- transmission configuration ;
- équipement accepte ;
- équipement refuse ;
- divergence détectée ;
- retour arrière configuration ;
- modification non autorisée refusée.

---

18. Interfaces de mise à jour¶

18.1 Objet des interfaces de mise à jour¶

Cette partie décrit les interfaces permettant de mettre à jour un firmware, une application serveur, une configuration, une base de données ou un composant système.

18.2 Types de mises à jour¶

Exemples :

- firmware équipement ;
- application serveur ;
- base de données ;
- IHM ;
- configuration ;
- certificat ;
- scripts ;
- règles d’alarme ;
- système d’exploitation ;
- dépendances logicielles.

18.3 Interface de mise à jour firmware¶

Exemple :

Identifiant : IF-UPD-001
Nom : mise à jour firmware
Source : serveur ou outil maintenance
Destination : équipement embarqué
Usage : transmettre et appliquer une nouvelle version firmware
Données :
- version cible ;
- fichier firmware ;
- checksum ;
- signature si applicable ;
- compatibilité hardware ;
- instructions de mise à jour.
Préconditions :
- équipement en mode mise à jour ou maintenance ;
- alimentation suffisante ;
- paquet valide ;
- source autorisée.
Réponse attendue :
- mise à jour acceptée ;
- mise à jour refusée ;
- installation réussie ;
- installation échouée.

18.4 Interface de mise à jour serveur¶

Cette partie décrit la mise à jour applicative.

Exemples :

- paquet applicatif ;
- image conteneur ;
- scripts de migration ;
- fichiers de configuration ;
- note de version ;
- sauvegarde préalable ;
- tests post-déploiement ;
- retour arrière.

18.5 Erreurs de mise à jour¶

Exemples :

- paquet invalide ;
- checksum incorrect ;
- signature invalide ;
- version incompatible ;
- espace insuffisant ;
- coupure réseau ;
- coupure alimentation ;
- migration base échouée ;
- échec redémarrage ;
- rollback impossible.

18.6 Tests associés¶

Exemples :

- mise à jour firmware nominale ;
- firmware incompatible ;
- paquet corrompu ;
- coupure pendant mise à jour ;
- rollback firmware ;
- mise à jour serveur ;
- migration base ;
- rollback serveur ;
- vérification version après mise à jour.

---

19. Interfaces d’authentification et droits¶

19.1 Objet des interfaces d’authentification¶

Cette partie décrit les interfaces permettant d’identifier les utilisateurs, équipements, services ou systèmes tiers.

L’authentification peut concerner les utilisateurs de l’IHM, les équipements qui se connectent au serveur, les API externes, les administrateurs ou les services techniques.

19.2 Authentification utilisateur¶

Exemples :

- authentification locale ;
- annuaire LDAP ;
- SSO ;
- OAuth2 ;
- OpenID Connect ;
- certificat ;
- double facteur si applicable.

19.3 Authentification équipement¶

Exemples :

- identifiant équipement ;
- certificat client ;
- clé API ;
- jeton ;
- secret partagé ;
- signature de message ;
- liste blanche ;
- contrôle adresse réseau.

19.4 Authentification service à service¶

Exemples :

- serveur applicatif vers base de données ;
- serveur vers système tiers ;
- serveur vers sauvegarde ;
- serveur vers supervision ;
- outil maintenance vers équipement ;
- API externe vers serveur.

19.5 Gestion des droits¶

Cette partie décrit comment les autorisations sont portées par les interfaces.

Exemples :

- rôle utilisateur ;
- groupe annuaire ;
- permission API ;
- droit équipement ;
- profil maintenance ;
- jeton limité ;
- durée de validité ;
- révocation.

19.6 Tests associés¶

Exemples :

- connexion utilisateur valide ;
- mot de passe invalide ;
- compte désactivé ;
- rôle insuffisant ;
- équipement autorisé ;
- équipement inconnu ;
- certificat invalide ;
- jeton expiré ;
- service tiers non autorisé ;
- action critique refusée.

---

20. Interfaces d’erreur, codes retour et messages d’état¶

20.1 Objet des codes d’erreur¶

Cette partie décrit les erreurs échangées entre composants.

Un bon système d’interface ne décrit pas seulement les cas nominaux. Il doit aussi décrire les erreurs, rejets, timeouts, états intermédiaires et motifs d’échec.

20.2 Familles de codes d’erreur¶

Exemples :

- erreur de format ;
- erreur de version ;
- erreur d’autorisation ;
- erreur d’authentification ;
- ressource inconnue ;
- configuration invalide ;
- commande refusée ;
- équipement indisponible ;
- serveur indisponible ;
- base indisponible ;
- timeout ;
- conflit ;
- doublon ;
- capacité insuffisante ;
- erreur interne.

20.3 Exemple de table de codes retour¶

Code | Signification | Action émetteur | Action récepteur
OK | message accepté | poursuivre | enregistrer succès
BAD_FORMAT | format invalide | corriger / ne pas répéter | journaliser rejet
UNAUTHORIZED | source non autorisée | bloquer / alerter | journaliser sécurité
UNSUPPORTED_VERSION | version non supportée | utiliser version compatible | alerter compatibilité
DUPLICATE | message déjà traité | supprimer de file locale | journaliser si nécessaire
RETRY_LATER | traitement temporairement impossible | retransmettre plus tard | surveiller incident
INTERNAL_ERROR | erreur serveur | retransmettre ou alerter | analyser logs

20.4 Messages d’état¶

Cette partie décrit les statuts échangés.

Exemples :

- connected ;
- disconnected ;
- degraded ;
- maintenance ;
- updating ;
- safe_state ;
- alarm_active ;
- alarm_acknowledged ;
- configuration_pending ;
- synchronization_pending ;
- synchronization_done.

20.5 Tests associés¶

Exemples :

- code OK ;
- code BAD_FORMAT ;
- code UNAUTHORIZED ;
- code DUPLICATE ;
- code RETRY_LATER ;
- code version incompatible ;
- message état dégradé ;
- message état maintenance ;
- erreur non reconnue.

---

21. Interfaces temporelles et synchronisation horaire¶

21.1 Objet de la synchronisation horaire¶

Cette partie décrit comment le système gère le temps.

La cohérence temporelle est essentielle pour les mesures, alarmes, historiques, événements, diagnostics, logs, resynchronisation et audits.

21.2 Sources de temps¶

Exemples :

- horloge locale équipement ;
- horloge serveur ;
- serveur NTP ;
- horloge RTC ;
- temps reçu d’un système tiers ;
- temps de réception serveur ;
- temps opérateur.

21.3 Horodatages échangés¶

Exemples :

timestamp_device :
heure de génération par l’équipement.

timestamp_server :
heure de réception ou traitement par le serveur.

timestamp_ack :
heure de l’acquittement.

timestamp_event :
heure réelle ou estimée de l’événement.

timestamp_sync :
heure de synchronisation.

21.4 Gestion d’une horloge incertaine¶

Cette partie décrit les cas où le temps local n’est pas fiable.

Exemples :

- équipement démarré sans synchronisation ;
- RTC absente ;
- dérive détectée ;
- serveur NTP indisponible ;
- horodatage incohérent ;
- date future ;
- date trop ancienne.

Exigence typique :

IF-TIME-001 — Les données dont l’horodatage est incertain doivent être identifiables par le serveur et l’IHM si cette incertitude impacte l’exploitation.

21.5 Tests associés¶

Exemples :

- horodatage nominal ;
- perte synchronisation ;
- données retransmises avec horodatage d’origine ;
- date future rejetée ou signalée ;
- dérive horaire ;
- serveur NTP indisponible ;
- affichage horodatage incertain.

---

22. Interfaces de journalisation et traçabilité¶

22.1 Objet des interfaces de logs¶

Cette partie décrit les journaux échangés ou produits aux frontières entre composants.

Les logs permettent de diagnostiquer les problèmes d’interface et de prouver qu’un échange a eu lieu.

22.2 Logs d’échange¶

Exemples :

- message reçu ;
- message rejeté ;
- acquittement envoyé ;
- commande reçue ;
- commande refusée ;
- configuration transmise ;
- export généré ;
- erreur système tiers ;
- tentative d’accès non autorisée ;
- perte communication ;
- resynchronisation.

22.3 Corrélation des logs¶

Cette partie est importante pour suivre un échange entre plusieurs composants.

Exemples :

- message_id ;
- correlation_id ;
- equipment_id ;
- user_id ;
- request_id ;
- alarm_id ;
- command_id ;
- timestamp_device ;
- timestamp_server.

22.4 Données interdites dans les logs¶

Exemples :

- mot de passe ;
- clé privée ;
- jeton complet ;
- secret partagé ;
- données personnelles non nécessaires ;
- contenu sensible non utile au diagnostic ;
- fichier complet si volumineux ou confidentiel.

22.5 Tests associés¶

Exemples :

- log message reçu ;
- log message rejeté ;
- corrélation message/acquittement ;
- log commande ;
- absence secret dans logs ;
- export logs ;
- rotation logs ;
- consultation logs par profil autorisé.

---

23. Interfaces de tests et simulateurs¶

23.1 Objet des interfaces de test¶

Cette partie décrit les moyens permettant de tester les interfaces sans disposer nécessairement de tous les composants réels.

Les simulateurs sont très utiles pour tester tôt les interfaces : simulateur d’équipement, simulateur serveur, simulateur capteur, simulateur système tiers, générateur de messages invalides, banc hardware.

23.2 Simulateur d’équipement¶

Exemples de fonctions :

- envoyer des mesures nominales ;
- envoyer des alarmes ;
- envoyer des messages invalides ;
- simuler une perte réseau ;
- simuler une resynchronisation ;
- simuler plusieurs équipements ;
- simuler un firmware ancien ;
- simuler un équipement non autorisé.

23.3 Simulateur serveur¶

Exemples de fonctions :

- accepter un message ;
- rejeter un message ;
- ne pas acquitter ;
- envoyer une configuration ;
- envoyer une commande ;
- simuler une erreur serveur ;
- simuler une version API incompatible.

23.4 Simulateur capteur ou hardware¶

Exemples :

- valeur nominale ;
- valeur limite ;
- valeur hors plage ;
- capteur absent ;
- court-circuit ;
- contact instable ;
- défaut intermittent ;
- retour d’état incohérent.

23.5 Simulateur système tiers¶

Exemples :

- réponse nominale ;
- timeout ;
- rejet authentification ;
- erreur format ;
- indisponibilité ;
- réponse lente ;
- doublon ;
- message incohérent.

23.6 Tests associés¶

Exemples :

- test interface avec simulateur équipement ;
- test serveur avec messages invalides ;
- test firmware avec serveur simulé ;
- test capteur simulé ;
- test système tiers indisponible ;
- test de charge messages ;
- test protocole ancien ;
- test interface en mode dégradé.

---

24. Exigences de sécurité des interfaces¶

24.1 Objet de la sécurité des interfaces¶

Cette partie décrit les exigences de protection applicables aux échanges entre composants.

Une interface est souvent un point d’entrée potentiel pour les erreurs, abus, attaques, mauvaises configurations ou fuites de données.

24.2 Interfaces à protéger en priorité¶

Exemples :

- équipement vers serveur ;
- serveur vers équipement ;
- API d’administration ;
- interface configuration ;
- interface mise à jour ;
- interface authentification ;
- interface maintenance ;
- interface sauvegarde ;
- interface système tiers ;
- interface logs sensibles.

24.3 Mesures de protection possibles¶

Exemples :

- authentification ;
- autorisation ;
- chiffrement ;
- signature ;
- checksum ;
- contrôle d’intégrité ;
- filtrage réseau ;
- validation de format ;
- limitation de taille ;
- limitation de fréquence ;
- journalisation ;
- expiration session ;
- révocation certificat ;
- séparation des rôles.

24.4 Validation des entrées¶

Cette partie impose de contrôler les données reçues.

Exemples :

IF-SEC-VAL-001 — Toute donnée reçue via une interface doit être validée avant traitement.

IF-SEC-VAL-002 — Les messages mal formés doivent être rejetés sans provoquer de comportement non maîtrisé.

IF-SEC-VAL-003 — Les tailles maximales de messages ou fichiers doivent être définies si nécessaire.

IF-SEC-VAL-004 — Les fichiers importés doivent être contrôlés avant application.

24.5 Gestion des secrets¶

Cette partie décrit les clés, certificats ou jetons utilisés par les interfaces.

Exemples :

- certificat équipement ;
- certificat serveur ;
- clé API ;
- jeton utilisateur ;
- mot de passe base de données ;
- clé SSH ;
- secret système tiers ;
- certificat VPN.

24.6 Tests associés¶

Exemples :

- équipement non autorisé ;
- certificat invalide ;
- message signé invalide ;
- jeton expiré ;
- utilisateur sans droit ;
- fichier importé malveillant ou invalide ;
- message trop volumineux ;
- tentative accès API admin ;
- secret absent des logs.

---

25. Matrices de synthèse¶

25.1 Matrice interfaces / sous-systèmes¶

Cette matrice indique quels sous-systèmes sont concernés par chaque interface.

Exemple :

Interface | Hardware | Firmware | Serveur | DB | IHM | Infrastructure | Tiers
IF-HW-001 alimentation | X |   |   |   |   | X |  
IF-SW-HW-001 entrée | X | X |   |   |   |   |  
IF-NET-001 équipement/serveur |   | X | X |   |   | X |  
IF-DB-001 serveur/base |   |   | X | X |   | X |  
IF-IHM-001 tableau bord |   |   | X | X | X |   |  
IF-TIERS-001 GMAO |   |   | X |   |   | X | X

25.2 Matrice interfaces / modes de fonctionnement¶

Cette matrice indique si une interface est active selon les modes.

Exemple :

Interface | Nominal | Maintenance | Dégradé com. | Secours | Mise à jour | Arrêt
IF-NET-001 équipement/serveur | oui | limité | non ou tentative | si possible | non | non
IF-MNT-001 port maintenance | non/limité | oui | oui | oui | oui | non
IF-HW-004 sortie relais | oui | test contrôlé | selon sécurité | non | non | non
IF-IHM-ALM alarmes | oui | oui | oui | critique | limité | non

25.3 Matrice interfaces / tests¶

Cette matrice relie chaque interface aux tests prévus.

Exemple :

Interface | Test unitaire | Test intégration | Test système | Validation client
IF-SW-HW-001 | TU lecture entrée | TI entrée firmware | TS acquisition | VAL acquisition
IF-NET-001 | TU format message | TI équipement serveur | TS communication | VAL perte réseau
IF-IHM-001 | TU API | TI backend/frontend | TS tableau bord | VAL exploitation
IF-BKP-001 | TU script | TI sauvegarde | TS restauration | VAL restauration

25.4 Matrice interfaces / responsabilités¶

Cette matrice clarifie qui est responsable de quoi.

Exemple :

Interface | Responsable source | Responsable destination | Responsable spécification | Responsable test
IF-HW-002 capteur | client/fournisseur | hardware | responsable hardware | test hardware
IF-NET-001 équipement/serveur | firmware | backend | architecte système | intégration
IF-IHM-001 tableau bord | backend | frontend | responsable applicatif | test IHM
IF-TIERS-001 GMAO | serveur | client IT | architecte applicatif | intégration tiers

25.5 Matrice données / interfaces¶

Cette matrice montre quelles données passent par quelles interfaces.

Exemple :

Donnée | IF-HW | IF-SW-HW | IF-NET | IF-DB | IF-IHM | IF-EXP
Température | capteur | acquisition | message MEASURE | table mesures | graphique | CSV
Alarme | capteur/firmware | événement | message ALARM | table alarmes | écran alarmes | PDF/CSV
Configuration | fichier/IHM | firmware | message CONFIG | table config | écran config | JSON
Logs | firmware/serveur | diagnostic | message LOG | fichier/table | écran maintenance | archive

---

26. Traçabilité¶

26.1 Traçabilité avec la spécification globale¶

Cette partie relie les interfaces aux exigences système.

Exemple :

Exigence système :
SYS-COM-004 — Le système doit conserver les données en perte réseau et les retransmettre au retour communication.

Interfaces associées :
IF-NET-001 — équipement vers serveur ;
IF-STO-001 — stockage local firmware ;
IF-ACK-001 — acquittement serveur ;
IF-DB-001 — historisation serveur ;
IF-IHM-ALM-001 — affichage état communication.

26.2 Traçabilité avec l’architecture système¶

Cette partie relie chaque interface aux blocs architecturaux.

Exemple :

Interface :
IF-NET-001 — équipement vers serveur

Blocs concernés :
SS-SW-001 — firmware embarqué
SS-SRV-001 — serveur applicatif
SS-INF-001 — réseau
SS-SEC-001 — sécurité

26.3 Traçabilité avec les spécifications détaillées¶

Cette partie indique dans quels documents les deux côtés de l’interface sont décrits.

Exemple :

Interface :
IF-SW-HW-003 — commande relais

Côté hardware :
Spécification détaillée hardware, section sorties relais.

Côté firmware :
Spécification détaillée software embarqué, section commande des sorties.

Tests :
Tests hardware, tests intégration hardware/software, tests état sûr.

26.4 Traçabilité vers les tests¶

Cette partie relie les interfaces aux tests.

Exemple :

Interface :
IF-API-MEASURE — API réception mesures

Tests associés :
TEST-API-MEASURE-001 — message valide.
TEST-API-MEASURE-002 — message sans équipement.
TEST-API-MEASURE-003 — message dupliqué.
TEST-INT-EQP-SRV-001 — équipement réel vers serveur.
TEST-SYS-HIST-001 — mesure visible dans historique.

26.5 Matrice de traçabilité des interfaces¶

Structure recommandée :

ID interface
Exigence système source
Sous-systèmes concernés
Documents concernés
Données échangées
Tests associés
Criticité
Statut
Commentaire

---

27. Contraintes, risques et points ouverts¶

27.1 Contraintes techniques¶

Cette partie liste les contraintes connues sur les interfaces.

Exemples :

- protocole imposé par un équipement tiers ;
- format de fichier imposé par le client ;
- réseau client contraint ;
- port réseau non ouvrable ;
- bande passante limitée ;
- latence élevée ;
- connectique imposée ;
- version API existante à maintenir ;
- compatibilité avec anciens firmwares ;
- contrainte de cybersécurité ;
- impossibilité d’accès Internet ;
- usage obligatoire d’un SAS.

27.2 Risques liés aux interfaces¶

Cette partie identifie les risques.

Exemples :

- interprétation différente d’un champ ;
- format de message incomplet ;
- absence d’acquittement ;
- doublons après resynchronisation ;
- interface non versionnée ;
- protocole tiers instable ;
- erreur de câblage ;
- polarité mal définie ;
- messages trop volumineux ;
- absence de test d’erreur ;
- sécurité insuffisante ;
- logs insuffisants pour diagnostiquer l’échange.

27.3 Mesures de réduction des risques¶

Exemples :

- dictionnaire de données partagé ;
- simulateur d’équipement ;
- simulateur serveur ;
- tests d’intégration précoces ;
- versionnement d’API ;
- exemples de messages ;
- validation de schéma JSON ;
- revue d’interface entre équipes ;
- matrice responsabilités ;
- tests de coupure réseau ;
- tests de messages invalides ;
- règles d’acquittement explicites ;
- journalisation avec correlation_id.

27.4 Points ouverts¶

Cette partie liste les décisions non encore prises.

Exemple :

ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-IF-001 | Protocole équipement/serveur | Choix final HTTPS ou MQTT/TLS | Architecte système | avant conception API | firmware/serveur | ouvert
PO-IF-002 | Format export | CSV ou JSON pour export client | Client/exploitation | avant IHM | reporting | ouvert
PO-IF-003 | Authentification équipement | Certificat ou jeton | Cybersécurité | avant intégration | sécurité | ouvert
PO-IF-004 | Interface GMAO | API disponible ou échange fichier | Client IT | avant intégration tiers | maintenance | ouvert
PO-IF-005 | Connecteur capteur | Référence connecteur à confirmer | Hardware/client | avant routage | hardware | ouvert

---

28. Critères d’acceptation de la spécification d’interfaces¶

28.1 Complétude¶

Cette partie définit les critères permettant de considérer le document comme complet.

Exemples :

La spécification détaillée des interfaces est considérée comme complète si :
- toutes les interfaces identifiées dans l’architecture sont décrites ;
- les interfaces hardware sont définies ;
- les interfaces firmware/hardware sont définies ;
- les interfaces équipement/serveur sont définies ;
- les interfaces serveur/base sont définies ;
- les interfaces IHM sont définies ;
- les interfaces fichiers sont définies ;
- les interfaces maintenance sont définies ;
- les interfaces systèmes tiers sont définies si applicables ;
- les formats de données principaux sont décrits ;
- les erreurs et codes retour sont décrits ;
- les exigences de sécurité sont définies ;
- les tests associés sont identifiés ;
- les responsabilités sont claires.

28.2 Cohérence¶

Cette partie définit les critères de cohérence.

Exemples :

Le document ne doit pas contenir :
- une interface sans source et destination ;
- une interface sans responsable ;
- un message sans format défini ;
- un champ obligatoire non expliqué ;
- un acquittement non défini ;
- une erreur non gérée ;
- une interface critique non sécurisée ;
- une interface non testable ;
- une contradiction entre firmware et serveur ;
- une contradiction entre hardware et firmware ;
- une interface externe sans responsabilité client/fournisseur.

28.3 Testabilité¶

Cette partie vérifie que les interfaces peuvent être testées.

Exemples :

La spécification est testable si :
- les messages nominaux sont décrits ;
- les messages invalides peuvent être construits ;
- les erreurs sont définies ;
- les acquittements sont définis ;
- les flux réseau sont identifiés ;
- les entrées/sorties hardware peuvent être stimulées ;
- les sorties peuvent être observées ;
- les simulateurs nécessaires sont identifiés ;
- les critères de succès sont explicites.

28.4 Exploitabilité et maintenabilité¶

Cette partie vérifie que les interfaces pourront être diagnostiquées en exploitation.

Exemples :

La spécification prend correctement en compte l’exploitation si :
- les erreurs d’interface sont journalisées ;
- les identifiants de corrélation sont prévus ;
- les messages rejetés sont traçables ;
- les états de communication sont visibles ;
- les interfaces de maintenance sont documentées ;
- les versions d’interface sont identifiables ;
- les incompatibilités peuvent être diagnostiquées.

28.5 Validation du document¶

Cette partie précise les revues nécessaires.

Exemple :

La spécification détaillée des interfaces doit être relue par :
- l’ingénieur système ;
- le responsable hardware ;
- le responsable software embarqué ;
- le responsable serveur/application ;
- le responsable infrastructure/réseau ;
- le responsable cybersécurité ;
- le responsable IHM ;
- le responsable intégration ;
- le responsable validation ;
- le représentant client si les interfaces impliquent le SI client ou des équipements tiers.

---

29. Annexes¶

29.1 Inventaire complet des interfaces¶

Cette annexe reprend la liste complète des interfaces.

Exemple :

ID | Nom | Type | Source | Destination | Criticité | Statut
IF-HW-001 | alimentation | hardware | site | équipement | critique | à valider
IF-SW-HW-001 | lecture entrée | firmware/hardware | carte | firmware | élevée | à spécifier
IF-NET-001 | équipement/serveur | réseau/API | firmware | serveur | élevée | à valider
IF-DB-001 | serveur/base | DB | serveur | base | critique | à spécifier
IF-IHM-001 | tableau bord | IHM | utilisateur | serveur | moyenne | à spécifier
IF-TIERS-001 | GMAO | API/fichier | serveur | GMAO | moyenne | ouvert

29.2 Dictionnaire de données¶

Cette annexe définit les champs échangés.

Exemple :

Champ | Type | Description | Obligatoire | Exemple
equipment_id | string | identifiant équipement | oui | EQP-001
message_id | string | identifiant message | oui | MSG-0001
timestamp_device | datetime | date côté équipement | oui si disponible | 2026-07-03T14:00:00Z
severity | enum | criticité alarme | oui pour alarme | minor/major/critical
quality | enum | qualité donnée | non/oui selon message | valid/invalid/uncertain

29.3 Catalogue des messages¶

Cette annexe reprend les messages échangés.

Exemples :

MEASURE
ALARM
EVENT
STATE
DIAGNOSTIC
LOG
ACK
NACK
CONFIG
COMMAND
TIME_SYNC
UPDATE_REQUEST

29.4 Catalogue des codes d’erreur¶

Cette annexe reprend les codes retour.

29.5 Catalogue des flux réseau¶

Cette annexe reprend tous les flux réseau autorisés.

29.6 Catalogue des fichiers¶

Cette annexe reprend les formats de fichiers utilisés.

29.7 Matrice interfaces / tests¶

Cette annexe reprend la matrice complète de vérification.

29.8 Matrice interfaces / responsabilités¶

Cette annexe reprend les responsabilités source, destination, spécification et test.

29.9 Exemples complets de messages¶

Cette annexe peut contenir des exemples JSON, XML, CSV ou autres.

29.10 Glossaire des interfaces¶

Cette annexe définit les termes spécifiques.

29.11 Historique des décisions d’interface¶

Cette annexe conserve les décisions importantes.

Exemple :

DEC-IF-001 :
Les échanges équipement/serveur utiliseront des messages avec identifiant unique message_id.

Justification :
permettre la détection des doublons lors de la resynchronisation après perte réseau.

Impact :
le firmware doit générer un identifiant stable, le serveur doit conserver les identifiants traités et les tests d’intégration doivent couvrir les cas de retransmission.