CANEVAS DES DOCUMENTS DU PROJET

# Canevas 3 — Spécification globale / Spécification système

## 1. Objet du document

### 1.1 Finalité de la spécification globale

Cette partie précise l’objectif du document.

La spécification globale, également appelée spécification système, traduit le besoin exprimé dans le cahier des charges en exigences structurées, compréhensibles et vérifiables. Elle décrit ce que le système complet doit faire, dans quelles conditions il doit le faire, avec quelles contraintes et dans quel environnement.

Elle ne doit pas encore détailler la solution interne de chaque sous-système. Elle doit rester au niveau du système complet, en décrivant les fonctions attendues, les interfaces externes, les modes de fonctionnement, les performances attendues, les contraintes de sécurité, de sûreté, d’exploitation et de validation.

**Exemple :**

> Le présent document a pour objectif de spécifier les exigences globales applicables au système. Il décrit les fonctions attendues, les modes de fonctionnement, les interfaces externes, les contraintes techniques, les exigences d’exploitation, les exigences de maintenance et les exigences de validation applicables à l’ensemble du système.

### 1.2 Positionnement dans le cycle en V

Cette partie situe la spécification globale dans le cycle en V.

La spécification globale se situe après le cahier des charges et avant l’architecture système, les spécifications détaillées et la conception. Elle constitue un document de référence pour les phases suivantes du projet.

Elle est utilisée pour établir :

```text

- l’architecture système ;

- l’allocation des fonctions vers le hardware, le software embarqué, les serveurs, le réseau ou les opérateurs ;

- les spécifications détaillées des sous-systèmes ;

- le plan de vérification ;

- les tests système ;

- le dossier de validation.

```

Dans le cycle en V, elle correspond au niveau qui sera vérifié par les **tests système** et confirmé par la **validation globale**.

```text

Cahier des charges client

        ↓

Spécification globale / système

        ↓

Architecture système

        ↓

Spécifications détaillées des sous-systèmes

        ↓

Conception détaillée

        ↓

Réalisation

        ↑

Tests unitaires

        ↑

Tests d’intégration

        ↑

Tests système

        ↑

Validation client / recette

```

### 1.3 Différence avec le cahier des charges

Cette partie précise la différence entre le cahier des charges et la spécification globale.

Le cahier des charges exprime le besoin du client. Il peut être formulé en langage métier, opérationnel ou contractuel. La spécification globale reformule ce besoin en exigences système organisées, non ambiguës, vérifiables et exploitables par les équipes techniques.

**Exemple :**

```text

Besoin client :

Le système doit continuer à fonctionner même si la communication avec le serveur est interrompue.

Spécification globale :

SYS-COM-004 — En cas de perte de communication avec le serveur, le système doit maintenir les fonctions locales critiques, conserver les données nécessaires localement et signaler l’état de communication dégradée à l’opérateur.

```

### 1.4 Différence avec la spécification détaillée

Cette partie précise la frontière avec les documents de spécification détaillée.

La spécification globale décrit le comportement attendu du système complet. Les spécifications détaillées décriront ensuite le comportement attendu de chaque sous-système : hardware, logiciel embarqué, application serveur, interface opérateur, infrastructure, réseau, etc.

**Exemple :**

```text

Spécification globale :

Le système doit générer une alarme lorsqu’une mesure dépasse un seuil configuré.

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

Le firmware doit comparer la mesure de température au seuil configuré toutes les 10 secondes.

Si la mesure dépasse le seuil pendant trois cycles consécutifs, le firmware doit créer un événement d’alarme TEMP_HIGH.

Spécification détaillée serveur :

Le serveur doit recevoir l’événement TEMP_HIGH, l’enregistrer en base de données et le rendre disponible à l’interface opérateur.

Spécification détaillée interface :

L’interface opérateur doit afficher l’alarme TEMP_HIGH dans la liste des alarmes actives avec son niveau, son horodatage et l’équipement concerné.

```

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

Cette partie précise qui rédige, relit et approuve la spécification globale.

Dans un projet industriel, la spécification globale est généralement rédigée par le fournisseur, l’ingénieur système ou le responsable technique, à partir du cahier des charges client. Elle doit être relue par les responsables hardware, software, infrastructure, tests, qualité, exploitation et maintenance si ces domaines sont concernés.

**Exemple :**

```text

Rédaction : ingénieur système / responsable technique fournisseur

Contributions : responsables hardware, software, infrastructure, tests, cybersécurité, maintenance

Relecture : chef de projet, qualité, responsable validation

Approbation : fournisseur et client si le document est contractuel

```

---

## 2. Références et documents applicables

### 2.1 Documents d’entrée

Cette partie liste les documents utilisés pour rédiger la spécification globale.

Les documents d’entrée doivent être identifiés avec leur référence, leur version et leur statut. Cela permet de savoir sur quelle base la spécification a été construite.

**Exemples :**

```text

- Cahier des charges client

- Dossier de validation client

- Contrat ou commande

- Expression du besoin

- Compte rendu de réunion de cadrage

- Analyse de l’existant

- Contraintes réglementaires

- Contraintes de sécurité et sûreté

- Contraintes d’exploitation

- Contraintes de maintenance

- Contraintes d’hébergement ou d’infrastructure

```

