Vérification ou validation dans le matériel électronique : quelle est la différence ?

Parfois, une conception matérielle peut sembler parfaitement correcte sur le banc de test : le MCU fonctionne de manière stable à 160 MHz, les capteurs communiquent via I²C et l’alimentation maintient 12 V en pleine charge. Mais un produit qui satisfait à toutes les exigences peut malgré tout ne pas répondre aux attentes une fois entre les mains de l’utilisateur.

La vérification et la validation (V&V) comblent l’écart entre le respect des exigences et la réponse au besoin réel. Certaines équipes hardware confondent ces deux termes. Les équipes qui considèrent la V&V comme une étape unique, ou qui en ignorent une parce que le prototype semble fonctionner, risquent de découvrir des problèmes tardivement : lors d’un audit ou une fois le produit déployé sur le terrain.

Dans cet article, nous expliquons ce que signifient la vérification et la validation dans le développement hardware et en quoi elles diffèrent. Nous verrons également comment la V&V se relie aux exigences via le modèle en V, comment créer un plan de V&V et comment éviter les erreurs courantes.

Points clés à retenir

• La vérification contrôle si le hardware satisfait aux exigences techniques définies. 
• La validation vérifie si le produit complet répond aux besoins pour lesquels il a été conçu.
• La V&V doit commencer tôt et relier les exigences aux activités planifiées, aux critères d’acceptation, aux résultats et aux preuves associées tout au long du développement hardware.

Qu’est-ce que la vérification ?

La vérification est le processus qui consiste à contrôler si le hardware correspond aux exigences définies et aux spécifications d’ingénierie. Elle répond à la question : construisons-nous correctement le produit ?

L’objectif de la vérification est de remplacer les hypothèses par des preuves. Au lieu de supposer qu’un circuit fonctionne, l’équipe compare la conception ou le prototype physique aux exigences définies et rassemble des preuves montrant s’il y répond ou non.

La vérification peut inclure des activités telles que :

• Revue des exigences : vérifier que les exigences sont claires, cohérentes, réalisables, traçables et vérifiables.
• Revue de conception : comparer les schémas, les routages PCB, les plans mécaniques et les interfaces aux exigences définies et aux règles de conception.
• Analyse et simulation : utiliser des calculs ou des modèles pour vérifier des paramètres tels que les marges thermiques, l’intégrité du signal, le timing ou la consommation électrique.
• Inspection : vérifier le hardware physique, les dimensions, l’assemblage, les composants ou les connexions par rapport à la documentation de conception.
• Essais et mesures : mesurer le hardware et comparer les résultats aux limites requises ou au comportement attendu de la conception.

Qu’est-ce que la validation ?

La validation est le processus qui consiste à vérifier si le hardware fonctionne réellement pour son usage prévu, ses utilisateurs et son environnement d’exploitation. Elle répond à la question : construisons-nous le bon produit ?

L’objectif principal de la validation est d’apporter la preuve que le produit répond réellement au problème qu’il a été conçu pour résoudre. Une conception peut satisfaire à toutes les exigences techniques et malgré tout être insuffisante si elle ne fonctionne pas comme prévu dans les conditions réelles d’exploitation. La validation vous donne l’assurance que le système complet est adapté à la tâche que les parties prenantes ont réellement besoin qu’il accomplisse.

La validation peut inclure des activités telles que :

• Validation des exigences :  vérifier que les exigences traduisent bien les besoins des parties prenantes et les conditions auxquelles le produit sera confronté en usage.
• Tests au niveau système : évaluer le produit complet afin de confirmer que tout fonctionne ensemble comme prévu.
• Tests de cas d’usage : vérifier si le produit peut accomplir les tâches et scénarios pour lesquels il a été conçu.
• Essais environnementaux : évaluer le produit dans des conditions réalistes de température, d’humidité, de vibration, de charge ou autres conditions de fonctionnement.
• Tests sur le terrain : faire fonctionner le hardware dans son environnement prévu afin de révéler des problèmes qui pourraient ne pas apparaître au laboratoire.
• Évaluation utilisateur : permettre à des utilisateurs représentatifs d’interagir avec le produit et vérifier s’il prend réellement en charge leur flux de travail et leurs besoins.

Vérification et validation dans le processus de développement hardware.

Différence entre vérification et validation

La V&V utilise souvent les mêmes outils d’ingénierie, comme les essais, les mesures, les inspections et l’analyse. La différence réside dans ce que vous cherchez à démontrer avec le résultat.

Par exemple, un essai en chambre thermique peut vérifier qu’un produit fonctionne sur une plage spécifiée de −20 °C à 60 °C. La validation demande si cette plage correspond réellement au besoin. Si le produit est installé dans un boîtier exposé au soleil qui atteint 75 °C, il peut réussir la vérification et néanmoins échouer en usage. La même chambre peut servir à la validation lorsqu’elle est utilisée avec le profil de température auquel le produit complet devrait être confronté sur le terrain.

