• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 05/12/2019

Initiez-vous à la certification logicielle

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Découvrez les principes de la certification aéronautique

Dans un précèdent chapitre, vous avez eu une présentation sur l’aspect sûreté de fonctionnement : à partir du niveau avion, il y a une approche descendante pour aller évaluer tous les éléments qui sont donc constitutifs de l’avion, puis une approche remontante afin de vérifier quand tous les objectifs de sûreté de fonctionnement sont tenus.

Les fondamentaux de la SDF
Approches montantes et descendantes
La propagation des fautes
La propagation des fautes

Ce schéma montre les différents niveaux d’évaluation des erreurs. Tout d’abord, une erreur dans le logiciel, que ce soit dans les données ou dans les codes, va être analysée pour évaluer son impact. À son tour au niveau système, cette anomalie sera évaluée par rapport à l’architecture système, par rapport à la fonction impactée par cette anomalie pour déterminer l’impact au niveau du fonctionnement du système, si cela crée une panne système ou pas. Et ensuite, au niveau avion, cette panne système sera évaluée là aussi par rapport à l’architecture de l’avion, pour déterminer son impact au niveau d’une condition de panne avion.

Classement des conditions de pannes

Pas d'effet sur la sécurité

Mineur

Majeur

Risqué

Catastrophique

Niveau de "probabilité qualitative" acceptable

Aucun niveau requis

 Probable

Eloigné

Très éloigné

Extrêmement improbable

Effets sur l'avion

Aucun effet sur la capacité opérationnelle ou la sécurité

Légère réduction des capacités fonctionnelles ou marges de sécurité

Réduction significative des capacités fonctionnelles ou marges de sécurité

Réduction importante des capacités fonctionnelles ou marges de sécurité

Atteinte du fuselage

Effets sur les passagers

Incommodation des passagers

Inconfort physique

Détresse physique / blessures légères

Blessure grave voire décès d'un passager

Nombreux décès

Effets sur l'équipage

 Pas d'effet

Légère augmentation de la charge de travail ou  des procédures de sécurité 

Inconfort physique et augmentation significative de la charge de travail 

Détresse physique ou charge de travail très lourde allant jusqu'à l'incapacité à accomplir certaines tâches

Blessures fatales / incapacité totale

Dans un précédent module, on vous a également expliqué les bases de la réglementation. Donc une seule panne ne peut pas conduire à une condition de panne catastrophique au niveau avion et on définit une occurrence acceptable d’une panne, 10-9 par million d’heures de vol pour des conditions de panne catastrophique, 10-7 pour des conditions de panne dangereuses.

Mais comment établir cette occurrence de panne sur du logiciel?

On considère que ce n’est pas possible. Cette approche n’est pas applicable aux logiciels. On va donc identifier les moyens acceptables de conformité qui seront reconnus par les autorités de certification pour évaluer les logiciels : c’est le DO-178 version C, qui est le standard maintenant pour l’évaluation des logiciels embarqués. De la même façon, on a un autre document, DO-254, qui est très proche du 178 mais qui, lui, s’applique au composants électroniques complexes.

Les recommandations de ce document sont orientées sur cinq principes :

  • orienté « processus ». Cela veut dire que la qualité du produit est liée à la qualité des processus, c’est-à-dire que l’on va s’intéresser autant au produit même qu’à toutes les phases d’élaboration de ce produit ;

  • principe de « fiabilité ». On a mis en place des activités qui permettent d’éviter d’introduire les erreurs dans le logiciel, mais également de définir les moyens de détection de ces erreurs et les activités pour éliminer, pour corriger le logiciel et vérifier que l’on a bien corrigé ces erreurs ;

  • le document « orienté objectifs » est le plus important. Ce document n’impose pas un cycle de vie logiciel, n’impose pas de faire certaines activités, n’impose pas des environnements, des outils, mais définit uniquement des objectifs ; et le développeur du logiciel doit mettre en place les activités, les moyens, définir les responsabilités pour atteindre cet objectif ;

  • les données du cycle de vie. Chaque activité va produire des données qui seront autant de preuves pour montrer que les objectifs sont satisfaits ;

  • implication de plusieurs acteurs: Toutes ces activités vont impliquer différents acteurs afin d’optimiser la non-introduction de panne, mais surtout la détection de ces pannes. On va voir donc la participation avec les équipes système, par exemple pour éviter de mauvaises interprétations des exigences système, de la vérification avec de l’indépendance, on va avoir également le rôle important de l’assurance qualité.

Processus logiciels: Combinaison de ces processus pour définir le cycle de vie du logiciel
Processus logiciels : combinaison de ces processus pour définir le cycle de vie du logiciel

Maintenant, nous allons vous illustrer chacun de ces 5 principes, en commençant par le principe n°1, orienté « processus ».

Que sont ces processus logiciel ?

Nous allons retrouver le processus de planification, qui va permettre de définir les activités, les méthodes, les environnements, les responsabilités., l’ensemble des processus de développement portant sur la spécification système jusqu'au code objet exécutable chargé sur la cible.

