DO-178C et DO-254 : logiciel + materiel avionique

Auteur Hugues Orgitello Mis à jour le 27 mai 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 demontrer l'aptitude au vol du logiciel et du materiel electronique embarques dans un aeronef 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 regulateurs pour traiter respectivement le logiciel airborne et le materiel electronique airborne dans le cadre des Federal Aviation Regulations (FAR Parts 23, 25, 27, 29) et des Certification Specifications europeennes equivalentes (CS-23, CS-25, CS-27, CS-29). Cette page expose l'architecture des deux documents, leur articulation avec les processus systeme SAE ARP4754A et SAE ARP4761, les Design Assurance Levels et leur mapping aux conditions de defaillance, les supplements DO-330/DO-331/DO-332/DO-333, et les pieges observes en pratique.

Une famille de documents process, pas un reglement

Ni DO-178C ni DO-254 ne sont des reglements. Ce sont des documents techniques publies par RTCA, organisme prive de standardisation aeronautique americain, repris en Europe par EUROCAE sous les references ED-12C et ED-80. Leur valeur reglementaire vient de leur acceptation explicite par les autorites 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'edition EUROCAE de DO-178C) comme Means of Compliance pour les CS-23/25/27/29 ;
• pour le materiel electronique, l'AC FAA AC 20-152A (revisee) et la position EASA correspondante referencent DO-254/ED-80.

Cette mecanique d'acceptation explique une caracteristique souvent mal comprise du domaine aeronautique : un projet ne "certifie" pas un logiciel ou un materiel isolement, il integre la demonstration de conformite a DO-178C ou DO-254 dans la base de certification negociee avec l'autorite pour le type aeronef ou pour l'equipement (par exemple via un TSO/ETSO). La conformite a DO-178C est un moyen de conformite parmi d'autres possibles, meme si en pratique aucune autre voie n'est utilisee a l'echelle.

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

ARP4754A et ARP4761 : le cadre systeme qui enveloppe DO-178C et DO-254

DO-178C et DO-254 ne traitent jamais d'un systeme dans son ensemble. Ils traitent d'un item logiciel (DO-178C) ou d'un item materiel electronique (DO-254) deja decoupe par le processus systeme. Ce decoupage est le travail de deux documents SAE :

• ARP4754A "Guidelines for Development of Civil Aircraft and Systems" definit le processus de developpement avion et systeme. Il decrit la decomposition fonctionnelle, l'allocation aux items, la verification et la validation a l'echelle systeme, la gestion des exigences et le suivi des Design Assurance Levels. Il est lui-meme 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" definit les methodes d'evaluation de la securite : 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'enchainement 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 decision du concepteur logiciel ou materiel : elle decoule directement du FHA et du PSSA conduits sous ARP4761, qui partent de la severite des conditions de defaillance a l'echelle systeme et avion, et qui les propagent jusqu'aux items en tenant compte de l'architecture (partitionnement, redondance, dissimilarite, monitoring).

Mapping DAL et condition de defaillance

Le mapping entre la severite d'une condition de defaillance 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 materiel allocates a une meme fonction critique sont developpes au meme DAL.

DAL	Condition de defaillance	Description (FAR/CS 25.1309)	Probabilite max par heure de vol
A	Catastrophic	Empeche la poursuite du vol et de l'atterrissage en securite ; perte multiple de vies	< 1E-9
B	Hazardous / Severe Major	Reduit la capacite de l'equipage a conduire le vol, blessures graves possibles, charge de travail extreme	< 1E-7
C	Major	Reduction significative des marges de securite ou de la capacite de l'equipage, inconfort pour les occupants	< 1E-5
D	Minor	Legere reduction des marges de securite, charge de travail accrue mais gerable, gene mineure	< 1E-3
E	No Safety Effect	Aucun effet sur la securite du vol ni sur la charge de travail de l'equipage	sans contrainte

La probabilite est definie au niveau systeme par CS-25.1309 / AC 25.1309-1A (et equivalents pour les autres Parts). Elle ne s'applique pas mecaniquement a un item logiciel pris isolement, mais a la condition de defaillance qui resulte de la combinaison d'items. Le DAL d'un item, lui, traduit l'effort d'assurance attendu sur le process de developpement, pas une probabilite directement quantifiable pour un logiciel (le logiciel n'a pas de "taux de defaillance" au sens statistique du materiel).

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 caractere 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 debut de programme et soumis a l'autorite pour acceptation.
• Development : exigences logicielles haut niveau (High-Level Requirements, HLR), exigences logicielles bas niveau (Low-Level Requirements, LLR), architecture logicielle, code source, code executable.
• Integral processes : verification, configuration management, software quality assurance, certification liaison. Ces process se deroulent en parallele du developpement 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 independance entre la personne qui produit un artefact et la personne qui le verifie. Le passage aux DAL inferieurs joue sur deux leviers :

