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

Hugues Orgitello mis à jour le 7 oct. 2026 14 min de lecture

DO-178C n'a pas changé depuis 2011, ni DO-254 depuis 2000, mais les textes qui les encadrent ont été réécrits en quatre ans. La FAA a remplacé sa circulaire matérielle de 2005 par l'AC 20-152A en octobre 2022, une réécriture complète qui fixe des objectifs pour les FPGA, les ASIC, les composants du commerce et les cartes, et sort le DAL D de son champ. Les processeurs multicœurs sont passés du position paper CAST-32A à l'AMC 20-193 (EASA, 2022) et à l'AC 20-193 (FAA, 2024). Et la SAE a remplacé ARP4754A et ARP4761 par ARP4754B et ARP4761A en décembre 2023. Ce guide expose ce que DO-178C et DO-254 exigent réellement, avec le nombre d'objectifs, les règles de couverture et les objectifs matériels de 2022, et corrige plusieurs lectures très répandues, dont celle qui range les FPGA dans l'Appendix B de DO-254.

En bref : DO-178C (logiciel) et DO-254 (matériel) sont des moyens de conformité reconnus par les AC/AMC 20-115D et AC/AMC 20-152A. Les niveaux A à E viennent de l'évaluation de sécurité système (ARP4754B, ARP4761A). DO-178C compte 71 objectifs au niveau A, 69 au B, 62 au C, 26 au D. La MC/DC n'est exigée qu'au niveau A, la couverture des décisions commence au B, celle des instructions au C. Pour le matériel, l'AC 20-152A couvre les DAL A à C, classe les composants spécifiques en simples ou complexes, et accepte la couverture du code HDL comme moyen de réaliser l'analyse élémentaire de l'Appendix B, qui vise les niveaux A et B, pas les FPGA en tant que tels.

Les documents et leurs évolutions

