CANEVAS DES DOCUMENTS DU PROJET

# Canevas 7A — Spécification détaillée hardware

## 1. Objet du document

### 1.1 Finalité de la spécification détaillée hardware

Cette partie précise l’objectif du document.

La spécification détaillée hardware décrit ce que doivent faire les éléments matériels du système. Elle précise les exigences applicables aux cartes électroniques, coffrets, alimentations, capteurs, actionneurs, interfaces électriques, connecteurs, protections, moyens de diagnostic, contraintes environnementales, contraintes de sécurité et exigences de testabilité.

Elle ne doit pas encore décrire complètement la conception électronique détaillée, les schémas, le routage PCB, le choix définitif de chaque composant ou les plans de fabrication. Ces éléments relèvent du dossier de conception détaillée hardware. La spécification détaillée hardware décrit d’abord les exigences que la conception devra satisfaire.

**Exemple :**

> Le présent document a pour objectif de spécifier les exigences détaillées applicables au sous-système hardware. Il décrit les fonctions matérielles attendues, les interfaces électriques, les contraintes d’alimentation, les entrées/sorties, les protections, les exigences environnementales, les exigences de sécurité, les exigences de diagnostic et les exigences de testabilité du matériel.

### 1.2 Positionnement dans le cycle en V

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

La spécification détaillée hardware est issue de la spécification globale, du dossier des modes de fonctionnement et de l’architecture système. Elle sert d’entrée à la conception détaillée hardware, aux tests unitaires hardware, aux tests d’intégration hardware/software et aux tests système.

Elle se situe entre l’architecture système et la conception détaillée hardware.

```text

Spécification globale

        ↓

Architecture système / conception globale

        ↓

Spécification détaillée hardware

        ↓

Conception détaillée hardware

        ↓

Fabrication / câblage / assemblage

        ↑

Tests unitaires hardware

        ↑

Tests d’intégration hardware/software

        ↑

Tests système

        ↑

Validation

```

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

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

La spécification globale décrit le comportement attendu du système complet. La spécification détaillée hardware décline ces exigences au niveau du matériel.

**Exemple :**

```text

Spécification globale :

Le système doit mesurer la température interne de l’équipement.

Spécification détaillée hardware :

Le sous-système hardware doit intégrer une entrée capteur de température compatible avec la plage de mesure définie.

Le capteur ou l’entrée de mesure doit permettre de couvrir la plage de température de fonctionnement du système avec une précision compatible avec les exigences de surveillance.

```

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

Cette partie précise la frontière avec la conception détaillée.

La spécification détaillée hardware dit **ce que le matériel doit permettre**.

La conception détaillée hardware dira **comment le matériel est réalisé**.

**Exemple :**

```text

Spécification détaillée hardware :

Le système doit fournir une entrée numérique isolée pour détecter l’état d’un contact sec externe.

Conception détaillée hardware :

L’entrée numérique est réalisée par un optocoupleur de référence X, avec résistance série Y, protection Z, filtrage RC et raccordement sur le connecteur J3 broche 4.

```

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

Cette partie précise qui rédige et valide le document.

La spécification détaillée hardware doit être rédigée par le responsable hardware ou l’ingénieur électronique, avec les contributions du responsable système, du logiciel embarqué, de l’intégration, de la validation, de la maintenance et de la sécurité si le matériel peut présenter un risque.

**Exemple :**

```text

Rédaction : responsable hardware / ingénieur électronique

Contribution : ingénieur système, logiciel embarqué, intégration, validation, maintenance, sécurité

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

Approbation : responsable technique fournisseur et client si le document est contractuel

```

---

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

### 2.1 Documents d’entrée

Cette partie liste les documents utilisés pour établir la spécification hardware.

Ces documents doivent être identifiés par leur référence, leur version et leur statut afin de garantir que la spécification est construite sur une base maîtrisée.

**Exemples :**

```text

- Cahier des charges / expression de besoin

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

- Architecture système / conception globale

- Dossier des modes de fonctionnement

- Analyse de risques préliminaire

- Contraintes d’installation

- Contraintes environnementales

- Contraintes de sécurité électrique

- Contraintes CEM

- Spécification des interfaces

- Spécification détaillée software embarqué, si disponible

- Documentation des capteurs ou actionneurs externes

```

### 2.2 Documents applicables

Cette partie liste les documents qui s’imposent au matériel.

Il peut s’agir de normes, de standards internes, de contraintes client ou de règles réglementaires.

**Exemples :**

```text

- normes électriques applicables ;

- exigences de compatibilité électromagnétique ;

- règles de câblage client ;

- standard de connectique ;

- standard de repérage des câbles ;

- exigences de protection IP ;

- exigences de sécurité machine ;

- exigences batteries si applicable ;

- exigences de maintenance ;

- exigences de testabilité ;

- exigences de marquage et identification.

```

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

