Si l'on vient de vous annoncer que votre logiciel doit être conforme au DO-178C, cette page s'adresse à vous. Elle suppose que vous êtes un ingénieur compétent qui n'a jamais travaillé sous une norme de logiciel embarqué, et elle explique ce que la norme exige réellement, ce que vous devrez produire, qui le vérifie, et où les programmes perdent habituellement du temps.
Elle se veut pratique plutôt qu'exhaustive. Des articles ultérieurs traitent chaque volet en détail.
Ce qu'est le DO-178C — et ce qu'il n'est pas
Le DO-178C, Software Considerations in Airborne Systems and Equipment Certification, est publié par la RTCA, et sous la référence ED-12C par l'EUROCAE en Europe. Les autorités de certification — la FAA, l'AESA et l'Aviation civile de Transports Canada — acceptent la conformité à cette norme comme moyen acceptable de démontrer qu'un logiciel embarqué est apte au vol.
Trois choses qu'il n'est pas, et ce sont les premières idées reçues :
- Ce n'est pas une norme de codage. Elle ne vous interdit jamais une construction de langage précise ni ne limite la longueur des fonctions. Elle exige que vous ayez une norme de codage et que vous démontriez l'avoir respectée.
- Ce n'est pas un processus de développement. Elle n'impose ni cycle en cascade, ni cycle en V, ni quoi que ce soit d'autre. Elle définit des objectifs et les preuves qui les satisfont ; l'enchaînement des travaux vous appartient, à vous de le planifier et de le justifier.
- Ce n'est pas une mesure de qualité logicielle. C'est une norme d'assurance de conception. Elle donne l'assurance que les erreurs susceptibles de provoquer une condition non sécuritaire ont été trouvées et éliminées — non pas que le logiciel est élégant, rapide ou facile à maintenir.
D'où vient le niveau d'assurance
Le malentendu le plus fréquent consiste à croire qu'une équipe logicielle choisit elle-même son niveau d'assurance. Il n'en est rien. Le niveau est transmis au logiciel par une évaluation de sécurité menée au niveau de l'aéronef et du système, normalement selon les ARP4754A/B et ARP4761/A.
La chaîne se déroule ainsi. Une évaluation des dangers fonctionnels (FHA) détermine ce qui arrive en cas de défaillance de chaque fonction et quelle en est la gravité. L'évaluation préliminaire de sécurité du système (PSSA) répartit les exigences et les niveaux d'assurance vers les éléments qui réalisent ces fonctions. L'évaluation de sécurité du système (SSA) confirme ensuite, une fois la conception concrète, que les objectifs ont été atteints. L'analyse des causes communes (CCA) se déroule en parallèle afin de vérifier que ce qui est présumé indépendant l'est réellement.
Conséquence pratique : si vous estimez que votre niveau est erroné, la discussion se tient avec les équipes systèmes et sécurité, et non avec l'autorité de certification. Une modification architecturale au niveau système — cloisonnement, moniteurs, redondance dissemblable — est la façon légitime de réduire un niveau d'assurance logiciel, et elle coûte bien moins cher que d'en débattre plus tard.
Les cinq niveaux d'assurance de conception
Le DO-178C définit cinq niveaux logiciels, de A à E, déterminés par la gravité de la condition de défaillance à laquelle le logiciel peut contribuer.
| Niveau | Condition de défaillance | Signification concrète | Objectifs (approx.) | Dont avec indépendance |
| A | Catastrophique | La défaillance empêcherait la poursuite du vol et l'atterrissage en sécurité | 71 | 30 |
| B | Dangereuse / majeure-sévère | Forte réduction des marges de sécurité ; blessures graves ou mortelles pour un petit nombre d'occupants | 69 | 18 |
| C | Majeure | Réduction importante des marges de sécurité ; inconfort, voire blessures légères | 62 | 5 |
| D | Mineure | Légère réduction des marges de sécurité ; augmentation courante de la charge de travail de l'équipage | 26 | 2 |
| E | Aucun effet sur la sécurité | Aucun effet sur la capacité opérationnelle ni sur la charge de travail de l'équipage | 0 | 0 |
Deux constats à tirer de ce tableau. D'abord, l'écart entre le niveau C et le niveau D est bien plus grand que celui entre B et A : la plupart des objectifs disparaissent au niveau D. Ensuite, c'est dans la mention « avec indépendance » que se cache le coût en personnel : elle signifie que la personne qui vérifie un élément ne peut être celle qui l'a produit, ce qui, au niveau A, s'applique à une trentaine d'objectifs et détermine la taille de votre équipe.
Le cycle de vie : ce que vous produisez réellement
Le DO-178C organise les travaux en trois groupes : le processus de planification ; les processus de développement — exigences, conception, codage, intégration ; et les processus intégraux — vérification, gestion de configuration, assurance qualité et liaison avec la certification — qui se déroulent en continu, en parallèle de tout le reste, et non comme une phase finale.
Le mot intégral a ici tout son sens. Les équipes qui découvrent la norme traitent couramment la vérification et la gestion de configuration comme des activités postérieures au codage. Sous le DO-178C, elles commencent dès la planification et ne s'arrêtent jamais ; un programme qui les reporte est un programme qui refera ses preuves.
L'ensemble documentaire
La planification produit cinq plans et trois normes. Tout ce qui suit est jugé par rapport à eux, ce qui fait de la planification l'endroit le moins coûteux où bien faire les choses, et le plus coûteux où les rater.
| Élément | Ce à quoi il vous engage |
| PSAC — Plan for Software Aspects of Certification | L'entente de haut niveau avec l'autorité de certification : aperçu du système, niveau logiciel, cycle de vie, normes, et mode de démonstration de la conformité |
| SDP — Software Development Plan | Comment les exigences, la conception, le code et l'intégration seront produits, et par qui |
| SVP — Software Verification Plan | Comment les revues, analyses et essais seront menés, y compris l'indépendance et la couverture |
| SCMP — Software Configuration Management Plan | Références de configuration, contrôle des modifications, rapports de problèmes, archivage et restitution |
| SQAP — Software Quality Assurance Plan | Comment la conformité aux plans est auditée, et par qui |
| Normes d'exigences | Règles et notation pour la rédaction des exigences de haut et de bas niveau |
| Normes de conception | Règles et contraintes visant l'architecture et la conception logicielles |
| Normes de codage | Sous-ensemble du langage, nommage, complexité et restrictions de constructions |
La vérification ne se limite pas aux essais
La vérification selon le DO-178C se compose de revues, d'analyses et d'essais. Les essais seuls n'en satisfont qu'une partie. Les essais découlent des exigences — ils ne s'écrivent pas en lisant le code — et chaque cas d'essai est tracé jusqu'à l'exigence qu'il sollicite.
La couverture structurelle est ensuite mesurée pour répondre à une autre question : non pas « le logiciel satisfait-il ses exigences », mais « mes essais fondés sur les exigences ont-ils réellement sollicité le code, et existe-t-il ici du code qu'aucune exigence n'a demandé ? » Une couverture qui refuse de se fermer signale généralement des exigences manquantes, des essais manquants, ou du code qui ne devrait pas exister.
| Niveau | Couverture des instructions | Couverture des décisions | MC/DC | Traçabilité code source vers code objet |
| A | Exigée | Exigée | Exigée | Exigée |
| B | Exigée | Exigée | — | — |
| C | Exigée | — | — | — |
| D | — | — | — | — |
| E | — | — | — | — |
Les audits : les stades d'implication 1 à 4
L'autorité de certification, ou son délégué, intervient à quatre moments. Il ne s'agit pas d'inspections-surprises : ce sont des revues planifiées de preuves que vous détenez déjà, et le calendrier en est proposé dans votre PSAC.
| Stade | Objet | Ce qui est réellement demandé |
| SOI nº 1 — Planification | Plans et normes | Le plan est-il crédible, complet et adapté au niveau logiciel ? |
| SOI nº 2 — Développement | Exigences, conception, code, traçabilité | Avez-vous respecté vos propres plans et normes ? |
| SOI nº 3 — Vérification | Cas d'essai, procédures, résultats, couverture | La preuve de vérification est-elle complète, et se ferme-t-elle réellement ? |
| SOI nº 4 — Final | SAS, SCI, rapports de problèmes ouverts | Le logiciel est-il prêt, et les problèmes connus restants sont-ils acceptables ? |
Les suppléments
Le DO-178C a été publié accompagné de documents connexes. Ils ne remplacent pas la norme de base : ils en modifient et en ajoutent des objectifs pour une technologie donnée.
| Document | S'applique lorsque | Résumé en une ligne |
| DO-330 | Vous vous fiez à un outil pour éliminer, réduire ou automatiser un processus | Qualification des outils. Détermine le niveau de qualification (TQL-1 à TQL-5) et les preuves exigées de l'outil lui-même |
| DO-331 | Vous développez ou vérifiez au moyen de modèles | Développement fondé sur les modèles. Définit ce qu'est un modèle en termes d'exigences et de conception, et le lien entre couverture des modèles et couverture structurelle |
| DO-332 | Vous utilisez des langages orientés objet ou des techniques connexes | Ajoute des objectifs visant l'héritage, le polymorphisme, la gestion dynamique de la mémoire et la sûreté du typage |
| DO-333 | Vous utilisez des méthodes formelles | Permet à l'analyse formelle de remplacer certains essais et certaines revues, avec ses propres exigences de preuve |
Où les programmes perdent réellement du temps
Sur les programmes de niveaux DAL A et DAL C, le temps se perd rarement à écrire du code. Il se perd à quatre endroits, tous prévisibles :
- La dette de traçabilité. Les liens sont consignés tardivement, à la main, de mémoire. Le travail à refaire n'est pas la mise en lien : c'est de découvrir, des mois plus tard, qu'une exigence n'a jamais été réalisée, ou qu'un morceau de code ne répond à rien.
- Les exigences dérivées non retournées à la sécurité. Les exigences inventées pendant la conception doivent retourner à l'évaluation de sécurité. L'omettre constitue un constat, et il se découvre tard.
- La couverture découverte à la fin. Une couverture structurelle exécutée pour la première fois vers la fin révèle immanquablement du code mort, des essais manquants et des lacunes d'exigences, tous en même temps, au pire moment.
- La qualification tardive des outils. Décider au moment de la vérification que la sortie d'un outil sera tenue pour acquise sans preuve de qualification est une conversation coûteuse à tenir au SOI nº 3.
Aucun de ces problèmes n'est difficile. Ce sont tous des problèmes d'enchaînement, et les quatre s'évitent à peu de frais dès la planification.
Le DO-178C au Canada
Pour les programmes canadiens, l'autorité de certification est l'Aviation civile de Transports Canada. La norme est le même document et les objectifs ne changent pas, mais la voie d'approbation, le recours aux délégués et le traitement des constats diffèrent du modèle de la FAA que suppose la quasi-totalité de la documentation publiée sur le DO-178C. Des ententes bilatérales entre le Canada, les États-Unis et l'Europe régissent en outre la façon dont une approbation accordée par une autorité est validée par une autre — ce qui compte beaucoup si vous êtes un fournisseur canadien qui vend dans un programme étranger, ou l'inverse.
Le sujet est assez vaste, et assez mal servi par la documentation existante, pour faire l'objet de son propre article.
Foire aux questions
Le DO-178C est-il obligatoire ?
Pas en soi. Le DO-178C est un moyen de conformité, non un règlement. Ce qui est obligatoire, c'est de démontrer à l'autorité de certification que votre logiciel embarqué est sécuritaire pour la fonction prévue. Le DO-178C est le moyen que les autorités acceptent couramment, et c'est en pratique ce que l'on attendra de vous.
Combien de temps prend une certification DO-178C ?
Cela dépend presque entièrement du niveau logiciel, et du fait que l'assurance ait été intégrée dès le départ ou ajoutée après coup. Le DO-178C allonge rarement un programme bien planifié autant que les équipes le craignent, et double fréquemment un programme mal planifié. Ajouter les preuves à du code déjà terminé, voilà le cas coûteux.
Peut-on utiliser une approche agile avec le DO-178C ?
Oui, et de nombreux programmes le font. Le DO-178C impose des objectifs et des preuves, non un modèle de cycle de vie. Ce que l'approche agile doit accommoder, c'est que certains éléments doivent être mis sous référence de configuration, revus avec indépendance et tenus en gestion de configuration — la définition de « terminé » d'un incrément doit donc inclure ses preuves.
Quelle est la différence entre le DO-178C et le DO-254 ?
Le DO-178C vise le logiciel embarqué ; le DO-254 vise le matériel électronique embarqué, comme les composants programmables complexes et les FPGA. Ils partagent la philosophie d'assurance de conception, et l'attribution du niveau provient de la même évaluation de sécurité du système, mais les objectifs et les preuves diffèrent.
Le DO-178C s'applique-t-il aux drones et aux aéronefs eVTOL ?
Lorsque l'aéronef fait l'objet d'une certification de type, oui : le même cadre de navigabilité s'applique. Ce qui varie, c'est la gravité de la condition de défaillance attribuée à une fonction donnée sur un aéronef sans équipage ou de conception nouvelle, ce qui peut placer le logiciel à un niveau différent de celui de la fonction équivalente sur un avion de transport.
Si vous cadrez un programme, en héritez d'un, ou préparez une première revue de stade d'implication, c'est exactement le travail que nous faisons — écrivez-nous.