### 2.2 Documents applicables

Cette partie liste les documents qui s’imposent au projet.

Un document applicable est un document que le système doit respecter. Il peut s’agir d’une norme, d’un règlement, d’une procédure client, d’un standard interne ou d’une exigence contractuelle.

**Exemples :**

```text

- Norme électrique applicable

- Norme CEM applicable

- Standard de cybersécurité client

- Procédure d’exploitation client

- Référentiel qualité projet

- Exigences de traçabilité documentaire

- Règles de codification des équipements

- Règles d’identification des alarmes

```

### 2.3 Documents de référence

Cette partie liste les documents utiles mais non obligatoires.

Ils peuvent servir de contexte ou d’inspiration, sans constituer des exigences strictement applicables.

**Exemples :**

```text

- Documentation d’un système existant

- Manuel d’un équipement similaire

- Retour d’expérience d’un projet précédent

- Schémas préliminaires

- Notes techniques

- Études de faisabilité

- Rapport d’analyse de risques préliminaire

```

### 2.4 Gestion des versions de référence

Cette partie précise que toute évolution d’un document d’entrée peut nécessiter une mise à jour de la spécification globale.

**Exemple :**

> Toute modification du cahier des charges, du dossier de validation ou d’une contrainte réglementaire applicable devra faire l’objet d’une analyse d’impact sur la présente spécification globale.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

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

Elle permet d’éviter les ambiguïtés entre le client, le fournisseur, les équipes hardware, software, exploitation et maintenance.

**Exemples :**

```text

Système :

Ensemble constitué de l’équipement embarqué, de son logiciel, de l’infrastructure serveur, des interfaces opérateur, du réseau de communication et des procédures associées.

Équipement embarqué :

Sous-ensemble matériel et logiciel installé sur site, chargé d’acquérir des données, de piloter des entrées/sorties et de communiquer avec le serveur.

Mode dégradé :

Mode de fonctionnement dans lequel le système conserve une partie de ses fonctions malgré la perte ou l’indisponibilité d’une ressource.

```

### 3.2 Acronymes

Cette partie liste les acronymes utilisés.

**Exemples :**

```text

API : Application Programming Interface

CEM : Compatibilité électromagnétique

CPU : Central Processing Unit

IHM : Interface Homme-Machine

IP : Internet Protocol

SAS : Zone ou serveur d’échange contrôlé entre deux environnements

VPN : Virtual Private Network

```

### 3.3 Conventions de rédaction des exigences

Cette partie définit la manière de rédiger et d’identifier les exigences.

Une exigence doit être claire, unique, vérifiable et traçable. Il est préférable d’éviter les formulations vagues comme “simple”, “rapide”, “ergonomique”, “suffisant” ou “performant” sans critère mesurable.

**Exemple de codification :**

```text

SYS-FCT-001 : exigence fonctionnelle système

SYS-MOD-001 : exigence relative aux modes de fonctionnement

SYS-COM-001 : exigence de communication

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

SYS-CYB-001 : exigence de cybersécurité

SYS-MNT-001 : exigence de maintenance

SYS-VAL-001 : exigence de validation

```

### 3.4 Formulation recommandée des exigences

Cette partie précise les formes attendues.

**Exemples :**

```text

Correct :

SYS-FCT-001 — Le système doit acquérir la mesure de température toutes les 10 secondes.

Incorrect :

Le système devra être rapide pour lire la température.

Correct :

SYS-COM-002 — Le système doit signaler une perte de communication serveur si aucun échange valide n’est reçu pendant plus de 120 secondes.

Incorrect :

Le système doit gérer correctement les problèmes réseau.

```

---

## 4. Vue générale du système

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

Cette partie donne une vue synthétique du système à réaliser.

Elle doit permettre à un lecteur qui ne connaît pas le projet de comprendre rapidement ce que fait le système, où il est installé, avec quels composants il interagit et à quoi il sert.

**Exemple :**

> Le système a pour objectif de surveiller un équipement industriel installé sur site, d’acquérir des mesures, de détecter des défauts, de transmettre les données à un serveur central et de permettre aux opérateurs de consulter l’état du système à distance.

### 4.2 Objectifs fonctionnels principaux

Cette partie reprend les objectifs principaux, mais sous une forme plus structurée que dans le cahier des charges.

**Exemples :**

```text

Le système doit permettre :

- l’acquisition périodique de mesures physiques ;

- la surveillance d’états et de défauts ;

- la génération d’alarmes ;

- le stockage local temporaire des données ;

- la transmission des données vers une infrastructure serveur ;

- la consultation des états par une interface opérateur ;

- la configuration de paramètres autorisés ;

- le diagnostic et la maintenance de l’équipement.

```

### 4.3 Composition générale du système

Cette partie décrit les grands éléments constitutifs du système.

**Exemples :**

```text

Le système comprend :

- un équipement embarqué installé sur site ;

- une carte électronique de contrôle ;

- un logiciel embarqué ;

- des capteurs et actionneurs ;

- un module de communication ;

- un serveur applicatif ;

- une base de données ;

- une interface opérateur ;

- un poste de maintenance ;

- un réseau de communication ;

- des procédures d’installation, de test et de maintenance.

```

### 4.4 Frontières du système

