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

1. LIVRE BLANC
LA DO-254
DO-
POUR LES NULS

2. 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é.

3. Chapitre 1
La différence entre vérification et validation
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).
Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

4. 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é.

5. Chapitre 2
L’indépendance
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.
Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

6. 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é.

7. 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é.

8. 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é.

9. 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é.

10. 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é.

11. Chapitre 4
Cots (partie 1)
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é.

12. 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é.

13. 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é.

14. 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é.

15. 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é.

16. Chapitre 5
Cots (partie 2)
Tout d’abord rappelons les faits quant à 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).

17. 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.

18. 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 …

19. 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.
Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.

20. DMAP DMAP DMAP
EXPERT IP DESIGN
www.dmap.fr
DMAP
Design Methods and Assurance Process
100 Route des Houillères—13590 Meyreuil—BP 2
04.42.61.29.13
contact@dmap.fr
DMAP est l’un des membres fondateurs du Groupement
Ils font confiance à DMAP
Ce document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.