Le niveau d'assurance de conception — le DAL — est le seul chiffre qui détermine l'ampleur d'un programme DO-178C. Il fixe le nombre d'objectifs à satisfaire, combien d'entre eux exigent un regard indépendant, et si vous mesurerez la couverture MC/DC ou rien du tout.
C'est aussi le chiffre que les équipes se trompent le plus souvent, généralement en présumant qu'il leur revient de le choisir. Ce n'est pas le cas. Voici ce que signifient les cinq niveaux, d'où vient le vôtre, et ce qui change réellement lorsqu'on monte l'échelle.
Les cinq niveaux en un coup d'œil
Le DO-178C définit cinq niveaux logiciels, de A à E. Le niveau découle entièrement d'une seule question : si ce logiciel contribue à une défaillance, quelle est la gravité du pire résultat plausible ?
| Niveau | Condition de défaillance | Ce que cela signifie à bord |
| A | Catastrophique | Empêcherait la poursuite du vol et l'atterrissage en sécurité |
| B | Dangereuse / majeure-sévère | Forte réduction des marges de sécurité ; blessures graves ou mortelles pour un petit nombre d'occupants |
| C | Majeure | Réduction importante des marges de sécurité ; inconfort, voire blessures légères |
| D | Mineure | Légère réduction des marges de sécurité ; augmentation courante de la charge de travail de l'équipage |
| E | Aucun effet sur la sécurité | Aucun effet sur la capacité opérationnelle ni sur la charge de travail de l'équipage |
Notez la formulation employée partout : condition de défaillance, et non criticité du logiciel. La gravité appartient à l'effet au niveau de l'aéronef, non à la complexité ou à l'ingéniosité du code. Un logiciel trivial peut être de niveau A, et un logiciel volumineux et sophistiqué peut être de niveau D.
Vous ne choisissez pas votre DAL
C'est le malentendu le plus répandu et le plus coûteux de toute la norme. Le niveau logiciel est un résultat de l'évaluation de sécurité de l'aéronef et du système, normalement menée selon les ARP4754A/B et ARP4761/A. Il parvient à l'équipe logicielle déjà déterminé.
Ce qui change réellement d'un niveau à l'autre
Monter d'un niveau ne signifie pas « faire le même travail avec plus de soin ». Cela signifie satisfaire davantage d'objectifs, et en satisfaire davantage de façon indépendante.
| Niveau | Objectifs | Dont avec indépendance | Par rapport au niveau inférieur |
| A | 71 | 30 | +9 objectifs, mais +12 avec indépendance |
| B | 69 | 18 | +7 objectifs, +13 avec indépendance |
| C | 62 | 5 | +36 objectifs — le grand saut |
| D | 26 | 2 | +26 objectifs par rapport au niveau E |
| E | 0 | 0 | Aucun objectif DO-178C |
Lisez attentivement la dernière colonne, car elle contredit l'intuition courante. Le saut que tout le monde redoute est celui de C vers B puis vers A. Le saut qui transforme réellement un programme est celui de D vers C : trente-six objectifs de plus, l'arrivée de la couverture structurelle, et la première véritable infrastructure de vérification. Passer de C à A ajoute bien moins d'objectifs — mais sextuple à peu près ceux qui exigent l'indépendance, ce qui relève de la dotation en personnel plutôt que du processus.
L'indépendance, le mot qui coûte cher
Un objectif « avec indépendance » signifie que la personne qui vérifie un élément ne peut être celle qui l'a produit. Il ne s'agit pas d'une question de services ou de liens hiérarchiques, mais bien de la personne.
Deux conséquences pratiques. D'abord, une équipe de deux personnes ne peut satisfaire le niveau A en travaillant en étroite collaboration : la séparation doit être réelle et doit paraître dans vos enregistrements. Ensuite, pour certains objectifs, un outil qualifié peut fournir l'indépendance à la place d'un deuxième ingénieur, ce qui constitue l'un des rares véritables leviers de coût aux niveaux supérieurs. C'est aussi pourquoi la qualification des outils (DO-330) apparaît surtout sur les programmes de niveaux A et B, et rarement au niveau D.
La couverture structurelle par niveau
C'est dans la couverture que le niveau se manifeste le plus concrètement au quotidien.
| Niveau | Instructions | 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 | — | — | — | — |
La couverture MC/DC au niveau A est l'exigence la plus souvent citée, et elle est réellement ardue pour une logique booléenne complexe. Mais l'exigence plus discrète du niveau A — démontrer que le code objet non directement traçable au code source est vérifié — est celle qui surprend les équipes, car elle dépend du compilateur et de ses options, et non de ce que l'équipe a écrit.
Erreurs de cadrage courantes
- Présumer un seul niveau pour tout le boîtier. Un même équipement peut héberger des fonctions de niveaux différents, à condition que le cloisonnement entre elles soit robuste et démontré. Aligner l'ensemble sur le DAL de la fonction la plus élevée est un réflexe courant et très coûteux.
- Traiter le niveau E comme « rien à faire ». Le niveau E ne comporte aucun objectif DO-178C, mais vous devez tout de même justifier ce classement auprès de l'autorité. Un niveau E non justifié est un constat, pas une économie.
- Confondre le DAL avec le SIL ou l'ASIL. Ils proviennent de normes différentes, avec des définitions différentes, et ne se transposent pas proprement. Un fournisseur venu de l'automobile ou de l'industriel devrait présumer que rien ne se transfère.
- Oublier l'effectif requis par l'indépendance. Les programmes de niveaux A et B sont fréquemment dotés comme si l'indépendance n'était qu'une étape de revue plutôt que le travail d'une personne distincte, et le manque se découvre au SOI nº 3.
- Figer le niveau avant que la FHA ne soit stable. Si l'évaluation de sécurité évolue, le niveau évolue, et les plans rédigés en fonction de l'ancien niveau évoluent avec lui.
Foire aux questions
Qui attribue le DAL ?
Il découle de l'évaluation de sécurité de l'aéronef et du système : l'évaluation des dangers fonctionnels établit la gravité, et le processus de sécurité du système attribue les niveaux d'assurance aux éléments qui réalisent chaque fonction. L'équipe logicielle le reçoit ; elle ne le fixe pas.
Des parties d'un même logiciel peuvent-elles être de niveaux différents ?
Oui, à condition de pouvoir démontrer un cloisonnement robuste entre elles, de sorte qu'un logiciel de niveau inférieur ne puisse nuire à un logiciel de niveau supérieur. Sans cette démonstration, tout ce qui se trouve dans la partition est traité au niveau le plus élevé présent.
Combien le niveau A coûte-t-il de plus que le niveau C ?
Il n'existe pas de multiplicateur unique honnête, car cela dépend bien davantage de la qualité de la planification que du niveau lui-même. Ce qui est prévisible, c'est la forme : passer de C à A ajoute relativement peu d'objectifs, mais accroît fortement ceux exigeant l'indépendance ; le coût se loge donc dans la dotation et dans l'infrastructure de vérification plutôt que dans des étapes de processus supplémentaires.
Le DAL est-il la même chose que la couverture MC/DC ?
Non. La couverture MC/DC est un critère de couverture qu'exige le niveau A. Le niveau détermine bien d'autres choses : le nombre d'objectifs, combien d'entre eux exigent l'indépendance, et si l'analyse du couplage des données et du couplage de contrôle s'applique.
Quelle est la différence entre DAL et IDAL ?
L'IDAL, niveau d'assurance de développement d'un élément, est le terme employé dans les normes de niveau système pour désigner le niveau attribué à un élément. Une fois cet élément devenu logiciel, le DO-178C parle de niveau logiciel. Dans les échanges courants les deux termes s'emploient indifféremment, mais l'attribution se fait au niveau système et aboutit au logiciel.
Vous cadrez un programme, ou vous remettez en question un niveau qui semble inadapté à l'architecture ? Cette discussion gagne à être tenue tôt — écrivez-nous.