Document	Rôle	Édition en vigueur	Reconnu par
DO-178C / ED-12C	Assurance du développement logiciel	Décembre 2011, avec les suppléments DO-330 à DO-333	FAA AC 20-115D ; EASA AMC 20-115D
DO-254 / ED-80	Assurance de conception du matériel électronique embarqué	Avril 2000	FAA AC 20-152A (7 octobre 2022, abroge l'AC 20-152 du 30 juin 2005) ; EASA AMC 20-152A (décision ED 2020/010/R)
AC 20-193 / AMC 20-193	Processeurs multicœurs	EASA janvier 2022 ; FAA 8 janvier 2024	Remplacent le position paper CAST-32A
ARP4754B / ED-79B	Développement avion et système, attribution des niveaux	20 décembre 2023	Succède à ARP4754A
ARP4761A / ED-135	Processus d'évaluation de la sécurité (FHA, PSSA, SSA)	Décembre 2023	Succède à ARP4761
DO-160	Conditions d'essais d'environnement	Document distinct	Qualification d'environnement, pas assurance de conception

L'historique de la famille explique un vocabulaire encore en usage : DO-178 (1982), DO-178A (1985), DO-178B (1992), DO-178C (2011). Les niveaux logiciels et les tableaux d'objectifs de l'annexe A viennent de DO-178B ; DO-178C les a clarifiés et a déplacé les outils, les modèles, l'orienté objet et les méthodes formelles dans des suppléments.

Aucun de ces documents n'est un règlement. Ce sont des moyens de conformité : les règlements sont les codes de navigabilité (14 CFR parties 23, 25, 27, 29 et 33, CS-23, CS-25, etc.) et les exigences TSO ou ETSO, et un programme démontre sa conformité par les plans qu'il convient avec l'autorité.

Niveaux et conditions de défaillance

Niveau	Condition de défaillance	Objectif quantitatif usuel pour les grands avions (AMC 25.1309)
A	Catastrophique	Extrêmement improbable, 1E-9 par heure de vol
B	Dangereuse	Extrêmement peu probable, 1E-7 par heure de vol
C	Majeure	Peu probable, 1E-5 par heure de vol
D	Mineure	Pas d'exigence quantitative (peut être probable)
E	Sans effet sur la sécurité	Aucun

Les probabilités s'appliquent aux conditions de défaillance au niveau système, pas à un élément logiciel : un logiciel n'a pas de taux de défaillance. Le niveau d'un élément traduit la rigueur de son processus de développement, et il est attribué par le processus système d'ARP4754B avec l'évaluation de sécurité d'ARP4761A, en tenant compte de l'architecture (partitionnement, indépendance, dissimilarité). Dans ARP4754B, le détail de l'articulation entre évaluation de sécurité et attribution des niveaux est passé dans ARP4761A ; les principes généraux des niveaux d'assurance de développement des fonctions et des éléments sont restés.

Pour le cadrage système des méthodes d'analyse des dangers et des risques, voir gestion des risques, ISO 14971 et IEC 31010.

DO-178C : objectifs par niveau

Niveau	Objectifs	Avec indépendance	Couverture structurelle	Autres exigences notables
A	71	30	MC/DC, décisions et instructions	Vérification du code objet non directement traçable au code source
B	69	18	Décisions et instructions
C	62	5	Instructions
D	26	2	Aucune	Vérification par rapport aux exigences de haut niveau seulement
E	0	0	Aucune

Les objectifs figurent dans les dix tableaux de l'annexe A (A-1 planification à A-10 liaison de certification). L'analyse du couplage de données et du couplage de contrôle est exigée aux niveaux A, B et C. L'« indépendance » signifie que la personne qui vérifie un artefact n'est pas celle qui l'a produit, ou qu'un outil qualifié réalise la vérification.

La MC/DC (couverture modifiée des conditions et des décisions) exige de montrer que chaque condition d'une décision influe de façon indépendante sur son résultat. Une couverture des décisions à 100 % n'implique pas la MC/DC : une décision a && b atteint ses deux résultats avec deux tests, mais la MC/DC en demande trois.

Données du cycle de vie

Donnée	Rôle
PSAC, Plan for Software Aspects of Certification	Convenu avec l'autorité : niveaux, cycle de vie, suppléments, outils, méthodes alternatives
SDP, SVP, SCMP, SQAP	Plans de développement, de vérification, de gestion de configuration et d'assurance qualité
Standards d'exigences, de conception et de code	Règles que le développement doit suivre, vérifiées en revue
Exigences de haut et de bas niveau, architecture	Sorties du développement, tracées dans les deux sens
Code source et code objet exécutable	Produits par un environnement sous gestion de configuration
Cas, procédures et résultats de vérification	Y compris l'analyse de couverture
SCI et SECI	Index de configuration du logiciel et de l'environnement du cycle de vie
SAS, Software Accomplishment Summary	Clôt la démonstration et liste les écarts et les rapports de problèmes ouverts

Tool Qualification Levels TQL-1 à TQL-5

DO-330 définit cinq Tool Qualification Levels, depuis TQL-5 (effort minimal) jusqu'à 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.

Catégorie 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 un processus de vérification ET sa sortie sert à justifier la suppression ou la réduction d'un processus de vérification autre que celui qu'il automatise, ou d'un processus de développement susceptible d'affecter le logiciel embarqué. Le discriminant n'est pas de savoir si l'outil choisit les artefacts à vérifier, mais si l'on renonce à d'autres travaux sur la foi de ce qu'il produit	TQL-4
Criteria 3	L'outil automatise un processus de vérification et pourrait ne pas détecter une erreur, mais rien d'autre n'est supprimé ni réduit sur la foi de sa sortie (typiquement : un compteur de couverture, un analyseur statique passé en contrôle supplémentaire, un outil de comparaison binaire)	TQL-5

Un exemple rend concrète la frontière entre Criteria 2 et Criteria 3. Un analyseur par interprétation abstraite qui prouve l'absence d'erreurs à l'exécution relève de Criteria 2 lorsque c'est sa preuve qui permet au projet d'abandonner les cas de test de robustesse correspondants, et de Criteria 3 lorsque la campagne de test complète est menée malgré tout et que l'analyseur n'est qu'un contrôle supplémentaire. Même outil, même configuration, deux catégories, départagées par ce que le projet cesse de faire à cause de lui.

Deux questions doivent rester distinctes. Savoir si un outil doit être qualifié se tranche par le paragraphe 12.2 de DO-178C au regard des trois critères ci-dessus ; savoir à quel niveau il l'est se tranche séparément. Seul Criteria 1 suit le DAL sur les quatre niveaux. Criteria 2 s'assouplit dès que le logiciel passe sous le niveau B. Criteria 3 reste au plancher, TQL-5, à tous les niveaux de A à D : rien ne décroît pour un outil de couverture sur un programme DAL D, il y est TQL-5 exactement comme au DAL A. TQL-5 est un niveau de qualification à part entière, porteur de ses 14 objectifs propres, et non une dispense : un projet qui ne budgète rien pour ses outils de couverture au DAL D doit malgré tout cette qualification. Passer à TQL-4 ajoute 24 objectifs supplémentaires, et c'est là qu'un outil acheté à un fournisseur commence à contraindre le planning. Le niveau exact de chaque combinaison se lit dans le tableau 12-1 de DO-178C, paragraphe 12.2, qui fait foi. La règle pratique : si l'outil produit du binaire embarqué (Criteria 1), sa qualification est l'effort le plus important du projet après le logiciel lui-même.

DO-331, DO-332 et DO-333

Supplément	Usage	Ce qu'il ajoute
DO-331	Développement et vérification à base de modèles	Objectifs pour les modèles de spécification et de conception, couverture de modèle, simulation comme moyen de vérification
DO-332	Technologie orientée objet	Objectifs pour l'héritage, le polymorphisme, la mémoire dynamique, les exceptions ; cohérence locale des types
DO-333	Méthodes formelles	Conditions dans lesquelles la preuve, le model checking ou l'interprétation abstraite peuvent remplacer ou compléter les tests

Chaque supplément est invoqué depuis le PSAC en complément de DO-178C ; un projet à base de modèles avec générateur de code qualifié combine typiquement DO-178C, DO-331 et DO-330.

DO-254 et l'AC 20-152A

DO-254 définit un cycle de vie matériel (planification, capture des exigences, conception préliminaire, conception détaillée, réalisation, transition vers la production) et des processus de support (validation, vérification, gestion de configuration, assurance du processus, liaison de certification). L'Appendix A module les données du cycle de vie selon le niveau. L'Appendix B ajoute des considérations d'assurance pour les fonctions de niveau A et B : atténuation par l'architecture, expérience en service du produit et méthodes de vérification avancées, dont l'analyse élémentaire.

L'AC 20-152A, publiée le 7 octobre 2022 et reprise par l'AMC 20-152A, a réécrit la façon dont la FAA applique DO-254 :

• Champ : matériel électronique embarqué contribuant à des fonctions de DAL A, B ou C ; au DAL C, seul un ensemble limité d'objectifs s'applique ; pour le DAL D, l'AC n'est pas requise et l'AC 00-72 donne les bonnes pratiques.
• Quatre sujets, quatre familles d'objectifs : composants spécifiques (CD), IP du commerce dans les composants spécifiques (IP), composants du commerce (COTS) et cartes électroniques (CBA).
• Composants spécifiques : PLD, FPGA et ASIC, les « custom micro-coded components » de DO-254.
• Simple ou complexe : un composant spécifique n'est simple que si une évaluation technique montre qu'il peut être vérifié de façon exhaustive par des tests et analyses déterministes dans toutes les conditions prévisibles. Les critères incluent le nombre et la simplicité des fonctions et des interfaces, le caractère synchrone ou asynchrone de la conception, le nombre d'horloges, et le nombre de machines à états et d'états. Tout ce qui n'est pas démontré simple est complexe.
• Robustesse : aux DAL A et B, les conditions anormales et limites et le comportement attendu doivent être écrits sous forme d'exigences (objectif CD-8).
• Couverture du code HDL : reconnue comme moyen de réaliser l'analyse élémentaire de l'Appendix B, section 3.3.1, pour les composants numériques, lorsqu'elle est menée pendant la vérification fondée sur les exigences. Le demandeur définit les critères de couverture (branches, conditions, etc.) dans ses plans, et tout cas non couvert doit être analysé et justifié (objectif CD-9).

Ni DO-254 ni l'AC 20-152A ne fixent de tableau de métriques de couverture RTL par niveau : les critères sont posés par le demandeur dans le PHAC et convenus avec l'autorité.

Processeurs multicœurs

L'AMC 20-193 (EASA, janvier 2022) et l'AC 20-193 (FAA, 8 janvier 2024) ont remplacé le position paper CAST-32A pour les processeurs multicœurs. Elles traitent des interférences entre cœurs via les ressources partagées, du temps d'exécution et de l'usage des ressources au pire cas, et des éléments de planification et de vérification attendus. Elles s'appliquent au logiciel exécuté sur la plateforme multicœur et sont généralement référencées depuis le PSAC.

Liaison de certification

L'autorité examine les travaux lors des étapes d'implication (SOI) : planification (SOI 1), développement (SOI 2), vérification (SOI 3) et finale (SOI 4). Le PSAC et le PHAC sont les accords qui encadrent ces revues ; les modifier revient à renégocier. Côté FAA, des représentants techniques désignés (DER) conduisent souvent les revues ; côté EASA, l'EASA ou une autorité nationale examine les travaux, et le demandeur détient normalement un agrément d'organisme de conception (Part 21, sous-partie J).

Réutilisation : PDS et Service Experience

DO-178C reconnaît la réutilisation d'artefacts logiciels déjà développés. Le Previously Developed Software (PDS) désigne 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 désigne l'usage de l'historique d'exploitation pour ancrer une partie de l'assurance. La voie est restrictive : historique de vol significatif, traçable à la version exacte, et documenté 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 accordé à cet historique reste à l'appréciation de l'autorité.

Logiciel et matériel à 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 à l'intégration, elle se construit en amont via ARP4754A. Plusieurs sujets transverses sont à soigner spécifiquement :

• Allocation des DAL : si un item logiciel et un item matériel collaborent à une même fonction critique, leurs DAL peuvent être identiques (cas simple) ou différenciés si l'architecture le justifie. Par exemple, deux canaux dissemblables développés 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'ARP4754B.
• 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-mêmes des PDS ou des items développés au DAL le plus élevé des partitions qu'ils contiennent.
• Hardware/Software Interface (HSI) : l'interface entre le matériel et le logiciel est un document spécifique souvent négligé. Il fixe la cartographie mémoire, les registres, les interruptions, les séquences de configuration. Une HSI documentée de manière stable est une condition préalable à la vérification logicielle sur cible.
• Vérification croisée : certaines exigences système sont satisfaites par une combinaison logiciel + matériel (par exemple, un timeout en logiciel adossé à un watchdog en matériel). Leur vérification croisée doit être planifiée au PSAC et au PHAC.

Lectures que les textes ne confirment pas

Lecture courante	Ce que dit le texte
« L'Appendix B de DO-254 est l'annexe des FPGA et ASIC »	L'Appendix B vise l'assurance supplémentaire des fonctions de niveau A et B ; les FPGA et ASIC sont des custom micro-coded components (section 1.2), détaillés dans l'AC/AMC 20-152A
« DO-254 exige une couverture équivalente MC/DC sur le RTL au DAL A »	Pas de métrique RTL fixe : la couverture du code HDL est un moyen reconnu de faire l'analyse élémentaire, avec des critères définis par le demandeur
« DO-254 s'applique jusqu'au DAL D »	L'AC 20-152A couvre les DAL A à C et précise qu'elle n'est pas requise pour le DAL D
« Les conditions mineures sont limitées à 1E-3 par heure »	L'AMC 25.1309 ne fixe pas d'exigence quantitative pour les conditions mineures
« Couplage de données et de contrôle au seul niveau module pour le niveau C »	L'analyse du couplage est un objectif des niveaux A, B et C sans cette restriction
« ARP4754A et ARP4761 sont en vigueur »	Remplacés par ARP4754B et ARP4761A en décembre 2023
« CAST-32A régit le multicœur »	AMC 20-193 (2022) et AC 20-193 (2024)

DO-160 : le compagnon souvent confondu

DO-160 (Environmental Conditions and Test Procedures for Airborne Equipment) définit des essais d'environnement : température, altitude, vibrations, humidité, alimentation, CEM, foudre et décharges électrostatiques. Il produit des rapports d'essai de l'équipement, pas une assurance de conception. Un programme DO-254 a toujours besoin d'une qualification DO-160 du matériel, et un rapport DO-160 ne dit rien de DO-254.

FAA et EASA côte à côte

Aspect	FAA	EASA
Codes de navigabilité	14 CFR parties 23, 25, 27, 29, 33	CS-23, CS-25, CS-27, CS-29, CS-E
Logiciel	AC 20-115D	AMC 20-115D
Matériel	AC 20-152A (2022)	AMC 20-152A (2020)
Multicœur	AC 20-193 (2024)	AMC 20-193 (2022)
Documents référencés	RTCA DO-178C, DO-254	EUROCAE ED-12C, ED-80
Revue	Bureau de certification aéronautique, souvent avec des représentants désignés	EASA ou autorité nationale

L'accord de sécurité de l'aviation civile entre les États-Unis et l'UE et ses procédures techniques permettent à un programme de soumettre un seul jeu de plans aux deux autorités ; les différences portent surtout sur le calendrier des revues et la paperasse.

Pièges fréquents

• Démarrer tard. Plans, standards et traçabilité ne se reconstruisent pas de façon convaincante après coup, et l'indépendance des revues passées ne se crée pas rétroactivement.
• Choisir un niveau sans évaluation de sécurité. Le niveau doit venir du processus ARP4754B et ARP4761A ; un niveau choisi à la seule demande du client tombe en SOI 1.
• Outils non qualifiés. Un générateur de code, un outil de couverture ou un analyseur statique dont la sortie supprime du travail de vérification exige une qualification DO-330 au bon TQL.
• Confondre couverture des décisions et MC/DC.
• Classer un FPGA comme simple sans l'évaluation technique demandée par l'AC 20-152A.
• Ignorer les composants du commerce et les cartes. L'AC 20-152A a ses propres objectifs COTS et CBA ; une carte n'est pas exemptée parce que ses composants sont du commerce.
• Du multicœur sans planification AMC/AC 20-193. L'analyse des interférences et des temps au pire cas doit figurer dans les plans dès le départ.

Référentiels d'assurance voisins

L'automobile applique l'ISO 26262 (ASIL A à D), l'industrie générale et le ferroviaire l'IEC 61508 et ses normes sectorielles, et le logiciel médical l'IEC 62304. Ils partagent planification, traçabilité, vérification et qualification d'outils, mais aucune autorité ne reconnaît de correspondance entre DAL, ASIL et SIL. Pour la cybersécurité avionique, voir DO-326A et ED-202A.

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
• Glossaire

Un cas concret de cadrage transverse d'un programme à forte exigence d'assurance (lecture ARP4754B / DO-178C / DO-254) ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter

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. FAA AC 20-152A, Development Assurance for Airborne Electronic Hardware (7 octobre 2022), FAA www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-152A.pdf
2. EASA AMC 20-152A, Development Assurance for Airborne Electronic Hardware (décision ED 2020/010/R), EASA www.easa.europa.eu/en/document-library/easy-access-rules
3. FAA AC 20-193, Use of Multi-Core Processors (8 janvier 2024), FAA www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-193.pdf
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. RTCA DO-178C et DO-254, RTCA www.rtca.org/
6. EUROCAE ED-12C / ED-80 (équivalents européens de DO-178C / DO-254), EUROCAE www.eurocae.net/
7. SAE ARP4754B, Guidelines for Development of Civil Aircraft and Systems, SAE International www.sae.org/standards/content/arp4754b/
8. SAE ARP4761A, Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment, SAE International www.sae.org/standards/content/arp4761a/
9. DO-178C (objectifs et indépendance par niveau logiciel), Wikipedia en.wikipedia.org/wiki/DO-178C