Cette partie précise ce qui appartient au système et ce qui est externe.

Elle est essentielle pour éviter les ambiguïtés sur les responsabilités.

**Exemple :**

```text

Inclus dans le système :

- équipement embarqué ;

- firmware ;

- serveur applicatif ;

- base de données ;

- interface opérateur ;

- procédures de sauvegarde ;

- documentation d’installation.

Externe au système :

- réseau Internet public ;

- alimentation générale du bâtiment ;

- système tiers de supervision client ;

- équipements non fournis par le projet ;

- infrastructure physique du site hors coffret livré.

```

### 4.5 Synoptique général

Cette partie doit contenir un schéma général du système.

Le schéma peut représenter les flux principaux entre l’équipement, le serveur, l’opérateur, les systèmes tiers et les moyens de maintenance.

**Exemple de représentation textuelle :**

```text

Capteurs / Actionneurs

        ↕

Équipement embarqué + firmware

        ↕

Réseau local / VPN / 4G

        ↕

Serveur applicatif

        ↕

Base de données

        ↕

Interface opérateur / interface maintenance

```

---

## 5. Périmètre fonctionnel global

### 5.1 Fonctions incluses

Cette partie liste les fonctions globales incluses dans le périmètre du système.

Chaque fonction peut ensuite être détaillée dans les sections suivantes ou dans les spécifications détaillées.

**Exemples :**

```text

FCT-01 : acquisition des mesures

FCT-02 : surveillance des seuils

FCT-03 : génération des alarmes

FCT-04 : stockage local

FCT-05 : communication serveur

FCT-06 : consultation opérateur

FCT-07 : configuration

FCT-08 : diagnostic

FCT-09 : maintenance

FCT-10 : sauvegarde et restauration

```

### 5.2 Fonctions exclues

Cette partie liste les fonctions explicitement non prises en charge par le système.

**Exemples :**

```text

Le système ne prend pas en charge :

- la fourniture du réseau Internet du site ;

- la maintenance des équipements tiers ;

- la certification réglementaire de l’installation complète ;

- le pilotage d’équipements non listés dans le périmètre ;

- l’hébergement dans un cloud public non validé par le client.

```

### 5.3 Fonctions optionnelles

Cette partie liste les fonctions qui ne sont pas incluses dans la version de base mais qui peuvent être prévues en option ou en évolution future.

**Exemples :**

```text

- application mobile ;

- export automatique vers un système tiers ;

- intelligence embarquée de diagnostic prédictif ;

- accès multi-sites ;

- synchronisation avec un ERP ou une GMAO ;

- tableau de bord avancé.

```

### 5.4 Priorité des fonctions

Cette partie classe les fonctions selon leur importance.

Cette classification aide à prioriser le développement, les tests et la validation.

**Exemple :**

```text

Critique :

- fonctions de sécurité ;

- maintien en état sûr ;

- détection des défauts majeurs.

Importante :

- acquisition des mesures ;

- transmission au serveur ;

- affichage des alarmes ;

- stockage local.

Secondaire :

- export de rapport ;

- personnalisation de l’affichage ;

- statistiques avancées.

```

---

## 6. Exigences fonctionnelles globales

### 6.1 Acquisition des données

Cette partie décrit les exigences relatives à l’acquisition des mesures, états, défauts et événements.

Elle doit préciser ce qui doit être acquis, à quelle fréquence, avec quelle précision éventuelle, dans quelles conditions et avec quel comportement en cas d’erreur.

**Exemples d’exigences :**

```text

SYS-FCT-001 — Le système doit acquérir les mesures définies dans la configuration active.

SYS-FCT-002 — Le système doit horodater chaque mesure acquise.

SYS-FCT-003 — Le système doit détecter l’absence d’une mesure attendue.

SYS-FCT-004 — Le système doit signaler toute mesure incohérente ou hors plage autorisée.

```

**Exemple explicatif :**

> Si le système surveille une batterie, les mesures peuvent inclure la tension, le courant, la température, l’état de charge et les défauts remontés par le BMS. Chaque mesure doit être horodatée afin de pouvoir reconstituer l’historique en cas d’incident.

### 6.2 Traitement des données

Cette partie décrit les traitements que le système doit réaliser sur les données acquises.

Il peut s’agir de filtrage, comparaison à des seuils, calcul d’indicateurs, agrégation, détection d’anomalies ou génération d’états synthétiques.

**Exemples d’exigences :**

```text

SYS-FCT-010 — Le système doit comparer les mesures acquises aux seuils configurés.

SYS-FCT-011 — Le système doit générer un événement lorsque la valeur d’une mesure franchit un seuil d’alerte.

SYS-FCT-012 — Le système doit distinguer les alarmes critiques, majeures, mineures et informatives.

SYS-FCT-013 — Le système doit conserver l’état courant de chaque équipement surveillé.

```

### 6.3 Commande et pilotage

Cette partie décrit les fonctions de commande ou d’action sur l’équipement.

Elle doit être particulièrement précise si le système peut déclencher des actions physiques : relais, contacteur, moteur, vanne, charge, arrêt, redémarrage, verrouillage.

**Exemples d’exigences :**

