White paper" La DO-254 pour les nuls"

20
LIVRE BLANC LIVRE BLANC LIVRE BLANC LA DO LA DO LA DO-254 254 254 POUR LES NULS POUR LES NULS POUR LES NULS

description

Petit manuel sur la DO-254 pour comprendre les bases et l'utilisation de ce standard.

Transcript of White paper" La DO-254 pour les nuls"

Page 1: White paper" La DO-254 pour les nuls"

LIVRE BLANCLIVRE BLANCLIVRE BLANC

LA DOLA DOLA DO---254 254 254

POUR LES NULSPOUR LES NULSPOUR LES NULS

Page 2: White paper" La DO-254 pour les nuls"

SOMMAIRE

Chapitre 1

La différence entre vérification et validation

Chapitre 2

L’indépendance

Chapitre 3

Mise en œuvre de l’indépendance

Chapitre 4

Cots (partie 1)

Chapitre 5

Cots (partie 2)

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 3: White paper" La DO-254 pour les nuls"

Petit rappel « historique » :

La DO254 est issue de la DO178 qui distingue très mal deux notions importantes et

fondamentalement distinctes : Il s’agit de déterminer les sources d’erreurs qui peuvent apparaître

lors du développement (erreur au sens de « non conforme par rapport au besoin »). Ceci est

clairement exprimé par le standard « chapeau » qui traite des aspects système, l’ARP4754 :

“Highly-integrated and complex systems present greater opportunities for development error

(requirements determination and design errors) and undesirable, unintended effects.” (ARP4754).

Il existe donc deux sources potentielles de non-conformité :

Les erreurs de conception (« bugs ») qui sont dues à une implémentation non rigoureusement

conforme aux attentes exprimées dans la spécification d’entrée (l’objet fabriqué ne fait pas ce que

l’on attend).

Les erreurs de spécification, dues à une spécification qui n’exprime pas correctement le besoin

du client (on se place ici sur le champ de l’ambiguïté, du non-dit, de l’inexactitude, de la

contradiction).

De ceci il découle deux activités distinctes :

La première consiste à s’assurer – le plus tôt possible – de l’exactitude de la spécification d’entrée,

par tout moyen approprié (outil lorsque cela est possible, revue sinon), afin de donner un point de

départ stable, complet et correct au projet (pour mémoire la spécification est le point d’entrée de

tout projet qui se déroule dans l’ordre …).

La seconde activité a pour objet de s’assurer que l’objet obtenu est bien conforme à la spécification

(qui est donc réputée valide à ce stade). Le terme « objet » signifie ici le résultat d’une opération de

transformation de la spécification en un objet physique (hardware item). Les étapes intermédiaires

de l’implémentation sont considérées – ici – comme des représentations successives de l’objet (code

VHDL, netlist après synthèse, composant physique dans son boîtier …). Les activités principales de

cette étape sont la simulation et le test (physique, sur banc …), ainsi que de l’analyse de résultat.

La DO178 parle indistinctement d’activité de vérification, même si nous l’avons vu le travail à

accomplir est sensiblement différent.

La DO254 dans une volonté assumée de clarification a choisi de distinguer les deux notions et parle donc de

Validation (conformité de la spécification/besoin) et de Vérification (preuve de l’implémentation, test).

Chapitre 1

La différence entre vérification et validation

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 4: White paper" La DO-254 pour les nuls"

Malheureusement, le terme nouveau retenu « validation » a une signification toute différente pour

la communauté des développeurs hardware et système : on parle de validation de carte et de

système lorsqu’il s’agit de remonter le cycle en V d’un projet et de passer aux tests finaux et

d’assemblage du système.

La validation – au sens DO254 – est clairement une activité très amont des projets (en haut à

gauche du cycle en V), alors que la vérification est une activité transverse, qui concrètement s’initie

plutôt dans le bas du cycle en V.

La Validation – au sens commun – d’un système (en haut à droite du cycle en V) est une activité de

finalisation qui tire profit de toute la vérification antérieure (remontée du cycle en V) et qui s’assure

– au final – que les différents acteurs ont bien compris la spécification système et ses déclinaisons.

En cela elle rejoint – un peu – la définition DO-254 de la validation.

Pour terminer ce brillant exposé, voici les définitions DO-254 officielles de ces deux termes à

employer avec – vous l’aurez compris – beaucoup de prudence.

“Validation - The process of determining that the requirements are the correct requirements

and that they are complete.” (Appendix C Glossary of terms).

Does requirements represents correctly and unambiguously what system expect ?

Activities : analyze, traceability

“Verification - The evaluation of an implementation of requirements to determine that they

have been met.” (Appendix C Glossary of terms).