La vérification donne généralement un résultat plus direct de réussite ou d’échec par rapport à une exigence définie et peut s’appliquer à des exigences individuelles, à des conceptions ou à des éléments hardware. La validation adopte une vue plus large du système intégré et détermine si son comportement global est acceptable pour l’usage prévu.

Dans un processus piloté par les exigences, la vérification produit des preuves que les exigences techniques individuelles ont été satisfaites. La validation vérifie ensuite si le produit complet répond au besoin des parties prenantes dans des conditions réelles d’exploitation, et elle peut montrer qu’une exigence était incomplète ou erronée.

Comment la V&V s’intègre au modèle en V

Le modèle en V montre comment organiser la V&V tout au long d’un projet de développement hardware.

Le modèle en V représente le cycle de vie du système sous la forme d’un V. Le côté gauche part des besoins et attentes des parties prenantes, les transforme en exigences système et sous-système, puis les affine en architecture et en conception détaillée. Le bas du V correspond à l’implémentation. Le côté droit remonte ensuite à travers l’intégration, avec des tests aux niveaux composant, sous-système et produit complet.

Le modèle en V du processus d’ingénierie système.

Chaque niveau à gauche est associé à un niveau de test à droite, et ces associations créent la traçabilité. Chaque exigence est reliée à l’activité de V&V et aux preuves qui la vérifient, et les équipes planifient cette activité pendant que la conception est encore en cours. 

Par exemple, une exigence selon laquelle l’entrée 12 V doit rester dans une plage de ±5 % en pleine charge peut être contrôlée à plusieurs niveaux : caractéristiques nominales des composants par rapport au schéma, simulation d’alimentation de la carte, puis mesure sur le produit assemblé.

Dans cette structure, la V&V remplit des rôles différents :

• La vérification confirme, à chaque niveau, que ce qui a été construit correspond aux exigences et à la conception associées sur le côté gauche. Les revues, l’analyse et la simulation commencent à gauche, tandis que les essais et mesures remontent le côté droit.
• La validation vérifie par rapport aux besoins des parties prenantes en haut à gauche. Elle commence par la validation des exigences par rapport à ces besoins et revient en haut à droite comme contrôle au niveau système : le produit complet satisfait-il les besoins des parties prenantes et l’usage prévu ?

Comment créer un plan de V&V

Au moment où le hardware arrive à la phase de test, l’équipe devrait déjà savoir quoi vérifier, à quelles exigences cela se rapporte, comment le résultat sera évalué et quelles preuves doivent être recueillies. Le plan de V&V regroupe ces décisions dans un document unique.

Un plan de V&V couvre généralement six décisions :

• Définir le périmètre : décider quel produit, quels sous-systèmes ou quelles fonctions hardware sont couverts par le plan, ce qui en est exclu et où l’effort de V&V doit se concentrer en priorité en fonction du risque.
• Relier les activités de V&V aux exigences : associer les exigences techniques aux activités de vérification et les besoins des parties prenantes aux activités de validation. Chacun dispose alors d’un chemin clair vers les preuves.
• Choisir les méthodes : décider comment chaque exigence sera vérifiée, par inspection, analyse, démonstration, essai ou toute autre méthode appropriée, et comment chaque besoin des parties prenantes sera validé, par test de cas d’usage, essai environnemental, évaluation utilisateur ou test sur le terrain.
• Définir les conditions et les critères d’acceptation : préciser la configuration hardware, les conditions de fonctionnement, l’équipement et le résultat mesurable qui déterminent si l’activité est réussie ou échouée.
• Planifier qui fait quoi et quand : attribuer les responsabilités, les ressources requises et le calendrier, et aligner chaque activité sur l’étape appropriée du développement hardware, comme les builds prototype, EVT, DVT ou PVT.
• Décider comment les résultats et les preuves sont consignés : définir comment chaque résultat est enregistré et relié aux preuves justificatives, et quelles activités doivent être répétées après des modifications de conception.

Pièges courants et comment les éviter

Alors qu’un bug logiciel peut souvent être corrigé par une mise à jour, un problème de conception matérielle est plus facile à corriger avant la fabrication des cartes. Nombre de ces problèmes trouvent leur origine dans la manière dont les exigences sont rédigées et dont la V&V est planifiée.

Le tableau ci-dessous met en évidence les pièges courants de la V&V et les bonnes pratiques qui permettent de les éviter.

Avantages de la V&V

Les modifications matérielles tardives dans le développement ont tendance à coûter plus cher que les modifications logicielles. Une nouvelle itération de carte, un changement d’outillage ou un échec de campagne de certification mobilisent un temps réel et un budget conséquent, et le matériel d’un produit déjà livré est difficile à corriger. C’est pourquoi la vérification et la validation ont une importance particulière dans le développement matériel. Utilisées ensemble, elles apportent aux équipes quatre avantages principaux :

