Développement des systèmes A IRBUS

Les systèmes avioniques développés par AIRBUS peuvent être regroupés en trois grandes

catégories de systèmes selon leurs fonctions :

− des systèmes de type contrôle/commande (commandes de vol, train d’atterrissage,

gestion des fonctions moteur, etc.) ;

− des systèmes de gestion de l’information des données (calculateur d’alarmes, calculateur

de maintenance, etc.) ;

− des systèmes gérant les communications (gestion des données bord/sol, l’avionique

modulaire intégrée, etc.).

Dans la suite de cette section, nous exposons les contraintes réglementaires qui doivent être

prises en compte au cours du développement des systèmes AIRBUS, puis nous présentons les

activités de validation et de vérification du cycle de développement des systèmes et nous

insistons sur les différentes étapes de validation et de vérification. Nous nous intéressons par la

suite aux deux axes qui ont guidé les travaux de cette thèse : le cycle de validation des

spécifications et le processus de vérification au cours des essais au sol des systèmes.

2.2.1 Contraintes réglementaires

Le développement des systèmes avioniques est soumis à des exigences de qualité. Le rôle

des autorités de certification est de formuler ces exigences et de s’assurer que les avions

construits sont conformes à la règlementation. L’autorité de certification est l’EASA (European

Aviation Safety Agency) pour l’Europe et la FAA (Federal Aviation Administration) pour les USA.

Ainsi, les règles que l’avionneur devra suivre durant toute la phase de développement sont

définies. Lorsque les exigences de l’autorité sont respectées, celle-ci délivre un certificat de

navigabilité qui permettra à l’avion de voler dans l’espace aérien qu’elle régit.

Le document ARP4754 [SAE96] définit les recommandations sur le processus de

développement des systèmes avioniques. AIRBUS se base sur ces recommandations pour définir

les règles de développement en concordance avec les exigences des autorités de certification. La

directive AIRBUS ABD200 [ABD06] décrit les exigences de développement de ses systèmes.

Ces recommandations s’organisent autour d’un processus d’évaluation de la sûreté de

fonctionnement d’un système au cours du développement. Ce processus est basé sur trois

2.2. Développement des systèmes Airbus 45

Safety Assessment) et la SSA (System Safety Assessment). Ces analyses s’intéressent aux FC

(Failure Conditions) correspondant aux différentes situations redoutées associées aux fonctions

réalisées par le système. Ces FC sont classées selon leur gravité en termes de sûreté de

fonctionnement.

La norme DO-178B [RTC92], document de référence pour la certification des logiciels, se

base sur la classification des FC pour définir les différents niveaux de criticité des systèmes

(logiciels) embarqués. Le tableau ci-dessous propose cette classification avec le niveau de

criticité associé.

Tableau 2.1 : Classification des défaillances

Gravité Effet de la défaillance Objectifs Niveau

Catastrophique L’avion ne peut voler de façon sûre, perte de

l’avion, de l’équipage ou de passagers

10-9 A

Dangereux Réduction importante des marges de sécurité

ou des fonctions, augmentation importante

de la charge de travail pour l’équipage,

blessures sévères

10-7 B

Majeur Réduction significative des marges de

sécurité ou des fonctions, augmentation de la

charge de travail pour l’équipage, inconfort

ou blessures possibles

10-5 C

Mineur Réduction légère des marges de sécurité ou

des fonctions, augmentation de la charge de

travail pour l’équipage, inconfort

10-3 D

Par conséquent, les activités de validation et de vérification des systèmes requises par la

règlementation dépendent du niveau de criticité (DO-178B). En effet, Cette norme définit les

objectifs et les activités du processus de V&V des systèmes (logiciels) embarqués. En

considérant les deux systèmes présentés dans la section précédente (section 2.1), les systèmes

de commande vol sont de niveau A et le système d’orientation des roues avant est de niveau B.

2.2.2 Objectifs du processus de V&V selon la DO-178B

Le but du processus de validation et de vérification des logiciels est de détecter et de

signaler les erreurs qui ont pu être introduites au cours du développement. La correction des

erreurs est une activité de processus de développement des logiciels. D’une manière générale,

les objectifs du processus de V&V sont de vérifier que :

− Les exigences du système allouées au logiciel ont été prises en compte et développées

46 Chapitre 2. Contexte industriel

− Les exigences « haut niveau » du logiciel ont été prises en compte et développées dans

l’architecture et les exigences « bas niveau » du logiciel. Il existe des processus où un ou

plusieurs niveaux d’exigences du logiciel peuvent être développés entre les exigences

« haut niveau » et les exigences « bas niveau ». Dans ce cas, les niveaux successifs des

exigences sont développés tels que successivement chaque niveau inferieur satisfait les

exigences du niveau supérieur. Cet objectif n’est pas considéré lorsque le code est généré

directement à partir des exigences de « haut niveau ».

− L’architecture et les exigences « bas niveau » ont été prises en compte et développées

dans le code du logiciel.

− Le code exécutable satisfait les exigences du logiciel.

Les moyens techniques déployés à travers les activités de V&V pour l’atteinte de ces

objectifs sont définis en fonction du niveau de criticité du logiciel.

2.2.3 Activités du processus de V&V selon la DO-178B

Les objectifs du processus de V&V sont réalisés à travers une combinaison de revues,

d’analyses, de définition et d’exécution de tests et de procédures. Les revues et les analyses

permettent l’évaluation, la précision, la complétude et la vérifiabilité des exigences, de

l’architecture et du code source du logiciel. La définition des tests permettent, en plus, une

évaluation de la cohérence et la complétude interne des exigences. L’exécution des procédures

de test permet une démonstration de la conformité avec les exigences.

Le processus de V&V permet de réaliser deux types de traçabilité entre l’implantation du

logiciel et la vérification des exigences :

− la traçabilité entre les exigences du logiciel et les tests est réalisée à l’aide d’une analyse

de couverture des exigences afin d’assurer la prise en compte de toutes les exigences du

logiciel et seulement ces exigences ;

− la traçabilité entre la structure du code et les tests est réalisée à l’aide d’une analyse de

couverture structurelle afin d’évaluer les critères de couverture des tests et d’identifier

d’éventuel code « mort ».

2.3. V&V et processus de développement Airbus 47

Dans le document Contribution à l'analyse de testabilité des systèmes réactifs temps-réel : Aide à la validation et à la vérification de systèmes (Page 45-48)