White paper" La DO-254 pour les nuls"

  • 8,439 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
8,439
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
330
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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, reviewCe 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épendanceLa 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 peuxvé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 devé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 laconformité du design avec la spécification, d’un point de vue fonctionnel. Les autres aspects de lavérification, en particulier tout ce qui peut être lié à l’environnement, aux tests physiques (certainsdisent « vérification formelle ») sur banc, à l’intégration, à la qualification - qui ont tous de trèsbonnes 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 laboutissement dune évaluation objective. A rapprocher de lindépendance intellectuelle telle que celle dun autre individu, et non de celle dun département ou dune entreprise“(DO-254 Annexe C Glossaire)Cette définition, issue de la version française de la DO-254 (oups! ED80), donne une approcheparticulière des attentes des auteurs en matière de mise en œuvre de l’indépendance.Séparation physiqueContrairement à l’idée assez répandue, jusque chez certains certificateurs, il n’est pas certain degarantir une vraie indépendance en séparant les acteurs impliqués dans ce processus, à savoirl’équipe de design et l’équipe de vérification.Travailler avec deux services distincts, voire deux entreprises (un donneur d’ordre en charge dudesign et un sous-traitant « V&V » qui ne fait que la validation et la vérification), ne garantit en rienune vraie indépendance, sauf à mettre des barrières infranchissables entre les deux équipes, ce quiest 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, laconfrontation 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 quilimite 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 devue (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épendanceIl est donc établi que dans tous les cas un dialogue et des échanges devront exister entre les deuxpartis 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 échangesLe 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 chacundes 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 del’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 ledessus (on est dans une phase de négociation), ce qui enlève toute objectivité au résultat (c’est le plusfort qui l’emporte, sans aucune garantie de validité des options choisies).La seule solution viable consiste à intercaler une entité indépendante dans la boucle (responsableprojet par exemple) qui va transmettre et arbitrer les conflits sur la spécification (ce qui va lui conférerun 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 designet code des cases de simulation pour l’équipe vérification) et que les outils CAO de simulation sontsollicités il doit exister une forme de dialogue et d’échange (ne serait-ce que pour pouvoir assemblerau même endroit les codes).Il arrive forcément un moment où le vérificateur aura entre ses mains le code source en provenancede la partie design (sauf à envisager des stratégies de cryptage, jamais mises en œuvre à maconnaissance). 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éesavancé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 toujourspossibles, 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 informationsde circuler d’un acteur à l’autre de façon par toujours ordonnée (par email par exemple), ni lesacteurs 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 cetteidée saugrenue de l’indépendance intellectuelle, qui fait sourire à la première lecture (encore undoux 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 êtrenécessairement confrontés. Ce n’est qu’à l’issue de cette phase (souvent itérative) que le niveau dequalité 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 organisationunique. Etre capable de gérer avec objectivité, honnêteté le flux de données, de questions etd’é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 dumal à rester objectif, tiraillé qu’il est, entre sa responsabilité vis-à-vis du projet et la pression de sahiérarchie). Le responsable assurance process (RAP) plus indépendant vis-à-vis de la structure peuttenir efficacement ce rôle, à condition d’être présent au plus près des équipes et d’avoir un minimumde compréhension technique.ConclusionOn en arrive ainsi à la conclusion – étonnante ! – que la qualité du produit est dépendante de laqualité des équipes de management du projet …. Tout ça pour ça !Mon expérience personnelle m’a permis de confronter de très nombreuses situationsd’indépendance -depuis des organisations séparées par des centaines de kms, jusqu’à des équipespartageant les mêmes bureaux - et m’a amené à cette conclusion évidente : l’indépendance n’atteintses 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é, desdé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 deCOTS. Au-delà de la définition que nous allons examiner –toujours très instructive – nous allons autravers de ce point particulier aborder quelques thèmes sensibles – très sensibles – des systèmesembarqués présents et futurs.Une definition Commercial Off-The-Shelf (COTS) Component - Component, integrated circuit or subsystemdeveloped 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, otherintegrated circuit types and their implementable models, printed wiring assemblies and complete LRUswhich 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éfinitionn’é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’apas conçu et fabriqué particulièrement pour vous.C’est l’exact contraire du composant spécifique (ASIC ou Application Specific Integrated Circuit ) quiest 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 ungrand nombre de fonctionnalités pour satisfaire à une application généralement standardisée : parexemple un ASSP pour GSM issu dun fabricant unique est utilisé comme circuit de base par différentsfabricants… (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 celasemble avoir eu un impact significatif sur le traitement de ces objets fondamentaux de l’électroniqueembarquée (un jour qui sait !). En fait les FPGA (avec leur programmation/personnalisation) sontconsidérés comme des composants relavant du traitement normal de la DO254 (démonstration ducycle de conception).Parmi les éléments de base des systèmes électroniques d’autres familles sont citées dans la noteassocié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é dessystèmes embarqués nous retrouvons le microprocesseur et par extension le microcontrôleur qui sedistingue 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”, quin’est pas la définition la plus Claire du lexique ! Une rapide recherche sur le Net vient confirmer cequi 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 constructiond’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’amis à son catalogue, qu’un concepteur achète avec son dossier et qu’il intègre dans son applicationspécifique (le principe du Lego).On trouve aujourd’hui des IP couvrant l’ensemble des bus de communication ou industriel, des cœursde processeurs, des périphériques et des interfaces, de quoi construire un système complet (il suffitde 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 IPsont des COTS.Pourquoi cette distinctionLa première question à se poser après cette énumération à la Prévert, est bien entendu celle de laraison 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 danstoutes 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 transversesindispensables à 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 ducommerce pour comprendre la difficulté de la tâche. Ou simplement se rappeler qu’une desderniè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 dossiersimilaire à 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 laplupart des fournisseurs de solutions sur catalogue (à commercer par les processeurs et autrescontrôleurs) !Or l’approche de la certification des systèmes embarqués repose en grande partie sur cette notiond’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égligeabledu système, voire sa partie fondamentale (le réseau AFDX d’un équipement distribué, le composantmicrocontrôleur).A quoi bon démontrer la parfaite conception d’un FPGA périphérique annexe d’un microcontrôleur, sile cœur lui-même n’est pas démontrable de cette façon ?Premiers éléments de réponseEtrangement 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 quelquesquestions gênantes trop évidentes.La première réponse a concerné les cœurs de processeurs, dès 2005 dans les premières notesd’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-152June 2005)Traduction : il n’a jamais été dans nos intentions de vous demander de démontrer lesmicroprocesseurs ( !). 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 theirintended 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’estavant 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 nombreimportant 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 parla 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 à ladé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 cellespréconisées par la DO254 (electronic component management process, COTS procurement) etdé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 cesobjets 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 desattentes de la DO254), et doit s’appuyer certainement sur des processus qualité rigoureux et unevérification poussée.Pour le moins il doit posséder le code source de l’IP et un minimum de documentation, qui autoriseune opération de reverse engineering pour reconstituer (la DO254 dit « supplémenter ») les donnéesmanquantes.En complément et par construction, un fournisseur d’IP doit pouvoir garantir un certain historiqued’utilisation de son bloc, ce qui est une garantie indirecte de la solidité de la construction (pourobtenir 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 pourdes é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éponsestandard 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 IPdans leur version embarquée dans des composants de type FPGA ou ASIC) qui doivent apporter desréponses plus approfondies, proches de celles apportées par les composants FPGA (cycle deconception régi par la DO254 et dossier associé) sous peine de discréditer l’ensemble de la démarched’assurance conception.Enfin, n’oublions pas qu’associée à la notion de COTS sont accrochées des problématiques à l’ordre dujour 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 relativementpré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éronefpré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 – enprincipe – non public (sauf erreur de ma part qu’un lecteur attentif corrigera, les CRI ne sont pasdisponibles sur le site de l’EASA.Maintenant, au travers du premier « Certification Memo » consacré à l’application de la DO254, laposition de l’EASA est clairement exprimée sur des points devenus, au fil du temps, essentiels etnécessitant une passe de clarification. Cela valait le coup d’attendre. D’autant plus que ce Memoayant été relu par de nombreux experts prend en compte – sous l’arbitrage de l’EASA – les positionsdes 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 pasforce 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 ceMemo (le plus gros chapitre, 15% du document).Rappel de quelques définitionsTout d’abord – comme il se doit – faisons une place de choix à la partie définition (glossaire) quicontient 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 ProcessingUnit) 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 duCAST27), le microcontrôleur comporte en plus des périphériques plus ou moins complexes (voireanalogiques) 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 chaquetype de COTS en fonction de sa complexité, du niveau de DAL recherché, du type de COTS et duniveau de service expérience démontrable.COTS microConcernant les « micro » l’introduction de ce chapitre est clair et sans ambiguïté (vous noterez quec’est la première fois que les choses sont aussi explicites depuis l’écriture de la DO254, dans undocument public – donc en dehors des CRI)« Software and microprocessors are out of scope of this Section. The development assurance ofmicroprocessors and of the core processing part of the microcontrollers and of highly complex COTSmicrocontrollers (Core Processing Unit) will be based on the application of ED-12B/DO-178B to thesoftware they host “Donc, comme nous le pressentions tous, seul l’unité centrale est couverte par la dérogation duCAST27.COTS IPUn 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 ICUn troisième type de COTS est traité dans ce chapitre 9 : les COTS ICCOTS IC : “Any COTS digital or hybrid electronic device which does not execute software in a specificcore. COTS ICs may be bus controllers, flip-flop, multiplexers, converters, memories… The hardwarefunctions 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 circuitinté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 decomposants :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 HighlyComplex:more than one Central Processing Unit (CPU) are embedded and they use the same bus (which isnot 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 busswitch matrix)Cette définition recouvre pas mal de préoccupations bien actuelles, comme le multicore, ce qui rendcette approche très intéressante.Pour les COTS relevant de ce chapitre les activités décrites sont assez proches de ce que la DO254propose dans le chapitre 11.2 qui traite du component management, du component procurement etdu « 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 typede 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 pouraujourd’hui.A suivre …
  • 19. A propos de l’auteur James Bezamat a fondé DMAP en 2009. Cest 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 quASIC, et une longue expérience dans le management technique déquipe, particulièrement dans le domaine de laé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 quauditeur. 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 dingénieur française (ESIEE). Il est diplômé de Centrale Lille et possède un master en micro- ondes de lUniversité 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 à DMAPCe document est la propriété de DMAP. Le contenu ne peut être reproduit ou utilisé sans l’autorisation écrite de la société.