Les équipes logicielles découvrent le niveau d'assurance de conception comme un fait qu'on leur transmet : c'est du niveau B, planifiez en conséquence. D'où il provient reste généralement opaque, ce qui rend difficile de distinguer un niveau réellement exigé d'un niveau qui n'est que le produit de la façon dont le système a été dessiné.
Voici la chaîne qui le produit, en termes simples, et les deux endroits où une équipe logicielle peut légitimement influencer la réponse.
La question à laquelle répond le processus de sécurité
Tout cet appareillage existe pour répondre à une seule question : qu'arrive-t-il à l'aéronef si cette fonction défaille, et avons-nous rendu cela suffisamment improbable ? Tout le reste — les acronymes, les évaluations, les niveaux — n'est que comptabilité au service de cette question.
Le processus descend de l'aéronef vers le système, puis vers l'élément, et le niveau logiciel en découle tout en bas.
La FHA : ce qui défaille, et avec quelle gravité
L'évaluation des dangers fonctionnels recense les fonctions de l'aéronef et se demande, pour chaque condition de défaillance, quelle serait la gravité de l'effet. Elle se fait d'abord au niveau de l'aéronef, puis au niveau du système, et elle intervient tôt — avant qu'il n'existe une conception à évaluer, ce qui est précisément l'intention.
La gravité est classée selon une échelle fixe, et chaque classe s'accompagne d'une cible d'improbabilité que la condition de défaillance doit atteindre.
| Gravité | Effet sur l'aéronef et les occupants | Ne doit pas être plus fréquent que |
| Catastrophique | Empêcherait la poursuite du vol et l'atterrissage en sécurité | Extrêmement improbable (de l'ordre de 10⁻⁹ par heure de vol) |
| Dangereuse | Forte réduction des marges de sécurité ; blessures graves ou mortelles pour un petit nombre d'occupants | Extrêmement rare (10⁻⁷ à 10⁻⁹) |
| Majeure | Réduction importante des marges de sécurité ; inconfort des occupants, voire blessures légères | Rare (10⁻⁵ à 10⁻⁷) |
| Mineure | Légère réduction des marges de sécurité ; augmentation courante de la charge de travail de l'équipage | Probable (plus fréquent que 10⁻⁵) |
| Aucun effet sur la sécurité | Aucun effet sur la capacité opérationnelle ni sur la charge de travail de l'équipage | Aucune cible |
La PSSA : répartir l'exigence vers le bas
L'évaluation préliminaire de sécurité du système reprend les conditions de défaillance issues de la FHA et détermine ce que l'architecture doit accomplir pour les satisfaire. C'est là que les niveaux d'assurance sont réellement attribués aux éléments qui réalisent chaque fonction — le matériel, et le logiciel.
C'est cette étape qui fixe votre DAL. C'est aussi, fait déterminant, une étape menée sur une architecture proposée, ce qui signifie que la réponse dépend d'une conception encore modifiable.
La SSA : démontrer que c'est bien ce qui en est ressorti
L'évaluation de sécurité du système constitue la plaidoirie finale : compte tenu de la conception telle que réalisée, les objectifs issus de la FHA ont-ils été atteints ? En parallèle, l'analyse des causes communes vérifie l'hypothèse voulant que tout ce que l'architecture tient pour indépendant le soit réellement — que deux voies ne partagent pas une alimentation, un connecteur, ou un composant logiciel dont personne n'avait remarqué qu'il leur était commun.
| Évaluation | Produite par | Quand | Ce qu'elle établit |
| FHA (aéronef, puis système) | Sécurité, avec les systèmes | Au plus tôt — avant la conception | La gravité de chaque condition de défaillance |
| PSSA | Sécurité, avec les systèmes | Sur l'architecture proposée | Ce que l'architecture doit accomplir ; le niveau d'assurance de chaque élément |
| CCA | Sécurité | En parallèle de la PSSA et de la SSA | Si ce qui est présumé indépendant l'est réellement |
| SSA | Sécurité | Sur la conception telle que réalisée | Si les objectifs ont été atteints |
L'architecture est le levier — le seul véritable
Si un niveau paraît trop élevé pour la fonction, la réponse productive n'est pas d'en débattre. C'est de modifier le système pour qu'une défaillance logicielle ne produise plus à elle seule le résultat grave.
Moniteurs, cloisonnement, dissemblance et verrouillages matériels fonctionnent tous de la même manière : ils rompent le chemin entre une erreur logicielle unique et le résultat dangereux. Ce qui compte, c'est que l'élément d'atténuation soit réellement indépendant — un moniteur qui partage le processeur, le compilateur et le jeu d'exigences de ce qu'il surveille ne vous procure pas ce que vous croyez, et l'analyse des causes communes existe précisément pour le détecter.
L'économie de la chose est brutale et mérite d'être dite clairement : cette discussion ne coûte presque rien pendant la PSSA, et devient quasi impossible une fois le code écrit et l'architecture figée.
Les exigences dérivées remontent la chaîne
La chaîne n'est pas à sens unique. Les exigences inventées pendant la conception logicielle — des décisions sans exigence parente au-dessus d'elles, que le DO-178C appelle exigences dérivées — doivent être restituées au processus de sécurité, car les personnes qui ont évalué les dangers ne pouvaient tenir compte de quelque chose que l'équipe logicielle n'avait pas encore inventé.
Ce qu'une équipe logicielle devrait réellement faire
- Demandez à consulter la FHA et la PSSA. Non pour les contester, mais parce qu'elles contiennent les hypothèses que votre logiciel est censé honorer. Les équipes construisent couramment vers un niveau sans jamais lire pourquoi c'est ce niveau.
- Soulevez les préoccupations d'architecture avant que la PSSA ne soit figée. C'est la fenêtre ; elle se referme discrètement.
- Suivez les hypothèses. Une PSSA formule habituellement des hypothèses sur votre logiciel — qu'il détecte une condition, ou qu'il défaille dans une direction donnée. Ce sont des exigences, même lorsqu'elles ne sont pas rédigées comme telles.
- Planifiez la restitution des exigences dérivées. Inscrivez-la dans les plans, avec un nom en regard.
- Attendez-vous à ce que le niveau bouge. Si l'évaluation de sécurité évolue, votre niveau et vos plans évoluent avec elle. Prévoyez une révision plutôt que d'en être surpris.
Foire aux questions
Quelle est la différence entre une FHA et une PSSA ?
La FHA recense les conditions de défaillance et en classe la gravité, avant qu'il n'existe une conception. La PSSA les reprend et détermine ce qu'une architecture proposée doit accomplir pour les satisfaire, y compris l'attribution des niveaux d'assurance aux éléments. La FHA demande à quel point c'est grave ; la PSSA demande ce qu'il faut donc faire.
Pourquoi le logiciel n'obtient-il pas une probabilité de défaillance comme le matériel ?
Parce que les défaillances logicielles sont systématiques et non aléatoires. Une erreur de conception est présente dans chaque exemplaire et surviendra chaque fois que la condition déclenchante se présente : il n'y a donc pas de taux à mesurer. L'assurance de développement substitue la rigueur du processus et des preuves à une probabilité qu'on ne peut attribuer.
Une équipe logicielle peut-elle faire abaisser son DAL ?
Pas directement, ni par négociation. Il change lorsque l'architecture du système change de sorte qu'une défaillance logicielle n'entraîne plus à elle seule l'effet grave — un moniteur, un cloisonnement, de la dissemblance. C'est une discussion de systèmes et de sécurité, et elle doit avoir lieu avant que l'architecture ne soit figée.
À quoi sert l'analyse des causes communes ?
À éprouver l'indépendance sur laquelle repose l'architecture. Si deux voies sont réputées indépendantes mais partagent une alimentation, un connecteur, une équipe de développement ou une bibliothèque logicielle, elles peuvent défaillir ensemble et l'argumentaire de sécurité s'effondre. La CCA recherche précisément ces chemins partagés.
Les valeurs de probabilité s'appliquent-elles à tous les aéronefs ?
Non. Les valeurs habituellement citées proviennent des exigences de la catégorie transport. D'autres catégories emploient des cibles différentes, et c'est votre base de certification qui détermine lesquelles s'appliquent. Validez-le sur la base réelle de votre programme plutôt que sur les chiffres les plus répétés en ligne.
Si un niveau semble inadapté à votre architecture, le moment de le dire est maintenant, et non au SOI nº 2 — écrivez-nous.