Cette partie liste les documents qui seront dérivés de la spécification détaillée hardware.

**Exemples :**

```text

- dossier de conception détaillée hardware ;

- schémas électroniques ;

- plans de câblage ;

- nomenclature matérielle ;

- plan d’implantation coffret ;

- dossier de fabrication ;

- procédure d’assemblage ;

- procédure de tests hardware ;

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

- dossier de maintenance hardware ;

- dossier de configuration matérielle livrée.

```

### 2.4 Gestion des versions

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

Une évolution hardware peut avoir des impacts importants sur le logiciel, les tests, les procédures de maintenance, les stocks de pièces de rechange et la compatibilité avec les installations existantes.

**Exemple :**

> Toute modification d’une interface électrique, d’un connecteur, d’une alimentation, d’un capteur, d’une carte électronique ou d’un composant critique doit faire l’objet d’une analyse d’impact sur le logiciel embarqué, les tests d’intégration, le dossier de maintenance et la configuration livrée.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

Cette partie définit les termes utilisés dans la spécification hardware.

**Exemples :**

```text

Entrée numérique :

Interface permettant de détecter un état logique, par exemple ouvert/fermé, actif/inactif, défaut présent/défaut absent.

Sortie relais :

Interface permettant de commander une charge ou de transmettre un contact d’état à un équipement externe.

Interface isolée :

Interface présentant une isolation électrique entre deux parties du système afin de limiter les risques de perturbation, défaut ou propagation de tension.

État sûr :

État matériel dans lequel les sorties et fonctions critiques sont placées afin d’éviter une situation dangereuse.

Banc de test :

Ensemble de moyens permettant de vérifier le fonctionnement d’une carte, d’un sous-ensemble ou de l’équipement complet.

```

### 3.2 Acronymes

**Exemples :**

```text

ADC   : Analog-to-Digital Converter

BMS   : Battery Management System

CEM   : Compatibilité électromagnétique

CPU   : Central Processing Unit

DC    : Direct Current

GPIO  : General Purpose Input/Output

I/O   : Input / Output

PCB   : Printed Circuit Board

PWM   : Pulse Width Modulation

RS485 : bus série différentiel

```

### 3.3 Convention d’identification des exigences hardware

Cette partie définit la codification des exigences.

**Exemple :**

```text

HW-ALIM-001 : exigence d’alimentation

HW-IN-001   : exigence d’entrée

HW-OUT-001  : exigence de sortie

HW-COM-001  : exigence de communication matérielle

HW-PROT-001 : exigence de protection

HW-ENV-001  : exigence environnementale

HW-MNT-001  : exigence de maintenance

HW-TEST-001 : exigence de testabilité

```

### 3.4 Convention de formulation des exigences

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

**Exemples :**

```text

Correct :

HW-IN-001 — Le matériel doit fournir une entrée numérique isolée permettant de détecter l’état d’un contact sec externe.

Incorrect :

L’entrée doit être robuste.

Correct :

HW-ALIM-001 — Le matériel doit fonctionner avec une alimentation nominale de 24 VDC, dans la plage définie par les contraintes d’installation.

Incorrect :

Le matériel doit supporter les variations normales d’alimentation.

```

---

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

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

Cette partie décrit le sous-système hardware dans son ensemble.

Elle doit permettre de comprendre quels éléments matériels composent le système, où ils sont installés, quelles fonctions ils assurent et quelles interfaces ils exposent au logiciel, aux capteurs, aux actionneurs et à l’infrastructure.

**Exemple :**

> Le sous-système hardware est constitué d’un coffret industriel intégrant une alimentation, une carte de contrôle, des interfaces d’entrées/sorties, un module de communication, des protections électriques, une connectique terrain, un port de maintenance et des moyens de signalisation locale.

### 4.2 Composition matérielle

Cette partie liste les éléments matériels prévus.

**Exemples :**

```text

- coffret ou boîtier ;

- carte électronique principale ;

- carte d’extension entrées/sorties ;

- alimentation ;

- protections électriques ;

- connecteurs terrain ;

- bornier ;

- module de communication ;

- support de stockage local ;

- afficheur ou voyants ;

- bouton de commande ;

- bouton d’arrêt d’urgence si applicable ;

- ventilateur ou dispositif thermique si nécessaire ;

- câbles internes ;

- capteurs intégrés ;

- actionneurs ou relais.

```

### 4.3 Synoptique matériel

Cette partie présente une vue schématique du matériel.

**Exemple textuel :**

```text

Alimentation externe

        ↓

Protection / filtrage

        ↓

Alimentation interne

        ↓

Carte de contrôle principale

        ├── Entrées numériques

        ├── Entrées analogiques

        ├── Sorties relais

        ├── Module de communication

        ├── Stockage local

        ├── Port maintenance

        ├── Voyants / afficheur

        └── Interface logiciel embarqué

```