```text

SYS-CMD-001 — Le système doit autoriser l’activation d’une commande uniquement si les conditions de sécurité associées sont satisfaites.

SYS-CMD-002 — Le système doit journaliser toute commande opérateur.

SYS-CMD-003 — Le système doit refuser toute commande non autorisée pour le profil utilisateur connecté.

SYS-CMD-004 — Le système doit confirmer l’exécution ou l’échec d’une commande.

```

**Exemple explicatif :**

> Une commande de redémarrage contrôlé ne doit pas pouvoir être lancée par un utilisateur non habilité. Elle doit faire l’objet d’une confirmation, être horodatée, journalisée et associée à l’identité de l’utilisateur.

### 6.4 Gestion des alarmes

Cette partie décrit les exigences générales relatives aux alarmes.

Elle doit préciser les types d’alarmes, leur cycle de vie, leur affichage, leur acquittement et leur historisation.

**Exemples d’exigences :**

```text

SYS-ALM-001 — Le système doit générer une alarme lorsqu’un défaut critique est détecté.

SYS-ALM-002 — Chaque alarme doit comporter un identifiant, un niveau, une date d’apparition, une description et l’équipement concerné.

SYS-ALM-003 — Le système doit permettre l’acquittement des alarmes par un utilisateur autorisé.

SYS-ALM-004 — Le système doit conserver l’historique des alarmes apparues, acquittées et clôturées.

SYS-ALM-005 — Le système doit distinguer une alarme active d’une alarme historisée.

```

### 6.5 Stockage et historisation

Cette partie décrit les exigences relatives à la conservation des mesures, événements, alarmes, logs et configurations.

**Exemples d’exigences :**

```text

SYS-STO-001 — Le système doit enregistrer les événements significatifs dans un historique consultable.

SYS-STO-002 — Le système doit conserver localement les données non transmises en cas de perte de communication.

SYS-STO-003 — Le système doit empêcher la perte silencieuse de données critiques.

SYS-STO-004 — Le système doit signaler une saturation prochaine du stockage local.

```

### 6.6 Communication

Cette partie décrit les exigences globales de communication avec les serveurs, équipements tiers, interfaces utilisateurs ou systèmes externes.

**Exemples d’exigences :**

```text

SYS-COM-001 — Le système doit transmettre les données d’état vers le serveur applicatif.

SYS-COM-002 — Le système doit détecter une perte de communication avec le serveur.

SYS-COM-003 — Le système doit signaler l’état de communication à l’opérateur.

SYS-COM-004 — Le système doit reprendre automatiquement la transmission des données après rétablissement de la communication.

SYS-COM-005 — Le système doit garantir que les données retransmises après coupure restent correctement horodatées.

```

### 6.7 Supervision et interface opérateur

Cette partie décrit ce que les utilisateurs doivent pouvoir voir, comprendre et réaliser depuis l’interface.

**Exemples d’exigences :**

```text

SYS-IHM-001 — Le système doit afficher l’état courant de chaque équipement surveillé.

SYS-IHM-002 — Le système doit afficher les alarmes actives avec leur niveau de criticité.

SYS-IHM-003 — Le système doit permettre la consultation de l’historique des événements.

SYS-IHM-004 — Le système doit présenter une information compréhensible par un opérateur non développeur.

SYS-IHM-005 — Le système doit distinguer les informations d’exploitation des informations de maintenance.

```

### 6.8 Configuration et paramétrage

Cette partie décrit les exigences relatives aux paramètres système.

Elle doit préciser ce qui est configurable, qui peut modifier les paramètres, comment les modifications sont contrôlées et comment elles sont tracées.

**Exemples d’exigences :**

```text

SYS-CFG-001 — Le système doit permettre la consultation de la configuration active.

SYS-CFG-002 — Le système doit réserver la modification des paramètres critiques aux utilisateurs habilités.

SYS-CFG-003 — Toute modification d’un paramètre critique doit être journalisée.

SYS-CFG-004 — Le système doit permettre l’export de la configuration active.

SYS-CFG-005 — Le système doit refuser une configuration invalide.

```

### 6.9 Diagnostic

Cette partie décrit les exigences permettant d’identifier l’origine d’un dysfonctionnement.

**Exemples d’exigences :**

```text

SYS-DIAG-001 — Le système doit fournir des informations de diagnostic accessibles aux utilisateurs autorisés.

SYS-DIAG-002 — Le système doit permettre la consultation des versions matérielles et logicielles installées.

SYS-DIAG-003 — Le système doit permettre l’export des journaux nécessaires à l’analyse d’un incident.

SYS-DIAG-004 — Le système doit distinguer les défauts matériel, logiciel, communication et configuration lorsque cette distinction est possible.

```

---

## 7. Modes de fonctionnement globaux

### 7.1 Objet de la description des modes

Cette partie explique pourquoi les modes de fonctionnement sont décrits dans la spécification globale.

Les modes de fonctionnement permettent de préciser comment le système se comporte dans les différentes situations de vie : arrêt, démarrage, fonctionnement nominal, maintenance, défaut, mode dégradé, secours, arrêt d’urgence, mise à jour, etc.

Dans certains projets, les modes de fonctionnement feront l’objet d’un document séparé. Dans ce cas, la spécification globale doit en donner une synthèse et renvoyer au dossier détaillé des modes.

### 7.2 Liste des modes

Cette partie liste les modes prévus.