Does hardware implementation reflects exactly the expected behavior described in requirements ?

Does what I have produced is in line with what was described ?

Activities : test, analyze, review

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 5: White paper" La DO-254 pour les nuls"

Cette première partie s’attachera à poser le problème, à décrire le contexte qui a amené à cette

notion. Ce sera également l’occasion de mettre en évidence quelques idées fondamentales de la

DO-254 et de toutes les normes/standards bâties sur les mêmes idées qui accompagnent le

développement de systèmes dans les domaines « safety critical ».

Une définition

Comme d’habitude la clarté vient de l’annexe A (le glossaire):

“Independence is a means to address potential common mode errors that could occur when a

designer verifies that the hardware item under development performs as designed,

not as required.”(DO-254 Appendix A).

Cette définition met en évidence un certain nombre de points qu’il faut ici analyser.

Objectif

L’objectif recherché est clair : la détection des erreurs potentielles de mode commun. Par « mode

commun » il faut comprendre : les erreurs commises par plusieurs personnes à la fois.

D’où proviennent ces erreurs ?

Majoritairement d’une mauvaise interprétation de la spécification qui est propagée depuis la

conception jusque dans la mise en œuvre de la vérification.

Un autre type d’erreur de mode commun, probablement aussi important pourrait être qualifié

d’erreur par omission.

La faiblesse d’une spécification réside souvent dans la difficulté à décrire précisément les effets de

bords, les cas aux limites, les comportements anormaux. Cela relève souvent d’une interprétation

croisée de plusieurs exigences ou au contraire d’une exigence générale de type « tenue aux

radiations », « robustesse » ou « aucune interruption ne doit être perdue ».

Dans ce cas un manque d’imagination du concepteur (ou un manque de recul) peut l’amener à ne

pas traiter tous les cas possibles. Si la vérification est faite par la même personne, il est clair qu’elle

a très peu de chance de traiter ce type de cas aux limites. La « vraie vie » se chargera rapidement

de lui rappeler que ‘tout est possible même l’improbable’ !

Le risque est donc grand de voir le designer reproduire sa compréhension du système dans la

vérification et donc de ne pas détecter les erreurs d’implémentation de la spécification, ni les

erreurs « par omission ».

C’est ce que décrit la définition de la DO-254 : le concepteur va vérifier sa conception et non pas la

spécification d’origine.

Chapitre 2

L’indépendance

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 6: White paper" La DO-254 pour les nuls"

L’indépendance: une idée largement partagée ?

Cette idée est parfois choquante aux oreilles de certains d’entre nous, surtout ceux qui ont une

longue expérience du design, avec un certain nombre de réussites qui démontrent qu’un designer

peut être un bon vérificateur de son propre design. C’est souvent le cas lors de développement

d’ASIC complexes.

C’est probablement lié à une approche différente de la spécification, qui va se construire et

s’affiner au cours du développement, ce qui rend plus difficile l’exercice de l’indépendance:

l’équipe de design est la seule à maîtriser la spécification, pas toujours totalement écrite. Dans ce

cas, le designer doit avoir conscience des risques décrits ci-dessus et doit pouvoir prendre le recul

nécessaire pour minimiser ceux-ci. Cela est souvent associé à une expérience avancée dans le

domaine et une capacité à s’appuyer sur du retour d’expérience.

Choix de la DO-254

Le choix fait par les rédacteurs de la DO-254 est tout autre, qui préconisent de régler une bonne

fois pour toute le problème en assurant une indépendance forte entre design et vérification – en

tout cas en DAL A et B. Ceci est possible car dans un cycle de vie DO-254 la spécification

« complète » et « correcte » peut servir de point de départ incontestable, à la fois pour le designer

et pour le vérificateur.

Le développement parallèle et indépendant du code source et des cas de vérification est un

exercice qui trouve son aboutissement lors de la confrontation entre les deux équipes, lors du

lancement effectif des tests et des simulations. Les erreurs de compréhension (qui peuvent être

dues à une spécification pas si complète et correcte que cela) et les erreurs par omissions ont dans

ce cas une probabilité plus forte d’être détectée.

Ce n’est en rien une solution miracle. Cela ne remplace pas une équipe expérimentée. Il s’agit juste

d’un moyen supplémentaire de refermer quelques trous dans la raquette, qui s’avère souvent très

efficace pour faire remonter les dernières incertitudes sur la spécification (on rejoint là des

préoccupations de la phase de validation …).

DAL C et indépendance

En DAL C ou D le risque est assumé et il est possible de s’affranchir de cette notion. Attention DAL

C ne veut pas dire fonction simple (c’est parfois le contraire) et donc les risques d’erreur décrits