1. certains objectifs disparaissent (un objectif applicable au DAL A peut etre marque "not applicable" au DAL C ou D),
2. certains objectifs perdent l'exigence d'independance, ce qui n'est pas le meme allegement mais reduit le cout d'organisation.

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

DAL	Effort d'assurance attendu
A	Tous les objectifs applicables, independance maximale, couverture de code Modified Condition/Decision Coverage (MC/DC) requise sur le code executable
B	Sous-ensemble eleve, independance pour la majorite des objectifs, couverture Decision Coverage requise
C	Sous-ensemble reduit, independance moindre, couverture Statement Coverage requise
D	Sous-ensemble minimal, peu d'exigence d'independance, verification orientee exigences
E	Aucune activite DO-178C requise (l'item est traite hors-DO-178C avec justification d'absence d'impact securite)

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 booleenne d'une decision ait pu independamment influencer le resultat de la decision. Pour un code embarque non trivial, cela demande des bancs de test specifiquement instrumentes et une couverture analytique souvent automatisee.

Independance : un levier souvent sous-estime

La notion d'independance est l'un des concepts les plus structurants de DO-178C. Independance ne signifie pas "double verification" mais separation organisationnelle : la personne qui produit un artefact (par exemple les Low-Level Requirements) ne peut pas etre la meme que celle qui le verifie. La separation peut etre organisationnelle (deux personnes distinctes, equipes distinctes) ou outillee (un outil de verification automatise dont la qualification DO-330 garantit l'objectivite).

L'independance est exigee au DAL A sur la majorite des objectifs de verification, allegee au DAL B (independance sur une partie reduite), et generalement 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 developpement, ce qui pour les programmes de taille moyenne represente un cout significatif souvent sous-estime en debut de programme.

Criteres de couverture par DAL

Les criteres de couverture exiges varient avec le DAL et constituent l'une des differences de cout les plus visibles entre niveaux. Trois criteres se cumulent en pratique : la couverture des exigences (chaque exigence est demontree par au moins un cas de test), la couverture structurelle du code, et l'analyse de couverture des donnees et du controle.

DAL	Couverture exigences	Couverture structurelle	Coverage Analysis
A	100% HLR + 100% LLR	Modified Condition/Decision Coverage (MC/DC) sur le code executable, 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 exigee	Non specifie
E	Non applicable	Non applicable	Non applicable

L'analyse de Data Coupling verifie que toute donnee echangee entre composants est exercee 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 maitre, soumis a l'autorite, qui declare la strategie de conformite, le DAL retenu, les supplements applicables (DO-330/331/332/333), les ecarts eventuels
Software Development Plan	SDP	Decrit le cycle de developpement adopte (cascade, iteratif, etc.), les phases, les revues, les responsabilites
Software Verification Plan	SVP	Decrit la strategie 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 independance, son plan d'audits
Software Requirements / Design / Code Standards	(standards)	Trois standards distincts qui codifient les regles de redaction et de relecture
Software Requirements Data	HLR	Exigences logicielles haut niveau, derivees des exigences systeme
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 etre 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'autorite, qui recapitule la demonstration de conformite

La liste reelle peut etre 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 supplements de DO-178C

DO-178C a ete publie en 2011 simultanement avec quatre supplements, qui n'ont pas vocation a etre lus seuls : ils ne s'invoquent qu'en complement de DO-178C, et chacun cible un mode de developpement ou une technologie particuliere.

Supplement	Sujet	Objet
DO-330	Software Tool Qualification Considerations	Definit les criteres et le processus de qualification des outils logiciels utilises dans le cycle (compilateurs verifies, generateurs 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 developpement 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 exprimees sous forme de modeles formels (par exemple en SCADE, Simulink/Stateflow) et lorsque la generation de code est automatisee
DO-332	Object-Oriented Technology and Related Techniques Supplement	Ajoute des objectifs lorsque le code utilise des techniques orientees objet (heritage, polymorphisme, allocation dynamique, exceptions) et des techniques apparentees (genericite, virtualisation) qui posent des questions de tracabilite et de verification non couvertes par DO-178C standard
DO-333	Formal Methods Supplement	Etend les objectifs de DO-178C lorsque des methodes formelles (preuve, model checking, interpretation abstraite) sont utilisees pour atteindre tout ou partie des objectifs de verification, en remplacement ou en complement des essais

Un projet typique applique DO-178C seul. Un projet model-based applique DO-178C + DO-331 + DO-330 (les outils de generation et de verification etant generalement qualifies). Un projet C++ applique DO-178C + DO-332. Un projet a forte criticite recourant a la preuve formelle peut combiner DO-178C + DO-333 + DO-330.

Tool Qualification Levels TQL-1 a TQL-5

DO-330 definit cinq Tool Qualification Levels, depuis TQL-5 (effort minimal) jusqu'a TQL-1 (effort comparable au developpement d'un logiciel DAL A). Le niveau s'obtient par croisement de deux dimensions : la categorie 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 : generateur de code automatique). Erreur de l'outil = erreur potentielle dans le binaire embarque	TQL-1
Criteria 2	L'outil automatise une activite de verification ET selectionne les artefacts a verifier (typiquement : un test bench automatise qui choisit les cas et evalue les resultats sans verification humaine intermediaire)	TQL-4
Criteria 3	L'outil automatise une activite de verification sans selectionner les artefacts (typiquement : un compteur de couverture, un analyseur statique en pretraitement, un outil de comparaison binaire)	TQL-5

Aux DAL inferieurs, le TQL exigible decroit. 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-meme.

DO-331 et la generation de code certifiable

DO-331 traite trois categories de modeles : specification (le modele exprime les exigences), design (le modele exprime l'architecture et le comportement), et implementation (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 generateurs qualifiables qui couvrent les objectifs DO-331 et leur qualification DO-330.

L'enjeu cle de DO-331 est l'equivalence modele-code : la traceabilite entre le modele d'origine et le code genere doit etre demontree, et la couverture demandee s'applique selon le cas sur le modele (model coverage) ou sur le code (object code coverage). Le supplement clarifie egalement le statut des elements derives de la modelisation qui n'apparaissent pas dans les exigences amont (par exemple, des etats internes generes automatiquement).

DO-333 et le statut des methodes formelles

DO-333 reconnait trois categories de methodes formelles utilisables pour atteindre les objectifs de verification : la preuve deductive (theorem proving, par exemple avec Coq, SPARK/Ada, Frama-C), le model checking (verification exhaustive d'un modele fini), et l'interpretation abstraite (par exemple avec Astree pour la preuve d'absence d'erreurs d'execution sur du C). Le supplement n'impose pas une methode particuliere, il fixe les conditions sous lesquelles une methode formelle peut se substituer a un essai pour demontrer un objectif.

L'usage des methodes formelles en aeronautique reste minoritaire en volume mais est en croissance sur les fonctions de plus haute criticite. La justification economique apparait lorsque le cout des essais et de leur couverture (typiquement MC/DC au DAL A) depasse le cout de la preuve, ce qui se produit pour des fonctions de petite taille mais de criticite maximale (controle de surfaces de vol primaires, par exemple).

DO-254 : assurance du materiel electronique embarque

DO-254 traite le materiel electronique avec une approche process equivalente a celle de DO-178C, mais adaptee a la specificite du materiel.

Structure generale

Le corps de DO-254 definit un cycle de vie materiel : planification, exigences, conception conceptuelle, conception detaillee, implementation, transition vers la production. Il identifie des process integraux equivalents 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 defaillance), avec la meme 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 considerations supplementaires pour le Complex Electronic Hardware (CEH) : composants dont la complexite 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 eventuellement a certains composants programmables hautement integres.

L'Appendix B etend le cycle de vie materiel de plusieurs maniere :

• verification de la programmation logique (RTL VHDL/Verilog) avec couverture fonctionnelle et structurelle equivalente, dans l'esprit, a la couverture de code logiciel,
• qualification des outils de synthese, place-and-route, simulation, generation de bitstream, dans une logique parallele a DO-330 cote logiciel,
• gestion des donnees de conception (schemas, RTL, contraintes de timing, fichiers de configuration) sous configuration management strict,
• traitement des elements derives (Derived Requirements) avec retour vers le safety assessment ARP4761.

Un composant electronique simple (resistance, capacite, transistor discret, regulateur de tension standard) reste dans le perimetre DO-254 general mais sort de l'Appendix B. Sa qualification repose sur sa specification fabricant, son qualification environmentale (DO-160 pour les essais d'environnement) et sa selection sous criteres de fiabilite.

Composants commerciaux vs CEH developpe en interne

DO-254 distingue deux situations pour le materiel electronique :

• Component Off-The-Shelf (COTS) : composant commercial achete dans le catalogue d'un fournisseur, sans visibilite sur son developpement interne. Le programme avion doit justifier l'usage du composant via sa specification, son historique d'usage en aeronautique (Service Experience), des essais complementaires si necessaires, et le cas echeant une analyse d'erratas du fabricant.
• Custom Electronic Hardware developpe en interne : circuit specifique 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 complexite 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'autorite 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 demontrer que le procede industriel reproduit l'unite verifiee. Pour un FPGA, cela couvre la traceabilite du bitstream, la sequence de programmation, le test de production. Pour un PCB, cela couvre les procedures 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 decomposition fonctionnelle du composant complexe, identifie les blocs internes et leur role dans la fonction declaree,
• Architectural Mitigation : utilisation explicite de redondance, partitionnement, dissimilarite, monitoring pour reduire le DAL effectif d'un sous-bloc. Par exemple, deux blocs DAL B independants peuvent atteindre une fonction DAL A si l'independance et la dissimilarite sont demontrees,
• Design Assurance Methods : verification par simulation fonctionnelle exhaustive (sur un perimetre delimite), revue, prototypage materiel, essais sur cible,
• Service Experience : utilisation d'un historique de service documente pour ancrer une partie de la demonstration d'assurance. Cette voie est restrictive et reservee aux composants ayant un historique de vol significatif et tracable.

Les Design Assurance Methods sont rarement utilisees seules ; un projet typique combine plusieurs techniques avec une justification de couverture argumentee dans le PHAC.

Couverture sur le code RTL

Pour les FPGA et ASIC sous Appendix B, la verification s'appuie sur des criteres 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 exercee)	Oui	Oui	Oui
Branch coverage (chaque branche if/case est prise dans les deux directions)	Oui	Oui	Conseille
Condition coverage (chaque condition booleenne prend les deux valeurs)	Oui	Oui	Optionnel
MC/DC equivalent (chaque condition d'une decision influence independamment le resultat)	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 etat et chaque transition d'une machine d'etats est atteint)	Oui	Oui	Oui

Ces criteres sont generalement atteints en simulation avec un outil de couverture qualifiable (Mentor Questa, Cadence Xcelium, Synopsys VCS dans leurs versions instrumentees). La qualification de l'outil de couverture est elle-meme un sous-projet DO-330-like adapte au materiel.

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 (temperature, altitude, vibration, choc, humidite, CEM, foudre, ESD) que doit subir un equipement avionique. DO-160 est applicable a tout equipement, 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 complementaires : DO-254 traite l'assurance de conception, DO-160 traite la qualification environnementale du materiel realise.

Certification liaison : l'interlocuteur autorite

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

• SOI 1 : revue des plans (PSAC, SDP, SVP, SCMP, SQAP) en debut de programme,
• SOI 2 : revue des standards et de la phase de developpement initiale,
• SOI 3 : revue de la verification (couverture, resultats d'essais, traceabilite),
• SOI 4 : revue finale, conditionnant la delivrance du certificat.

Cote FAA, le dialogue passe par le Aircraft Certification Office (ACO), avec parfois delegation a un Designated Engineering Representative (DER). Cote EASA, le dialogue passe par les inspecteurs EASA ou une autorite nationale agissant sous mandate, et le fournisseur opere generalement sous agrement Part 21J (design) et Part 21G (production).

Le PSAC (logiciel) et son equivalent PHAC (Plan for Hardware Aspects of Certification, materiel) encadrent contractuellement cette liaison. Leur revision est traitee comme une renegociation de la base de certification.

Reutilisation : PDS et Service Experience

DO-178C reconnait la reutilisation d'artefacts logiciels deja developpes. Le Previously Developed Software (PDS) designe un logiciel deja certifie sur un programme anterieur (bibliotheque de calcul, RTOS certifie, pile ARINC). Sa reutilisation demande de demontrer trois points : la portee d'usage anterieure couvre l'usage cible, la documentation amont est disponible, et l'environnement d'execution est equivalent ou les ecarts 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, tracable a la version exacte, et documente sur les incidents. En pratique, Service Experience est rarement la voie principale, plus souvent un complement.

DO-254 propose une voie equivalente cote materiel via la Service Experience appliquee aux COTS : un composant avec un historique de service avionique long peut etre accepte plus facilement qu'un composant nouveau equivalent, mais le poids accorde a cet historique reste a l'appreciation de l'autorite.

Logiciel et materiel a l'integration : coherence des bases

La coherence entre la demonstration logicielle DO-178C et la demonstration materielle DO-254 ne se construit pas a l'integration, elle se construit en amont via ARP4754A. Plusieurs sujets transverses sont a soigner specifiquement :

• Allocation des DAL : si un item logiciel et un item materiel collaborent a une meme fonction critique, leurs DAL peuvent etre 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 materiel DAL B peuvent collectivement implementer une fonction DAL A si la dissimilarite est demontree au sens d'ARP4754A.
• Partitionnement : la separation entre items logiciels de DAL differents sur une meme plate-forme (RTOS partitionne ARINC 653, hyperviseur certifie) doit etre demontree 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 materiel et le logiciel est un document specifique souvent neglige. Il fixe la cartographie memoire, les registres, les interruptions, les sequences de configuration. Une HSI documentee de maniere stable est une condition prealable a la verification logicielle sur cible.
• Verification croisee : certaines exigences systeme sont satisfaites par une combinaison logiciel + materiel (par exemple, un timeout en logiciel adosse a un watchdog en materiel). Leur verification croisee doit etre planifiee au PSAC et au PHAC.

Voir aussi

• DO-326A et ED-202A: cybersecurite avionique
• MIL-STD-461 et MIL-STD-464, normes CEM defense
• AEC-Q100, Q101, Q200 : composants automobiles
• IATF 16949 : management de la qualite 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 materielle. Les autres grands domaines reglementes utilisent des cadres voisins, parfois fortement inspires mais juridiquement independants :

• 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 generale et le ferroviaire appliquent IEC 61508 et ses normes derivees (IEC 61511 process, EN 50128 logiciel ferroviaire, EN 50129 systemes 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 materiel, sur une logique de classes de securite logicielle (Class A/B/C) et de risque clinique.

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

Submission FAA et submission EASA

Sur le fond, FAA et EASA reconnaissent DO-178C/DO-254 de maniere equivalente. Sur la forme, plusieurs nuances meritent d'etre relevees pour un programme dual.

Aspect	FAA	EASA
Texte reglementaire	FAR Parts 23/25/27/29	CS-23/25/27/29
Acceptance logiciel	AC 20-115D	AMC 20-115
Acceptance materiel	AC 20-152A (revisee)	Position EASA equivalente
Reference adoptee	DO-178C / DO-254 (RTCA)	ED-12C / ED-80 (EUROCAE)
Instruction technique	ACO + DER eventuel	EASA ou autorite nationale agreee
Organisation fournisseur	TSO/PMA pour certaines productions	Part 21J (design) + Part 21G (production) usuels
Reconnaissance mutuelle	BASA US-UE, procedures executives FAA-EASA	idem cote europeen

En pratique, le PSAC d'un programme dual est unifie : il declare une seule strategie de conformite DO-178C soumise simultanement aux deux autorites, 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 ecueils reviennent regulierement dans les retours d'experience publics.

• Demarrage tardif : invocation de DO-178C/DO-254 apres l'integration, sans documentation amont produite en temps reel. La reconstitution a posteriori est couteuse, et certains objectifs (revue par independance) sont impossibles a demontrer retroactivement.
• DAL allocate sans safety assessment : choix d'un DAL par hypothese, sans FHA/PSSA documente sous ARP4761. L'allocation devient indefendable au SOI 1.
• Confusion DO-178C / DO-254 / DO-160 : application de DO-160 en pensant satisfaire DO-254, ou inversement. Les trois sont complementaires, non substituables.
• Outils non qualifies : utilisation d'un outil de generation, couverture ou analyse statique sans demarche DO-330. Si l'outil "elimine, reduit ou automatise" une activite de verification, sa qualification est requise.
• Traceabilite cassee : ruptures entre exigences systeme, 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 decision et MC/DC. Une couverture decisionnelle 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 specifique. Inversement, un FPGA tres simple peut sortir de l'Appendix B sur justification documentee.
• PSAC fige trop tot : un PSAC ecrit avant clarification de l'architecture oblige a renegocier la base de certification. Inversement, un PSAC retarde sature le SOI 1.

Pour aller plus loin

Cette page expose le cadre general DO-178C/DO-254. Pour la lecture transverse avec les autres referentiels d'assurance, voir ISO 26262 (automobile) et IEC 61508 (industrie generale). 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/