**Exemples :**

```text

MOD-01 : mode arrêt

MOD-02 : mode démarrage

MOD-03 : mode initialisation

MOD-04 : mode nominal

MOD-05 : mode maintenance

MOD-06 : mode diagnostic

MOD-07 : mode dégradé communication

MOD-08 : mode dégradé capteur

MOD-09 : mode secours

MOD-10 : mode mise à jour

MOD-11 : mode arrêt contrôlé

MOD-12 : mode arrêt d’urgence

```

### 7.3 Mode arrêt

Cette partie décrit le comportement attendu lorsque le système est arrêté.

**Exemples d’exigences :**

```text

SYS-MOD-001 — En mode arrêt, le système ne doit exécuter aucune commande active.

SYS-MOD-002 — En mode arrêt, le système doit conserver la configuration persistante.

SYS-MOD-003 — En mode arrêt, le système doit permettre un démarrage contrôlé si les conditions d’alimentation sont satisfaites.

```

### 7.4 Mode démarrage et initialisation

Cette partie décrit les exigences relatives au démarrage.

**Exemples d’exigences :**

```text

SYS-MOD-010 — Au démarrage, le système doit vérifier la validité de sa configuration.

SYS-MOD-011 — Au démarrage, le système doit initialiser les interfaces nécessaires au fonctionnement nominal.

SYS-MOD-012 — Le système doit signaler toute anomalie empêchant le passage en mode nominal.

SYS-MOD-013 — Le système doit passer en mode nominal uniquement si les conditions minimales de fonctionnement sont satisfaites.

```

### 7.5 Mode nominal

Cette partie décrit le fonctionnement normal du système.

**Exemple :**

> En mode nominal, le système acquiert les mesures prévues, surveille les seuils configurés, transmet les données au serveur, met à jour l’interface opérateur et génère les alarmes si les conditions associées sont rencontrées.

**Exemples d’exigences :**

```text

SYS-MOD-020 — En mode nominal, le système doit exécuter les fonctions d’acquisition, de surveillance, de communication et de journalisation.

SYS-MOD-021 — En mode nominal, le système doit signaler tout défaut détecté.

SYS-MOD-022 — En mode nominal, le système doit maintenir l’état courant du système disponible pour l’opérateur.

```

### 7.6 Mode maintenance

Cette partie décrit les exigences générales applicables au mode maintenance.

**Exemples d’exigences :**

```text

SYS-MOD-030 — Le passage en mode maintenance doit être réservé à un utilisateur habilité.

SYS-MOD-031 — Le système doit indiquer clairement qu’il est en mode maintenance.

SYS-MOD-032 — Les actions réalisées en mode maintenance doivent être journalisées.

SYS-MOD-033 — Le retour au mode nominal doit réactiver les fonctions temporairement inhibées, sauf exception explicitement confirmée.

```

### 7.7 Modes dégradés

Cette partie décrit les exigences générales applicables aux modes dégradés.

Un mode dégradé doit préciser ce qui est perdu, ce qui est maintenu, ce qui est interdit, ce qui est signalé et comment le retour à la normale est réalisé.

**Exemples d’exigences :**

```text

SYS-MOD-040 — En cas de perte de communication serveur, le système doit maintenir les fonctions locales critiques.

SYS-MOD-041 — En cas d’indisponibilité d’un capteur non critique, le système doit signaler l’anomalie et poursuivre les fonctions non dépendantes de ce capteur.

SYS-MOD-042 — En cas de défaut critique, le système doit se placer dans un état sûr.

SYS-MOD-043 — Le système doit historiser l’entrée et la sortie d’un mode dégradé.

```

### 7.8 Transitions entre modes

Cette partie décrit les conditions de passage d’un mode à un autre.

Pour un système embarqué ou industriel, cette partie est particulièrement importante. Les erreurs de transition entre modes sont une source fréquente de défauts.

**Exemple :**

```text

Arrêt → Démarrage :

Condition : alimentation présente et commande de démarrage reçue.

Démarrage → Nominal :

Condition : configuration valide, interfaces initialisées, aucun défaut bloquant.

Nominal → Dégradé communication :

Condition : absence de communication serveur pendant plus de 120 secondes.

Dégradé communication → Nominal :

Condition : communication rétablie et synchronisation des données réalisée.

Nominal → Maintenance :

Condition : demande utilisateur habilité et absence d’action critique en cours.

```

---

## 8. Interfaces externes du système

### 8.1 Objet de la description des interfaces

Cette partie précise les interfaces entre le système et son environnement.

Une interface externe peut être matérielle, logicielle, réseau, utilisateur, électrique, mécanique ou documentaire.

Cette section ne doit pas encore nécessairement contenir tous les détails de protocole ou de câblage, qui pourront être décrits dans un dossier d’interfaces détaillé. Elle doit néanmoins identifier toutes les interfaces importantes.

### 8.2 Interfaces matérielles

Cette partie décrit les interfaces physiques avec les capteurs, actionneurs, alimentations, connecteurs ou équipements tiers.

**Exemples :**

```text

- alimentation électrique ;

- entrées numériques ;

- sorties relais ;

- entrées analogiques ;

- bus série ;

- connecteurs de maintenance ;

- capteurs externes ;

- actionneurs externes ;

- coffret ou armoire électrique.

```