Tout au long de ces étapes de développement, on va impliquer les processus intégraux que sont les activités de vérification, de gestion de configuration, de données de cycle de vie logiciel, les activités d’assurance qualité qui vont permettre de faire un suivi de l’application des processus. Il reste à mentionner un processus un petit peu particulier qui est la communication avec les autorités de certification pour assurer l’approbation du logiciel.

Pour respecter le principe de fiabilité, il faut éviter l’introduction des erreurs et définir les moyens pour détecter ces erreurs, dans la partie développement que l’on vient de voir.

Du côté de la détection des erreurs, le DO-178 est très orienté vérification. La vérification est une combinaison d’activités statiques, dynamiques, d’analyses quantitatives et qualitatives.

On distingue trois types d’activités :

  • les revues qui sont une activité dite de « lecture » d’une donnée par une personne indépendante en fonction de la criticité du logiciel ; c’est davantage une évaluation qualitative ;

  • des activités d’analyse, donc un examen détaillé d’une donnée sur des critères particuliers, par exemple les standards de développement, les standards de codage. Cela peut éventuellement être effectué à l’aide d’un outil d’analyse, donc typiquement une analyse qui est davantage quantitative ou reproductible ;

  • la troisième méthode est le test, c’est l’exécution du logiciel ou du composant du logiciel afin d’obtenir des résultats que l’on va comparer avec les résultats attendus définis au regard des exigences.

Le DO-178 insiste sur la nécessité de développer les tests basés sur les exigences. Les exigences, à différents niveaux, soit au niveau du logiciel complet, soit au niveau d’un composant ou d’un sous-composant, définissent le comportement attendu. Donc les tests vont mettre en œuvre ce composant, ce logiciel, sur un certain nombre de combinaisons d’entrées de transition entre différents modes. Tout cela est défini sur une stratégie de sélection des tests, qui est un échantillonnage de tous les cas possibles. On aura des classes d’équivalence de données numériques, des points singuliers, des valeurs limites, des transitions de modes, des combinatoires d’entrée logique.

Aspects logiciels de la certification

Pour illustrer le troisième principe, orienté « objectifs », prenons un exemple très classique : le code objet exécutable est conforme à ses exigences.

On pense tout de suite aux tests de la mise en œuvre du logiciel aux travers de différents scénarios.

La conformité au DO-178 est donc la satisfaction de cet objectif. Elle peut aussi se faire au travers d’autres activités, comme par exemple, utiliser un générateur de code qualifié. Un autre exemple consisterait à mener des vérifications au niveau des exigences comme de la simulation de modèles et, en respectant cette contrainte, en tirer crédit également sur la conformité de cause objet exécutable. Il est également possible de proposer des analyses formelles menées sur des modèles formels pour atteindre cet objectif.

Le principe suivant concerne la production du cycle de vie comme autant de preuves de satisfaction des exigences. Par exemple, on va produire des plans, on va enregistrer les exigences, on va produire des fichiers de code source, des données de tests, des résultats de vérification, également des enregistrements des défauts qui ont été identifiés.

Le dernier principe est l’implication de différents acteurs dans les activités pour satisfaire l’ensemble des objectifs. Il n’y a pas de règles sur l’organisation sur ce point. La seule contrainte concerne l’assurance qualité qui doit être suffisamment indépendante pour avoir moins de contraintes et plus librement pouvoir identifier des écarts par rapport aux plans qui ont été approuvés.

Il n’y a pas non plus, comme dans d’autres domaines, des critères sur la compétence des équipes. On considère que si les objectifs sont satisfaits, cela veut dire que l’on a choisi les bonnes personnes, on a le bon niveau de compétences pour mener des activités.

En résumé

L’introduction massive des systèmes embarqués, contrôlée par la réglementation, a amélioré la « safety »
L’introduction massive des systèmes embarqués, contrôlée par la réglementation, a amélioré la « safety »

En conclusion, je dirais que les chiffres montrent que l’ensemble de la réglementation et des moyens de conformité montrent l'efficacité de cette démarche.

L'Association internationale du transport aérien (IATA), association des compagnies aériennes,  recense moins de 0,4 accident par million d’heures de vol

L’introduction massive des systèmes embarqués, et notamment des logiciels, a même, on peut dire, amélioré la sûreté de fonctionnement.

À la question « qu’est-ce que coûte l’application du DO-178 ? », on peut tout à fait répondre que c’est le prix pour faire un produit fiable. Développer un produit certifié, c’est d’abord bien comprendre la réglementation et notamment les principes pour appliquer un cycle de vie et des activités qui sont vraiment pertinentes par rapport au produit lui-même. C’est mettre de la rigueur dans toutes les étapes du cycle de vie pour éviter d’introduire des erreurs, choisir les meilleurs moyens de vérification pour détecter les erreurs qui ont malgré tout été introduites, et enregistrer les preuves de toutes les activités qui ont été menées. Gardez en tête que toutes les activités peuvent avoir un impact sur la sûreté de fonctionnement. La rigueur doit être présente dans toutes les étapes.

Pour développer des logiciels critiques, des outils sont nécessaires (compilateur, générateur de code, ...). Ceux-ci doivent alors eux aussi répondre à des exigences lorsqu'ils participent à une démarche de certification...

Exemple de certificat de réussite
Exemple de certificat de réussite