DO-178C expliquée : niveaux DAL, objectifs, audits SOI et tests

Qu’est-ce que la DO-178C ?

La DO-178C, « Software Considerations in Airborne Systems and Equipment Certification », est une norme de processus. Elle ne dit pas comment écrire le code. Elle dit quels objectifs le cycle de vie logiciel doit atteindre et quelles preuves le démontrent. Plus le risque est élevé, plus les objectifs sont nombreux, et plus ils doivent être atteints avec indépendance.

La DO-178C ne s’utilise jamais seule. La FAA précise que les suppléments s’utilisent avec la DO-178C, et que le PSAC (Plan for Software Aspects of Certification) doit dire comment ils se combinent.

Les exigences système viennent de l’ARP4754A/B (développement avion et système) et de l’analyse de sécurité. Le matériel électronique suit la DO-254. La DO-178C commence là où le système alloue des exigences au logiciel.

Quels sont les niveaux DAL de la DO-178C ?

Le niveau d’assurance de conception (DAL), aussi appelé niveau logiciel, découle de l’analyse de sécurité système. Il reflète la pire condition de panne qu’une défaillance du logiciel pourrait causer. Le DAL A est le plus exigeant ; le DAL E n’a aucun objectif DO-178C.

La couverture du couplage de données et de contrôle s’applique aux niveaux A, B et C. Chaque niveau en moins retire des objectifs, de l’indépendance et des critères de couverture : le DAL est le premier facteur de coût d’un projet DO-178C. Fixez-le tôt avec l’équipe sécurité système ; un niveau qui change tard change tout le plan de vérification.

Les 10 tableaux d’objectifs de l’Annexe A

L’Annexe A de la DO-178C regroupe les objectifs en dix tableaux. Chaque objectif indique les sections qui le décrivent, les niveaux concernés, l’exigence d’indépendance et les données de cycle de vie qui le prouvent.

1. A-1 Processus de planification
2. A-2 Processus de développement (exigences, conception, code, intégration)
3. A-3 Vérification des exigences de haut niveau (HLR)
4. A-4 Vérification des exigences de bas niveau (LLR) et de l’architecture
5. A-5 Vérification du code source et du processus d’intégration
6. A-6 Test des sorties du processus d’intégration (le code exécutable)
7. A-7 Vérification de la vérification : procédures, résultats, couverture des exigences, couverture structurelle
8. A-8 Gestion de configuration
9. A-9 Assurance qualité logicielle
10. A-10 Relations avec l’autorité de certification

Les tableaux A-6 et A-7 concentrent l’essentiel du travail de test. A-6 demande que le code exécutable soit conforme et robuste vis-à-vis des HLR et des LLR, et compatible avec le calculateur cible. A-7 demande que les procédures et résultats de test soient corrects, que chaque HLR et LLR soit couverte par des tests et que les critères de couverture structurelle du niveau soient atteints.

Quels documents les auditeurs attendent-ils ?

La DO-178C démontre la conformité par les données de cycle de vie. Les noms varient selon les entreprises, mais le contenu est attendu dans tous les projets :

• Plans : PSAC, plan de développement, plan de vérification, plan de gestion de configuration, plan d’assurance qualité.
• Standards : règles d’écriture des exigences, de conception et de codage.
• Données de développement : exigences de haut niveau, conception (architecture et exigences de bas niveau), code source, code exécutable.
• Données de traçabilité : liens bidirectionnels entre exigences système, HLR, LLR, code et tests.
• Données de vérification : comptes rendus de revues et d’analyses, cas et procédures de test, résultats, analyse de couverture.
• Enregistrements de configuration et qualité : références (baselines), rapports d’anomalie, historique des modifications, enregistrements AQ, index de configuration logicielle.
• Software Accomplishment Summary (SAS) : la déclaration finale que les plans ont été suivis et les objectifs atteints.