**Exemple d’exigence :**

```text

SYS-IF-HW-001 — Le système doit disposer d’une interface d’alimentation compatible avec les caractéristiques électriques définies dans le dossier d’installation.

```

### 8.3 Interfaces logicielles

Cette partie décrit les interfaces avec les logiciels externes, applications tierces, API ou systèmes de supervision.

**Exemples :**

```text

- API serveur ;

- interface de supervision ;

- import/export de fichiers ;

- interface de configuration ;

- interface de diagnostic ;

- échange avec un logiciel tiers.

```

### 8.4 Interfaces réseau

Cette partie décrit les interfaces de communication réseau.

**Exemples :**

```text

- Ethernet ;

- Wi-Fi ;

- 4G / 5G ;

- VPN ;

- réseau local client ;

- réseau isolé de test ;

- protocole HTTPS ;

- protocole MQTT ;

- protocole Modbus TCP ;

- protocole propriétaire.

```

**Exemple d’exigence :**

```text

SYS-IF-NET-001 — Le système doit communiquer avec le serveur applicatif via le réseau défini dans le dossier d’infrastructure.

```

### 8.5 Interfaces utilisateur

Cette partie décrit les interfaces entre le système et les utilisateurs.

**Exemples :**

```text

- interface opérateur ;

- interface administrateur ;

- interface maintenance ;

- voyants ou afficheurs locaux ;

- boutons physiques ;

- messages d’alarme ;

- rapports exportés.

```

### 8.6 Interfaces documentaires

Cette partie précise les documents nécessaires aux échanges entre client, fournisseur, installateur, exploitant et mainteneur.

**Exemples :**

```text

- fichier de configuration ;

- fichier d’export ;

- rapport d’incident ;

- rapport de test ;

- journal d’exploitation ;

- procédure de maintenance ;

- dossier de configuration livrée.

```

---

## 9. Exigences non fonctionnelles

### 9.1 Exigences de performance

Cette partie décrit les exigences de temps de réponse, fréquence d’acquisition, délai d’affichage, volume de données, capacité de traitement ou nombre d’utilisateurs.

Les performances doivent être mesurables.

**Exemples d’exigences :**

```text

SYS-PERF-001 — Le système doit acquérir les mesures critiques avec une période maximale de 10 secondes.

SYS-PERF-002 — Une alarme critique doit être affichée sur l’interface opérateur en moins de 5 secondes après réception par le serveur.

SYS-PERF-003 — Le système doit permettre la consultation de l’historique des alarmes sur une période minimale de 12 mois.

SYS-PERF-004 — L’interface opérateur doit permettre la connexion simultanée d’au moins 10 utilisateurs.

```

### 9.2 Exigences de disponibilité

Cette partie décrit les exigences relatives à la disponibilité du système.

**Exemples :**

```text

SYS-DISP-001 — Le système doit être conçu pour permettre une exploitation continue pendant les périodes définies par le client.

SYS-DISP-002 — Une perte temporaire du serveur ne doit pas interrompre les fonctions locales critiques de l’équipement embarqué.

SYS-DISP-003 — Le système doit permettre un redémarrage contrôlé après coupure d’alimentation.

```

### 9.3 Exigences de fiabilité

Cette partie décrit les exigences relatives à la robustesse et à la stabilité du système.

**Exemples :**

```text

SYS-FIAB-001 — Le système ne doit pas perdre de configuration lors d’un redémarrage contrôlé.

SYS-FIAB-002 — Le système doit détecter et signaler les erreurs internes significatives.

SYS-FIAB-003 — Le système doit éviter toute perte silencieuse de données critiques.

```

### 9.4 Exigences de maintenabilité

Cette partie décrit les exigences facilitant la maintenance.

**Exemples :**

```text

SYS-MNT-001 — Le système doit permettre l’identification de la version logicielle installée.

SYS-MNT-002 — Le système doit permettre l’export des journaux nécessaires au diagnostic.

SYS-MNT-003 — Les composants remplaçables doivent être identifiables.

SYS-MNT-004 — Les opérations de maintenance courante doivent être décrites dans une procédure dédiée.

```

### 9.5 Exigences d’évolutivité

Cette partie décrit les exigences relatives aux extensions futures.

**Exemples :**

```text

SYS-EVO-001 — Le système doit permettre l’ajout d’un nouvel équipement surveillé sans modification majeure de l’architecture.

SYS-EVO-002 — Le système doit permettre l’ajout de nouveaux types d’alarmes par configuration ou évolution logicielle maîtrisée.

SYS-EVO-003 — Le système doit permettre une évolution des interfaces externes sous contrôle de version.

```

### 9.6 Exigences d’ergonomie

Cette partie décrit les attentes en matière d’usage et de lisibilité.

**Exemples :**

```text

SYS-ERG-001 — Les alarmes critiques doivent être visuellement distinguables des alarmes mineures.

SYS-ERG-002 — Les messages affichés à l’opérateur doivent être compréhensibles sans connaissance du code interne.

SYS-ERG-003 — Les actions critiques doivent demander une confirmation explicite.

```

---

## 10. Exigences de sécurité, sûreté et cybersécurité

### 10.1 Sécurité des personnes et des biens

