DO-178C et DO-254 : logiciel + matériel avionique

Auteur Hugues Orgitello Mis à jour le 3 juillet 2026 ~6 min de lecture

Guide · DO-178C / DO-254

DO-178C et DO-254 sont les deux documents de reference reconnus par la FAA et par l'EASA pour démontrer l'aptitude au vol du logiciel et du matériel électronique embarques dans un aéronef civil. Publies par RTCA aux Etats-Unis, repris sous les references ED-12C et ED-80 par EUROCAE en Europe, ils constituent depuis 1992 (DO-178A/B) et 2000 (DO-254) le socle process accepte par les régulateurs pour traiter respectivement le logiciel airborne et le matériel électronique airborne dans le cadre des Federal Aviation Regulations (FAR Parts 23, 25, 27, 29) et des Certification Specifications européennes équivalentes (CS-23, CS-25, CS-27, CS-29). Cette page expose l'architecture des deux documents, leur articulation avec les processus système SAE ARP4754A et SAE ARP4761, les Design Assurance Levels et leur mapping aux conditions de défaillance, les suppléments DO-330/DO-331/DO-332/DO-333, et les pieges observes en pratique.

Une famille de documents process, pas un règlement

Ni DO-178C ni DO-254 ne sont des règlements. Ce sont des documents techniques publies par RTCA, organisme prive de standardisation aéronautique américain, repris en Europe par EUROCAE sous les references ED-12C et ED-80. Leur valeur réglementaire vient de leur acceptation explicite par les autorités de certification :

• la FAA publie l'Advisory Circular AC 20-115D, qui declare DO-178C acceptable comme Means of Compliance pour les aspects logiciels des certifications de type sous FAR Parts 23, 25, 27, 29 ;
• l'EASA publie l'AMC (Acceptable Means of Compliance) 20-115, qui retient ED-12C (l'édition EUROCAE de DO-178C) comme Means of Compliance pour les CS-23/25/27/29 ;
• pour le matériel électronique, l'AC FAA AC 20-152A (révisée) et la position EASA correspondante référencent DO-254/ED-80.

Cette mécanique d'acceptation explique une caractéristique souvent mal comprise du domaine aéronautique : un projet ne "certifie" pas un logiciel ou un matériel isolement, il integre la démonstration de conformité a DO-178C ou DO-254 dans la base de certification négociée avec l'autorité pour le type aéronef ou pour l'équipement (par exemple via un TSO/ETSO). La conformité a DO-178C est un moyen de conformité parmi d'autres possibles, même si en pratique aucune autre voie n'est utilisée a l'échelle.

Pour le marquage CE généraliste, voir la page CE ; pour le glossaire des termes (DAL, FHA, PSSA, PSAC, CEH, etc.), voir le glossaire.

ARP4754A et ARP4761 : le cadre système qui enveloppe DO-178C et DO-254

DO-178C et DO-254 ne traitent jamais d'un système dans son ensemble. Ils traitent d'un item logiciel (DO-178C) ou d'un item matériel électronique (DO-254) déjà decoupe par le processus système. Ce découpage est le travail de deux documents SAE :

• ARP4754A "Guidelines for Development of Civil Aircraft and Systems" définit le processus de développement avion et système. Il décrit la décomposition fonctionnelle, l'allocation aux items, la verification et la validation a l'échelle système, la gestion des exigences et le suivi des Design Assurance Levels. Il est lui-même accepte par FAA AC 20-174 et par EASA AMC 25.1309.
• ARP4761 "Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment" définit les méthodes d'évaluation de la sécurité : Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA), Common Cause Analysis (CCA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA).

L'enchaînement de principe est le suivant :

[ARP4754A : developpement systeme]                [ARP4761 : safety assessment]
            |                                                    |
            v                                                    v
  Decoupage fonctionnel  <----------- FHA niveau aeronef -------->
            |                                                    |
            v                                                    v
  Allocation aux items                          PSSA : allocation des DAL
            |                                                    |
            +--------- items logiciels ---> DO-178C / ED-12C ----+
            |                                                    |
            +--------- items materiel ---> DO-254 / ED-80 -------+
            |                                                    |
            v                                                    v
    Integration systeme  <---- SSA : verification du safety budget
            |
            v
  Type Certification / STC / TSO / ETSO  (FAA / EASA)

Cette articulation explique pourquoi l'attribution des Design Assurance Levels n'est pas une décision du concepteur logiciel ou matériel : elle decoule directement du FHA et du PSSA conduits sous ARP4761, qui partent de la sévérité des conditions de défaillance a l'échelle système et avion, et qui les propagent jusqu'aux items en tenant compte de l'architecture (partitionnement, redondance, dissimilarité, monitoring).

Mapping DAL et condition de défaillance

Le mapping entre la sévérité d'une condition de défaillance et le DAL applicable a l'item est fixe par ARP4761 et repris par DO-178C et DO-254. Il est strictement identique dans les deux documents : un item logiciel et un item matériel allocates a une même fonction critique sont developpes au même DAL.

DAL	Condition de défaillance	Description (FAR/CS 25.1309)	Probabilite max par heure de vol
A	Catastrophic	Empeche la poursuite du vol et de l'atterrissage en sécurité ; perte multiple de vies	< 1E-9
B	Hazardous / Severe Major	Reduit la capacité de l'équipage a conduire le vol, blessures graves possibles, charge de travail extrême	< 1E-7
C	Major	Reduction significative des marges de sécurité ou de la capacité de l'équipage, inconfort pour les occupants	< 1E-5
D	Minor	Legere réduction des marges de sécurité, charge de travail accrue mais gérable, gene mineure	< 1E-3
E	No Safety Effect	Aucun effet sur la sécurité du vol ni sur la charge de travail de l'équipage	sans contrainte

La probabilité est définie au niveau système par CS-25.1309 / AC 25.1309-1A (et équivalents pour les autres Parts). Elle ne s'applique pas mécaniquement a un item logiciel pris isolement, mais a la condition de défaillance qui resulte de la combinaison d'items. Le DAL d'un item, lui, traduit l'effort d'assurance attendu sur le process de développement, pas une probabilité directement quantifiable pour un logiciel (le logiciel n'a pas de "taux de défaillance" au sens statistique du matériel).