ci-dessus sont tout aussi forts. Par contre on considère que cela ne remet pas en cause le niveau de

safety de l’objet (approche assez discutable …).

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 7: White paper" La DO-254 pour les nuls"

Ce que cela relève des fondements de la DO-254

En généralisant, l’approche préconisée par les rédacteurs est clairement la suivante :

Une stratégie gagnante ne peut être construite sur la confiance aveugle dans la compétence

des équipes. Il est nécessaire d’avoir un point de contrôle indépendant pour toutes les

activités du cycle de vie de la conception.

On entend souvent les sentences suivantes, qui relèvent de cette « philosophie » :

« Ce n’est pas celui qui a écrit un document qui doit décider si ce document est correct ou non »

« Ce n’est celui qui a écrit la spécification qui doit décider si elle est complète et correcte »

« Ce n’est pas le designer qui doit écrire la vérification »

La première phrase amène à la notion de peer review largement admise et utilisée dans le cadre

d’un développement sous contrainte DO-254.

La seconde phrase décrit la nécessaire indépendance de la phase de validation (oubli de la

DO-254, corrigé par le CAST 27 et les différents CRI et autres documents annexes)

La dernière phrase décrit l’indépendance de la vérification, qui fait l’objet de l’annexe A de la

DO-254.

L’ensemble est renforcé par le rôle de l’assurance process qui doit s’assurer que ces

recommandations ont bien été suivies (confiance, confiance ….).

Nous aborderons le coût et les moyens de l’indépendance dans une prochaine livraison, y compris

ses aspects les plus modernes liés à l’utilisation de langages avancés et de nouveaux moyens de

vérification , indispensable pour le développement d’IP complexes et de Système de type SoC.

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 8: White paper" La DO-254 pour les nuls"

Chapitre 3

Mise en œuvre de l’indépendance

La première partie de ce chapitre a permis de mettre en évidence les avantages de l’indépendance – à

tous les stades du développement – et les objectifs recherchés, à savoir garantir un niveau de qualité

élevé des processus et éliminer toute une catégorie d’erreurs dites de mode commun (« je ne peux

vérifier correctement ce que j’ai produit »).

Nous allons maintenant examiner de plus près la mise en œuvre de l’indépendance dans la phase de

vérification. Pour plus de clarté nous nous limiterons à examiner les phases de vérification

« virtuelle », avec des outils CAO, en particulier la simulation, qui a pour objectif de s’assurer de la

conformité du design avec la spécification, d’un point de vue fonctionnel. Les autres aspects de la

vérification, en particulier tout ce qui peut être lié à l’environnement, aux tests physiques (certains

disent « vérification formelle ») sur banc, à l’intégration, à la qualification - qui ont tous de très

bonnes raisons d’exister dans la remontée du cycle en V - ne sont pas abordés ici.

Une définition

“Indépendance - Séparation des responsabilités qui garantit l'aboutissement d'une évaluation

objective. A rapprocher de l'indépendance intellectuelle telle que celle d'un autre individu, et non de

celle d'un département ou d'une entreprise“(DO-254 Annexe C Glossaire)

Cette définition, issue de la version française de la DO-254 (oups! ED80), donne une approche

particulière des attentes des auteurs en matière de mise en œuvre de l’indépendance.

Séparation physique

Contrairement à l’idée assez répandue, jusque chez certains certificateurs, il n’est pas certain de

garantir une vraie indépendance en séparant les acteurs impliqués dans ce processus, à savoir

l’équipe de design et l’équipe de vérification.

Travailler avec deux services distincts, voire deux entreprises (un donneur d’ordre en charge du

design et un sous-traitant « V&V » qui ne fait que la validation et la vérification), ne garantit en rien

une vraie indépendance, sauf à mettre des barrières infranchissables entre les deux équipes, ce qui

est une façon très efficace de mettre un projet en péril.

Car le vrai paradoxe de la vérification est qu’elle ne peut aboutir que par le dialogue, l’échange, la

confrontation et la résolution des conflits.

Ou alors il faut admettre que le design est parfait et ne nécessite pas de remise en question, ce qui

limite singulièrement l’intérêt de la vérification fonctionnelle, vous en conviendrez certainement !

Donc aussi poussée soit-elle, l’indépendance aboutit à un dialogue, une confrontation des points de

vue (le mécanisme basique de la revue !).

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 9: White paper" La DO-254 pour les nuls"

La seule exception qui me vient à l’esprit concerne la conformité de protocoles complexes (type PCI-E)

qui peuvent être établis via des tests préexistants et totalement indépendants, sans dialogue possible

(test de conformité avec tampon officiel à la clé). Ceci n’est rendu possible que par l’aspect normalisé