### 4.4 Frontières du sous-système hardware

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

**Exemple :**

```text

Inclus :

- coffret fourni ;

- carte électronique ;

- alimentation interne ;

- connectique ;

- protections ;

- module communication ;

- voyants locaux.

Externe :

- alimentation générale du site ;

- réseau client ;

- capteurs fournis par le client si non inclus ;

- actionneurs tiers ;

- serveur applicatif ;

- poste opérateur ;

- installation électrique amont.

```

### 4.5 Responsabilités hardware / software

Cette partie clarifie ce qui relève du matériel et ce qui relève du logiciel embarqué.

**Exemple :**

```text

Fonction : détection d’un contact sec.

Responsabilité hardware :

fournir une entrée électrique compatible, protégée et lisible par le microcontrôleur.

Responsabilité software :

lire l’entrée, filtrer les rebonds, interpréter l’état, générer un événement si l’état change.

```

---

## 5. Exigences d’alimentation

### 5.1 Objet des exigences d’alimentation

Cette partie décrit les exigences relatives à l’énergie nécessaire au fonctionnement du matériel.

L’alimentation est un point critique, car elle conditionne le démarrage, la stabilité, la sécurité, les protections, les modes dégradés et la disponibilité du système.

### 5.2 Source d’alimentation

Cette partie précise la ou les sources d’alimentation prévues.

**Exemples :**

```text

- alimentation secteur 230 VAC ;

- alimentation 24 VDC industrielle ;

- alimentation batterie ;

- alimentation secourue ;

- alimentation issue d’un équipement tiers ;

- alimentation photovoltaïque ou autonome ;

- alimentation par bus ou connecteur spécifique.

```

**Exemple d’exigence :**

```text

HW-ALIM-001 — Le sous-système hardware doit être compatible avec la source d’alimentation définie dans le dossier d’installation.

```

### 5.3 Plage de fonctionnement

Cette partie précise les tolérances d’alimentation.

**Exemple :**

```text

HW-ALIM-002 — Le sous-système hardware doit fonctionner dans la plage de tension d’alimentation définie pour l’installation, incluant les variations normales de la source.

```

Il faut éviter les formulations vagues. Lorsque les valeurs sont connues, elles doivent être explicites.

**Exemple plus précis :**

```text

HW-ALIM-002 — Le sous-système hardware doit fonctionner avec une alimentation 24 VDC dans une plage de 20 VDC à 30 VDC.

```

### 5.4 Consommation électrique

Cette partie décrit les exigences de consommation.

**Exemples :**

```text

HW-ALIM-010 — La consommation maximale du sous-système hardware doit être compatible avec le dimensionnement de l’alimentation prévue.

HW-ALIM-011 — La consommation en mode veille ou arrêt doit être documentée.

HW-ALIM-012 — La consommation des sorties commandées doit être prise en compte dans le dimensionnement global.

```

### 5.5 Protection de l’alimentation

Cette partie décrit les protections attendues.

**Exemples :**

```text

- protection contre inversion de polarité ;

- protection contre surtension ;

- protection contre surintensité ;

- fusible ;

- disjoncteur ;

- filtrage ;

- protection contre transitoires ;

- mise à la terre ;

- isolement.

```

**Exemple d’exigence :**

```text

HW-ALIM-020 — Le sous-système hardware doit intégrer ou prévoir une protection contre les surintensités susceptibles d’endommager l’équipement.

```

### 5.6 Comportement en cas de perte d’alimentation

Cette partie décrit le comportement attendu lors d’une coupure.

**Exemples :**

```text

HW-ALIM-030 — En cas de perte d’alimentation, les sorties doivent rejoindre un état défini.

HW-ALIM-031 — Le matériel ne doit pas générer de commande intempestive lors de la perte ou du retour d’alimentation.

HW-ALIM-032 — Les données critiques doivent être protégées contre une corruption liée à une coupure d’alimentation, lorsque cela dépend du matériel.

```

### 5.7 Alimentation secourue

Cette partie est à compléter si une batterie ou une alimentation de secours existe.

**Exemples :**

```text

- autonomie minimale ;

- fonctions maintenues sur secours ;

- seuil de batterie faible ;

- alarme alimentation secours ;

- comportement en fin d’autonomie ;

- recharge ;

- diagnostic de l’état batterie ;

- remplacement batterie.

```

---

## 6. Exigences d’entrées

### 6.1 Objet des entrées

Cette partie décrit les signaux que le matériel doit recevoir.

Il peut s’agir d’entrées numériques, analogiques, capteurs, bus de communication, contacts secs, signaux de défaut, commandes externes ou mesures électriques.

### 6.2 Liste des entrées

Cette partie liste toutes les entrées prévues.