Les auditeurs ne se contentent pas de lire. Ils prennent une exigence, la suivent jusqu’au code et à ses tests, et vérifient que chaque lien, résultat et compte rendu de revue existe et est cohérent. Une traçabilité faible est l’une des causes les plus fréquentes d’écarts.

Que se passe-t-il aux audits SOI#1 à SOI#4 ?

L’autorité de certification, ou son représentant, revoit le projet à quatre étapes d’implication (Stages of Involvement). L’Order 8110.49A de la FAA décrit le déroulement de ces revues.

Le moment le moins cher pour corriger une exigence est avant le SOI#2. Une exigence manquante ou ambiguë découverte au SOI#3 implique de nouveaux tests, de nouvelles revues et souvent du nouveau code.

Comment fonctionnent les tests en DO-178C ?

La DO-178C ne donne de crédit qu’aux tests basés sur les exigences. Chaque cas de test se rattache à une exigence de haut ou de bas niveau. La couverture structurelle n’est pas un but : elle mesure si les tests basés sur les exigences sont complets et aide à révéler du code qu’aucune exigence ne demandait.

Tests en plage normale et tests de robustesse

• Les tests en plage normale (§6.4.2.1) montrent que le logiciel répond correctement aux entrées valides : classes d’équivalence, valeurs limites, transitions d’état valides, fonctions temporelles.
• Les tests de robustesse (§6.4.2.2) montrent qu’il se comporte correctement face aux entrées et conditions anormales : valeurs hors plage, états invalides, modes de panne, débordements, temporisations. Le comportement attendu doit être écrit dans les exigences.

Où s’exécutent les tests

Un crédit est possible pour des tests sur émulateur de la cible ou simulateur hôte, si l’on démontre que l’environnement est représentatif. Les tests d’intégration matériel/logiciel qui montrent la compatibilité avec le calculateur cible doivent tourner sur la vraie cible.

Quand la couverture n’atteint pas 100 %

Chaque partie de code non couverte demande une analyse avec l’une de quatre conclusions : un test manque, une exigence manque, c’est du code mort (à supprimer) ou du code désactivé (à justifier, en montrant qu’il ne peut pas s’exécuter). En pratique, les deux premiers cas sont les plus fréquents, et tous deux commencent dans les exigences.

Retour de notre banc d’essai

Dans le banc d’essai à l’aveugle de KomAInu sur des tests générés par IA à partir d’exigences synthétiques de type DAL C, la plupart des tests faux venaient de deux endroits : le comportement à la mise sous tension et à l’initialisation, et les bornes des temporisations (par exemple, pour une condition tenue « plus de 250 ms » avec un cycle de 20 ms, une lecture naïve déclenchait à 280 ms au lieu de 260 ms). Ce sont deux cas de robustesse qu’un relecteur doit vérifier ligne à ligne.

Pour trouver ces lacunes avant l’audit, KomAInu mène une analyse des lacunes de couverture à partir de vos exigences et de vos tests existants, et génère les cas de test manquants à partir des exigences, soumis à la revue de l’ingénieur.

Ce que le DAL C n’exige pas (et ce qu’il exige toujours)

La plupart des équipementiers travaillent au DAL C ou D, où les écarts de coût avec les DAL A et B sont importants. Le tableau résume les différences de vérification qui comptent pour la planification.

Au DAL C, les développeurs peuvent écrire leurs propres tests bas niveau, ce qui réduit beaucoup le coût. La robustesse, la couverture des instructions, l’analyse du couplage et la traçabilité complète restent dues : la qualité des exigences reste le premier facteur d’effort.

Traçabilité bidirectionnelle et données de traçabilité

La DO-178C a créé une donnée de cycle de vie à part, les Trace Data (§11.21). Elles doivent montrer les liens dans les deux sens : de chaque exigence système vers les HLR, les LLR, le code et les tests, et de chaque test et ligne de code vers une exigence. Les liens descendants prouvent que chaque exigence est implémentée et vérifiée. Les liens montants prouvent que rien n’a été ajouté sans exigence.