de ces protocoles. A noter dans ce cas que c’est le test qui sert de référence et qu’en cas de conflit

(failure) c’est toujours le design qui est en cause : pas besoin de discuter …

Dialogue et indépendance

Il est donc établi que dans tous les cas un dialogue et des échanges devront exister entre les deux

partis qui s’opposent (le design et la vérification).

Toute la question réside dans le timing associé à ce dialogue et dans la façon dont il est encadré,

contraint, maitrisé par l’équipe de management et par la qualité.

La définition du glossaire parle de responsabilité et d’objectivité et d’indépendance avant tout

« intellectuelle », je dirais plutôt « honnête ».

Origine des échanges

Le timing de la confrontation est variable et fortement lié à la maturité de la spécification.

Une spécification immature (incomplète, ambiguë) va susciter rapidement des questions de chacun

des participants vers le responsable de ce document d’entrée.

Il est peu recommandé de mettre en relation designer et vérificateur à ce stade très précoce de

l’analyse fine de la spécification, surtout si le designer est également le spécificateur (assez courant).

De toute façon le risque encouru est très élevé, d’autant plus si l’un des deux protagonistes prend le

dessus (on est dans une phase de négociation), ce qui enlève toute objectivité au résultat (c’est le plus

fort qui l’emporte, sans aucune garantie de validité des options choisies).

La seule solution viable consiste à intercaler une entité indépendante dans la boucle (responsable

projet par exemple) qui va transmettre et arbitrer les conflits sur la spécification (ce qui va lui conférer

un niveau de maturité supérieur et ceci assez rapidement).

A ce stade de la compréhension de la fonctionnalité il n’est nul besoin de dialogue direct entre les

équipes.

Dans une phase plus avancée dans le temps, lorsque les codes sont écrits (code source pour le design

et code des cases de simulation pour l’équipe vérification) et que les outils CAO de simulation sont

sollicités il doit exister une forme de dialogue et d’échange (ne serait-ce que pour pouvoir assembler

au même endroit les codes).

Il arrive forcément un moment où le vérificateur aura entre ses mains le code source en provenance

de la partie design (sauf à envisager des stratégies de cryptage, jamais mises en œuvre à ma

connaissance). De plus le partage des données via un système de gestion de la configuration (CVS,

SVN..) rendent « public » les données de tous les acteurs. Ceci est vrai également pour les données

avancées de design (dossier de conception détaillée par exemple) que le vérificateur n’est pas censé

connaître.

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 10: White paper" La DO-254 pour les nuls"

Les stratégies très coercitives de masquage, de gestion différenciée des droits, sont toujours

possibles, mais complexes à mettre en œuvre, lourdes et souvent faciles à contourner.

Bien entendu ici on voit bien que la séparation physique des équipes n’a plus aucun sens, sauf à

croire que l’on peut conduire la vérification à son terme en aveugle …

Au contraire, les moyens de communication actuels font que rien ne peut empêcher les informations

de circuler d’un acteur à l’autre de façon par toujours ordonnée (par email par exemple), ni les

acteurs de discuter entre eux directement – en violation totale des pratiques de l’indépendance.

Honnêteté, responsabilité, objectivité

En définitive ce qui fait fonctionner avec la plus grande efficacité l’indépendance réside dans cette

idée saugrenue de l’indépendance intellectuelle, qui fait sourire à la première lecture (encore un

doux rêveur, un utopiste dans un monde technique sans pitié …).

L’indépendance comporte une phase délicate et essentielle, celle ou les points de vue doivent être

nécessairement confrontés. Ce n’est qu’à l’issue de cette phase (souvent itérative) que le niveau de

qualité du projet aura progressé, ainsi que son niveau de maturité.

En soi, garantir la séparation des personnes est assez simple, même au sein d’une organisation

unique. Etre capable de gérer avec objectivité, honnêteté le flux de données, de questions et

d’échanges entre les deux équipes est une tâche beaucoup plus complexe, qui requiert capacité à

manager et sens des responsabilité, vis-à-vis du projet, du client et de l’entreprise.

Selon les organisations ce rôle d’arbitre peut être tenu par le chef de projet ( qui peut parfois avoir du

mal à rester objectif, tiraillé qu’il est, entre sa responsabilité vis-à-vis du projet et la pression de sa

hiérarchie). Le responsable assurance process (RAP) plus indépendant vis-à-vis de la structure peut

tenir efficacement ce rôle, à condition d’être présent au plus près des équipes et d’avoir un minimum

de compréhension technique.

Conclusion

On en arrive ainsi à la conclusion – étonnante ! – que la qualité du produit est dépendante de la