**Exemple :**

```text

Entrée | Type             | Source              | Usage              | Criticité

IN-001 | numérique isolée | contact sec externe | état porte coffret | moyenne

IN-002 | analogique       | capteur température | mesure température | élevée

IN-003 | numérique        | bouton local        | demande démarrage  | élevée

IN-004 | bus RS485        | équipement tiers    | données BMS        | élevée

IN-005 | arrêt urgence    | bouton AU           | sécurité           | critique

```

### 6.3 Entrées numériques

Cette partie décrit les exigences applicables aux entrées logiques.

**Exemples d’exigences :**

```text

HW-IN-001 — Le matériel doit fournir le nombre d’entrées numériques défini par le besoin d’interface terrain.

HW-IN-002 — Les entrées numériques doivent être compatibles avec les niveaux électriques des signaux externes.

HW-IN-003 — Les entrées numériques critiques doivent être protégées contre les perturbations électriques raisonnablement prévisibles dans l’environnement d’installation.

HW-IN-004 — L’état des entrées numériques doit être lisible par le logiciel embarqué.

```

### 6.4 Entrées analogiques

Cette partie décrit les exigences relatives aux mesures analogiques.

**Exemples :**

```text

HW-IN-ANA-001 — Le matériel doit fournir une entrée analogique compatible avec la plage de mesure du capteur raccordé.

HW-IN-ANA-002 — La résolution de mesure doit être compatible avec la précision attendue au niveau système.

HW-IN-ANA-003 — Les entrées analogiques doivent être protégées contre les dépassements raisonnablement prévisibles.

HW-IN-ANA-004 — Les entrées analogiques doivent permettre la détection d’une valeur hors plage si cette information est nécessaire au diagnostic.

```

### 6.5 Entrées capteurs

Cette partie décrit les exigences propres aux capteurs.

**Exemples de points à préciser :**

```text

- type de capteur ;

- plage de mesure ;

- précision attendue ;

- fréquence de lecture ;

- raccordement ;

- alimentation du capteur ;

- diagnostic capteur ;

- détection de rupture ;

- détection de court-circuit ;

- calibration ;

- remplacement.

```

### 6.6 Entrées critiques de sécurité

Cette partie concerne les entrées ayant un impact direct sur la sécurité.

**Exemples :**

```text

- arrêt d’urgence ;

- défaut électrique critique ;

- défaut batterie ;

- porte ouverte ;

- surtempérature ;

- défaut de contacteur ;

- défaut de retour d’état ;

- signal de consignation.

```

**Exemple d’exigence :**

```text

HW-IN-SEC-001 — Les entrées critiques de sécurité doivent être conçues de manière à permettre la détection fiable de leur état par le système.

```

### 6.7 Filtrage et anti-rebond

Cette partie précise les exigences liées au filtrage des signaux.

Le filtrage peut être matériel, logiciel ou mixte. La spécification hardware doit préciser ce qui est attendu du matériel.

**Exemple :**

```text

HW-IN-010 — Les entrées susceptibles d’être perturbées par des rebonds ou parasites doivent permettre un filtrage compatible avec les exigences de détection du système.

```

### 6.8 Diagnostic des entrées

Cette partie décrit les exigences permettant de détecter des défauts d’entrée.

**Exemples :**

```text

- entrée bloquée ;

- valeur incohérente ;

- signal absent ;

- court-circuit ;

- rupture de câble ;

- valeur hors plage ;

- défaut capteur.

```

---

## 7. Exigences de sorties

### 7.1 Objet des sorties

Cette partie décrit les signaux ou actions que le matériel doit produire.

Il peut s’agir de sorties relais, sorties numériques, sorties analogiques, voyants, afficheurs, commandes d’actionneurs, signaux de défaut ou interfaces vers un équipement tiers.

### 7.2 Liste des sorties

**Exemple :**

```text

Sortie  | Type       | Destination        | Usage                 | Criticité

OUT-001 | relais     | contacteur externe | commande marche/arrêt | critique

OUT-002 | voyant     | face avant         | état système          | faible

OUT-003 | numérique  | équipement tiers   | défaut général        | élevée

OUT-004 | analogique | régulateur         | consigne              | moyenne

```

### 7.3 Sorties relais

Cette partie décrit les exigences applicables aux relais.

**Exemples :**

```text

HW-OUT-REL-001 — Le matériel doit fournir une sortie relais destinée à commander ou signaler un état vers un équipement externe.

HW-OUT-REL-002 — Le pouvoir de coupure du relais doit être compatible avec la charge raccordée.

HW-OUT-REL-003 — L’état par défaut du relais en absence d’alimentation doit être défini.

HW-OUT-REL-004 — Les sorties relais critiques doivent être identifiées dans le dossier hardware.

```

### 7.4 Sorties numériques