Cette partie décrit les exigences visant à éviter les dommages physiques.

**Exemples :**

```text

SYS-SEC-001 — Le système ne doit pas déclencher une commande pouvant mettre en danger une personne si les conditions de sécurité ne sont pas satisfaites.

SYS-SEC-002 — En cas de défaut critique, le système doit rejoindre ou maintenir un état sûr.

SYS-SEC-003 — Les actions manuelles de maintenance doivent être réalisées dans des conditions empêchant les commandes intempestives.

```

### 10.2 Sûreté de fonctionnement

Cette partie décrit les exigences liées aux pannes, défauts, erreurs et comportements de repli.

**Exemples :**

```text

SYS-SDF-001 — Le système doit détecter les défauts critiques définis dans la spécification.

SYS-SDF-002 — Le système doit signaler les défauts détectés à l’opérateur.

SYS-SDF-003 — Le système doit garantir qu’un défaut critique ne reste pas silencieux.

SYS-SDF-004 — Le système doit conserver un historique des défauts critiques.

```

### 10.3 Cybersécurité

Cette partie décrit les exigences de protection contre les accès non autorisés, les modifications non maîtrisées, l’exposition réseau et la compromission des données.

**Exemples :**

```text

SYS-CYB-001 — L’accès aux fonctions d’administration doit être réservé aux utilisateurs authentifiés et autorisés.

SYS-CYB-002 — Les communications sensibles doivent être protégées conformément aux contraintes du projet.

SYS-CYB-003 — Les actions d’administration doivent être journalisées.

SYS-CYB-004 — Les mises à jour logicielles doivent être réalisées selon une procédure contrôlée.

SYS-CYB-005 — Les mots de passe ou secrets techniques ne doivent pas être stockés en clair dans les fichiers de configuration accessibles.

```

### 10.4 Gestion des droits

Cette partie décrit les profils d’accès attendus.

**Exemple :**

```text

Profil opérateur :

- consulter les états ;

- consulter les alarmes ;

- acquitter certaines alarmes.

Profil maintenance :

- accéder aux diagnostics ;

- exporter les logs ;

- réaliser certains tests.

Profil administrateur :

- gérer les comptes ;

- modifier la configuration ;

- réaliser les opérations de sauvegarde/restauration.

```

### 10.5 Journalisation des événements sensibles

Cette partie décrit les exigences de traçabilité des actions importantes.

**Exemples :**

```text

SYS-LOG-001 — Le système doit journaliser les connexions utilisateur.

SYS-LOG-002 — Le système doit journaliser les modifications de configuration.

SYS-LOG-003 — Le système doit journaliser les passages en mode maintenance.

SYS-LOG-004 — Le système doit journaliser les commandes critiques.

```

---

## 11. Exigences d’exploitation

### 11.1 Conditions d’exploitation

Cette partie décrit les conditions dans lesquelles le système devra être utilisé.

**Exemples :**

```text

- exploitation locale ;

- exploitation distante ;

- fonctionnement 24 h / 24 ;

- exploitation uniquement pendant les heures ouvrées ;

- présence ou absence d’un opérateur permanent ;

- environnement industriel ;

- environnement extérieur ;

- environnement isolé ou connecté.

```

### 11.2 Supervision

Cette partie décrit les exigences relatives à la surveillance du système.

**Exemples :**

```text

SYS-EXP-001 — Le système doit fournir un état global de fonctionnement.

SYS-EXP-002 — Le système doit signaler les défauts techniques empêchant la supervision.

SYS-EXP-003 — Le système doit permettre la consultation de l’état de communication des équipements.

SYS-EXP-004 — Le système doit permettre l’identification d’un équipement non joignable.

```

### 11.3 Sauvegarde

Cette partie décrit les exigences générales de sauvegarde.

Le détail technique pourra être décrit dans le dossier infrastructure.

**Exemples :**

```text

SYS-SAV-001 — Le système doit permettre la sauvegarde des données critiques.

SYS-SAV-002 — Le système doit permettre la sauvegarde de la configuration active.

SYS-SAV-003 — L’échec d’une sauvegarde planifiée doit être signalé à un utilisateur autorisé.

```

### 11.4 Restauration

Cette partie décrit les exigences relatives à la restauration du système.

**Exemples :**

```text

SYS-REST-001 — Le système doit permettre la restauration d’une configuration sauvegardée.

SYS-REST-002 — Une procédure de restauration doit être fournie.

SYS-REST-003 — La restauration doit être vérifiable par un test dédié.

```

### 11.5 Archivage

Cette partie décrit les exigences de conservation longue durée.

**Exemples :**

```text

SYS-ARCH-001 — Le système doit permettre l’archivage des historiques au-delà de la période de consultation courante.

SYS-ARCH-002 — Les données archivées doivent rester associées à leur horodatage et à l’équipement d’origine.

```

---

## 12. Exigences de maintenance

### 12.1 Maintenance préventive

Cette partie décrit les exigences générales relatives aux opérations périodiques de maintenance.

**Exemples :**

```text

SYS-MNT-010 — Le système doit permettre la vérification de son état de fonctionnement.

SYS-MNT-011 — Le système doit fournir les informations nécessaires à la maintenance préventive.

SYS-MNT-012 — Les opérations de maintenance préventive doivent être décrites dans une procédure dédiée.

```