qualité des équipes de management du projet …. Tout ça pour ça !

Mon expérience personnelle m’a permis de confronter de très nombreuses situations

d’indépendance -depuis des organisations séparées par des centaines de kms, jusqu’à des équipes

partageant les mêmes bureaux - et m’a amené à cette conclusion évidente : l’indépendance n’atteint

ses objectifs que lorsqu’elle est envisagée de façon « intellectuelle » avec des notions d’honnêteté

partagée par l’ensemble des acteurs et par la hiérarchie du projet.

Dans tous les autres cas le projet en pâtit, que ce soit au travers de sa qualité, de sa maturité, des

délais non respectés, où des dépassements de coût pour reprise non planifiée.

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 11: White paper" La DO-254 pour les nuls"

Ce chapitre a pour objectif de clarifier quelques notions pas toujours explicites autour du concept de

COTS. Au-delà de la définition que nous allons examiner –toujours très instructive – nous allons au

travers de ce point particulier aborder quelques thèmes sensibles – très sensibles – des systèmes

embarqués présents et futurs.

Une definition

Commercial Off-The-Shelf (COTS) Component - Component, integrated circuit or subsystem

developed by a supplier for multiple customers, whose design and configuration is controlled by the

supplier’s or an industry specification.

Note: Examples of COTS components may include resistors, capacitors, microprocessors,

unprogrammed Field Programmable Gate Array and Erasable Programmable Logic Devices, other

integrated circuit types and their implementable models, printed wiring assemblies and complete LRUs

which are typically available from a supplier as a catalog item.

Cette définition, issue de l’annexe C de la DO-254 (le très précieux glossaire), est une des plus longues,

une des rares à nécessiter une note et la seule s’appuyant sur des exemples, comme si la définition

n’était pas suffisante (un brin de clairvoyance de la part des rédacteurs).

Un périmètre bien délimité

A la première lecture la définition est simple est claire :

Un composant de type COTS est un composant que vous avez acheté chez un fournisseur qui ne l’a

pas conçu et fabriqué particulièrement pour vous.

C’est l’exact contraire du composant spécifique (ASIC ou Application Specific Integrated Circuit ) qui

est fabriqué expressément pour vous et uniquement pour vous.

Certains sont familiers avec la notion d’ASSP (Application Specific Standard Product) qui correspond à

la dernière partie de la définition des COTS :

Un Application Specific Standard Product ou ASSP est un circuit électronique intégré regroupant un

grand nombre de fonctionnalités pour satisfaire à une application généralement standardisée : par

exemple un ASSP pour GSM issu d'un fabricant unique est utilisé comme circuit de base par différents

fabricants… (Thanks to Widipedia)

Les ASSP sont donc considérés comme des COTS.

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Chapitre 4

Cots (partie 1)

Page 12: White paper" La DO-254 pour les nuls"

Les FPGA et autres PLD avant programmation sont aussi considérés comme des COTS, sans que cela

semble avoir eu un impact significatif sur le traitement de ces objets fondamentaux de l’électronique

embarquée (un jour qui sait !). En fait les FPGA (avec leur programmation/personnalisation) sont

considérés comme des composants relavant du traitement normal de la DO254 (démonstration du

cycle de conception).

Parmi les éléments de base des systèmes électroniques d’autres familles sont citées dans la note

associée à la définition :

Résistances, capacités : en clair les composants discrets achetés sur catalogue. Là aussi la

pression ne s’est pas encore fait sentir, le regard étant plutôt tourné vers l’électronique numé-

rique complexe.

Les cartes et les ensembles achetés chez un fournisseur de solutions standards. La pression

commence à s’exercer sur ces ensembles complexes dont la maîtrise est souhaitable (nous

développerons ceci).

Au cœur des préoccupations depuis l’origine, avec une remontée très puissante dans l’actualité des

systèmes embarqués nous retrouvons le microprocesseur et par extension le microcontrôleur qui se

distingue par son nombre de périphérique beaucoup plus grand.

Nous traiterons de ce cas au combien particulier dans la suite de ce chapitre.

Enfin, last but not the least, “other integrated circuit types and their implementable models”, qui

n’est pas la définition la plus Claire du lexique ! Une rapide recherche sur le Net vient confirmer ce

qui est issu d’un consensus assez large, il s’agit ici d’une définition approximative du concept d’IP.

L’IP (Intellectual Property) est un bloc fonctionnel qui va servir d’élément de base à la construction

d’un système intégré plus complexe. C’est donc la brique de base qui sert à la construction

(l’intégration) d’un SoC ou d’un SoPC (Système sur une Puce ou un FPGA).

Ce type d’élément correspond bien à la notion de COTS, puisque développé par un fournisseur qui l’a