Cette partie décrit les sorties logiques.

**Exemples :**

```text

HW-OUT-DIG-001 — Les sorties numériques doivent être compatibles avec les niveaux électriques de l’équipement destinataire.

HW-OUT-DIG-002 — Les sorties numériques doivent être protégées contre les courts-circuits si l’environnement d’utilisation le nécessite.

HW-OUT-DIG-003 — L’état initial des sorties au démarrage doit être défini.

```

### 7.5 Sorties analogiques

Cette partie décrit les sorties analogiques éventuelles.

**Exemples :**

```text

HW-OUT-ANA-001 — Le matériel doit fournir une sortie analogique compatible avec la plage de consigne attendue.

HW-OUT-ANA-002 — La précision de la sortie analogique doit être compatible avec l’usage prévu.

HW-OUT-ANA-003 — Une valeur de repli doit être définie en cas de défaut critique.

```

### 7.6 Signalisation locale

Cette partie décrit les voyants, afficheurs ou signaux locaux.

**Exemples :**

```text

- voyant alimentation ;

- voyant défaut ;

- voyant communication ;

- voyant mode maintenance ;

- afficheur état système ;

- buzzer ;

- indicateur batterie ;

- indicateur activité réseau.

```

**Exemple d’exigence :**

```text

HW-SIG-001 — Le matériel doit fournir une signalisation locale permettant d’identifier l’état général du système : alimentation, fonctionnement nominal, défaut et communication.

```

### 7.7 État sûr des sorties

Cette partie est essentielle pour les systèmes industriels.

Elle définit l’état des sorties lors des situations critiques : arrêt, démarrage, défaut, perte d’alimentation, arrêt d’urgence, redémarrage.

**Exemples :**

```text

HW-OUT-SAFE-001 — Les sorties critiques doivent rejoindre un état sûr en cas de perte d’alimentation.

HW-OUT-SAFE-002 — Les sorties ne doivent pas générer d’impulsion intempestive lors du démarrage.

HW-OUT-SAFE-003 — Les sorties commandant une action dangereuse doivent être inhibées en mode secours ou arrêt d’urgence.

```

---

## 8. Exigences de communication matérielle

### 8.1 Objet des interfaces de communication

Cette partie décrit les interfaces matérielles permettant l’échange de données entre le matériel et d’autres éléments : logiciel embarqué, serveur, capteurs intelligents, BMS, équipements tiers, port de maintenance, bus terrain, etc.

### 8.2 Interfaces prévues

**Exemples :**

```text

- Ethernet ;

- RS485 ;

- CAN ;

- USB ;

- UART ;

- SPI ;

- I2C ;

- Wi-Fi ;

- 4G / LTE ;

- Bluetooth si applicable ;

- interface propriétaire ;

- port de maintenance.

```

### 8.3 Ethernet

Cette partie décrit les exigences matérielles liées à l’Ethernet.

**Exemples :**

```text

HW-COM-ETH-001 — Le matériel doit disposer d’une interface Ethernet compatible avec le réseau défini dans le dossier infrastructure.

HW-COM-ETH-002 — Le connecteur Ethernet doit être accessible selon les contraintes d’installation et de maintenance.

HW-COM-ETH-003 — L’état de liaison Ethernet doit être détectable ou signalable si nécessaire au diagnostic.

```

### 8.4 Bus série ou industriel

Cette partie décrit les bus de type RS485, CAN ou autres.

**Exemples :**

```text

HW-COM-BUS-001 — Le matériel doit fournir une interface RS485 compatible avec l’équipement tiers défini.

HW-COM-BUS-002 — L’interface bus doit permettre un fonctionnement fiable dans l’environnement électromagnétique prévu.

HW-COM-BUS-003 — Le câblage du bus doit être documenté dans le dossier d’installation.

```

### 8.5 Module radio ou cellulaire

Cette partie est à compléter si une liaison radio ou 4G est prévue.

**Exemples de points à spécifier :**

```text

- type de module ;

- antenne ;

- connecteur antenne ;

- carte SIM ;

- puissance ;

- couverture ;

- consommation ;

- diagnostic réseau ;

- redémarrage module ;

- contraintes réglementaires radio.

```

### 8.6 Port de maintenance

Cette partie décrit l’interface de maintenance locale.

**Exemples :**

```text

HW-MNT-PORT-001 — Le matériel doit fournir un port de maintenance permettant le diagnostic local de l’équipement.

HW-MNT-PORT-002 — L’accès au port de maintenance doit être physiquement accessible sans démontage excessif de l’équipement, tout en restant protégé contre un usage non autorisé si nécessaire.

HW-MNT-PORT-003 — Le port de maintenance ne doit pas permettre d’action dangereuse sans contrôle logiciel ou procédure adaptée.

```

---

## 9. Exigences de traitement matériel et ressources embarquées