Garder ces liens justes après chaque modification est la partie lente et risquée. Une matrice de traçabilité des exigences construite et vérifiée automatiquement, puis relue par un ingénieur, garde les preuves prêtes pour le SOI#2 et le SOI#3.

Qualification des outils (DO-330) et niveaux TQL

Un outil ne doit être qualifié que s’il supprime, réduit ou automatise un processus DO-178C sans que sa sortie soit vérifiée. Le niveau de qualification (TQL) dépend du niveau logiciel et de ce que l’outil pourrait faire de travers.

• Un outil est qualifié dans le cadre d’un projet, pas en général. Un fournisseur ne peut vendre qu’un outil « qualifiable » et un kit de qualification.
• Un kit TQL-5 contient en général les exigences opérationnelles de l’outil (TOR), un plan de qualification, des cas et procédures de vérification avec résultats attendus, et un résumé (TAS).
• Un certificat de sécurité générique (par exemple TÜV) ne remplace pas la qualification DO-330.
• Si la sortie de l’outil est entièrement relue, l’outil n’a en général pas besoin d’être qualifié. Déclarez l’approche tôt dans le PSAC.

Peut-on utiliser l’IA dans un projet DO-178C ?

Oui, comme assistant dont la sortie est vérifiée. Dans un document remis à l’OACI en septembre 2026, l’EASA écrit que les outils dont les sorties sont entièrement et indépendamment vérifiées peuvent ne pas demander de qualification ; sinon, une qualification proportionnée au risque s’applique (EASA, DGCA61/DP/03/06, §1.3). Les supports des AI Days 2026 de l’EASA montrent aussi que la prochaine étape réglementaire, avec une consultation prévue au T2 2027, accepte deux façons de vérifier les sorties d’IA : des contrôles systématiques par le personnel, ou des contrôles automatiques par un logiciel non-IA.

L’ED-324 / ARP6983, la nouvelle norme sur l’apprentissage automatique embarqué, a atteint le consensus le 24 août 2026. Elle vise le ML embarqué, pas les outils de vérification.

Cela dessine une architecture claire : le modèle de langage propose, des moteurs déterministes calculent et contrôlent, l’ingénieur décide. Les nombres et les unités doivent venir du code, pas de la génération de texte, et l’outil doit tourner sur une pile figée, sur site, pour que les résultats soient rejouables.

Limites : exigences synthétiques écrites par un agent séparé, une seule exécution par système, juges LLM à l’aveugle avec environ ±3 points de bruit. La leçon reste valable : poser à l’ingénieur des questions ciblées sur les exigences ambiguës a supprimé tous les tests faux de cette exécution, ce qu’aucun prompt seul n’a obtenu.

KomAInu suit cette approche : il challenge chaque exigence, pose à l’ingénieur les questions qui la tranchent et écrit des cas de test déterministes pour revue. Il peut tourner sur site ou en environnement isolé, et nos ingénieurs peuvent mener le travail avec votre équipe en V&V as a Service.

Où trouver le PDF de la DO-178C (et des ressources gratuites)

Le texte de la DO-178C est protégé et vendu par la RTCA (DO-178C) et l’EUROCAE (ED-12C). Les copies gratuites trouvées en ligne sont souvent non officielles ou périmées. Plusieurs documents officiels sont gratuits et utiles :

• FAA AC 20-115D : comment la FAA reconnaît la DO-178C et ses suppléments.
• EASA AMC 20-115D : l’équivalent européen harmonisé.
• FAA Order 8110.49A : comment la FAA conduit les revues logicielles et les SOI.
• FAA « DO-178B/C Differences Tool » : ce qui a changé entre DO-178B et DO-178C, section par section.
• Le livret d’AdaCore « Technologies for Airborne Software » (CC BY-SA) : une lecture objectif par objectif des tableaux A-6 et A-7.