mis à son catalogue, qu’un concepteur achète avec son dossier et qu’il intègre dans son application

spécifique (le principe du Lego).

On trouve aujourd’hui des IP couvrant l’ensemble des bus de communication ou industriel, des cœurs

de processeurs, des périphériques et des interfaces, de quoi construire un système complet (il suffit

de rajouter son application sous forme hardware – glue- ou software – logiciel applicatif).

On parle dans le monde de l’aéronautique de « COTS IP » pour bien signifier que par défaut les IP

sont des COTS.

Pourquoi cette distinction

La première question à se poser après cette énumération à la Prévert, est bien entendu celle de la

raison qui justifie un tel effort.

En effet quel problème pose l’ensemble de la famille des COTS ?

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 13: White paper" La DO-254 pour les nuls"

Tout simplement celui de représenter tout ce que la DO254 ne peut maîtriser dans un système.

Par « maîtriser » il faut entendre la capacité à démontrer le cycle de développement de l’objet dans

toutes ses dimensions, à savoir les étapes du cycle en V (conception depuis le recueil des exigences,

jusqu’au dossier détaillé et le code, vérification exhaustive prouvée) ainsi que les activités transverses

indispensables à la construction d’une conception sûre (assurance qualité, traçabilité, gestion docu-

mentaire, gestion de la configuration, suivi des modifications, outils maison utilisés …).

Il suffit d’imaginer disposer du dossier de conception complet et du code source d’un processeur du

commerce pour comprendre la difficulté de la tâche. Ou simplement se rappeler qu’une des

dernières discussions sur les forums dédiés traitait de l’opportunité de conserver tous les emails

échangés lors de la conception d’un objet !

Les COTS posent réellement un souci car il est impensable de demander la production d’un dossier

similaire à celui qui est fourni lorsque le développement est fait par vos soins.

Je n’insisterai pas sur la notion de quantité et sur la faible place du marché aéronautique pour la

plupart des fournisseurs de solutions sur catalogue (à commercer par les processeurs et autres

contrôleurs) !

Or l’approche de la certification des systèmes embarqués repose en grande partie sur cette notion

d’assurance qualité du développement (et non de la fourniture).

Ceci est d’autant plus gênant lorsque les objets en questions représentent une partie non négligeable

du système, voire sa partie fondamentale (le réseau AFDX d’un équipement distribué, le composant

microcontrôleur).

A quoi bon démontrer la parfaite conception d’un FPGA périphérique annexe d’un microcontrôleur, si

le cœur lui-même n’est pas démontrable de cette façon ?

Premiers éléments de réponse

Etrangement dans les temps reculés de la DO254 (plus de 10 ans déjà ...) la place des COTS a été

négligée et souvent traitée comme une notion marginale, surtout utile pour évacuer quelques

questions gênantes trop évidentes.

La première réponse a concerné les cœurs de processeurs, dès 2005 dans les premières notes

d’applications émises par le CAST et la FAA :

“Therefore, we don’t intend that you apply RTCA/DO-254 to COTS microprocessors. (FAA AC 20-152

June 2005)

Traduction : il n’a jamais été dans nos intentions de vous demander de démontrer les

microprocesseurs ( !). Une très jolie mise au point !

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 14: White paper" La DO-254 pour les nuls"

There are alternative methods or processes to ensure that COTS microprocessors perform their

intended functions and meet airworthiness requirements.” (CAST-27 12.b)

Traduction : laissons les gens du logiciel se débrouiller avec la DO178B (après tout un micro c’est

avant un tout un socle pour recevoir du logiciel applicatif).

Ceci a permis aux aéronefs de la dernière décennie de voler et ce n’est un moindre succès.

Cependant ceci appelle quelques remarques :

Cœur de microprocesseur ne veut pas dire microcontrôleur, surtout si l’on considère le nombre

important de périphériques embarqués par ces objets complexes, dont certains ne sont pas utilisés

(assimilable à du code mort) et dont le fonctionnement fin n’est pas accessible (mode communs,

tenue aux radiations, mécanisme de désactivation …).

L’industrie du système embarqué après s’être généreusement engouffrée dans la brèche ouverte par

la FAA, a probablement poussé un peu trop loin le curseur.

D’où une remontée forte des questions autour des cœurs de micro dans l’actualité du domaine,

surtout si on ajoute quelques soucis quant à la pérennité (plus de 30 ans ?) de ces objets et quant à la

démonstration de la reproduction du fonctionnement (déterminisme d’un multi-cœur).

Cette question sera abordée dans un chapitre ultérieur.

Pour le reste des COTS, à l’exception notoire des IP, il n’y guère d’autres solutions que celles