### 9.1 Objet des ressources de traitement

Cette partie décrit les exigences relatives au microcontrôleur, processeur, mémoire, stockage local et ressources matérielles nécessaires à l’exécution du logiciel embarqué.

### 9.2 Processeur ou microcontrôleur

Cette partie précise les contraintes de puissance de calcul.

**Exemples :**

```text

HW-CPU-001 — Le processeur ou microcontrôleur doit disposer des ressources nécessaires pour exécuter les fonctions d’acquisition, traitement, communication, stockage local et diagnostic.

HW-CPU-002 — La charge de calcul prévue doit conserver une marge compatible avec les évolutions et les pics d’activité.

HW-CPU-003 — Les périphériques matériels nécessaires aux interfaces prévues doivent être disponibles.

```

### 9.3 Mémoire volatile

Cette partie décrit les besoins de RAM.

**Exemples :**

```text

HW-MEM-001 — La mémoire volatile doit être suffisante pour exécuter le logiciel embarqué et gérer les buffers de communication, d’acquisition et de stockage temporaire.

HW-MEM-002 — Une marge mémoire doit être prévue afin d’éviter un fonctionnement proche de la saturation.

```

### 9.4 Mémoire non volatile

Cette partie décrit les besoins de stockage persistant.

**Exemples :**

```text

HW-NVM-001 — Le matériel doit fournir une mémoire non volatile permettant de conserver la configuration locale.

HW-NVM-002 — Les données critiques nécessaires à la reprise après redémarrage doivent être stockées de manière persistante.

HW-NVM-003 — La mémoire non volatile doit être compatible avec le nombre d’écritures attendu sur la durée de vie du système.

```

### 9.5 Stockage local de données

Cette partie concerne les systèmes qui doivent fonctionner en perte réseau.

**Exemple :**

```text

HW-STO-001 — Le matériel doit fournir une capacité de stockage local suffisante pour conserver les données non transmises pendant la durée minimale de perte communication définie.

```

**Exemple explicatif :**

> Si le système doit pouvoir fonctionner 48 heures sans serveur, la capacité de stockage local doit être dimensionnée à partir de la fréquence d’acquisition, de la taille des messages, du nombre de données conservées et d’une marge de sécurité.

### 9.6 Horloge temps réel

Cette partie décrit les exigences d’horodatage.

**Exemples :**

```text

HW-RTC-001 — Le matériel doit permettre le maintien d’une référence temporelle locale si les données doivent être horodatées en absence de communication serveur.

HW-RTC-002 — En cas de perte de synchronisation horaire, le système doit permettre l’identification de l’incertitude d’horodatage.

```

### 9.7 Watchdog matériel

Cette partie décrit les exigences de surveillance matérielle.

**Exemples :**

```text

HW-WDG-001 — Le matériel doit fournir un mécanisme de surveillance permettant de détecter un blocage logiciel critique.

HW-WDG-002 — Le déclenchement du watchdog doit placer le système dans un état défini et permettre une journalisation ou une détection au redémarrage si possible.

```

---

## 10. Exigences mécaniques et intégration physique

### 10.1 Objet des exigences mécaniques

Cette partie décrit les contraintes d’intégration physique : coffret, dimensions, fixation, accessibilité, connectique, dissipation thermique, protection, maintenance.

### 10.2 Coffret ou boîtier

**Exemples :**

```text

HW-MEC-001 — Le matériel doit être intégré dans un coffret compatible avec l’environnement d’installation.

HW-MEC-002 — Le coffret doit permettre l’accès aux éléments de maintenance prévus.

HW-MEC-003 — Le coffret doit protéger les composants internes contre les conditions environnementales spécifiées.

```

### 10.3 Dimensions et encombrement

Cette partie précise les contraintes de taille.

**Exemples :**

```text

- largeur maximale ;

- hauteur maximale ;

- profondeur maximale ;

- volume disponible ;

- espace pour câblage ;

- dégagement pour ventilation ;

- rayon de courbure des câbles ;

- accès maintenance.

```

### 10.4 Fixation et montage

Cette partie décrit la manière dont le matériel est installé.

**Exemples :**

```text

- montage mural ;

- rail DIN ;

- rack ;

- platine ;

- fixation sur châssis ;

- intégration en coffret existant ;

- montage antivibratoire ;

- orientation imposée.

```

### 10.5 Accessibilité maintenance

Cette partie décrit ce qui doit être accessible pendant une intervention.

**Exemples :**

```text

- connecteurs ;

- fusibles ;

- voyants ;

- port maintenance ;

- carte mémoire ;

- batterie ;

- module remplaçable ;

- étiquettes d’identification ;

- boutons de test.

```

### 10.6 Dissipation thermique

Cette partie décrit les exigences thermiques.

**Exemples :**