• Détection plus précoce des problèmes : Les revues, la simulation et les premiers prototypes mettent en évidence les lacunes dans les exigences, les erreurs de conception et les oublis. À ce stade, la correction consiste généralement à modifier une spécification ou un schéma.
• Des preuves pour chaque exigence : La vérification relie chaque exigence à un résultat, afin que l’équipe puisse montrer ce qui a été vérifié, comment et avec quel résultat. Ces preuves facilitent également la conformité, et le matériel réglementé, comme les dispositifs médicaux, les exige généralement dans le cadre des contrôles de conception.
• Adéquation avec l’usage réel : La validation teste le produit complet dans son environnement, avec ses utilisateurs et dans le cadre de ses tâches réelles. Cela couvre des problèmes qu’une vérification exigence par exigence peut manquer, comme la dérive d’un capteur ou l’éblouissement d’un écran en plein soleil.
• Des informations pour le cycle suivant : Les marges mesurées et les constats de défaillance orientent les modifications de conception, les révisions futures et les générations suivantes de produits. Ils montrent aussi où une exigence doit être renforcée ou assouplie.

Outils logiciels pour gérer la vérification et la validation

Le développement matériel implique de nombreuses exigences et de nombreux résultats d’essai, et leur suivi manuel tout au long d’un projet peut être difficile. Les équipes peuvent se retrouver avec un mélange de fichiers dispersés et d’outils déconnectés, tels que :

• Tableurs et documents : Pratiques pour les petits projets avec peu d’exigences et de cas de test. À mesure que le périmètre de la V&V s’élargit, maintenir la traçabilité et la préparation aux audits peut exiger un travail manuel, et les enregistrements peuvent finir par ne plus être synchronisés.
• Outils de suivi des tickets (par ex. Jira, GitHub) : Ces outils peuvent être adaptés pour organiser le travail de V&V et relier les éléments associés via des liens, des champs ou des étiquettes. Mais le maintien de la traçabilité des exigences et d’une couverture complète de la V&V nécessite généralement une configuration supplémentaire et des plugins personnalisés.
• Outils dédiés à la gestion des exigences : Conçus pour structurer les exigences et la traçabilité. Mais selon l’outil, la planification des tests et la collecte des preuves peuvent nécessiter des modules séparés ou des intégrations avec des outils de test externes. 

Pour les équipes qui veulent planifier et suivre les activités de V&V en parallèle des exigences dans un espace de travail partagé, Requirements Portal relie les exigences aux plans de vérification, aux exécutions de test, aux preuves et à l’historique des modifications. Les équipes peuvent ainsi voir ce qui a été vérifié et ce qui nécessite encore une attention particulière.

Conclusion & prochaines étapes

En bref, la vérification prouve que votre matériel respecte les spécifications, tandis que la validation prouve qu’il fonctionne réellement pour l’utilisateur. Pour que cela fonctionne, la V&V ne peut pas se limiter à une checklist finale. Elle doit être intégrée au processus de développement produit dès le premier jour.

Si vous souhaitez approfondir votre compréhension des cadres de V&V, les ressources suivantes sont utiles pour aller plus loin :

• NASA Systems Engineering Handbook fournit des conseils pratiques sur la planification et l’exécution de la V&V pour des produits matériels de niveau spatial.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) offre une vision plus large de la V&V du point de vue de l’ingénierie système.
• INCOSE V&V Across Product Lifecycle traite de la V&V aux différentes étapes du cycle de vie, du modèle en V, des méthodes de V&V, des cas de test et des critères de réussite.

Si vous êtes prêt à passer de la théorie à la pratique, essayez Requirements Portal pour relier les cas de test aux exigences et aux conceptions électroniques, suivre la couverture et consigner les preuves d’ingénierie.

Foire aux questions

La vérification est-elle la même chose que la validation ?

Non. La vérification contrôle le matériel par rapport à des exigences définies. La validation vérifie si les exigences et le produit reflètent les besoins des parties prenantes dans l’usage réel.

Qu’est-ce qui vient en premier, la vérification ou la validation ?

Les deux doivent être planifiées tôt, et aucune des deux ne constitue une phase unique. La vérification commence par des revues, des analyses et des simulations à mesure que la conception progresse. La validation commence par vérifier les exigences par rapport aux besoins des parties prenantes et devient plus importante à mesure que le produit intégré prend forme.

Quels sont les types courants de méthodes de V&V ?

Les méthodes courantes de V&V incluent les revues, les inspections, les analyses, les simulations, les démonstrations et les tests. Une même méthode peut servir à la vérification ou à la validation, selon qu’elle contrôle une exigence définie ou qu’elle évalue le produit dans le contexte de son usage prévu.