préconisées par la DO254 (electronic component management process, COTS procurement) et

décrites dans le chapitre 11.2. Nous y reviendrons dans la seconde partie de ce chapitre.

Les IP sont une exception car il existe des solutions qui permettent de considérer et de traiter ces

objets comme des objets relevant du « droit commun » de la DO254.

Après tout un fournisseur d’IP doit pouvoir démontrer un flot de conception structuré (proche des

attentes de la DO254), et doit s’appuyer certainement sur des processus qualité rigoureux et une

vérification poussée.

Pour le moins il doit posséder le code source de l’IP et un minimum de documentation, qui autorise

une opération de reverse engineering pour reconstituer (la DO254 dit « supplémenter ») les données

manquantes.

En complément et par construction, un fournisseur d’IP doit pouvoir garantir un certain historique

d’utilisation de son bloc, ce qui est une garantie indirecte de la solidité de la construction (pour

obtenir des crédits de confiance).

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 15: White paper" La DO-254 pour les nuls"

En résumé

La notion de COTS est très vaste (de la résistance au processeur en passant par les IP).

Ils représentent un point bloquant dans la méthodologie sous-jacente à la certification des objets

électroniques (impossibilité de démontrer le cycle de conception de façon satisfaisante).

Le traitement par contournement (gestion des composants et des fournisseurs) est acceptable pour

des éléments « mineurs » (notion à définir, est ce qu’une capacité est un élément mineur ?)

De par leur importance dans le système certains COTS ne peuvent se satisfaire de la réponse

standard et nécessitent lorsque cela est possible une approche plus directe.

C’est le cas des cœurs de processeur (dont la démonstration est renvoyée au logiciel).

C’est également le cas des IP et des microcontrôleurs (qui peuvent être considérés comme des IP

dans leur version embarquée dans des composants de type FPGA ou ASIC) qui doivent apporter des

réponses plus approfondies, proches de celles apportées par les composants FPGA (cycle de

conception régi par la DO254 et dossier associé) sous peine de discréditer l’ensemble de la démarche

d’assurance conception.

Enfin, n’oublions pas qu’associée à la notion de COTS sont accrochées des problématiques à l’ordre du

jour de toutes les conversations : pérennité, tenue aux radiations, évolutivité.

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

Page 16: White paper" La DO-254 pour les nuls"

Tout d’abord rappelons les faits qu ant à la position de l’EASA sur les COTS:

Après quelques années de silence l’EASA vient de finaliser un document très complet et relativement

précis sur la façon dont il faudrait envisager certains points de la mise en œuvre de la DO254.

Silence n’est pas le terme exact puisque l’EASA s’est exprimé, principalement au travers des CRI

(Certification Review Item) qui sont des précisions sur les moyens à mettre en place pour un aéronef

précis (CRI F-16 pour l’EC175 par exemple).

Ces documents sont très utiles mais liés à un projet (donc par essence non universel) et surtout – en

