CANEVAS DES DOCUMENTS DU PROJET

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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.

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```json

{

  "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

```json

{

  "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 :**

```json

{

  "protocol_version": "1.0",

  "message_id": "MSG-000124",

  "ack_id": "ACK-000985",

  "status": "ACCEPTED",

  "timestamp_server": "2026-07-03T14:03:02Z"

}

```

**Statuts possibles :**

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

- é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 :**

```text

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

```text

É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 :**

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

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

```text

- é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 :**

```text

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

```text

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

```text

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