### 12.2 Maintenance corrective

Cette partie décrit les exigences permettant de diagnostiquer et corriger une anomalie.

**Exemples :**

```text

SYS-MNT-020 — Le système doit fournir des codes défauts ou messages permettant d’orienter le diagnostic.

SYS-MNT-021 — Le système doit permettre l’export des journaux techniques.

SYS-MNT-022 — Le remplacement d’un composant doit être possible selon une procédure documentée si le composant est prévu comme remplaçable.

```

### 12.3 Maintenance logicielle

Cette partie décrit les exigences relatives aux mises à jour logiciel ou firmware.

**Exemples :**

```text

SYS-MNT-030 — Le système doit permettre l’identification de la version logicielle installée.

SYS-MNT-031 — La mise à jour logicielle doit être réalisée selon une procédure contrôlée.

SYS-MNT-032 — Une mise à jour doit être journalisée.

SYS-MNT-033 — Le système doit permettre une vérification du bon fonctionnement après mise à jour.

```

### 12.4 Maintenance infrastructure

Cette partie décrit les exigences liées aux serveurs, bases de données, réseau et sauvegardes.

**Exemples :**

```text

SYS-MNT-040 — Le système doit permettre la vérification de l’état des services applicatifs.

SYS-MNT-041 — Le système doit fournir les informations nécessaires au diagnostic d’un défaut serveur ou réseau.

SYS-MNT-042 — Les procédures de redémarrage, sauvegarde et restauration doivent être documentées.

```

---

## 13. Exigences d’installation et de déploiement

### 13.1 Installation matérielle

Cette partie décrit les exigences globales liées à l’installation physique.

**Exemples :**

```text

SYS-INS-001 — Le système doit être installable dans les conditions environnementales définies par le projet.

SYS-INS-002 — Les interfaces électriques et mécaniques nécessaires à l’installation doivent être identifiées.

SYS-INS-003 — Une procédure d’installation matérielle doit être fournie.

```

### 13.2 Déploiement logiciel

Cette partie décrit les exigences globales de déploiement logiciel.

**Exemples :**

```text

SYS-DEP-001 — Le système doit être livré avec les éléments nécessaires à l’installation du logiciel.

SYS-DEP-002 — Les versions logicielles déployées doivent être identifiables.

SYS-DEP-003 — Une procédure de déploiement doit être fournie.

SYS-DEP-004 — Le déploiement doit permettre une vérification du bon fonctionnement après installation.

```

### 13.3 Environnements de déploiement

Cette partie décrit les environnements concernés.

**Exemples :**

```text

- environnement de développement ;

- environnement de test ;

- environnement de validation ;

- environnement de préproduction ;

- environnement de production ;

- environnement de maintenance.

```

### 13.4 Configuration initiale

Cette partie décrit les exigences relatives à la configuration au démarrage ou à la livraison.

**Exemples :**

```text

SYS-CFG-010 — Le système doit être livré avec une configuration initiale documentée.

SYS-CFG-011 — Toute configuration spécifique au site doit être identifiée.

SYS-CFG-012 — La configuration livrée doit être sauvegardée avant mise en service.

```

---

## 14. Exigences d’infrastructure

### 14.1 Objet des exigences d’infrastructure

Cette partie décrit les exigences globales relatives aux PC, serveurs, réseau, stockage, sauvegarde, environnements et services nécessaires au fonctionnement du système.

Le détail technique complet peut être placé dans le dossier d’infrastructure, mais la spécification globale doit identifier les exigences principales.

### 14.2 Serveurs

Cette partie décrit les exigences concernant les serveurs nécessaires.

**Exemples :**

```text

SYS-INF-001 — Le système doit disposer d’un environnement serveur permettant l’exécution de l’application.

SYS-INF-002 — Les rôles des serveurs de test, validation et production doivent être distingués.

SYS-INF-003 — Les versions des composants logiciels serveur doivent être identifiables.

```

### 14.3 Stockage

Cette partie décrit les exigences relatives au stockage des données.

**Exemples :**

```text

SYS-INF-010 — Le système doit disposer d’une capacité de stockage suffisante pour les données d’exploitation sur la durée définie.

SYS-INF-011 — Le système doit signaler une saturation prochaine du stockage si cette saturation peut affecter le fonctionnement.

SYS-INF-012 — Les données critiques doivent être protégées contre une suppression accidentelle non maîtrisée.

```

### 14.4 Réseau

Cette partie décrit les exigences réseau globales.

**Exemples :**

```text

SYS-INF-020 — Le système doit pouvoir fonctionner sur le réseau défini pour le projet.

SYS-INF-021 — Les flux réseau nécessaires au fonctionnement doivent être identifiés.

SYS-INF-022 — Le système doit pouvoir détecter une perte de communication avec les équipements ou serveurs critiques.

```

### 14.5 Sauvegarde et restauration

Cette partie décrit les exigences principales de sauvegarde et restauration.

**Exemples :**

```text

SYS-INF-030 — Les données et configurations critiques doivent être sauvegardables.

SYS-INF-031 — Une procédure de restauration doit permettre de récupérer un état exploitable du système.

SYS-INF-032 — La restauration doit être testée dans le cadre de la validation.