Traçabilité DO-178C

La DO-178C est la norme d'assurance logicielle selon laquelle les systèmes embarqués aéronautiques sont certifiés. En son cœur se trouve une idée que les autorités de certification vérifient sans relâche : la traçabilité. Chaque comportement du logiciel touchant à la sécurité doit pouvoir être relié à une exigence, et chaque exigence doit pouvoir être reliée vers l'aval au code et aux tests qui l'implémentent et la vérifient. Cette page explique à quoi ressemble cette chaîne, ce que signifie concrètement la traçabilité bidirectionnelle, comment les niveaux d'assurance de conception dimensionnent l'effort, et où les équipes rencontrent le plus souvent des difficultés.

Si vous certifiez un logiciel avionique, la traçabilité n'est pas une paperasse produite à la fin. C'est le tissu conjonctif qui permet à un auditeur de suivre n'importe quelle exigence jusqu'à son implémentation, puis de revenir en arrière, et c'est l'un des premiers points qu'un représentant technique agréé ou une autorité va sonder.

Ce qu'est la DO-178C

La DO-178C, intitulée Software Considerations in Airborne Systems and Equipment Certification, est publiée par la RTCA. Son équivalent européen identique est l'ED-12C, publiée par l'EUROCAE. Les deux documents partagent les mêmes objectifs et le même contenu : un projet conforme à l'un est conforme à l'autre. Aux États-Unis comme en Europe, la FAA et l'EASA reconnaissent la DO-178C / ED-12C comme le moyen de conformité accepté pour le logiciel des systèmes embarqués aéronautiques.

La DO-178C est fondée sur des objectifs plutôt que prescriptive. Au lieu d'imposer un processus de développement unique, elle définit un ensemble d'objectifs que le cycle de vie logiciel doit satisfaire, et laisse le demandeur libre de choisir comment les atteindre. Le demandeur produit ensuite des preuves, sous la forme de données du cycle de vie, montrant que chaque objectif applicable a été atteint. Les données de traçabilité constituent l'un des éléments centraux de ces preuves.

Pour une vue plus large de la certification dans ce domaine, y compris son pendant matériel, consultez notre présentation de l'ingénierie Aérospatiale & Défense et l'article associé Certifications aéronautiques DO-178C & DO-254.

Niveaux d'assurance de conception (DAL A à E)

La rigueur exigée par la DO-178C n'est pas la même pour tous les logiciels. Elle est dimensionnée par le niveau d'assurance de conception (DAL, Design Assurance Level), parfois appelé niveau logiciel. Le DAL est attribué en fonction de la gravité de la condition de panne à laquelle le logiciel pourrait contribuer, telle que déterminée par l'évaluation de la sécurité du système. Il existe cinq niveaux, de A (le plus critique) à E (le moins critique) :

Le principe clé est que le nombre d'objectifs applicables, et le degré d'indépendance requis pour les satisfaire, augmentent avec la criticité. Les niveaux les plus élevés exigent pour l'essentiel l'ensemble complet des objectifs ; les niveaux inférieurs relâchent progressivement à la fois le nombre et les attentes en matière d'indépendance. Une grande partie des objectifs supplémentaires aux niveaux A et B concerne la vérification et la couverture structurelle, précisément là où une traçabilité rigoureuse porte ses fruits.

La chaîne de traçabilité

La traçabilité DO-178C suit le logiciel à mesure qu'il est raffiné, d'un besoin abstrait vers un code exécutable et vérifié. La chaîne parcourt généralement les couches suivantes :

1. Exigences système allouées au logiciel. Elles proviennent du niveau système et définissent ce que le logiciel doit faire.
2. Exigences de haut niveau (HLR). Les exigences logicielles dérivées des exigences système : ce que le logiciel doit faire, sans figer la conception interne.
3. Exigences de bas niveau (LLR) et architecture logicielle. Les exigences détaillées à partir desquelles le code source peut être écrit directement, ainsi que l'architecture qui les organise.
4. Code source. L'implémentation, développée à partir des exigences de bas niveau.
5. Cas de test, procédures et résultats. Les preuves de vérification qui montrent que les exigences sont satisfaites, y compris les résultats de l'exécution des tests et l'analyse de couverture associée.

Chaque maillon de cette chaîne doit être documenté. Une exigence de haut niveau se relie vers l'aval aux exigences de bas niveau qui la décomposent ; chaque exigence de bas niveau se relie au code qui l'implémente ; chaque exigence se relie aux cas de test qui la vérifient et aux résultats de leur exécution. Lue dans l'autre sens, chaque ligne de code et chaque test devraient se relier vers l'amont à une exigence qui justifie leur existence.

Ce que signifie la traçabilité bidirectionnelle

La traçabilité bidirectionnelle signifie que les liens de trace peuvent être suivis dans les deux sens, et que ces deux sens sont complets :

• Vers l'aval (descendante) : de chaque élément de niveau supérieur vers les éléments de niveau inférieur qui le satisfont. Cela démontre que chaque exigence est implémentée et vérifiée. Si une exigence n'a aucune trace descendante, elle n'a pas été réalisée.
• Vers l'amont (ascendante) : de chaque élément de niveau inférieur vers l'élément de niveau supérieur qui le justifie. Cela démontre que rien d'involontaire n'a été ajouté. Si un code ou un test n'a aucune trace ascendante, il peut s'agir d'une fonction non voulue (souvent appelée code, ou exigence, mort ou superflu), ce qui constitue en soi un constat.