DO-178C : architecture des objectifs

DO-178C structure ses exigences sous forme d'objectifs repartis en trois familles de process et listes dans les tableaux de l'Annexe A (Tables A-1 a A-10). C'est la structure objectifs-par-tableau qui donne au document son caractère process-centric.

Les trois piliers process

• Planning : production des plans (PSAC, SDP, SVP, SCMP, SQAP) et des standards (Software Requirements Standards, Software Design Standards, Software Code Standards). Ces documents sont produits en début de programme et soumis a l'autorité pour acceptation.
• Development : exigences logicielles haut niveau (High-Level Requirements, HLR), exigences logicielles bas niveau (Low-Level Requirements, LLR), architecture logicielle, code source, code exécutable.
• Integral processes : verification, configuration management, software quality assurance, certification liaison. Ces process se déroulent en parallèle du développement et conditionnent l'acceptation finale.

Decroissance des objectifs avec le DAL

Au DAL A, l'ensemble des objectifs des tableaux A-1 a A-10 s'applique, dont une partie avec indépendance entre la personne qui produit un artefact et la personne qui le verifie. Le passage aux DAL inférieurs joue sur deux leviers :

1. certains objectifs disparaissent (un objectif applicable au DAL A peut être marque "not applicable" au DAL C ou D),
2. certains objectifs perdent l'exigence d'indépendance, ce qui n'est pas le même allégement mais réduit le coût d'organisation.

Le nombre total d'objectifs souvent cite dans la littérature professionnelle est de 71 objectifs au DAL A. Le decompte exact par DAL doit être lu dans l'Annexe A de DO-178C, qui est la reference autoritative ; les éditions DO-178B et DO-178C n'ont pas exactement le même decompte (DO-178C ayant clarifie et reordonne certains objectifs).

