Validation, vérification et certification

Notre objectif ici, est de revenir sur le rôle que pourrait jouer notre démarche HiLeS et la conception descendante telle que nous l’appréhendons, pour aider à des procédures de validation, vérification, certification dont nous venons de préciser la terminologie.

HiLeS Designer est un outil graphique travaillant en blocs fonctionnels interconnectés et hiérarchisés.

L’écriture de ces blocs et les modèles HiLeS associés sont compatibles VHDL-AMS de telle sorte que l’on peut simuler la fonctionnalité de chaque bloc et la fonctionnalité globale (les modèles utilisés sont des modèles d’ingénieur ; équations différentielles, fonctionnes logiques…).

La gestion temporelle de ces blocs est décrite par des Réseaux de Petri simulables sur TINA. Le simulateur TINA vérifie la bonne exécution des modes opératoires déduite des objectifs généraux du produit et des considérations générales d’utilisation.

Les blocs sont créés par le concepteur mais une bibliothèque de blocs et de modèles de l’ingénieur facilite la description du système.

; =; D ! ? =6 ? : 7 E Réutilisation Réutilisation B8 %;6 ( &

Figure 3-21. Etapes préliminaires de la démarche.

Pour illustrer les enjeux, voici quelques questions générales intéressant le triptyque : validation, vérification, certification :

• Les spécifications :

o complètes et correctes ?

o réalisables ?

• Vérification des fonctions attendues du système • Détection de fonctions inattendues ?

o Détection de modes opératoires de défaillance • Evaluation de modes de fonctionnement dégradé ?

o Modes de fonctionnement impossibles

• Estimation de marges de fonctionnement : Optimisations et tolérances ? • Autres ?

3.6.1 Le niveau « validation »

Il se pose à l’ingénieur lorsqu’on lui amène : • Des spécifications pour un produit nouveau,

• Des spécifications de modification sur un produit déjà existant. La question qui lui est posée est : est-ce que l’on va savoir faire ? Cette question est en fait, multiple :

• Est-ce que l’on sait concevoir ? • Est-ce que l’on sait réaliser ? • Est-ce que l’on sait produire ?

• Est-ce que l’on sait vérifier chacune des étapes ?

Les réponses ne peuvent être qu’estimations d’autant plus imprécises que la part de « re- use » est faible…

L’expérience de l’ingénieur et de l’équipe va jouer un rôle essentiel : Il va puiser dans son expérience et dans son expertise pour donner cette estimation qu’il argumentera par des calculs, si possible.

On voit bien que HiLeS peut jouer un rôle très positif en validation,:

• Parce qu’il propose une modélisation simple, générique, que l’on doit pouvoir

nourrir de l ‘expérience cumulée des ingénieurs (base de données experte).

• Parce qu’il peut associer dans une représentation unique les modélisations précises des parts de « re-use » qui seront retenues et des modélisations « expertes » telle que nous venons de les présenter.

• Parce qu’il servira de base à la construction de scénarios techniques multiples que l’on pourra comparer par simulation.

3.6.2 Le niveau « Vérification »

Vérifier, c’est apporter la preuve que l’on peut satisfaire une exigence prévue, dans un environnement précis. Cette preuve sera préférablement démontrée formellement, et, le cas échéant, démontrée par des simulations multiples.

De ce point de vue TINA est l’opérateur de vérification des représentations HiLeS. Le

mettre en œuvre suppose :

Chapitre 3 : Une plate-forme de conception amont 99

• D’interpréter le résultat en terme de preuve.

Cette procédure de test, doit, comme il est indique dans notre chapitre 2 (Figure 2-8), s’appliquer aux deux étapes :

• En amont, au stade de la définition fonctionnelle du système et de sa mise en architecture.

• Au niveau du prototypage virtuel, lorsque le modèle des composants réels du système ont été choisis

On notera que la représentation HiLeS amont est en complète continuité avec la modélisation VHDL-AMS du prototype virtuel. Ainsi, les questions prises en amont restent valables pour la vérification finale du prototype virtuel.

3.6.3 Le niveau de certification

Ce niveau ne peut pas être traité par la seule représentation fonctionnelle, quelle soit au niveau architectural, HiLeS ou au stade du prototypage virtuel VHDL-AMS, car on ne peut vérifier que les

fonctions attendues du système.

Or, il y a de très nombreux mécanismes de défaillance qui peuvent induire un disfonctionnement de manière indirecte : par exemple la destruction d’une connexion par contrainte mécanique n’est pas incluse dans les descriptions de HiLeS ou VHDL-AMS.

HiLeS ou VHDL-AMS ne proposent qu’une modélisation fonctionnelle, comportementale, qu’il

faut donc compléter pour des objectifs de fiabilité prédictive ou de certification, d’identification et de modélisation des fonctions inattendues. On peut ainsi imaginer d’étendre le rôle du

prototypage virtuel vers d’autres intérêts de conception, grâce à un prototypage plus complet et plus spécialisé sur le type d’analyse visée. Pour l’instant nous apercevons un rôle actif uniquement dans une éventuelle modélisation du mode de fonctionnement dégradé des systèmes si c’est décrit explicitement dans les spécifications.

3.6.4 Perspectives dans ce domaine

En résumé, la conception système pose les problèmes de validation, de vérification et de certification. La démarche « HiLeS », bien documentée des modélisations expertes et des modélisations de « reuse », peut être un outil très intéressant d’estimation de la faisabilité d’un système ou d’aménagement d’un système existant.

Le couplage HiLeS-TINA introduit une procédure possible de vérification intégrée sur les propriétés fonctionnelles et comportementales au niveau amont et au niveau du prototypage virtuel.

La certification implique que soient associés aux fonctions et performances attendues du système, les fonctions inattendues, parasites, qui peuvent induire des erreurs ou des défaillances… La méthode est à découvrir et à implanter pour traiter cette question.

Il y a beaucoup de travail à faire pour compléter les outils et les méthodes dans les applications : Validation et vérification.

Dans cette perspective, que peut apporter une démarche telle que HiLeS à la validation et à la vérification d’une application électronique embarquée ?

L’inventaire des possibilités suivant est à compléter et à approfondir :

• Recherche et exploration d’architectures Hardware-firmware : définition des meilleurs choix possibles.

• Modélisation comportementale de la spécification (avec un haut niveau d’abstraction). • Démonstration que l’architecture fonctionnelle est correcte par construction.

• Recherche et exploration d’architectures sur des paramètres non fonctionnels (consommation, nombre de connections, masse, taille…) : ces paramètres dits industriels sont dimensionnants pour l’électronique.

• Obtention d’un ensemble de vecteurs de tests pour vérifier à tous les niveaux d’implémentation que la conception est bonne par construction.

• Obtention d’un modèle fonctionnel décrit dans un langage standardisé, donc portable. • Diminution du temps de génération des vecteurs de test à chaque étape, puisque l’on

disposerait d’un ensemble de référence (lié à la modélisation haut niveau). Dans les étapes descendantes de la conception, l’effort serait porté sur les vecteurs complémentaires, pour tester des cas aux limites…

• Facilitation de la compréhension du besoin par la modélisation haut niveau.

En ce qui concerne les aspects outils, on ne doit pas rechercher à qualifier HiLeS Designer (au sens DO178B). Une démonstration que les sorties de l’outil sont évaluées indépendamment est possible mais reste à faire.

Avec ces perspectives, les étapes à continuer sont, entre autres : • Lien avec des langages de modélisation haut niveau (AADL…). • Lien avec des langages de génération de testbench (PSL…). • Lien avec la modélisation du « firmware » (logiciels de bas niveau). • Analyse des paramètres industriels.

• Formalisation de la méthode de conception supportée par HILES.