```text

HW-THERM-001 — Le matériel doit dissiper la chaleur produite sans dépasser les limites de fonctionnement des composants.

HW-THERM-002 — Si une ventilation est nécessaire, son défaut doit être pris en compte dans le diagnostic ou la maintenance.

HW-THERM-003 — Les composants sensibles à la température doivent être implantés ou protégés de manière compatible avec l’environnement prévu.

```

### 10.7 Marquage et identification

Cette partie précise les exigences d’étiquetage.

**Exemples :**

```text

- numéro de série ;

- version hardware ;

- référence produit ;

- tension d’alimentation ;

- avertissements de sécurité ;

- identification connecteurs ;

- repérage des câbles ;

- date de fabrication ;

- QR code ou code-barres si applicable.

```

---

## 11. Exigences environnementales

### 11.1 Objet des exigences environnementales

Cette partie décrit les conditions physiques dans lesquelles le matériel doit fonctionner, être stocké, transporté ou maintenu.

### 11.2 Température

**Exemples :**

```text

HW-ENV-TEMP-001 — Le matériel doit fonctionner dans la plage de température définie pour son environnement d’utilisation.

HW-ENV-TEMP-002 — Le matériel doit être stockable dans la plage de température définie pour le transport et l’entreposage.

HW-ENV-TEMP-003 — Le système doit signaler ou prendre en compte une température interne excessive si cela est nécessaire à la sûreté de fonctionnement.

```

### 11.3 Humidité et condensation

**Exemples :**

```text

HW-ENV-HUM-001 — Le matériel doit être compatible avec le niveau d’humidité attendu dans l’environnement d’installation.

HW-ENV-HUM-002 — Les risques de condensation doivent être pris en compte si le matériel est installé en environnement extérieur ou non chauffé.

```

### 11.4 Poussière, eau et indice de protection

**Exemples :**

```text

- protection contre poussière ;

- projections d’eau ;

- pluie ;

- nettoyage ;

- environnement extérieur ;

- indice IP ;

- presse-étoupes ;

- joints ;

- évent de mise à l’air si nécessaire.

```

### 11.5 Vibrations et chocs

Cette partie est importante si le matériel est embarqué dans un véhicule, une machine, un container, une installation mobile ou un environnement industriel.

**Exemples :**

```text

HW-ENV-VIB-001 — Le matériel doit supporter les vibrations attendues dans son environnement d’installation.

HW-ENV-CHOC-001 — Les fixations et connecteurs doivent être adaptés aux chocs et vibrations prévisibles.

```

### 11.6 Compatibilité électromagnétique

Cette partie décrit les contraintes CEM.

**Exemples :**

```text

- immunité aux perturbations ;

- émissions conduites ;

- émissions rayonnées ;

- filtrage ;

- blindage ;

- mise à la terre ;

- séparation puissance / signaux faibles ;

- protections transitoires ;

- routage des câbles.

```

---

## 12. Exigences de sécurité matérielle

### 12.1 Objet des exigences de sécurité

Cette partie décrit les exigences visant à éviter les risques pour les personnes, les biens, l’environnement et les équipements.

### 12.2 Risques électriques

**Exemples :**

```text

- contact direct ;

- court-circuit ;

- surintensité ;

- surtension ;

- défaut d’isolement ;

- échauffement ;

- mauvaise mise à la terre ;

- erreur de câblage ;

- inversion de polarité.

```

**Exemple d’exigence :**

```text

HW-SEC-ELEC-001 — Les parties accessibles du matériel ne doivent pas présenter de risque électrique dans les conditions normales d’utilisation et de maintenance prévues.

```

### 12.3 Risques thermiques

**Exemples :**

```text

HW-SEC-THERM-001 — Les surfaces accessibles ne doivent pas atteindre une température présentant un risque pour l’utilisateur dans les conditions normales d’exploitation.

HW-SEC-THERM-002 — Les composants susceptibles de chauffer doivent être installés de manière à limiter le risque d’endommagement des éléments voisins.

```

### 12.4 Risques liés aux batteries

Cette partie est à compléter si le système comporte des batteries.

**Exemples :**

```text

- protection contre surintensité ;

- protection contre court-circuit ;

- surveillance température ;

- ventilation ;

- isolement ;

- remplacement ;

- transport ;

- stockage ;

- incendie ;

- BMS ;

- consignation.

```

### 12.5 Arrêt d’urgence

Cette partie décrit l’arrêt d’urgence si applicable.

**Exemples :**

```text

HW-AU-001 — Le matériel doit permettre le raccordement d’un arrêt d’urgence si cette fonction est requise par le système.

HW-AU-002 — L’arrêt d’urgence doit avoir priorité sur les commandes logicielles.

HW-AU-003 — Le réarmement après arrêt d’urgence doit nécessiter une action maîtrisée.

```

