Motivations

Les activités de validation et de vérification, menées au cours du développement des

systèmes AIRBUS, mêlent revues, activités de traçabilité, analyse statique de code et test.

L’activité de test est réalisée à tous les niveaux (Avion, Système, Equipement) du processus de

développement (Figure 2.4). A chaque phase de test correspond une problématique spécifique

liée aux objectifs de validation ou de vérification définis. Nous nous intéressons aux

problématiques liées à la génération de test de validation de la spécification détaillée des

systèmes et à la vérification des systèmes au cours des essais au sol sur la chaîne d’assemblage

finale de l’avion.

Validation de la spécification détaillée des systèmes

La spécification détaillée formelle des systèmes AIRBUS est écrite en utilisant

l’environnement SCADE. Certains comportements physiques peuvent être analysés sur des

modèles SIMULINK. AIRBUS utilise le générateur de code qualifié SCADE pour les systèmes décrits

2.4. Motivations 53

Par ailleurs, quel que soit le formalisme utilisé et le type de système traité, seuls des tests

fonctionnels sont réalisés sur l’ensemble des activités de test réalisées au cours de cette étape de

validation. Les tests sont réalisés sur le simulateur système de bureau dit « OCASIME » ; des

activités de validation peuvent être menées à l’aide d’outils disponibles au niveau de

l’environnement SCADE, à savoir :

− tests à l’aide du simulateur SCADE,

− preuve de propriétés à l’aide de SCADE Verifier.

La réalisation des activités de V&V dynamique, au cours de la validation, nécessite la

définition de vecteurs ou données de tests pertinents puisqu’il s’agit d’effectuer des campagnes

de tests dans des environnements de simulation. Or, la définition de jeux de d’essai (les données

de test et l’oracle) permettant de valider une spécification détaillée formelle nécessite un effort

important. En effet, cette définition est confrontée aux problèmes suivants :

− comment être certain que toutes les fonctions ont été correctement testées ?

− comment s’assurer que le système ne se retrouve pas dans certaines configurations

redoutées qui pourraient nuire à la sûreté de fonctionnement de l’avion ?

Afin de répondre à ces questions, AIRBUS propose de mener des activités de vérification et

validation guidées par les fonctions du système et de définir explicitement des critères d’arrêt,

c’est à dire des critères capables de s’assurer qu’un nombre suffisant de tests a été réalisé afin de

garantir le niveau recherché de sûreté de fonctionnement du système.

Dans ce contexte, sera très bénéfique toute méthode ou outil permettant d’aider, au cours du

processus de définition des tests et aux activités d’analyse de couverture, à l’évaluation de la

couverture des :

− spécifications détaillées formelles vis-à-vis des exigences liées aux fonctions du système ;

− jeux d’essai définis dans le LTR vis-à-vis des spécifications détaillées formelles.

Nous proposons, dans le chapitre 3, une méthodologie d’aide à la validation des systèmes

basée sur une approche d’analyse de testabilité des spécifications flot de données.

Vérification des systèmes sur la FAL (Final Assembly Line)

Le gain de temps est un facteur très important au cours de la vérification des systèmes sur la

chaîne d’assemblage finale. En effet, toute activité raccourcie permet de réduire le temps de

livraison de l’avion, ce qui est un facteur important de réduction des coûts. C’est ainsi qu’AIRBUS

cherche sans cesse à améliorer et à automatiser ses outils de test sur la FAL des différents

programmes (types d’avion).

54 Chapitre 2. Contexte industriel

Cependant, la conception des essais et une partie de l’activité de diagnostic est basée sur

l’expertise humaine (compréhension, expériences, …). Toutefois, la méthodologie adoptée pour

la conception des essais consiste à :

− limiter le nombre de configurations au cours de la vérification des systèmes installés à

bord. L’idée est de pouvoir exploiter au maximum une configuration, c’est à dire, exécuter

un maximum d’essais avec une configuration donnée. Par exemple, une configuration

peut être requise pour tester le système hydraulique de l’avion ; une pour les commandes

de vol ; et une autre pour les bus d’acquisitions;

− rationaliser les essais au cours de leur définition. Cette phase passe par une bonne

répartition et un bon ordonnancement des tests à exécuter.

Quant à la partie non automatisée de la phase diagnostic, elle dépend du technicien de test

assurant les activités de vérification d’un système. Selon le vécu de la personne, l’approche de

diagnostic adoptée face à une défaillance du système peut être différente. De ce fait, l’efficacité

d’une approche de diagnostic ne dépend que de l’expérience du testeur.

Dans ce contexte, il est important de définir des concepts permettant, au cours des activités

de définitions de tests et de diagnostic de fautes, de :

− aider à la définition d’essais pertinents ;

− aider à la détection et à l’identification de tests redondants ;

− guider le processus d’identification des composants (ou ressources) défaillants du

système ;

− aider à l’amélioration de la précision du diagnostic d’un système.

Nous proposons une méthodologie basée sur certains concepts d’analyse de testabilité dans

l’objectif de fournir, pour un système, des informations sur la qualité des essais depuis leur

conception jusqu’au diagnostic des ressources tout au long du processus de vérification sur la

Chapitre 3

Aide à la génération de tests de validation

La validation d’un système AIRBUS, au cours de sa conception, est le processus qui permet

d’assurer que les exigences spécifiées sont suffisamment correctes et complètes afin qu’il

réponde aux exigences de navigabilité requises [ABD06]. Les techniques de V&V menées au

cours de cette phase, notamment la technique dynamique (test), ont pour objectif de montrer

que l’ensemble des fonctions du système sont correctement spécifiées et de fournir des

assurances sur le comportement du système en termes de sûreté de fonctionnement. De ce fait,

les jeux d’essai ou tests fonctionnels définis pour atteindre ces objectifs doivent être les plus

pertinents possibles.

Or, la définition des tests fonctionnels pour la validation se fait de façon manuelle à partir

des exigences fonctionnelles textuelles du système. Ceci conduit à un processus de test coûteux

en termes de ressources. En effet, le manque d’outillage pour cette phase fait que certains tests

sont redondants ou oubliés dans les phases initiales de définition des tests, malgré l’existence de

guides méthodologiques. De plus, les critères d’arrêt du test sont empiriques : couverture

fonctionnelle des tests vis-à-vis des exigences du système difficilement évaluable, couverture

structurelle de la spécification non établie. Malgré tout, les tests définis sont complets à l’issue

des différentes campagnes de test réalisées tout au long du développement mais au prix d’un

effort conséquent.

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 53-57)