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.
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 :
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 :
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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
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 :
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 :
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 :
- 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 :
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 :
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 :
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 :
- 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 :
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 :
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 :
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 :
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 :
- protection contre inversion de polarité ;
- protection contre surtension ;
- protection contre surintensité ;
- fusible ;
- disjoncteur ;
- filtrage ;
- protection contre transitoires ;
- mise à la terre ;
- isolement.
Exemple d’exigence :
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 :
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 :
- 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 :
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 :
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 :
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 :
- 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 :
- 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 :
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 :
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 :
- 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 :
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 :
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 :
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 :
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 :
- voyant alimentation ;
- voyant défaut ;
- voyant communication ;
- voyant mode maintenance ;
- afficheur état système ;
- buzzer ;
- indicateur batterie ;
- indicateur activité réseau.
Exemple d’exigence :
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 :
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 :
- 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 :
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 :
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 :
- 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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
- 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 :
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 :
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 :
- 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 :
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 :
- 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 :
- 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 :
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 :
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 :
- 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 :
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 :
- 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 :
- 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 :
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 :
- 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 :
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 :
- 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 :
- 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 :
- 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 :
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 :
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¶
Exemples :
- détrompage connecteurs ;
- repérage câbles ;
- marquage des borniers ;
- vis captives ;
- étiquetage ;
- procédure illustrée ;
- contrôle post-maintenance ;
- logs d’intervention.
15. Exigences de testabilité hardware¶
15.1 Objet de la testabilité¶
Cette partie décrit les moyens permettant de tester le matériel en fabrication, intégration, maintenance ou validation.
La testabilité doit être pensée dès la spécification. Un matériel non testable devient coûteux à intégrer et difficile à maintenir.
15.2 Points de test¶
Exemples :
- points de mesure alimentation ;
- points de test signaux critiques ;
- accès au bus de communication ;
- connecteur debug ;
- connecteur programmation ;
- sortie défaut ;
- voyant d’état ;
- mesure température interne.
15.3 Tests unitaires hardware attendus¶
Exemples :
- test alimentation ;
- test entrées numériques ;
- test entrées analogiques ;
- test sorties relais ;
- test communication ;
- test stockage local ;
- test watchdog ;
- test voyants ;
- test port maintenance ;
- test protections.
15.4 Tests d’intégration hardware/software¶
Cette partie décrit les tests nécessitant le logiciel embarqué.
Exemples :
- lecture correcte d’une entrée physique ;
- commande d’une sortie par le firmware ;
- détection d’un défaut capteur ;
- passage en état sûr ;
- stockage local en perte réseau ;
- diagnostic des modules ;
- mise à jour firmware ;
- comportement au redémarrage.
15.5 Banc de test hardware¶
Cette partie décrit les exigences relatives au banc de test.
Exemples :
HW-TEST-010 — Le matériel doit pouvoir être testé sur un banc permettant de simuler les entrées principales.
HW-TEST-011 — Le banc de test doit permettre de vérifier les sorties critiques sans raccorder les charges réelles dangereuses.
HW-TEST-012 — Le banc de test doit permettre de générer des défauts représentatifs : perte capteur, perte alimentation, défaut communication.
15.6 Critères de réussite des tests hardware¶
Exemples :
- toutes les entrées sont lues correctement ;
- toutes les sorties atteignent l’état attendu ;
- les protections ne se déclenchent pas en fonctionnement nominal ;
- les protections se déclenchent en cas de défaut simulé ;
- les interfaces communication répondent ;
- aucun échauffement anormal n’est observé ;
- les états sûrs sont conformes ;
- les défauts sont détectés et signalés.
16. Exigences de fabrication, assemblage et contrôle¶
16.1 Objet de cette section¶
Cette partie décrit les exigences à prendre en compte pour fabriquer, assembler, contrôler et livrer le matériel.
Elle ne remplace pas le dossier de fabrication, mais elle fixe les exigences minimales que ce dossier devra couvrir.
16.2 Fabrication des cartes¶
Exemples :
- qualité PCB ;
- assemblage composants ;
- contrôle visuel ;
- programmation ;
- nettoyage ;
- protection ;
- traçabilité lot ;
- test électrique ;
- test fonctionnel ;
- gestion des non-conformités.
16.3 Assemblage coffret¶
Exemples :
- fixation des cartes ;
- montage alimentation ;
- câblage interne ;
- repérage fils ;
- serrage borniers ;
- montage presse-étoupes ;
- mise à la terre ;
- séparation puissance/signaux ;
- contrôle final.
16.4 Contrôles en fabrication¶
Exemples :
- contrôle visuel ;
- contrôle continuité ;
- contrôle isolement ;
- contrôle alimentation ;
- test entrées ;
- test sorties ;
- test communication ;
- test firmware de base ;
- test voyants ;
- test sécurité.
16.5 Traçabilité matérielle¶
Cette partie décrit les informations à conserver.
Exemples :
- numéro de série ;
- version carte ;
- version assemblage ;
- lot de fabrication ;
- date fabrication ;
- opérateur ou atelier ;
- résultats de test ;
- composants critiques ;
- version firmware chargée ;
- configuration livrée.
16.6 Gestion des non-conformités¶
Exemples :
- défaut composant ;
- défaut soudure ;
- mauvais câblage ;
- échec test ;
- composant remplacé ;
- dérogation acceptée ;
- action corrective ;
- retest après correction.
17. Contraintes de compatibilité avec le logiciel embarqué¶
17.1 Objet de la compatibilité hardware/software¶
Cette partie décrit les exigences nécessaires pour garantir que le logiciel embarqué pourra piloter correctement le matériel.
17.2 Correspondance entrées/sorties / logiciel¶
Exemple :
Entrée ou sortie | Fonction logicielle associée | Module logiciel | Criticité
IN-001 contact sec | lecture état porte | InputManager | moyenne
IN-005 arrêt urgence | détection sécurité | SafetyManager | critique
OUT-001 relais | commande contacteur | OutputManager | critique
LED-001 défaut | signalisation état | StatusManager | faible
17.3 Versions hardware compatibles¶
Cette partie précise les versions compatibles avec le logiciel.
Exemple :
HW-COMP-001 — Le logiciel embarqué version 1.0 doit être compatible avec la carte hardware version A.
HW-COMP-002 — Toute évolution de brochage, polarité, niveau électrique ou périphérique doit entraîner une analyse d’impact software.
HW-COMP-003 — Le logiciel doit pouvoir identifier la version hardware si plusieurs versions matérielles sont supportées.
17.4 Contraintes de démarrage¶
Cette partie décrit les exigences matérielles ayant un impact sur le boot.
Exemples :
- temps de stabilisation alimentation ;
- état initial des entrées ;
- état initial des sorties ;
- disponibilité mémoire ;
- disponibilité horloge ;
- initialisation module communication ;
- lecture version carte ;
- détection configuration matérielle.
17.5 Contraintes de timing¶
Cette partie décrit les exigences temporelles du matériel.
Exemples :
- temps de réponse entrée ;
- temps de commutation relais ;
- délai de stabilisation capteur ;
- temps de démarrage module communication ;
- délai watchdog ;
- temps d’écriture mémoire ;
- temps de réveil depuis veille.
18. Contraintes de configuration matérielle¶
18.1 Objet de la configuration matérielle¶
Cette partie décrit les variantes, options, cavaliers, modules, cartes ou paramètres matériels pouvant changer selon les installations.
18.2 Variantes hardware¶
Exemples :
- version avec Ethernet ;
- version avec 4G ;
- version avec stockage local étendu ;
- version avec batterie secours ;
- version avec nombre d’entrées augmenté ;
- version avec coffret extérieur ;
- version avec arrêt d’urgence ;
- version avec capteur intégré.
18.3 Options matérielles¶
Exemples :
Option | Description | Impact
OPT-4G | module communication cellulaire | antenne, SIM, consommation
OPT-BAT | batterie de secours | autonomie, sécurité, maintenance
OPT-IO | extension entrées/sorties | câblage, logiciel, tests
OPT-IP65 | coffret renforcé | mécanique, thermique, coût
18.4 Identification de la configuration¶
Cette partie décrit comment identifier la configuration installée.
Exemples :
- étiquette ;
- numéro de série ;
- code configuration ;
- lecture par logiciel ;
- fichier de configuration ;
- QR code ;
- rapport de fabrication ;
- dossier de configuration livrée.
18.5 Compatibilité des variantes¶
Cette partie décrit les contraintes de compatibilité.
Exemple :
HW-CONF-001 — Chaque variante matérielle doit être associée à une configuration logicielle compatible.
HW-CONF-002 — Les options installées doivent être identifiables lors de la mise en service.
HW-CONF-003 — Une option absente ne doit pas provoquer d’erreur bloquante si elle n’est pas requise par la configuration du site.
19. Exigences de documentation hardware¶
19.1 Objet de la documentation hardware¶
Cette partie liste les documents matériels à produire.
19.2 Documents attendus¶
Exemples :
- schémas électroniques ;
- plan de câblage ;
- nomenclature ;
- plan d’implantation coffret ;
- plan mécanique ;
- notice d’installation ;
- procédure de tests hardware ;
- procédure de maintenance ;
- dossier de fabrication ;
- dossier de configuration livrée ;
- fiche technique ;
- guide de remplacement des modules ;
- liste des pièces de rechange.
19.3 Documentation d’installation¶
Cette partie décrit les informations nécessaires à l’installateur.
Exemples :
- dimensions ;
- fixation ;
- alimentation ;
- câblage ;
- connecteurs ;
- repérage ;
- conditions environnementales ;
- mise à la terre ;
- contrôles avant mise sous tension ;
- vérifications après installation.
19.4 Documentation de maintenance¶
Cette partie décrit les informations nécessaires au mainteneur.
Exemples :
- diagnostic défaut ;
- remplacement fusible ;
- remplacement module ;
- vérification alimentation ;
- vérification entrées/sorties ;
- lecture voyants ;
- export logs ;
- tests après intervention ;
- précautions de sécurité.
19.5 Documentation de configuration livrée¶
Cette partie décrit les informations à conserver pour chaque équipement livré.
Exemple :
- numéro de série ;
- version hardware ;
- options installées ;
- version firmware ;
- configuration initiale ;
- résultats de tests usine ;
- date de fabrication ;
- date de livraison ;
- pièces remplacées si applicable.
20. Tests et vérification des exigences hardware¶
20.1 Objet de la vérification hardware¶
Cette partie décrit comment les exigences hardware seront vérifiées.
Chaque exigence hardware importante doit être associée à une méthode de vérification : test, inspection, analyse, mesure ou revue documentaire.
20.2 Méthodes de vérification¶
Exemples :
Test :
exécution d’un essai sur le matériel.
Inspection :
vérification visuelle ou documentaire.
Analyse :
calcul ou justification technique.
Mesure :
mesure instrumentée avec multimètre, oscilloscope, analyseur, capteur.
Revue :
examen collectif d’un document de conception ou fabrication.
20.3 Matrice exigences hardware / vérification¶
Exemple :
ID exigence | Méthode | Test associé | Critère
HW-ALIM-001 | test | TEST-HW-ALIM-001 | démarrage dans plage alim
HW-IN-001 | test | TEST-HW-IN-001 | état entrée correctement lu
HW-OUT-001 | test | TEST-HW-OUT-001 | sortie atteint état attendu
HW-ENV-001 | analyse/test | TEST-HW-ENV-001 | fonctionnement plage température
HW-MNT-001 | inspection | REV-HW-MNT-001 | accès maintenance conforme
20.4 Tests unitaires hardware¶
Cette partie liste les tests à réaliser sur les éléments matériels isolés.
Exemples :
- test alimentation ;
- test protection ;
- test entrée numérique ;
- test entrée analogique ;
- test sortie relais ;
- test communication Ethernet ;
- test RS485 ;
- test stockage ;
- test voyant ;
- test bouton ;
- test watchdog ;
- test port maintenance.
20.5 Tests d’intégration hardware/software¶
Cette partie décrit les tests à réaliser avec le logiciel embarqué.
Exemples :
- lecture d’une entrée réelle par le firmware ;
- commande d’une sortie réelle par le firmware ;
- génération d’une alarme sur défaut matériel ;
- passage en mode dégradé après défaut capteur ;
- passage en état sûr après défaut critique ;
- détection de perte communication module ;
- stockage local et lecture par logiciel ;
- redémarrage après coupure d’alimentation.
20.6 Tests d’environnement¶
Cette partie décrit les tests ou analyses liés à l’environnement.
Exemples :
- température haute ;
- température basse ;
- humidité ;
- vibration ;
- CEM ;
- protection IP ;
- échauffement ;
- endurance ;
- vieillissement si applicable.
20.7 Critères d’acceptation hardware¶
Exemple :
Le sous-système hardware est considéré comme acceptable si :
- toutes les exigences critiques sont vérifiées ;
- les entrées/sorties fonctionnent selon les spécifications ;
- les protections attendues sont présentes ;
- les états sûrs sont conformes ;
- les tests unitaires hardware sont réussis ;
- les tests d’intégration hardware/software critiques sont réussis ;
- aucune anomalie bloquante n’est ouverte ;
- la documentation hardware requise est disponible.
21. Traçabilité¶
21.1 Traçabilité avec la spécification globale¶
Cette partie relie les exigences hardware aux exigences système.
Exemple :
Exigence système :
SYS-FCT-001 — Le système doit acquérir les mesures définies.
Exigences hardware associées :
HW-IN-ANA-001 — Le matériel doit fournir les entrées analogiques nécessaires.
HW-CPU-001 — Le matériel doit fournir les ressources de traitement nécessaires.
HW-STO-001 — Le matériel doit fournir un stockage local si les données doivent être conservées en perte réseau.
21.2 Traçabilité avec l’architecture système¶
Cette partie relie les exigences hardware aux blocs d’architecture.
Exemple :
Bloc architecture :
SS-HW-001 — sous-système matériel embarqué.
Exigences associées :
HW-ALIM-001, HW-IN-001, HW-OUT-001, HW-COM-ETH-001, HW-MNT-PORT-001.
21.3 Traçabilité vers la conception détaillée hardware¶
Cette partie indique où chaque exigence sera implémentée.
Exemple :
HW-IN-001 — Entrée numérique isolée
Document de conception :
DCH-HW-003 — schéma carte I/O, section entrées numériques.
Éléments de conception :
connecteur J4, optocoupleur U12, filtrage RC, GPIO MCU PA5.
21.4 Traçabilité vers les tests¶
Cette partie relie les exigences aux tests.
Exemple :
HW-OUT-SAFE-001 — Sorties en état sûr en perte alimentation
Tests associés :
TEST-HW-OUT-004 — coupure alimentation et mesure état sortie.
TEST-INT-SAFE-002 — vérification état sûr hardware/software.
21.5 Matrice de traçabilité hardware¶
Structure recommandée :
ID exigence hardware
Exigence système source
Bloc architectural
Élément de conception
Test associé
Statut
Commentaire
22. Contraintes, risques et points ouverts¶
22.1 Contraintes techniques¶
Cette partie liste les contraintes techniques connues.
Exemples :
- encombrement limité ;
- alimentation imposée ;
- connectique imposée ;
- protocole matériel imposé ;
- environnement sévère ;
- température élevée ;
- maintenance difficile ;
- composant fournisseur imposé ;
- disponibilité limitée d’un composant ;
- compatibilité avec installation existante.
22.2 Risques hardware¶
Cette partie identifie les risques matériels.
Exemples :
- sous-dimensionnement alimentation ;
- échauffement ;
- perturbations CEM ;
- usure relais ;
- saturation mémoire locale ;
- connecteur difficilement accessible ;
- erreur de câblage ;
- incompatibilité capteur ;
- indisponibilité composant ;
- défaut de protection électrique ;
- maintenance trop complexe.
22.3 Mesures de réduction des risques¶
Exemples :
- marge de dimensionnement ;
- prototype ;
- test thermique ;
- test CEM ;
- détrompage connecteurs ;
- choix composant alternatif ;
- test endurance relais ;
- banc de test ;
- revue hardware/software ;
- procédure maintenance illustrée.
22.4 Points ouverts¶
Cette partie recense les questions à trancher.
Exemple :
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-HW-001 | Alimentation | Confirmer 24 VDC ou 230 VAC | Client | avant conception | alimentation | ouvert
PO-HW-002 | Capteur température | Référence capteur non confirmée | Fournisseur | avant schéma | entrée analogique | ouvert
PO-HW-003 | Connectique | Standard connecteur terrain à confirmer | Client | avant routage | mécanique/câblage | ouvert
PO-HW-004 | Stockage local | Durée minimale de stockage à confirmer | Système/client | avant choix mémoire | hardware/software | ouvert
23. Critères d’acceptation de la spécification hardware¶
23.1 Complétude¶
Cette partie définit les critères permettant de considérer la spécification comme complète.
Exemples :
La spécification détaillée hardware est considérée comme complète si :
- toutes les fonctions matérielles sont identifiées ;
- toutes les entrées/sorties sont listées ;
- les exigences d’alimentation sont décrites ;
- les interfaces de communication sont décrites ;
- les contraintes mécaniques sont décrites ;
- les contraintes environnementales sont décrites ;
- les exigences de sécurité sont décrites ;
- les exigences de diagnostic sont décrites ;
- les exigences de maintenance sont décrites ;
- les exigences de testabilité sont décrites ;
- les exigences critiques sont traçables vers les tests.
23.2 Cohérence¶
Cette partie définit les critères de cohérence.
Exemples :
Le document ne doit pas contenir :
- d’entrée ou sortie sans usage identifié ;
- de fonction hardware non allouée ;
- d’exigence non vérifiable ;
- de contradiction avec l’architecture système ;
- de contradiction avec le dossier des modes ;
- d’état sûr non défini pour une sortie critique ;
- de capteur critique sans diagnostic ;
- de stockage local sans estimation de capacité ;
- de maintenance prévue sans accessibilité physique.
23.3 Testabilité¶
Cette partie vérifie que la spécification permet de définir des tests.
Exemples :
La spécification est testable si :
- chaque exigence critique peut être vérifiée ;
- les moyens de test sont identifiés ;
- les entrées/sorties peuvent être stimulées ;
- les sorties peuvent être mesurées ;
- les défauts principaux peuvent être simulés ;
- les critères de réussite sont explicites ;
- les états sûrs peuvent être observés.
23.4 Maintenabilité¶
Cette partie vérifie que les contraintes de maintenance sont prises en compte.
Exemples :
La spécification prend correctement en compte la maintenance si :
- les composants remplaçables sont identifiés ;
- les accès maintenance sont prévus ;
- les défauts matériels sont diagnostiquables ;
- les versions hardware sont identifiables ;
- les connecteurs sont repérables ;
- les procédures de test après intervention sont prévues.
23.5 Validation du document¶
Cette partie précise les revues nécessaires.
Exemple :
La spécification détaillée hardware doit être relue par :
- le responsable hardware ;
- l’ingénieur système ;
- le responsable logiciel embarqué ;
- le responsable intégration ;
- le responsable validation ;
- le responsable maintenance ;
- le responsable sécurité si applicable ;
- le représentant client si les interfaces terrain ou contraintes d’installation relèvent du client.
24. Annexes¶
24.1 Liste complète des exigences hardware¶
Cette annexe peut contenir la liste tabulaire de toutes les exigences.
Exemple :
ID | Catégorie | Libellé | Criticité | Vérification | Statut
HW-ALIM-001 | alimentation | compatibilité source alim | élevée | test | à faire
HW-IN-001 | entrée | entrée numérique isolée | moyenne | test | à faire
HW-OUT-SAFE-001 | sécurité | état sûr sorties | critique | test | à faire
HW-MNT-PORT-001 | maintenance | port diagnostic | moyenne | inspection/test | à faire
24.2 Liste des entrées/sorties¶
Cette annexe reprend toutes les entrées et sorties.
24.3 Liste des interfaces matérielles¶
Cette annexe reprend les connecteurs, ports, bus, liaisons et interfaces physiques.
24.4 Liste des variantes hardware¶
Cette annexe reprend les variantes et options matérielles.
24.5 Liste des composants critiques¶
Cette annexe identifie les composants ayant un impact fort sur la sécurité, la disponibilité ou la maintenance.
Exemples :
- alimentation ;
- relais de commande ;
- stockage local ;
- module communication ;
- microcontrôleur ;
- capteur critique ;
- bouton arrêt d’urgence ;
- connecteur principal.
24.6 Matrice exigences / tests hardware¶
Cette annexe reprend la matrice de vérification.
24.7 Schémas préliminaires¶
Cette annexe peut contenir des schémas non définitifs : synoptique matériel, principe d’alimentation, principe d’entrées/sorties, intégration coffret.
24.8 Glossaire hardware¶
Cette annexe définit les termes propres au matériel.
24.9 Historique des décisions hardware¶
Cette annexe conserve les décisions importantes.
Exemple :
DEC-HW-001 :
Un stockage local est intégré à l’équipement.
Justification :
permettre le fonctionnement en mode dégradé communication et conserver les données pendant une perte réseau.
Impact :
nécessite un dimensionnement mémoire, une gestion d’usure, une fonction de diagnostic et des tests de saturation.
Updated by Redmine Admin 3 months ago · 1 revisions