### 12.6 État sûr matériel

Cette partie décrit les exigences permettant de garantir un comportement sûr en cas de défaut.

**Exemples :**

```text

- sorties à zéro ;

- relais ouverts ;

- commande inhibée ;

- alimentation coupée ;

- maintien mécanique ;

- défaut signalé ;

- intervention obligatoire avant redémarrage.

```

---

## 13. Exigences de diagnostic hardware

### 13.1 Objet du diagnostic hardware

Cette partie décrit les informations que le matériel doit fournir pour permettre le diagnostic, la maintenance et le support.

### 13.2 Diagnostic local

**Exemples :**

```text

- voyants d’état ;

- code défaut ;

- afficheur local ;

- bouton test ;

- port diagnostic ;

- mesure de tension ;

- état alimentation ;

- état communication ;

- état entrées/sorties.

```

### 13.3 Diagnostic logiciel des éléments hardware

Cette partie décrit les informations matérielles lisibles par le logiciel.

**Exemples :**

```text

HW-DIAG-001 — Le logiciel embarqué doit pouvoir lire l’état des entrées critiques.

HW-DIAG-002 — Le logiciel embarqué doit pouvoir détecter un défaut de communication avec un module matériel.

HW-DIAG-003 — Le logiciel embarqué doit pouvoir identifier une saturation ou erreur du stockage local si cette fonction est utilisée.

HW-DIAG-004 — Le système doit pouvoir identifier la version matérielle de la carte principale si cela est nécessaire à la maintenance.

```

### 13.4 Autotests

Cette partie décrit les tests automatiques réalisables par le matériel ou par le logiciel sur le matériel.

**Exemples :**

```text

- test au démarrage ;

- test mémoire ;

- test communication ;

- test entrées/sorties ;

- test stockage ;

- test horloge ;

- test capteur ;

- test alimentation ;

- test watchdog.

```

### 13.5 Codes défauts hardware

Cette partie décrit les défauts matériels identifiables.

**Exemple :**

```text

Code       | Défaut                          | Criticité | Action attendue

HW-ERR-001 | alimentation hors plage         | critique  | état sûr

HW-ERR-002 | capteur critique absent         | élevée    | mode dégradé ou état sûr

HW-ERR-003 | stockage local inaccessible     | élevée    | alarme + limitation fonctionnelle

HW-ERR-004 | communication module impossible | moyenne   | alarme maintenance

```

### 13.6 Export des informations de diagnostic

Cette partie décrit les informations utiles au support.

**Exemples :**

```text

- version hardware ;

- version firmware ;

- état entrées/sorties ;

- tensions internes ;

- température interne ;

- compteurs d’erreurs ;

- historique des défauts ;

- dernier redémarrage ;

- cause du dernier reset ;

- état stockage ;

- état communication.

```

---

## 14. Exigences de maintenance hardware

### 14.1 Objet des exigences de maintenance

Cette partie décrit ce que le matériel doit permettre pour faciliter la maintenance préventive et corrective.

### 14.2 Maintenance préventive

**Exemples :**

```text

- inspection visuelle ;

- vérification connecteurs ;

- vérification ventilation ;

- contrôle batterie ;

- contrôle voyants ;

- nettoyage filtre ;

- vérification serrage borniers ;

- contrôle température ;

- test entrée/sortie ;

- vérification sauvegarde configuration si liée au matériel.

```

### 14.3 Maintenance corrective

**Exemples :**

```text

- remplacement d’un fusible ;

- remplacement d’un module ;

- remplacement d’un capteur ;

- remplacement d’une carte ;

- remplacement d’une alimentation ;

- changement d’une batterie ;

- diagnostic d’une entrée défaillante ;

- diagnostic d’un port communication.

```

### 14.4 Composants remplaçables

Cette partie liste les composants remplaçables en maintenance.

**Exemple :**

```text

Composant            | Remplaçable sur site | Outillage            | Précaution          | Test après remplacement

Fusible              | oui                  | tournevis            | couper alimentation | test alimentation

Module communication | oui                  | tournevis            | ESD                 | test réseau

Carte principale     | oui/non selon projet | outillage spécifique | configuration       | test complet

Batterie             | oui                  | EPI selon type       | sécurité batterie   | test autonomie

```

### 14.5 Accessibilité et temps d’intervention

Cette partie décrit les exigences facilitant l’intervention.

**Exemples :**

```text

HW-MNT-010 — Les composants prévus comme remplaçables doivent être accessibles sans démontage complet de l’équipement.

HW-MNT-011 — Les connecteurs doivent être identifiés afin de limiter les erreurs de recâblage.

HW-MNT-012 — Les opérations de maintenance doivent pouvoir être réalisées avec l’outillage défini dans le manuel de maintenance.

```

### 14.6 Prévention des erreurs de maintenance