La bidirectionnalité est importante parce que les deux sens détectent des problèmes différents. La traçabilité descendante détecte les omissions : des exigences jamais implémentées ou jamais testées. La traçabilité ascendante détecte les ajouts : un comportement présent dans le code mais qu'aucune exigence n'a demandé. Les deux sont des enjeux de sécurité dans un système embarqué, et la DO-178C attend explicitement que les données de trace permettent l'analyse dans les deux sens. Lorsqu'une exigence change, des liens bidirectionnels complets sont aussi ce qui rend l'analyse d'impact exploitable : on voit immédiatement quels éléments de conception, unités de code et tests sont affectés.

Vérification et revues

La traçabilité est vérifiée, pas seulement déclarée. La vérification DO-178C combine revues, analyses et essais, et la traçabilité sous-tend les trois.

• Les revues des exigences de haut et de bas niveau confirment, entre autres propriétés, qu'elles se relient correctement à leurs éléments parents.
• Les revues du code source confirment qu'il se relie aux exigences de bas niveau et reste cohérent avec elles.
• Les essais fondés sur les exigences confirment que le logiciel satisfait ses exigences ; la trace des exigences vers les cas de test montre que le jeu de tests est complet.
• L'analyse de couverture structurelle (instructions, décisions et, au niveau A, couverture des conditions et décisions modifiées, MC/DC) est réalisée sur les résultats des essais fondés sur les exigences. Une couverture non exercée peut révéler des lacunes dans les exigences, dans les tests, ou un code non voulu, ce qui referme la boucle sur la traçabilité.

Plus le DAL est élevé, plus cette vérification doit être réalisée avec indépendance, c'est-à-dire par une autre personne que l'auteur de l'élément vérifié.

Les suppléments : DO-330 à DO-333

La DO-178C est accompagnée de quatre suppléments technologiques. Ils ne remplacent pas la norme de base : ils expliquent comment ses objectifs s'appliquent lorsqu'une technique particulière est employée, et ils portent leurs propres attentes de traçabilité.

• DO-330, qualification des outils logiciels. Lorsqu'un outil automatise, remplace ou réduit un processus DO-178C (par exemple un outil qui génère du code ou qui réalise une vérification), l'outil lui-même peut devoir être qualifié. La DO-330 définit comment, avec une rigueur dépendant de l'impact de l'outil.
• DO-331, développement et vérification fondés sur les modèles. Traite de la façon dont les objectifs s'appliquent lorsque des modèles servent d'exigences ou de conception, et de la manière dont la traçabilité s'étend vers ces modèles et depuis eux.
• DO-332, technologies orientées objet et techniques associées. Traite des enjeux de vérification propres aux techniques orientées objet et associées, comme l'héritage et la liaison dynamique.
• DO-333, méthodes formelles. Explique comment les méthodes formelles (spécification et vérification fondées sur les mathématiques) peuvent satisfaire des objectifs de vérification, y compris là où une preuve peut se substituer à un essai.

Quels que soient les suppléments applicables, l'obligation de traçabilité sous-jacente ne disparaît pas : modèles, artefacts générés et spécifications formelles doivent tous continuer à se relier vers les données du cycle de vie environnantes et depuis elles.

Pièges courants du traçage dans des documents et tableurs

Beaucoup d'équipes commencent à tracer les artefacts DO-178C dans des documents de traitement de texte et des tableurs, et nombre d'entre elles découvrent tard dans le programme que cela ne passe pas à l'échelle. Les problèmes récurrents sont :

• Liens périmés. Une exigence est modifiée ou renumérotée, et les références de trace qui pointent vers elle ne sont pas mises à jour. La matrice paraît toujours complète mais pointe vers la mauvaise version.
• Couverture à sens unique. Les liens descendants sont maintenus mais les liens ascendants sont négligés, si bien que le code non voulu et les tests orphelins passent inaperçus jusqu'à un audit.
• Aucun impact du changement. Lorsqu'une exigence de haut niveau change, il n'existe aucun moyen automatique de voir chaque exigence de bas niveau, unité de code et test affectés en aval : le périmètre de revérification est deviné plutôt que connu.
• Décalage de versions entre fichiers. Exigences, conception, code et données de test vivent dans des fichiers séparés sous des révisions séparées, et maintenir la trace cohérente entre tous devient une réconciliation manuelle et sujette aux erreurs.
• Preuves assemblées à la fin. La traçabilité est reconstruite pour le dossier de certification plutôt que maintenue en continu, ce qui est précisément le moment où les lacunes et incohérences apparaissent avec le moins de temps pour les corriger.

L'alternative consiste à conserver les exigences, la conception, les références de code et les artefacts de test comme des items liés au sein d'un seul modèle connecté, de sorte qu'un lien de trace soit une relation vivante plutôt qu'un identifiant recopié. Les requêtes bidirectionnelles et l'impact du changement viennent alors gratuitement, et la preuve de certification devient un rapport généré à partir du modèle plutôt qu'un document assemblé à la main.