principe – non public (sauf erreur de ma part qu’un lecteur attentif corrigera, les CRI ne sont pas

disponibles sur le site de l’EASA.

Maintenant, au travers du premier « Certification Memo » consacré à l’application de la DO254, la

position de l’EASA est clairement exprimée sur des points devenus, au fil du temps, essentiels et

nécessitant une passe de clarification. Cela valait le coup d’attendre. D’autant plus que ce Memo

ayant été relu par de nombreux experts prend en compte – sous l’arbitrage de l’EASA – les positions

des intervenants majeurs du secteur (avionneur et équipementiers).

Ce document – rare vous l’aurez compris- mérite donc une lecture approfondie, même s’il n’a pas

force de loi, il devra être probablement mis en document applicable des prochains CRI.

Nous examinerons ici ce qui est dit sur le champ des COTS qui représente une part importante de ce

Memo (le plus gros chapitre, 15% du document).

Rappel de quelques définitions

Tout d’abord – comme il se doit – faisons une place de choix à la partie définition (glossaire) qui

contient souvent de très utiles informations.

Ici nous trouvons une définition exemplaire des microcontrôleurs, qui ne laisse aucun doute à ceux –

plus très nombreux – qui croient que la limite entre uP et uC est négociable :

COTS Microcontroller :”Any IC which executes software in a specific core area (Central Processing

Unit) and implements peripheral hardware elements such as, for example, input/output (I/O), bus con-

trollers… Such a peripheral element may be considered simple (e.g. a UART, A/D, D/A) or complex (e.g.

a bus controller).”

En clair : le microprocesseur c’est l’unité centrale (traitée par la DO178 selon les recommandations du

CAST27), le microcontrôleur comporte en plus des périphériques plus ou moins complexes (voire

analogiques) qu’il va falloir traiter comme tels. (définition un peu plus détaillée que celle des CRI).

Chapitre 5

Cots (partie 2)

Page 17: White paper" La DO-254 pour les nuls"

Le chapitre 9 du Certification Memo traite des activités d’assurance design à appliquer pour chaque

type de COTS en fonction de sa complexité, du niveau de DAL recherché, du type de COTS et du

niveau de service expérience démontrable.

COTS micro

Concernant les « micro » l’introduction de ce chapitre est clair et sans ambiguïté (vous noterez que

c’est la première fois que les choses sont aussi explicites depuis l’écriture de la DO254, dans un

document public – donc en dehors des CRI)

« Software and microprocessors are out of scope of this Section. The development assurance of

microprocessors and of the core processing part of the microcontrollers and of highly complex COTS

microcontrollers (Core Processing Unit) will be based on the application of ED-12B/DO-178B to the

software they host “

Donc, comme nous le pressentions tous, seul l’unité centrale est couverte par la dérogation du

CAST27.

COTS IP

Un second type de COTS est rapidement traité dans ce chapitre : les COTS IP

“ COTS IP is outside the scope of this section.“

En fait les IP sont traitées de façon très succincte dans une autre section.

COTS IC

Un troisième type de COTS est traité dans ce chapitre 9 : les COTS IC

COTS IC : “Any COTS digital or hybrid electronic device which does not execute software in a specific

core. COTS ICs may be bus controllers, flip-flop, multiplexers, converters, memories… The hardware

functions implemented within these components may be simple or complex. “

Une définition assez proche de celle des ASSP (voir la DO-254 pour les nuls chapitre 4) : un circuit

intégré complexe sans micro à l’intérieur.

Page 18: White paper" La DO-254 pour les nuls"

Au final le chapitre 9 du Certification Memo de l’EASA traite uniquement que de trois type de

composants :

Les COTS IC, les microcontrôleurs, et les microcontrôleurs très complexes.

Cette dernière catégorie fait apparaître une classification originale en trois catégories :

simple, complexe, très complexe.

Kaisse qu’un micro très complexe ?

If a COTS microcontroller has any of the following characteristics, it should be classified as Highly

Complex:

more than one Central Processing Unit (CPU) are embedded and they use the same bus (which is

not strictly separated or which uses the same single port memory)

several controllers of complex peripherals are dependent on each other and exchange data

several internal busses are integrated and are used in a dynamic way (for example, a dynamic bus

switch matrix)

Cette définition recouvre pas mal de préoccupations bien actuelles, comme le multicore, ce qui rend

cette approche très intéressante.

Pour les COTS relevant de ce chapitre les activités décrites sont assez proches de ce que la DO254

propose dans le chapitre 11.2 qui traite du component management, du component procurement et

du « in service experience » (11.3).

La proposition de l’EASA est cependant plus complète, plus détaillée et modulée en fonction du type

de COTS (simple, complexe, très complexe) du niveau de DAL( A, B ou C) et de la quantité de PSE

(Product Service Expérience) disponible.

Certaines de ces activités mériteraient d’être plus détaillées ici, mais il est temps de conclure pour

aujourd’hui.

A suivre …

Page 19: White paper" La DO-254 pour les nuls"

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

A propos de l’auteur

James Bezamat a fondé DMAP en 2009. C'est un expert microélectronique, possédant

une expérience de 25 ans dans le domaine de la conception numérique, tant dans le

design FPGA qu'ASIC, et une longue expérience dans le management technique

d'équipe, particulièrement dans le domaine de l'aérospatial et de la défense.

James Bezamat est un expert dans les méthodes associées à la DO-254, avec plus de 8

ans de projets dans le domaine aéronautique, et il est familier avec les différentes

approches communément utilisées par les principaux équipementiers. Il a été impli-

qué dans la définition de la plupart de ces stratégies avec une implication pratique

forte, en tant que responsable Assurance Process ou en tant qu'auditeur. Il est égale-

ment un formateur reconnu en microélectronique et en méthodologie

DO-254. James a passé 8 ans comme enseignant dans une grande école d'ingénieur

française (ESIEE). Il est diplômé de Centrale Lille et possède un master en micro-

ondes de l'Université de Lille.

Page 20: White paper" La DO-254 pour les nuls"

ww

w.d

ma

p.f

r

Ils font confiance à DMAP

DMAP

EXPERT

DMAP

IP

DMAP

DESIGN

DMAP

Design Methods and Assurance Process

100 Route des Houillères—13590 Meyreuil—BP 2

04.42.61.29.13

[email protected]

Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

DMAP est l’un des membres fondateurs du Groupement