DAL	Effort d'assurance attendu
A	Tous les objectifs applicables, indépendance maximale, couverture de code Modified Condition/Decision Coverage (MC/DC) requise sur le code exécutable
B	Sous-ensemble eleve, indépendance pour la majorité des objectifs, couverture Decision Coverage requise
C	Sous-ensemble réduit, indépendance moindre, couverture Statement Coverage requise
D	Sous-ensemble minimal, peu d'exigence d'indépendance, verification orientée exigences
E	Aucune activité DO-178C requise (l'item est traite hors-DO-178C avec justification d'absence d'impact sécurité)

La couverture MC/DC (Modified Condition/Decision Coverage) au DAL A est probablement l'exigence la plus discriminante du document : elle impose qu'aux essais, chaque condition booléenne d'une décision ait pu indépendamment influencer le résultat de la décision. Pour un code embarque non trivial, cela demande des bancs de test spécifiquement instrumentes et une couverture analytique souvent automatisée.

Independance : un levier souvent sous-estime

La notion d'indépendance est l'un des concepts les plus structurants de DO-178C. Indépendance ne signifie pas "double verification" mais séparation organisationnelle : la personne qui produit un artefact (par exemple les Low-Level Requirements) ne peut pas être la même que celle qui le verifie. La séparation peut être organisationnelle (deux personnes distinctes, equipes distinctes) ou outillée (un outil de verification automatise dont la qualification DO-330 garantit l'objectivité).

L'indépendance est exigée au DAL A sur la majorité des objectifs de verification, allégée au DAL B (indépendance sur une partie réduite), et généralement absente aux DAL C et D. Cette graduation a un impact direct sur la taille de l'equipe projet : un programme DAL A demande quasi-systematiquement une equipe de verification distincte de l'equipe de développement, ce qui pour les programmes de taille moyenne represente un coût significatif souvent sous-estime en début de programme.

Criteres de couverture par DAL

Les critères de couverture exiges varient avec le DAL et constituent l'une des différences de coût les plus visibles entre niveaux. Trois critères se cumulent en pratique : la couverture des exigences (chaque exigence est démontrée par au moins un cas de test), la couverture structurelle du code, et l'analyse de couverture des données et du controle.

DAL	Couverture exigences	Couverture structurelle	Coverage Analysis
A	100% HLR + 100% LLR	Modified Condition/Decision Coverage (MC/DC) sur le code exécutable, plus Decision Coverage, plus Statement Coverage	Data Coupling et Control Coupling exiges
B	100% HLR + 100% LLR	Decision Coverage plus Statement Coverage	Data Coupling et Control Coupling exiges
C	100% HLR + 100% LLR	Statement Coverage	Data Coupling et Control Coupling exiges au niveau modular
D	100% HLR	Pas de couverture structurelle exigée	Non specifie
E	Non applicable	Non applicable	Non applicable

L'analyse de Data Coupling verifie que toute donnée échangée entre composants est exercée par les tests. L'analyse de Control Coupling verifie que tous les chemins d'invocation entre composants sont exerces. Ces deux analyses, introduites avec une rigueur accrue par DO-178C par rapport a DO-178B, generent souvent des cas de test additionnels en fin de cycle, ce qui surprend les programmes ayant sous-estime cette charge.

Les livrables documentaires DO-178C

Livrable	Acronyme	Role
Plan for Software Aspects of Certification	PSAC	Document maître, soumis a l'autorité, qui declare la stratégie de conformité, le DAL retenu, les suppléments applicables (DO-330/331/332/333), les écarts éventuels
Software Development Plan	SDP	Decrit le cycle de développement adopte (cascade, itératif, etc.), les phases, les revues, les responsabilités
Software Verification Plan	SVP	Decrit la stratégie de verification : revues, analyses, essais, couverture, traceabilite
Software Configuration Management Plan	SCMP	Decrit la gestion de configuration des artefacts, le contole des versions, les baselines
Software Quality Assurance Plan	SQAP	Decrit l'organisation SQA, son indépendance, son plan d'audits
Software Requirements / Design / Code Standards	(standards)	Trois standards distincts qui codifient les regles de rédaction et de relecture
Software Requirements Data	HLR	Exigences logicielles haut niveau, dérivées des exigences système
Software Design Description	LLR + Architecture	Exigences logicielles bas niveau et architecture logicielle
Source Code	(code)	Code source conforme aux Software Code Standards
Executable Object Code	(binaire)	Binaire produit par la chaine d'outils ; les outils peuvent être soumis a DO-330
Verification Results		Resultats de revues, analyses et essais, avec couverture
Software Configuration Index	SCI	Index des artefacts d'une baseline de release
Software Accomplishment Summary	SAS	Document de cloture, soumis a l'autorité, qui recapitule la démonstration de conformité

La liste réelle peut être plus longue (Software Life Cycle Environment Configuration Index, Problem Reports, Software Change History, etc.). Le PSAC declare la liste effective applicable au programme.

Les quatre suppléments de DO-178C

DO-178C a ete publie en 2011 simultanément avec quatre suppléments, qui n'ont pas vocation a être lus seuls : ils ne s'invoquent qu'en complément de DO-178C, et chacun cible un mode de développement ou une technologie particulière.

Supplement	Sujet	Objet
DO-330	Software Tool Qualification Considerations	Definit les critères et le processus de qualification des outils logiciels utilises dans le cycle (compilateurs verifies, générateurs de code, outils de couverture, outils d'analyse statique). Cinq Tool Qualification Levels (TQL-1 a TQL-5) selon l'impact de l'outil sur le produit final et selon que l'outil est de développement ou de verification
DO-331	Model-Based Development and Verification Supplement	Etend les objectifs de DO-178C lorsque tout ou partie des exigences ou du design sont exprimées sous forme de modeles formels (par exemple en SCADE, Simulink/Stateflow) et lorsque la génération de code est automatisée
DO-332	Object-Oriented Technology and Related Techniques Supplement	Ajoute des objectifs lorsque le code utilise des techniques orientées objet (héritage, polymorphisme, allocation dynamique, exceptions) et des techniques apparentées (généricité, virtualisation) qui posent des questions de traçabilité et de verification non couvertes par DO-178C standard
DO-333	Formal Methods Supplement	Etend les objectifs de DO-178C lorsque des méthodes formelles (preuve, model checking, interprétation abstraite) sont utilisées pour atteindre tout ou partie des objectifs de verification, en remplacement ou en complément des essais

Un projet typique applique DO-178C seul. Un projet model-based applique DO-178C + DO-331 + DO-330 (les outils de génération et de verification étant généralement qualifies). Un projet C++ applique DO-178C + DO-332. Un projet a forte criticité recourant a la preuve formelle peut combiner DO-178C + DO-333 + DO-330.

Tool Qualification Levels TQL-1 a TQL-5

DO-330 définit cinq Tool Qualification Levels, depuis TQL-5 (effort minimal) jusqu'a TQL-1 (effort comparable au développement d'un logiciel DAL A). Le niveau s'obtient par croisement de deux dimensions : la catégorie d'outil (Criteria 1, 2 ou 3, qui codifie l'impact de l'outil sur le produit final) et le DAL du logiciel produit.

Categorie d'outil	Description	TQL au DAL A
Criteria 1	Le sortie de l'outil fait partie du logiciel embarque (typiquement : générateur de code automatique). Erreur de l'outil = erreur potentielle dans le binaire embarque	TQL-1
Criteria 2	L'outil automatise une activité de verification ET selectionne les artefacts a vérifier (typiquement : un test bench automatise qui choisit les cas et evalue les résultats sans verification humaine intermédiaire)	TQL-4
Criteria 3	L'outil automatise une activité de verification sans sélectionner les artefacts (typiquement : un compteur de couverture, un analyseur statique en prétraitement, un outil de comparaison binaire)	TQL-5

Aux DAL inférieurs, le TQL exigible décroît. Au DAL D, la quasi-totalite des outils Criteria 3 ne demande pas de qualification formelle, seule une justification est attendue. La regle pratique : si l'outil produit du binaire embarque (Criteria 1), sa qualification est l'effort le plus important du projet apres le logiciel lui-même.

DO-331 et la génération de code certifiable

DO-331 traite trois catégories de modeles : spécification (le modele exprime les exigences), design (le modele exprime l'architecture et le comportement), et implémentation (le modele est genere en code et le code est embarque). Plusieurs chaines d'outils du marche (SCADE Suite d'ANSYS, Embedded Coder de MathWorks avec Polyspace) proposent des générateurs qualifiables qui couvrent les objectifs DO-331 et leur qualification DO-330.

L'enjeu cle de DO-331 est l'équivalence modele-code : la traceabilite entre le modele d'origine et le code genere doit être démontrée, et la couverture demandée s'applique selon le cas sur le modele (model coverage) ou sur le code (object code coverage). Le supplément clarifie également le statut des éléments derives de la modélisation qui n'apparaissent pas dans les exigences amont (par exemple, des états internes générés automatiquement).

DO-333 et le statut des méthodes formelles

DO-333 reconnaît trois catégories de méthodes formelles utilisables pour atteindre les objectifs de verification : la preuve déductive (theorem proving, par exemple avec Coq, SPARK/Ada, Frama-C), le model checking (verification exhaustive d'un modele fini), et l'interprétation abstraite (par exemple avec Astree pour la preuve d'absence d'erreurs d'exécution sur du C). Le supplément n'impose pas une méthode particulière, il fixe les conditions sous lesquelles une méthode formelle peut se substituer a un essai pour démontrer un objectif.

L'usage des méthodes formelles en aéronautique reste minoritaire en volume mais est en croissance sur les fonctions de plus haute criticité. La justification économique apparaît lorsque le coût des essais et de leur couverture (typiquement MC/DC au DAL A) depasse le coût de la preuve, ce qui se produit pour des fonctions de petite taille mais de criticité maximale (controle de surfaces de vol primaires, par exemple).

DO-254 : assurance du matériel électronique embarque

DO-254 traite le matériel électronique avec une approche process équivalente a celle de DO-178C, mais adaptée a la spécificité du matériel.

Structure générale

Le corps de DO-254 définit un cycle de vie matériel : planification, exigences, conception conceptuelle, conception détaillée, implémentation, transition vers la production. Il identifie des process intégraux équivalents a DO-178C : verification, validation, configuration management, process assurance, certification liaison.

Les DAL A a E sont identiques a ceux de DO-178C dans leur signification (mapping aux conditions de défaillance), avec la même propagation depuis ARP4761. L'effort de verification et de validation augmente avec le DAL.

L'Appendix B : Complex Electronic Hardware

L'Appendix B de DO-254 fixe des considérations supplémentaires pour le Complex Electronic Hardware (CEH) : composants dont la complexité empeche une verification exhaustive par essais seuls. En pratique, l'Appendix B s'applique aux FPGA, aux ASIC et aux PLD complexes developpes pour le programme, et éventuellement a certains composants programmables hautement integres.

L'Appendix B étend le cycle de vie matériel de plusieurs maniere :

• verification de la programmation logique (RTL VHDL/Verilog) avec couverture fonctionnelle et structurelle équivalente, dans l'esprit, a la couverture de code logiciel,
• qualification des outils de synthèse, place-and-route, simulation, génération de bitstream, dans une logique parallèle a DO-330 cote logiciel,
• gestion des données de conception (schémas, RTL, contraintes de timing, fichiers de configuration) sous configuration management strict,
• traitement des éléments derives (Derived Requirements) avec retour vers le safety assessment ARP4761.

Un composant électronique simple (résistance, capacité, transistor discret, régulateur de tension standard) reste dans le périmètre DO-254 général mais sort de l'Appendix B. Sa qualification repose sur sa spécification fabricant, son qualification environmentale (DO-160 pour les essais d'environnement) et sa sélection sous critères de fiabilite.

Composants commerciaux vs CEH developpe en interne

DO-254 distingue deux situations pour le matériel électronique :

• Component Off-The-Shelf (COTS) : composant commercial achete dans le catalogue d'un fournisseur, sans visibilité sur son développement interne. Le programme avion doit justifier l'usage du composant via sa spécification, son historique d'usage en aéronautique (Service Experience), des essais complémentaires si nécessaires, et le cas échéant une analyse d'erratas du fabricant.
• Custom Electronic Hardware developpe en interne : circuit spécifique developpe pour le programme, ou FPGA programme par l'equipe. Tout le cycle DO-254 s'applique, et l'Appendix B est invoque si la complexité l'exige.

Cette distinction est l'objet de nombreuses discussions en review : le passage entre COTS, CEH et "composant complexe" n'est pas binaire, et la position de l'autorité peut varier selon les programmes et l'historique du composant.

Transition vers la production

DO-254 inclut une phase de transition vers la production : le cycle ne s'acheve pas a la livraison du prototype, il doit démontrer que le procede industriel reproduit l'unité verifiee. Pour un FPGA, cela couvre la traceabilite du bitstream, la séquence de programmation, le test de production. Pour un PCB, cela couvre les procédures d'assemblage, les essais de production (ICT, AOI, X-ray) et la maitrise de l'obsolescence.

Techniques de verification au sein de l'Appendix B

L'Appendix B identifie un ensemble de techniques de verification que le programme peut combiner pour atteindre un DAL donne. Les principales sont :

• Element Analysis : analyse de la décomposition fonctionnelle du composant complexe, identifie les blocs internes et leur rôle dans la fonction déclarée,
• Architectural Mitigation : utilisation explicite de redondance, partitionnement, dissimilarité, monitoring pour réduire le DAL effectif d'un sous-bloc. Par exemple, deux blocs DAL B indépendants peuvent atteindre une fonction DAL A si l'indépendance et la dissimilarité sont démontrées,
• Design Assurance Methods : verification par simulation fonctionnelle exhaustive (sur un périmètre delimite), revue, prototypage matériel, essais sur cible,
• Service Experience : utilisation d'un historique de service documente pour ancrer une partie de la démonstration d'assurance. Cette voie est restrictive et réservée aux composants ayant un historique de vol significatif et traçable.

Les Design Assurance Methods sont rarement utilisées seules ; un projet typique combine plusieurs techniques avec une justification de couverture argumentée dans le PHAC.

Couverture sur le code RTL

Pour les FPGA et ASIC sous Appendix B, la verification s'appuie sur des critères de couverture analogues a ceux de DO-178C mais adaptes au RTL :

Couverture RTL	DAL A	DAL B	DAL C
Statement coverage (chaque instruction RTL est exercée)	Oui	Oui	Oui
Branch coverage (chaque branche if/case est prise dans les deux directions)	Oui	Oui	Conseille
Condition coverage (chaque condition booléenne prend les deux valeurs)	Oui	Oui	Optionnel
MC/DC équivalent (chaque condition d'une décision influence indépendamment le résultat)	Oui (au DAL A)	Optionnel	Non
Toggle coverage (chaque bit de signal a transitionne 0 vers 1 et 1 vers 0)	Oui	Oui	Conseille
FSM coverage (chaque état et chaque transition d'une machine d'états est atteint)	Oui	Oui	Oui

Ces critères sont généralement atteints en simulation avec un outil de couverture qualifiable (Mentor Questa, Cadence Xcelium, Synopsys VCS dans leurs versions instrumentées). La qualification de l'outil de couverture est elle-même un sous-projet DO-330-like adapte au matériel.

DO-160 : un compagnon de DO-254 souvent confondu

Une confusion frequente concerne DO-160 "Environmental Conditions and Test Procedures for Airborne Equipment". DO-160 n'est ni DO-178C ni DO-254 : il specifie les essais d'environnement (température, altitude, vibration, choc, humidité, CEM, foudre, ESD) que doit subir un équipement avionique. DO-160 est applicable a tout équipement, quel que soit son DAL, et produit un dossier d'essai d'environnement, pas un dossier d'assurance process. DO-254 et DO-160 sont complémentaires : DO-254 traite l'assurance de conception, DO-160 traite la qualification environnementale du matériel realise.

Certification liaison : l'interlocuteur autorité

DO-178C et DO-254 prévoient un process formel de certification liaison entre le fournisseur et l'autorité. Les jalons typiques sont les Stage of Involvement (SOI) :

• SOI 1 : revue des plans (PSAC, SDP, SVP, SCMP, SQAP) en début de programme,
• SOI 2 : revue des standards et de la phase de développement initiale,
• SOI 3 : revue de la verification (couverture, résultats d'essais, traceabilite),
• SOI 4 : revue finale, conditionnant la délivrance du certificat.

Cote FAA, le dialogue passe par le Aircraft Certification Office (ACO), avec parfois délégation a un Designated Engineering Representative (DER). Cote EASA, le dialogue passe par les inspecteurs EASA ou une autorité nationale agissant sous mandate, et le fournisseur opere généralement sous agrément Part 21J (design) et Part 21G (production).

Le PSAC (logiciel) et son équivalent PHAC (Plan for Hardware Aspects of Certification, matériel) encadrent contractuellement cette liaison. Leur révision est traitée comme une renégociation de la base de certification.

Reutilisation : PDS et Service Experience

DO-178C reconnaît la réutilisation d'artefacts logiciels déjà developpes. Le Previously Developed Software (PDS) designe un logiciel déjà certifie sur un programme antérieur (bibliothèque de calcul, RTOS certifie, pile ARINC). Sa réutilisation demande de démontrer trois points : la portée d'usage antérieure couvre l'usage cible, la documentation amont est disponible, et l'environnement d'exécution est équivalent ou les écarts sont justifies. En pratique cela cible les RTOS comme VxWorks 653, INTEGRITY-178, PikeOS, ou les piles ARINC 653.

Le Service Experience designe l'usage de l'historique d'exploitation pour ancrer une partie de l'assurance. La voie est restrictive : historique de vol significatif, traçable a la version exacte, et documente sur les incidents. En pratique, Service Experience est rarement la voie principale, plus souvent un complément.

DO-254 propose une voie équivalente cote matériel via la Service Experience appliquée aux COTS : un composant avec un historique de service avionique long peut être accepte plus facilement qu'un composant nouveau équivalent, mais le poids accorde a cet historique reste a l'appréciation de l'autorité.

Logiciel et matériel a l'intégration : cohérence des bases

La cohérence entre la démonstration logicielle DO-178C et la démonstration matérielle DO-254 ne se construit pas a l'intégration, elle se construit en amont via ARP4754A. Plusieurs sujets transverses sont a soigner spécifiquement :

• Allocation des DAL : si un item logiciel et un item matériel collaborent a une même fonction critique, leurs DAL peuvent être identiques (cas simple) ou differencies si l'architecture le justifie. Par exemple, deux canaux dissemblables developpes l'un en logiciel DAL B et l'autre en matériel DAL B peuvent collectivement implémenter une fonction DAL A si la dissimilarité est démontrée au sens d'ARP4754A.
• Partitionnement : la séparation entre items logiciels de DAL différents sur une même plate-forme (RTOS partitionne ARINC 653, hyperviseur certifie) doit être démontrée par le RTOS ou l'hyperviseur, qui sont eux-memes des PDS ou des items developpes au DAL le plus eleve des partitions qu'ils contiennent.
• Hardware/Software Interface (HSI) : l'interface entre le matériel et le logiciel est un document spécifique souvent neglige. Il fixe la cartographie mémoire, les registres, les interruptions, les séquences de configuration. Une HSI documentée de maniere stable est une condition préalable a la verification logicielle sur cible.
• Verification croisée : certaines exigences système sont satisfaites par une combinaison logiciel + matériel (par exemple, un timeout en logiciel adosse a un watchdog en matériel). Leur verification croisée doit être planifiée au PSAC et au PHAC.

Voir aussi

• DO-326A et ED-202A: cybersécurité avionique
• MIL-STD-461 et MIL-STD-464, normes CEM défense
• AEC-Q100, Q101, Q200 : composants automobiles
• IATF 16949 : management de la qualité automobile

Un cas concret de le cadrage normatif d'un projet a forte exigence d'assurance (lecture transverse ARP4754A / DO-178C / DO-254) ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Articulation avec les autres standards d'assurance

DO-178C et DO-254 ne sont pas les seuls cadres d'assurance logicielle et matérielle. Les autres grands domaines reglementes utilisent des cadres voisins, parfois fortement inspires mais juridiquement indépendants :

• l'automobile applique ISO 26262, avec des Automotive Safety Integrity Levels ASIL A a D et un cycle V documentaire proche de DO-178C dans l'esprit ;
• l'industrie générale et le ferroviaire appliquent IEC 61508 et ses normes dérivées (IEC 61511 process, EN 50128 logiciel ferroviaire, EN 50129 systèmes ferroviaires), avec des Safety Integrity Levels SIL 1 a 4 ;
• le medical applique IEC 62304 pour le logiciel et la combinaison IEC 60601-1 + ISO 14971 pour le matériel, sur une logique de classes de sécurité logicielle (Class A/B/C) et de risque clinique.

Ces standards partagent une grammaire commune : séparation planning / development / verification, traceabilite exigences-design-code-test, configuration management, qualification des outils, niveaux d'assurance gradues. Ils ne sont néanmoins pas substituables : DO-178C n'a aucune valeur réglementaire en automobile, ISO 26262 n'a aucune valeur réglementaire en avionique. Le mapping entre niveaux (DAL, ASIL, SIL) est l'objet d'une littérature abondante mais n'est jamais reconnu de maniere formelle par les autorités.

Submission FAA et submission EASA

Sur le fond, FAA et EASA reconnaissent DO-178C/DO-254 de maniere équivalente. Sur la forme, plusieurs nuances méritent d'être relevées pour un programme dual.

Aspect	FAA	EASA
Texte réglementaire	FAR Parts 23/25/27/29	CS-23/25/27/29
Acceptance logiciel	AC 20-115D	AMC 20-115
Acceptance matériel	AC 20-152A (révisée)	Position EASA équivalente
Reference adoptée	DO-178C / DO-254 (RTCA)	ED-12C / ED-80 (EUROCAE)
Instruction technique	ACO + DER éventuel	EASA ou autorité nationale agréée
Organisation fournisseur	TSO/PMA pour certaines productions	Part 21J (design) + Part 21G (production) usuels
Reconnaissance mutuelle	BASA US-UE, procédures exécutives FAA-EASA	idem cote européen

En pratique, le PSAC d'un programme dual est unifie : il declare une seule stratégie de conformité DO-178C soumise simultanément aux deux autorités, en s'appuyant sur les accords BASA. Les divergences portent sur les jalons d'instruction (SOI) et sur la documentation administrative.

Pieges classiques observes en programme

Plusieurs écueils reviennent régulièrement dans les retours d'expérience publics.

• Demarrage tardif : invocation de DO-178C/DO-254 apres l'intégration, sans documentation amont produite en temps reel. La reconstitution a posteriori est coûteuse, et certains objectifs (revue par indépendance) sont impossibles a démontrer retroactivement.
• DAL allocate sans safety assessment : choix d'un DAL par hypothèse, sans FHA/PSSA documente sous ARP4761. L'allocation devient indéfendable au SOI 1.
• Confusion DO-178C / DO-254 / DO-160 : application de DO-160 en pensant satisfaire DO-254, ou inversement. Les trois sont complémentaires, non substituables.
• Outils non qualifies : utilisation d'un outil de génération, couverture ou analyse statique sans demarche DO-330. Si l'outil "elimine, réduit ou automatise" une activité de verification, sa qualification est requise.
• Traceabilite cassée : ruptures entre exigences système, HLR, LLR, code et tests. Le SOI 3 echoue si la chaine de traceabilite n'est pas exhaustive et bidirectionnelle.
• MC/DC mal compris au DAL A : confusion entre couverture de décision et MC/DC. Une couverture décisionnelle a 100% ne demontre pas MC/DC.
• Confusion COTS / CEH / Appendix B : un FPGA achete pre-programme ne devient pas COTS s'il a une configuration spécifique. Inversement, un FPGA très simple peut sortir de l'Appendix B sur justification documentée.
• PSAC fige trop tot : un PSAC écrit avant clarification de l'architecture oblige a renégocier la base de certification. Inversement, un PSAC retarde sature le SOI 1.

Pour aller plus loin

Cette page expose le cadre général DO-178C/DO-254. Pour la lecture transverse avec les autres référentiels d'assurance, voir ISO 26262 (automobile) et IEC 61508 (industrie générale). Pour le glossaire complet (DAL, FHA, PSSA, PSAC, PHAC, SOI, DER, CEH, MC/DC), consulter le glossaire.

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Sources & références

1. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification , RTCA www.rtca.org/
2. RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware , RTCA www.rtca.org/
3. EUROCAE ED-12C / ED-80 (european counterparts of DO-178C / DO-254) , EUROCAE www.eurocae.net/
4. FAA Advisory Circular AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178 , FAA www.faa.gov/regulations_policies/advisory_circulars
5. EASA AMC 20-115, Software Aspects of Certification , EASA www.easa.europa.eu/en/document-library/general-publications/easy-access-rules-acceptable-means-compliance-and-guidance
6. SAE ARP4754A, Guidelines for Development of Civil Aircraft and Systems , SAE International www.sae.org/standards/content/arp4754a/
7. SAE ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment , SAE International www.sae.org/standards/content/arp4761/