THÈSE
THÈSE
En vue de l’obtention duDOCTORAT DE L’UNIVERSIT´
E DE TOULOUSE
D´elivr´e par : l’Universit´e Toulouse 3 Paul Sabatier (UT3 Paul Sabatier)
Pr´esent´ee et soutenue le 16/07/2018 par :
Robin Bussenot
Rendre Agile les tests d’int´egration des syst`emes avioniques par des langages d´edi´es
JURY
Ana Rosa Cavalli Professeur,
Institut T´el´ecom Sud Paris
Rapporteur
Herv´e Leblanc Maˆıtre de conf´erence,
Universit´e Paul Sabatier
Co-directeur
Christian Percebois Professeur,
Universit´e Paul Sabatier
Directeur
Laurent R´eveill`ere Professeur,
Universit´e de Bordeaux
Rapporteur
S´ebastien Salva Professeur,
Universit´e d’Auvergne
Examinateur H´el`ene Waeselynck Directrice de recherche CNRS,
LAAS
Examinatrice
Jean-Pierre Gaubert Ing´enieur, Airbus Invit´e
´
Ecole doctorale et sp´ecialit´e :
MITT : Domaine STIC : R´eseaux, T´el´ecoms, Syst`emes et Architecture Unit´e de Recherche :
Institut de Recherche en Informatique de Toulouse Directeur(s) de Th`ese :
Christian Percebois et Herv´e Leblanc Rapporteurs :
R´
esum´
e
Dans l’ing´enierie avionique, les tests d’int´egration sont cruciaux : ils permettent de s’assurer du bon comportement d’un avion avant son premier vol, ils sont n´ecessaires au processus de certification et permettent des tests de non-r´egression `a chaque nouvelle ver-sion d’un syst`eme, d’un logiciel ou d’un mat´eriel. La conception d’un test d’int´egration coˆute cher car elle mˆele la r´ealisation de la proc´edure, le param´etrage de nombreux outils coupl´es au banc de test ainsi que l’adressage des interfaces du syst`eme test´e. Avec des proc´edures de test ´ecrites en langage naturel, l’interpr´etation des instructions d’un test lors de son rejeu manuel peut provoquer des erreurs coˆuteuses `a corriger, en raison notam-ment des actions pr´ecises `a entreprendre lors de l’ex´ecution d’une instruction de test. La formalisation et l’automatisation de ces proc´edures permettraient aux ´equipes de testeurs de se concentrer sur la r´ealisation de nouveaux tests exploratoires et sur la mise au point de tels syst`emes au plus tˆot. Or, un syst`eme avionique est compos´e de plus d’une centaine de syst`emes embarqu´es, chacun concernant des comp´etences sp´ecifiques.
Notre contribution est alors un framework orchestrant les langages de test d´edi´es `a l’int´egration de syst`emes avioniques dans une vision Agile. Nous introduisons tout d’abord le concept de langage sp´ecifique `a un domaine (Domain Specific Language ou DSL) et montrons comment nous l’utilisons pour la formalisation des proc´edures de test d´edi´ees `
a un type de syst`eme particulier. Ces langages devront pouvoir ˆetre utilis´es par des tes-teurs avioniques qui n’ont pas forc´ement de comp´etences en informatique. Ils permettent l’automatisation des tests d’int´egration, tout en conservant l’intention du test dans la des-cription des proc´edures. Puis, nous proposons l’approche BDD (Behavior Driven Develop-ment ) pour valider l’int´egration de syst`emes par sc´enarios comportementaux d´ecrivant le comportement attendu de l’avion.
Nous nommons Domain Specific Test Languages (DSTL) les langages utilis´es par les testeurs. A chaque syst`eme (ATA ou Air Transport Association of America) correspond un DSTL m´etier. Un premier DSTL concernant les syst`emes de r´egulation de l’air a ´et´e d´evelopp´e enti`erement en tant que preuve du concept `a partir de proc´edures existantes pseudo-formalis´ees. L’exp´erimentation s’est poursuivie avec les calculateurs standardis´es IMA (Integrated Modular Avionic) pour lesquels les proc´edures de test sont d´ecrites en langage naturel et sont donc non automatisables. A partir d’un corpus de proc´edures, nous proposons un premier processus empirique d’identification des patrons de phrases peuplant
un DSTL. Le corpus fourni est compos´e de dix proc´edures totalisant 108 chapitres de test et 252 tests ou sous-tests comportant au total 3708 instructions pour 250 pages Word. Rendre Agile ces tests d’int´egration consiste `a proposer une approche collaborative pour formaliser un DSTL que ce soit pour les patrons de phrases de la grammaire concr`ete ou pour les patrons de transformations vers des langages ex´ecutables.
Abstract
In avionics engineering, integration tests are crucials : they allow to ensure the right behavior of an airplane before his first flight, they are needed to the certification process and they allow non-regression testing for each new version of a system, of a software or of a hardware. The design of an integration test is expensive because it involves the implementation of the procedure, the configuration of tools of the bench and the setup of the interfaces of the system under test. With procedure written in natural language, the interpretation of statements of a test during the manual execution can lead to mistakes that are expensive to fix due to accurate actions needed to perform a statement. The formalization and the automation of those procedures allow testers team to focus on the implementation of new test cases.
First of all, we introduce Domain Specific Language (DSL) and show how we use it to formalize tests procedures dedicated to a kind of system. Those languages should be able to be use by avionic testers which do not necessarily have programming skills. They allow test automation, while maintaining test intention in the test description. Then, we proposed a BDD (Behavior Driven Development) approach to validate the integration of systems thanks to behavioral scenarios describing the expected behavior of the airplane. Our contribution is a framework which orchestrate DSLs dedicated to integration test of avionic systems in an Agile vision.
We named Domain Specific Test Languages (DSTL), languages used by expert testers. For each system (ATA ou Air Transport Association of America) corresponds a DSTL business. A first DSTL about the validation of airflow control systems has been developed as a proof of concept from existing procedures pseudo-formalized. The experimentation has been continued with IMA (Integrated Modular Avionic) calculators for which test procedures are written in natural language and thus are not automatable. From a corpus of procedures, we propose a first empirical process to identify sentence patterns composing the DSTL. The corpus provided is composed by ten procedures totaling 108 test chapters and 252 tests or subtests involving 3708 statements for a total of 250 Word pages. Make Agile integration tests in this context consist to propose a collaborative approach to formalize a DSTL and to integrate it in the orchestration framework to generate automatically the glu code.
Remerciements
En premier lieu, je tiens `a adresser mes remerciements `a Monsieur Percebois et Mon-sieur Leblanc, respectivement directeur et encadrant de cette th`ese. Ils ont su me soutenir, m’aider et me guider tout au long de ce travail. J’associe `a ces remerciements toutes les personnes du jury qui ont permis la validation de cette th`ese.
Je tiens ´egalement `a remercier Jean-Pierre Gaubert, responsable d’une ´equipe d’int´ e-gration Airbus, de m’avoir fait confiance et de m’avoir donn´e l’opportunit´e d’exp´erimenter mes travaux dans un contexte industriel. De mˆeme, j’aimerais remercier tous les acteurs du projet ACOVAS qui m’ont aiguill´es grˆace `a leurs exp´eriences et qui m’ont permis d’ap-pr´ehender l’industrie avionique et ses besoins.
J’aimerais remercier toutes les personnes pr´esentes `a mes cˆot´es tout au long de mes ´
etudes. J’adresse toute ma reconnaissance `a Tariq qui a su ˆetre l`a quand j’en avais besoin, `
a Xavier qui m’a aid´e `a garder le cap pour atteindre mes objectifs et `a Vanessa, sa compagne, pour sa bonne humeur et les relectures effectu´ees lors de la r´edaction de ce manuscrit.
Mes remerciements vont aussi `a ma famille et principalement `a mes parents qui ont ´et´e pr´esents dans les bons comme dans les mauvais moments et qui m’ont support´e `a chaque instant. Je les remercie de leur patience et de m’avoir donn´e la chance d’accomplir toutes ces ann´ees d’´etudes.
Mes derniers remerciements vont `a ma compagne, Charl`ene, qui a toujours ´et´e pr´esente pour moi et qui m’encourage et me motive dans tout ce que j’entreprends. La patience et le soutien dont elle a fait preuve durant cette th`ese ont ´et´e infaillibles et m’ont donn´e la force pour achever ce travail.
Table des mati`
eres
Introduction 13
1 Tests pour l’ing´enierie des syst`emes avioniques 17
1.1 Syst`eme avionique : production, caract´eristiques et
nouvelles infra-structures . . . 18
1.1.1 Processus de d´eveloppement : les cycles en V . . . 18
1.1.2 Caract´eristiques d’un syst`eme avionique . . . 21
1.1.3 D´ecoupage d’un syst`eme avionique . . . 22
1.1.4 Diff´erents types d’architecture avionique . . . 25
1.1.5 Interface Control Document (ICD) . . . 27
1.1.6 Les phases de test . . . 28
1.2 Un focus sur les tests d’int´egration . . . 30
1.2.1 Les phases de test d’int´egration . . . 31
1.2.2 In-the-Loop testing . . . 33
1.2.3 Le banc de test . . . 35
1.2.4 Des exigences aux proc´edures de test . . . 36
1.2.5 Les langages de test . . . 37
1.3 Introduction du g´enie logiciel dans les tests avioniques . . . 38
1.3.1 Pour le test de plates-formes IMA . . . 38
1.3.2 Par l’utilisation de l’ing´enierie des mod`eles . . . 39
1.3.3 Par l’utilisation des m´ethodes agiles . . . 41
1.4 Un framework BDD pour la conception de test d’int´egration . . . 42
1.4.1 Un framework de langages de test d’int´egration . . . 43
1.4.2 Une famille de langages de haut niveau . . . 44
1.5 Conclusion . . . 45
2 Orchestration de langages de test m´etier dans une approche comporte-mentale 47 2.1 Domain Specific Language (DSL) . . . 48
2.1.2 B´en´efices attendus . . . 50
2.1.3 Fronti`ere avec les langages de programmation classiques . . . 51
2.1.4 Domaines d’application . . . 52
2.1.5 Impl´ementation d’un DSL . . . 54
2.1.6 Apport des DSL aux tests d’int´egration avionique . . . 58
2.2 Behavior Driven Development (BDD) . . . 59
2.2.1 Le BDD, une alternative au Test Driven Development . . . 59
2.2.2 L’approche BDD . . . 60
2.2.3 Outils et framework BDD . . . 61
2.3 Choix de l’outil pour la conception de langages . . . 62
2.3.1 Outils disponibles . . . 62
2.3.2 Un exemple JBehave impl´ement´e avec Xtext et MPS . . . 63
2.3.3 R´esultat de l’exp´erimentation . . . 70
2.4 Une approche BDD pour les tests d’int´egration syst`eme . . . 74
2.4.1 Sch´ema global du framework . . . 74
2.4.2 B´en´efices attendus . . . 76
3 Exp´erimentation du framework sur l’ATA 21 77 3.1 Emergence du langage pivot . . . 78
3.1.1 Contexte . . . 78
3.1.2 Conception du langage pivot . . . 80
3.1.3 Grammaire des instructions du langage . . . 82
3.1.4 Syntaxe concr`ete et ´editeurs projectionnels . . . 86
3.1.5 Formalisation d’un ICD et des outils externes . . . 87
3.1.6 S´emantique des instructions du langage . . . 90
3.2 Le DSTL ATA 21 . . . 91
3.2.1 Conception du langage ATA 21 . . . 92
3.2.2 Grammaire du DSTL ATA 21 . . . 94
3.2.3 M´ecanisme d’alias des param`etres avioniques . . . 96
3.2.4 Exemple de cas de test . . . 97
3.3 Chaˆıne de transformations du framework . . . 99
3.3.1 Du langage DSTL ATA 21 vers le langage pivot . . . 99
3.3.2 Exemple de transformation en langage pivot . . . 102
3.3.3 Du langage pivot vers SCXML . . . 102
3.3.4 Du langage pivot vers Python . . . 107
3.4 Conclusion . . . 110
4 Exp´erimentation de la formalisation d’un DSTL pour l’ATA 42 113 4.1 Pr´esentation du corpus des proc´edures . . . 114
4.1.1 Structuration des proc´edures existantes . . . 115
4.1.3 M´etriques du corpus . . . 117
4.2 Structure g´en´erique d’un DSTL . . . 117
4.2.1 Concepts du langage core . . . 118
4.2.2 Contraintes s´emantiques . . . 120
4.2.3 Tra¸cabilit´e des objectifs de test . . . 122
4.2.4 Composition des langages dans le framework . . . 123
4.3 Outils NLP pour l’identification des instructions ATA 42 . . . 125
4.3.1 Utilisabilit´e des outils NLP . . . 126
4.3.2 Instructions Step . . . 127
4.3.3 Instructions Trace . . . 129
4.3.4 Instructions Check et Log . . . 131
4.4 Carte conceptuelle des instructions ATA 42 . . . 132
4.4.1 Processus de cr´eation de la carte conceptuelle . . . 133
4.4.2 Instructions Step . . . 133
4.4.3 Instructions Trace . . . 136
4.4.4 Instruction Log . . . 137
4.4.5 Instruction Check . . . 140
4.5 Premi`ere validation par les testeurs . . . 141
4.6 Conclusion . . . 146
Conclusion 149
Introduction
Les syst`emes composant un a´eronef sont critiques, embarqu´es, r´eactifs et temps-r´eel. Le d´ecoupage de l’a´eronef en syst`emes, sous-syst`emes, puis en ´equipements est ´etabli lors de la phase de sp´ecification du syst`eme global. Une fois les fonctions de l’avion identifi´ees, elles sont regroup´ees en plusieurs domaines. Ces domaines correspondent `a la classifica-tion ATA (Air Transport Associaclassifica-tion of America) qui propose un d´ecoupage des syst`emes d’un avion en 100 chapitres diff´erents. A titre d’exemple, le syst`eme de l’a´eronef inclut les domaines suivants : air conditionn´e et pressurisation, vol automatique, communications, g´en´eration ´electrique, commandes de vol, avionique modulaire int´egr´e . . . La criticit´e des syst`emes avioniques implique qu’ils doivent ˆetre pr´ealablement certifi´es pour qu’un avion soit commercialisable. La v´erification et la validation des syst`emes composant un domaine, puis de l’int´egration correcte de ces syst`emes, sont pr´epond´erantes pour garantir la sˆuret´e de fonctionnement d’un avion en toutes circonstances.
Le test est l’activit´e essentielle du processus de v´erification et de validation lors de l’´etape d’assemblage des sous-syst`emes d’un avion. Tout au long du cycle de d´eveloppement, chacun des syst`emes est test´e en isolation pour v´erifier son ad´equation aux sp´ecifications. Ces syst`emes sont ensuite assembl´es par domaine dans une phase dite d’int´egration. Nous nous sommes int´eress´es aux tests r´ealis´es durant cette phase. Ces tests sont cruciaux car ils permettent les derni`eres v´erifications avant le premier vol. Les erreurs qui ne sont pas d´etect´ees `a ce moment peuvent alors ˆetre extrˆemement coˆuteuses car elles sont susceptibles de causer des pertes humaines, mat´erielles et des dommages environnementaux.
Les tests d’int´egration sont ex´ecut´es `a travers un banc de test. Un banc interagit avec le syst`eme test´e en s’appuyant sur ses interfaces de communication. Il lie le syst`eme `a une simulation temps-r´eel qui ex´ecute artificiellement les conditions environnementales et les comportements des syst`emes qui ne sont pas encore int´egr´es. Un test d’int´egration n´ecessite de configurer les interfaces du banc pour ´etablir la connexion avec le syst`eme test´e et de coordonner la simulation temps-r´eel et les actions `a r´ealiser pour obtenir le comportement d´esir´e. La plupart du temps, ces comportements sont valid´es a posteriori par un expert `a partir de donn´ees d’ex´ecution sauvegard´ees par le banc.
L’ex´ecution manuelle de ces tests est fastidieuse car elle demande de r´ealiser des actions minutieuses ou dans un bref d´elai, comme c’est le cas pour la collecte des r´esultats au cours de l’ex´ecution. De plus, une grande partie des proc´edures de test d’int´egration sont r´edig´ees
en langage naturel, moyen d’expression porteur d’ambigu¨ıt´e o`u l’interpr´etation de chacun entre en jeu. Les erreurs pouvant intervenir lors de l’interpr´etation d’une instruction, lors de la manipulation du banc ou du syst`eme et lors de la collecte de r´esultats peuvent rendre caduque l’ex´ecution d’un test, voire d’une campagne de tests. Le coˆut d’ex´ecution ´
elev´e de ces tests implique qu’ils sont rejou´es un minimum de fois. De plus, la conception d’une proc´edure de test n´ecessite un savoir-faire d’expert et du temps pour rendre explicite les proc´edures en langage naturel. La formalisation et l’automatisation de ces proc´edures permettraient aux ´equipes de testeurs de concevoir de mani`ere plus rapide et plus sˆure des proc´edures de test, de se concentrer sur la r´ealisation de nouveaux tests exploratoires et sur la mise au point de tels syst`emes au plus tˆot.
La formalisation des proc´edures a pour but de lever toute ambigu¨ıt´e. C’est la premi`ere ´
etape pour les automatiser. Les experts concevant ces proc´edures connaissent les syst`emes test´es et les bancs de tests utilis´es, mais n’ont cependant pas de comp´etences en program-mation. Peu de langages de programmation sont d´edi´es aux tests des syst`emes embarqu´es et ils ne permettent pas aux experts de participer activement `a la conception des proc´ e-dures de test automatisables. Dans un premier temps, nous avons propos´e d’utiliser les DSL (Domain Specific Languages) pour formaliser les proc´edures de test sp´ecifiques `a chaque ATA. Puisque ces langages sont proches du niveau du langage naturel utilis´e des testeurs experts et proches des exigences, nous avons nomm´e ces langages DSTL (Domain Specific Test Languages). Ce concept sera pr´esent´e au chapitre 2 de la th`ese. L’´elaboration d’un DSTL `a partir de la donn´ee de dizaines de proc´edures de test en langage naturel fera l’objet du chapitre 4.
Comme ´ecrit pr´ec´edemment, les tests d’int´egration permettent de s’assurer du bon comportement d’un avion avant son premier vol. Ils sont n´ecessaires au processus de certi-fication et permettent des tests de non-r´egression `a chaque nouvelle version d’un syst`eme, d’un logiciel ou d’un mat´eriel. L’automatisation des tests d’int´egration repr´esente alors un enjeu fondamental, que ce soit dans leur ex´ecution et dans leur verdict. L’automatisation de l’ex´ecution des tests r´eduit consid´erablement les coˆuts d’int´egration des syst`emes. Elle a aussi pour cons´equence de faciliter le rejeu des tests pour augmenter la confiance lors de la mise en production d’un ensemble de syst`emes complexes. Les experts en charge de ces tests disposeront ainsi de plus de temps pour rejouer un bug et en d´ecouvrir les causes. Nos DSTL sont alors orchestr´es dans un framework en charge de leur automatisation. Ce framework offre trois niveaux de langage, du plus ubiquitaire aux langages de script sp´ecifiques `a un banc de test. La chaˆıne de transformations de programmes est acc´el´er´ee et simplifi´ee grˆace `
a la donn´ee d’un langage dit pivot accessible aux programmeurs testeurs. Le framework est pr´esent´e au chapitre 2. Le langage pivot combin´e `a des patrons de transformation vers des automates temporis´es facilite la production de scripts ex´ecutables comme d´emontr´e au chapitre 3.
Le premier chapitre de cette th`ese d´ecrit les processus de d´eveloppement n´ecessaires `
a la conception d’un avion et la place pr´epond´erante des tests dans ces processus. Diff´ e-rentes approches concernant la formalisation et l’automatisation des tests sont pr´esent´ees
et discut´ees. Nous avons choisi l’ing´enierie des langages pour formaliser et orchestrer les diff´erents langages de test d´edi´es aux ATA. Le deuxi`eme chapitre d´etaille cette contribu-tion en pr´esentant, tout d’abord, le concept de DSTL, puis leur orchestration. Le troisi`eme chapitre montre la preuve du concept sur le d´eveloppement complet d’un premier langage de haut niveau d´edi´e au syst`eme de r´egulation de l’air en cabine, jusqu’`a la g´en´eration de code ex´ecutable pour plusieurs types de banc. Le dernier chapitre exp´erimente et ´ebauche un processus de d´eveloppement d´edi´e `a la conception de DSTL `a partir d’un corpus de proc´edures existantes en langage naturel pour un nouvel ATA.
Ces travaux ont ´et´e conduits dans le cadre du projet FUI ACOVAS (outil Agile pour la COnception et la VAlidation Syst`eme). Ce projet a pour objectif de concevoir une plate-forme de validation et d’int´egration syst`eme inspir´ee des m´ethodes agiles. Cette agilisation concerne aussi bien les fonctionnalit´es d’un banc que les processus de d´eveloppement d´edi´es aux proc´edures de test. Rendre Agile les tests d’int´egration des syst`emes avioniques par des langages d´edi´es constitue notre contribution `a ce projet. Le BDD (Behavior Driven Development ) propose que les experts d’un domaine puissent d´ecrire leurs besoins dans un langage ubiquitaire que les programmeurs testeurs transforment en tests automatis´es. Les tests d’acceptation automatis´es deviennent alors le vecteur de communication pour les parties prenantes. Nous avons transpos´e cette approche issue de l’ing´enierie logicielle `a l’ing´enierie syst`eme pour la conception des tests d’int´egration de syst`emes avioniques.
Chapitre 1
Tests pour l’ing´
enierie des
syst`
emes avioniques
Nous abordons dans ce chapitre la mani`ere dont le d´eveloppement et les tests entrent en jeu dans le processus de conception d’un avion. Un avion est compos´e d’un certain nombre de syst`emes h´et´erog`enes produits par des fournisseurs diff´erents et int´egr´es par un avion-neur. Ces syst`emes sont embarqu´es, temps-r´eel, r´eactifs et critiques. Ces caract´eristiques demandent un effort et une rigueur accrus sur les tests pour des besoins de v´erification et de validation, mais aussi de certification car une seule d´efaillance peut entraˆıner des pertes humaines. Ces syst`emes doivent respecter des normes et des standards qui sont d´efinis par des organisations telles que EUROCAE, (EURopean Organisation for Civil Aviation Equipment [33]) ou encore RTCA (Radio Technical Commission for Aeronautics [64]).
Le test est une activit´e pr´epond´erante du processus de v´erification et de validation lors de la r´ealisation d’un avion. Pour autant, un effort d’automatisation des tests reste `a faire, en particulier sur les tests d’int´egration. Leur automatisation permettrait de r´eduire les coˆuts d’int´egration des syst`emes. L’automatisation a aussi pour cons´equence de faciliter le rejeu des tests pour augmenter la confiance lors de la mise en production d’un ensemble de syst`emes complexes.
Avant d’entrer dans le vif du sujet, nous pr´esentons les sp´ecificit´es du d´eveloppement avionique, en particulier les ´evolutions des architectures mat´erielles et logicielles permet-tant aux diff´erents syst`emes composant un avion de communiquer. Une fois les diff´erentes phases du processus de d´eveloppement pr´esent´ees (section 1.1), nous nous concentrerons sur notre champ d’´etude qui sont les activit´es li´ees aux tests d’int´egration (section 1.2). Nous positionnerons notre travail qui est un framework BDD (Behavior Driven Development ) pour la conception des campagnes de tests d’int´egration (section 1.4), apr`es avoir pr´esent´e diff´erents travaux sur la transposition du g´enie logiciel `a l’ing´enierie syst`eme (section 1.3).
1.1
Syst`
eme avionique : production, caract´
eristiques et
nouvelles infra-structures
Le processus de d´eveloppement d’un avion implique des dizaines de milliers de per-sonnes venant de sites, d’entreprises et mˆeme tr`es souvent de pays diff´erents. Dans un tel contexte, les erreurs de conception ou d’impl´ementation sont souvent dues `a des erreurs de communication. Le vocabulaire utilis´e diff`ere en fonction des m´etiers et des disciplines. On peut, par exemple, citer le cas du projet Mars Surveyor 98 visant `a envoyer sur l’orbite de Mars deux sondes spatiales. Un probl`eme logiciel s’´etant produit lors du calcul de l’alti-tude a caus´e la perte de la sonde Mars Climate Orbiter. Le rapport [78] produit quelques semaines apr`es, montre que la perte de la sonde est due `a une erreur de communication entre l’´equipe principale du projet bas´ee dans le Colorado et l’´equipe charg´ee du syst`eme de navigation bas´ee en Californie. Ces deux ´equipes utilisaient deux syst`emes d’unit´es de mesure diff´erents. L’´equipe en Californie utilisait le syst`eme anglo-saxon pour produire le syst`eme de navigation alors que le reste du syst`eme ´etait cod´e avec les unit´es du syst`eme m´etrique. Tout ceci montre que la communication est un point des plus importants dans le d´eveloppement de syst`emes complexes. C’est d’autant plus vrai pour les syst`emes critiques car leurs d´efauts peuvent causer la perte de vies humaines, engendrer des pertes mat´erielles importantes ou avoir des cons´equences environnementales graves [54].
Dans un autre rapport [45], Edward Weiler, qui ´etait `a l’´epoque directeur du pˆole espace `
a la NASA disait ”Les gens font parfois des erreurs”. Cependant, selon lui le probl`eme ne vient pas de l’erreur en elle-mˆeme mais plutˆot du fait qu’elle n’ait pas ´et´e d´etect´ee en amont durant le d´eveloppement. Edward Weiler met aussi en avant l’importance du processus de v´erification et de validation qui aurait dˆu r´ev´eler cette erreur si les activit´es de v´erification et de validation avaient ´et´e r´ealis´ees de mani`ere plus rigoureuse. Plus une erreur est identifi´ee tardivement, plus elle est coˆuteuse `a corriger.
Cette section aborde les aspects du processus de d´eveloppement et les caract´eristiques d’un syst`eme avionique. Nous ´etudions ensuite les diff´erentes g´en´erations d’architectures qui peuvent prendre place dans un avion. Pour qu’une erreur dans le comportement d’un syst`eme avionique soit d´etect´ee au plus tˆot, des activit´es de test prennent place tout `a long du cycle de d´eveloppement.
1.1.1 Processus de d´eveloppement : les cycles en V
Le processus de d´eveloppement d’un avion suit le mod`ele du cycle en V , comme pr´esent´e `
a la figure 1.1. Ce mod`ele permet de mettre en opposition le processus de d´eveloppement qui suit une approche descendante et le processus de v´erification et de validation qui suit une approche ascendante.
Le processus de d´eveloppement d’un avion commence par une phase de sp´ecification et de conception de l’avion dans sa globalit´e. Il se poursuit par un raffinement des sp´ecifications et de la conception de chaque syst`eme le composant. Ce raffinement a pour but de d´ecouper
ce syst`eme en entit´es plus petites et moins complexes, jusqu’`a arriver au bon niveau de granularit´e. Les syst`emes qui composent un avion sont divers ; ils incluent le plus souvent une partie mat´erielle et une partie logicielle. Ces deux parties sont d´evelopp´ees s´epar´ement puis sont assembl´ees durant la phase dite d’int´egration. Le logiciel permettra de piloter et de fournir la logique pour alimenter en donn´ees et contrˆoler les ´equipements mat´eriels qui `
a leur tour produiront des donn´ees qui seront fournies en entr´ee aux calculateurs. Figure 1.1 – D´eveloppement et activit´es de tests
Des documents sont r´edig´es tout au long de la phase descendante pour rendre compte des sp´ecifications du syst`eme et des choix de conception r´ealis´es.
Cette repr´esentation du processus de d´eveloppement pourrait laisser penser que les acti-vit´es de v´erification et de validation ne sont r´ealis´ees qu’une fois le d´eveloppement complet du syst`eme r´ealis´e. Ce n’est pas le cas. Pour anticiper les changements dus `a des choix erron´es de conception ou `a des exigences mal d´efinies, d’autres processus it´eratifs entrent en jeu `a chaque niveau de d´etail de la conception. Ces cycles it´eratifs sont repr´esent´es par les fl`eches de validation des besoins sur la figure 1.1.
Cette figure montre aussi les activit´es de test r´ealis´ees durant la phase ascendante du cycle en V . Ces activit´es sont regroup´ees selon les diff´erents niveaux d’int´egration d’un avion.
– Au niveau ´equipement, on retrouve les activit´es de test validant les applications logicielles et les plates-formes d’ex´ecution. Finalement, les tests de qualification ga-rantissent que les applications logicielles s’ex´ecutent correctement lorsqu’elles sont h´eberg´ees par une plate-forme mat´erielle pr´ealablement test´ee.
– Au niveau syst`eme, les tests s’assurent que les syst`emes produits sont corrects et qu’ils s’interfacent correctement avec les autres syst`emes de l’avion. Le niveau domaine int`egre les syst`emes d’un domaine et permet de r´ealiser les premiers tests au sol. – Au niveau avion, tous les syst`emes, pr´ealablement certifi´es, sont pr´esents dans une
Au niveau syst`eme, on retrouve un cycle en V par syst`eme `a d´evelopper. La figure 1.2 repr´esente le cycle en V pour un syst`eme donn´e. Dans ce cycle en V , on distingue deux autres processus respectant aussi le mod`ele en V : un pour le d´eveloppement du mat´eriel et un pour le d´eveloppement du logiciel. Ces deux cycles sont repr´esent´es en bas de la figure et forment un mod`ele de d´eveloppement sp´ecifique appel´e mod`ele en W .
Figure 1.2 – Mod`ele en W
Cette approche d´ecoupe le d´eveloppement d’un syst`eme selon deux niveaux : un niveau syst`eme o`u l’int´egrateur r´ealise la phase de sp´ecification des besoins et des exigences et commence la conception globale du syst`eme (haut de la figure) et le niveau composant o`u les phases de d´eveloppement de chaque partie d’un syst`eme sont r´ealis´ees par un fournisseur (bas de la figure). L’int´egrateur r´ealise aussi les activit´es de v´erification et de validation lors de l’int´egration du syst`eme d´evelopp´e. Au-dessus du niveau syst`eme, on trouve le niveau multi-syst`eme qui vise `a l’int´egration de plusieurs syst`emes pr´ealablement test´es, comme c’est le cas dans l’iron bird par exemple. De plus amples informations sur l’iron bird sont disponibles `a la section 1.1.6.
Chacun des syst`emes sont test´es s´epar´ement pour v´erifier que les sp´ecifications sont bien respect´ees. Ces activit´es sont repr´esent´ees par les phases de Software testing et de Harware testing en bas de la figure. Une fois le syst`eme d´evelopp´e et livr´e, l’int´egration du syst`eme dans l’avion est `a la charge de l’avionneur. Cette ´etape est repr´esent´ee sur la figure 1.2 par l’activit´e Components Integration V&V. D’autres tests visent `a valider au plus tˆot,
la conception du syst`eme grˆace `a de la mod´elisation temps-r´eel (Model-in-the-Loop), le logiciel grˆace `a la simulation de la plate-forme mat´erielle d’ex´ecution (Software-in-the-Loop) et l’int´egration du mat´eriel dans un environnement simulant les communications avec les autres syst`emes de l’avion (Hardware-in-the-Loop). Ces types de test d’int´egration seront d´etaill´es dans la section 1.2.2.
1.1.2 Caract´eristiques d’un syst`eme avionique
Un syst`eme avionique est un syst`eme temps-r´eel, critique, embarqu´e, r´eactif et tol´erant aux pannes.
Temps-r´eel : Les syst`emes r´eel sont divis´es en deux cat´egories. Le temps-r´eel strict implique que la r´eponse du syst`eme lors d’une sollicitation doit toujours arriver dans un laps de temps donn´e. Le temps-r´eel souple autorise un temps de r´eponse sup´erieur `a une contrainte temporelle, mais ce temps de r´eponse ne doit pas d´epasser un certain nombre de cycles d’ex´ecution. Dans le contexte avionique, les syst`emes temps-r´eel sont majoritairement stricts. Cette caract´eristique impacte tr`es largement les choix de conception et d’impl´ementation que ce soit sur le logiciel ou sur le mat´eriel.
Critique : La d´efaillance d’un syst`eme critique a un impact direct sur la s´ecurit´e des personnes l’utilisant. Des m´ethodes de v´erification et de validation sont donc mises en place pour assurer un fonctionnement fiable. De plus, des normes de certification existent pour assurer un niveau de s´ecurit´e en fonction de la criticit´e du syst`eme. La norme pour les syst`emes complexes est la norme ARP4754 (Guidelines For Develop-ment Of Civil Aircraft and Systems) [67]. Elle permet de classifier, en fonction de leur criticit´e, les syst`emes selon cinq niveaux : catastrophique, dangereux, majeur, mineur, sans impact. Elle propose aussi d’assigner un niveau de confiance dans le d´eveloppement (Development Assurance Level - DAL) d’un syst`eme en fonction de son niveau de criticit´e (DAL A pour les plus critiques jusqu’`a DAL E pour les moins critiques). La norme ARP4754 est compl´et´ee par la norme DO-178C (Software Consi-derations in Airborne Systems and Equipment Certification) [66] qui vise `a certifier le logiciel embarqu´e `a l’int´erieur d’un syst`eme critique et la norme DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) pour le mat´eriel [39]. Embarqu´e : Les syst`emes qui composent un avion sont embarqu´es dans celui-ci ; ils
sont compos´es d’une partie mat´erielle et d’une partie logicielle. Cette caract´eristique implique qu’ils sont contraints au niveau spatial, car ils doivent ˆetre contenus dans le syst`eme qui les embarque. Ils sont ´egalement contraints au niveau ´energ´etique car ils sont coupl´es au syst`eme d’alimentation de l’avion. Ils sont aussi contraints par la puissance de calcul et la place m´emoire qui leur sont attribu´ees. L’augmentation de la capacit´e de calcul de ces syst`emes a un effet direct sur la consommation en ´energie.
R´eactif : Ces syst`emes sont dits r´eactifs car ils sont en permanence en interaction avec leur environnement. Ils doivent r´eagir aux changements et s’ajuster continuelle-ment. Ils ´echangent des donn´ees en temps r´eel pour r´ealiser les fonctions n´ecessaires `
a un avion. La limite de temps durant laquelle ces syst`emes doivent r´eagir `a un ´
ev`enement pour que leur comportement ne soit pas jug´es d´efaillant, montre le lien ´
etroit entre le fait qu’ils sont r´eactifs et qu’ils sont temps r´eel. L’aspect r´eactif de ces syst`emes demande de mettre en place des tests particuliers.
Tol´erance aux pannes et propagation des erreurs : L’avion doit, en toutes circonstances, r´eagir `a son environnement en temps r´eel et la d´efaillance d’un de ses syst`emes ne doit pas entraˆıner sa panne. Pour r´epondre `a cette probl´ematique, des m´ecanismes de redondance sont ´elabor´es lors de la conception g´en´erale de l’avion. Ces m´ecanismes r´epondent aux contraintes de disponibilit´e des ´equipements et des fonctions avioniques. Ils permettent, par exemple, aux fonctions logicielles critiques d’ˆetre h´eberg´ees par deux calculateurs diff´erents de l’avion. Ces calculateurs dis-posent d’un syst`eme de communication inter-modules et intra-module qui permet aux applications de coop´erer dans la r´ealisation de certaines tˆaches. Ces syst`emes de communication donnent la possibilit´e de changer d’application concourant `a la r´ ea-lisation d’une tˆache lorsqu’une erreur provenant d’une des applications est d´etect´ee. Une plate-forme d’ex´ecution logicielle est partitionn´ee en plusieurs entit´es. Elle peut donc h´eberger plusieurs fonctions. La m´emoire n’est pas partag´ee entre les diff´erentes partitions pour ´eviter la propagation d’erreurs pouvant ˆetre critiques.
Les syst`emes embarqu´es au sein d’un avion ont une complexit´e toujours plus ´elev´ee de par les caract´eristiques cit´ees ci-dessus. L’´etat de ces syst`emes d´epend ´etroitement de l’´etat des syst`emes avec lesquels ils communiquent. Les types de communication et les donn´ees transf´er´ees sont h´et´erog`enes.
Toutes ces caract´eristiques impliquent un effort accru pour la conception et le test des syst`emes avioniques.
1.1.3 D´ecoupage d’un syst`eme avionique
Le d´ecoupage de l’avion en domaines, syst`emes, sous-syst`emes, puis en ´equipements est ´
etabli lors de la phase de sp´ecification du syst`eme global comme le montre la figure 1.1. Il permet de raffiner les sp´ecifications du syst`eme depuis les fonctionnalit´es g´en´erales de l’avion jusqu’aux sp´ecifications les plus d´etaill´ees de chaque ´equipement. A chaque ´etape de sp´ecification, des documents de conception et d’exigences sont produits. Le bureau d’´etude explicite les exigences de haut niveau et les besoins fonctionnels de l’avion et r´ealise la conception de l’architecture physique de l’avion. Des documents d’exigences et de description du syst`eme sont produits et sont li´es aux exigences du niveau avion pour permettre la tra¸cabilit´e.
domaines. Ces domaines correspondent `a la classification ATA (Air Transport Association of America) qui propose un d´ecoupage des syst`emes d’un avion en 100 chapitres [79]. Les tableaux 1.1 et 1.2 pr´esentent quelques-uns de ces chapitres et ´equipements. Il s’agit ensuite d’identifier et de concevoir les syst`emes qui r´epondront aux fonctions de l’avion.
Table 1.1 – Exemple de chapitres ATA et des sous-syst`emes correspondants (1/2)
Domaine syst`eme de l’a´eronef Equipements´
21 Air conditionn´e et pressurisation
Compression Distribution Pressurisation Chauffage Climatisation
Contrˆole de la temp´erature
22 Vol automatique Pilote automatique
Correction de la vitesse
23 Communications
Communication vocale Communication satellite
Informations pour les passagers et divertissements
24 G´en´eration ´electrique
Contrˆole du g´en´erateur
G´en´eration de courant alternatif G´en´eration de courant continu Alimentation externe
Distribution du courant alternatif Distribution du courant continu
27 Commandes de vol
Aileron et tab
Gouvernail de direction et tab Gouvernail de profondeur et tab Stabilisateur horizontal
Dispositif hypersustentateur 42 Avionique modulaire int´egr´e Syst`eme principal
Composants r´eseau
44 Syst`emes de la cabine
Syst`eme de cabine principal Syst`eme de divertissement en vol Syst`eme de communication externe Syst`eme de gestion de la cabine
Les deux cas d’´etudes que nous avons d´evelopp´e au cours du projet FUI ACOVAS (outil Agile pour la COnception et la VAlidation Syst`eme) sont tir´es de l’ATA 21 (Air conditionn´e et pressurisation) et de l’ATA 42 (Avionique modulaire int´egr´e). Le premier cas d’´etude correspond aux tests r´ealis´es par un fournisseur de syst`emes alors que le deuxi`eme
correspond aux tests r´ealis´es par l’avionneur lors de l’int´egration des syst`emes produits par les fournisseurs.
Table 1.2 – Exemple de chapitres ATA et des sous-syst`emes correspondants (2/2)
Domaine structure Equipements´
52 Portes
Portes pour les passagers et l’´equipage Sortie d’urgence
Porte de la soute
Porte pour la maintenance des syst`emes Escaliers d’entr´ees
57 Ailes
Aile centrale Aile externe Bout de l’aile
Bord d’attaque de l’aile Bord de fuite de l’aile Ailerons et ´elevons Domaine moteur 72 Moteurs Compresseur Chambre de combustion Turbine
73 Carburant moteur et r´egulation
Distribution Diviseur de d´ebit Contrˆole du carburant
80 D´emarrage Syst`eme de d´emarrage
Moteurs
Un domaine est compos´e de plusieurs syst`emes. L’architecture d’interconnexion des syst`emes d´efinit les interfaces de communication interne et externe auxquels les syst`emes devront se conformer. Le choix de l’architecture a aussi un impact sur la structure interne de chaque syst`eme. Il doit prendre en compte les exigences en mati`ere de s´ecurit´e, les possibles propagations d’erreurs et principalement les exigences m´etier. Le bureau d’´etude produit un document de sp´ecification technique d’acheteur (Purchaser Technical Specification ou PST) du syst`eme pour le transmettre au fournisseur afin qu’il r´ealise le syst`eme souhait´e. La figure 1.3 r´esume l’ensemble des documents produits lors de la conception d’un avion.
Le niveau le plus bas dans ce d´ecoupage est le niveau ´equipement. A ce niveau, les sp´ecifications techniques du syst`eme sont d´etaill´ees pour chaque ´equipement qui le compose. Un document PST est aussi produit au niveau ´equipement. Un ´equipement comprend une partie mat´erielle (contrˆoleur, capteur, actionneur) et le logiciel le pilotant (syst`eme d’exploitation, syst`eme applicatif). Pour chacun de ces ´el´ements mat´eriels et logiciels, des documents de sp´ecification et de conception ainsi qu’un PST sont ´egalement produits. Les
Figure 1.3 – Documents pour la conception et activit´es de d´eveloppement d’un avion
PST servent ici aussi de cahier des charges qui sont d´elivr´es aux fournisseurs pour qu’ils r´ealisent le d´eveloppement du mat´eriel et du logiciel.
1.1.4 Diff´erents types d’architecture avionique
Une architecture avionique d´efinit comment les unit´es de calcul et les diff´erents capteurs et senseurs de l’avion sont connect´es entre eux. Une ´etude des diff´erentes architectures avioniques a ´et´e r´ealis´ee par Bill Filmer [35]. G´en´eralement, on les classe en trois grandes cat´egories : les architectures ind´ependantes, les architectures f´ed´er´ees et les architectures int´egr´ees.
Les architectures ind´ependantes proposent une forte s´eparation entre les syst`emes ap-partenant `a des domaines diff´erents. Elles ont pour but de s´eparer chaque syst`eme de contrˆole compos´e d’un calculateur, des capteurs correspondants et d’autres ´equipements associ´es. Chacun de ces syst`emes r´ealise les fonctions avioniques d’un mˆeme domaine. Les syst`emes de contrˆole n’ont pas de connexions entre eux ce qui implique qu’il ne peut pas y avoir de propagation d’erreurs d’un syst`eme `a un autre.
La logique autour des architectures f´ed´er´ees consiste `a s´eparer fortement chaque syst`eme tout en autorisant la communication inter-syst`emes par des connexions point `a point entre certains syst`emes. La complexit´e de l’architecture est augment´ee en partageant des donn´ees entre plusieurs fonctions de syst`emes diff´erents. Avec ce type d’architecture, une erreur peut se propager d’un syst`eme `a l’autre ; sa d´etection et sa tol´erance sont g´er´ees via des m´ecanismes logiciels et grˆace `a la redondance physique d’´equipements. La figure 1.4 montre un exemple d’une telle architecture.
Une nouvelle g´en´eration d’architecture a ´et´e d´evelopp´ee, rempla¸cant les calculateurs sp´ecifiques `a chaque syst`eme par des calculateurs standardis´es pouvant h´eberger plusieurs fonctions logicielles venant de plusieurs syst`emes. Ces plates-formes sont appel´ees des
mo-Figure 1.4 – Architecture f´ed´er´ee
dules IMA (Integrated Modular Avionic) ou calculateurs IMA. Ces modules sont inter-connect´es par des bus de donn´ees et des switchs de communication. Ce type d’architecture met l’accent sur la modularit´e et la flexibilit´e de la conception des nouveaux syst`emes em-barqu´es ; elle est aussi, de par sa nature, plus tol´erante aux fautes mˆeme si le traitement des erreurs n´ecessite une certaine complexit´e de mise en œuvre. La figure 1.5 montre un exemple d’une telle architecture. La standardisation des modules de calcul IMA les rend interchangeables : l’avionneur peut donc changer de fournisseur. Cette architecture permet de r´eduire les coˆuts de d´eveloppement car les activit´es d’int´egration de ces calculateurs standardis´es et con¸cus pour les besoins particuliers de l’avionique (special-to-purpose) sont grandement simplifi´es.
L’´evolution autour des architectures concerne essentiellement les moyens de communi-cation entre les diff´erents syst`emes et la standardisation des calculateurs. Les communica-tions entre les calculateurs standardis´es d’une architecture IMA se font par des switchs de communications repr´esent´es en noir sur la figure 1.5, ce qui permet de r´eduire le nombre de connexions physiques dans l’avion, en connectant les syst`emes non co-g´eolocalis´es `a un mˆeme bus de donn´ees.
Ces architectures permettent d’h´eberger des fonctionnalit´es de diff´erents syst`emes sur un mˆeme calculateur. Un calculateur doit alors partager ses ressources pour des fonction-nalit´es de diff´erents syst`emes : ressources de calcul mais aussi ressources m´emoire. Afin de retrouver le niveau d’encapsulation des architectures ind´ependantes, un partitionnement
Figure 1.5 – Architecture IMA
des ressources est r´ealis´e [51].
1.1.5 Interface Control Document (ICD)
Ces nouveaux types d’architecture demandent un effort suppl´ementaire lors de la d´ e-finition des interfaces de chaque syst`eme. Chaque syst`eme consomme et produit des don-n´ees via ses interfaces. La d´efinition des interfaces d’un syst`eme n´ecessite la mise en place d’un document de contrˆole des interfaces (Interface Control Document ). Un ICD est un document contenant les interfaces d’un syst`eme embarqu´e. Le nom d’ICD est un nom g´ e-n´erique et sa structuration peut varier en fonction des entreprises, et mˆeme au sein d’une mˆeme entreprise. Le changement le plus notoire est la fa¸con d’identifier de mani`ere unique les diff´erentes interfaces d’entr´ee et de sortie du syst`eme. Ces interfaces d’entr´ee et de sor-tie seront le support pour l’envoi et la r´eception des param`etres avioniques. Un param`etre avionique correspond `a un signal contenant un message qui sera d´elivr´e ou consomm´e par le syst`eme. Ce document permet aussi de connaˆıtre quel est le type d’un param`etre d’ap-plication (entier, r´eel, bool´een . . .), ses valeurs minimale et maximale, ou encore le taux de rafraichissement de sa valeur. La transmission des messages peut se faire selon deux modes de communication [41]. Le premier, le mode sampling transmet des messages de structure homog`ene, o`u seule la valeur des param`etres contenus dans le message change. Les ports
d’entr´ee et de sortie conservent uniquement la derni`ere occurrence du message `a envoyer ou du message re¸cu car seules les valeurs les plus r´ecentes sont pertinentes. Le mode queuing transmet des messages de structure h´et´erog`ene : deux messages re¸cus ou envoy´es par un mˆeme port ne contiennent pas obligatoirement les mˆemes param`etres. L’information trans-port´ee par les messages du mode queuing est variable demandant aux ports de stocker toutes les occurrences de messages re¸cus ou `a envoyer. Le mode queuing l`eve une alarme lorsque la file de transmission est pleine ou quand la file de r´eception est vide.
Plusieurs niveaux de d´etail sont fournis. Au plus bas niveau, on retrouve les identifiants des connecteurs du syst`eme sous test. Chaque connecteur comprend plusieurs broches (ou pins). Il permet de renseigner les bus de communication qui sont rattach´es au connecteur physique. A un niveau logique, on retrouve les messages qui transitent sur ces bus. Puis, au niveau logique le plus haut, les param`etres d’application et les signaux qui lui sont rattach´es sont d´ecrits.
Figure 1.6 – Exemple de param`etre ICD
La figure 1.6 est l’exemple d’un param`etre contenu dans un fichier ICD. Dans cet exemple, le param`etre est unique grˆace au triplet compos´e du nom d’application, du nom du bus et du nom de variable qui lui sera attribu´e. A ce param`etre sera aussi associ´e un type de donn´ees, une unit´e de mesure et un m´edia de communication. Le param`etre d´ecrit `
a la figure 1.6 correspond `a la temp´erature de la zone nomm´ee Temperature_cabine1 qui sera re¸cue sur le bus A01_IN par l’application PRIM1A qui sera h´eberg´ee sur le syst`eme auquel l’ICD appartient.
Ces param`etres sont transmis sur le r´eseau via des m´edia de communication qui sont de plusieurs types : analogique, discret, AFDX (Avionics Full-Duplex Switched Ethernet ) [2], conforme au protocole ARINC 429 [6], CAN (Controller Area Network ), ou MIL-STD-1553B [28].
1.1.6 Les phases de test
Cette section s’attache `a d´ecrire les phases de test d’un syst`eme avionique complet depuis les tests unitaires portant sur le logiciel et le mat´eriel jusqu’aux tests en vol. Pour le d´eveloppement de syst`emes avioniques, le processus suivi est un processus dirig´e par les plans de test. Il est d´ecrit par Ian Sommerville d’un point de vue logiciel [76]. Ce processus est adapt´e `a chaque entreprise en fonction de ses besoins et de ses strat´egies de test. La figure 1.7 sch´ematise les activit´es de test dans la branche ascendante du cycle en V .
Les premi`eres phases de test sur les ´el´ements r´eels sont r´ealis´ees sur le logiciel et les plates-formes qui l’ex´ecuteront ainsi que sur les ´equipements annexes `a ces syst`emes, comme les capteurs et les actionneurs, les cˆables . . . Chaque ´equipement ou logiciel int´egr´e dans
Figure 1.7 – Phases de test
l’avion sera pr´ealablement test´e en isolation. Le d´eveloppement des syst`emes se faisant en parall`ele, il est donc possible de r´ealiser les tests en parall`ele. On peut consid´erer un syst`eme embarqu´e comme ´etant compos´e d’une application ex´ecut´ee sur un syst`eme d’exploitation grˆace `a une plate-forme mat´erielle. La plate-forme mat´erielle h´eberge un syst`eme d’exploi-tation temps-r´eel. La plate-forme et le syst`eme d’exploitation sont test´es s´epar´ement dans un premier temps, puis en int´egration lors de la phase de test de la plate-forme.
Les fonctions logicielles et les algorithmes sont test´es dans un environnement d’ex´ecution temps-r´eel simul´e : ce sont les tests d’application. Puis, cette simulation est remplac´ee par une mod´elisation de la plate-forme qui l’accueillera r´eellement dans l’avion. Ces tests correspondent aux tests d’application.
Concernant la plate-forme, le test s’´etablit en plusieurs ´etapes :
– Au niveau mat´eriel, les ´equipements (capteurs, contrˆoleur, . . .) subissent deux types de test : des tests fonctionnels et des tests environnementaux permettant de v´erifier que le mat´eriel peut assurer son service dans les conditions de vol normales et ex-ceptionnelles (vibrations, d´ecompression, pressurisation, variations de temp´eratures, humidit´e . . .). Les tests environnementaux sont d´efinis par les standards et normes qui permettent la certification.
– Puis le syst`eme d’exploitation est aussi test´e, en se concentrant sur son aspect fonc-tionnel. Les pilotes de communication sont test´es via un environnement simul´e qui produit les messages entrants et sortants.
– Enfin, des tests d’int´egration du syst`eme d’exploitation sur le mat´eriel sont r´ealis´es. Une simulation logicielle du comportement et des caract´eristiques du mat´eriel permet de tester le syst`eme d’exploitation dans des conditions proches de l’int´egration sur le mat´eriel r´eel. Le syst`eme d’exploitation est aussi test´e sur un mat´eriel r´eel qui aura ´et´e v´erifi´e au pr´ealable par les divers tests cit´es ci-dessus. L’int´egration du syst`eme d’exploitation sur le mat´eriel constitue la plate-forme qui pourra ensuite h´eberger les
applications avioniques.
Une fois ces trois types de test r´ealis´es, la plate-forme mat´erielle pilot´ee par le syst`eme d’exploitation, peut alors accueillir les applications logicielles qu’elle h´ebergera r´eellement dans l’avion. Les tests d’int´egration des applications logicielles sur la plate-forme mat´erielle correspondent aux tests de qualification.
On obtient un syst`eme lorsqu’une plate-forme contrˆol´ee par un syst`eme d’exploitation permettant d’ex´ecuter une application avionique est int´egr´ee `a des ´equipements externes additionnels. Ce syst`eme est test´e et correspond `a l’activit´e tests syst`eme de la figure 1.7. Pour les tests d’int´egration syst`eme, des mod`eles permettent de simuler les autres sys-t`emes interagissant avec le syst`eme test´e ainsi que l’environnement ext´erieur. A ce niveau, le concept de redondance est mis en place. De la mˆeme mani`ere que les tests d’int´egration sont r´ealis´es, des tests multi-syst`emes sont possibles lorsque plusieurs syst`emes r´eels sont int´egr´es ensemble.
Les syst`emes sont alors int´egr´es domaine par domaine, et les syst`emes appartenant `a un autre domaine sont simul´es lors de cette phase de test. Au niveau domaine, les premiers tests au sol sont r´ealis´es.
Une des derni`eres phases d’int´egration assemble les syst`emes de la plupart des do-maines. Le but est de monter une premi`ere version de l’avion en taille r´eelle (iron bird ) ou non (mini-bird ) et de v´erifier que cette version est op´erationnelle i.e. les syst`emes fonc-tionnent correctement lors d’une ex´ecution individuelle et simultan´ee. Dans un iron bird, les syst`emes, r´eseaux informatiques, hydrauliques, de ventilation, . . . sont int´egr´es et pilot´es par les calculateurs et contrˆoleurs r´eels. L’iron bird est donc la version finale de l’int´egration de l’avion qui permet de r´ealiser les tests au sol puis de r´ealiser les premi`eres simulations de vol. Tant que ces batteries de tests ne sont pas valid´ees, aucun test en vol ne sera r´ealis´e. Lors de la r´ealisation de la premi`ere version de l’avion, les premiers tests en vol sont enfin r´ealis´es.
1.2
Un focus sur les tests d’int´
egration
Le d´eveloppement d’un avion peut ˆetre divis´e en deux grandes phases : la phase de conception et de d´eveloppement et la phase d’int´egration et de test. Durant la premi`ere phase, la v´erification et la validation sont effectu´ees au niveau des sp´ecifications, et durant la deuxi`eme elles sont r´ealis´ees au niveau impl´ementation. Le processus de V´erification et de Validation (V&V) intervient principalement dans la phase montante du cycle en V qui li´ee `a l’int´egration des syst`emes [5]. La v´erification d´etermine si une partie ou l’ensemble du syst`eme respecte bien ses sp´ecifications. La validation s’assure que le syst`eme refl`ete les besoins et attentes des utilisateurs (op´erateurs, personnels de maintenance, agences de r`eglementation et les utilisateurs finaux). Plus pr´ecis´ement :
– La v´erification au niveau ´elicitation et sp´ecification des besoins garantit que les sp´ecifications et besoins de bas niveau sont conformes aux sp´ecifications de
plus haut niveau.
– La validation au niveau ´elicitation et sp´ecification des besoins concerne les ´el´ements de d´ecision pris lors de la phase de conception.
– La v´erification au niveau impl´ementation montre la conformit´e des syst`emes, sous-syst`emes, composants mat´eriels ou logiciels avec les sp´ecifications et d´etails de conception.
– La validation au niveau impl´ementation s’assure que les besoins de l’avionneur ont bien ´et´e impl´ement´es dans le syst`eme embarqu´e livr´e.
Les activit´es de v´erification comprennent : l’analyse statique, la v´erification de mod`eles et la preuve formelle. Des revues et des inspections sur les documents de V&V ont pour but d’am´eliorer leur qualit´e.
Le test est le principal moyen de validation. Un test interagit avec le syst`eme sous test (System Under Test - SUT) pour le stimuler avec des donn´ees d’entr´ee dans le but d’obtenir des informations en sortie qui seront ensuite analys´ees pour les comparer aux comportements attendus. Un test comporte plusieurs cas de test. Un cas de test est compos´e par un ensemble de valeurs en entr´ee, des conditions d’ex´ecution et la description du r´esultat attendu. Le processus d´edi´e aux tests commence par leur conception, i.e. les choix des cas de test et la description de la logique de chaque cas de test. La deuxi`eme phase correspond `
a l’impl´ementation qui pr´epare et configure l’environnement et les ´equipements n´ecessaires `
a la r´ealisation du test ; elle inclue la production du code ex´ecutable des tests automatis´es. Il n’est pas possible d’assurer un comportement correct pour l’ensemble des cas d’ex´ e-cution d’un syst`eme complexe. La v´erification et la validation servent donc `a augmenter le niveau de confiance des syst`emes embarqu´es.
Dans cette section, nous nous concentrons principalement sur les activit´es de test d’in-t´egration (section 1.2.1) qui sont au cœur des pr´eoccupations de cette th`ese. Nous nous int´eressons aux tests dits In-the-Loop qui sont une fa¸con de r´ealiser des tests d’int´egration pour les syst`emes embarqu´es (section 1.2.2). Nous aborderons pour finir l’impl´ementation des proc´edures de test (section 1.2.4) sur un moyen d’essai d´edi´e : le banc de test (sec-tion 1.2.3). La phase d’int´egration, portant sur le syst`eme complet, implique des tests tr`es coˆuteux `a ex´ecuter en ressources et personnels. Les tests d’int´egration sont en g´en´eral non automatis´es.
1.2.1 Les phases de test d’int´egration
La phase d’int´egration permet de s’assurer que l’ensemble des composants d’un avion ont le comportement pr´evu lors de leur ex´ecution conjointe. Lors de cette phase, certains comportements doivent ˆetre simul´es pour se rapprocher au maximum des conditions de vol r´eel. Les tests d’int´egration accompagnent cette phase et se font grˆace `a des bancs de test qui permettent de connecter les SUT avec les outils de test et de simuler, grˆace `a des
mod`eles, l’environnement ext´erieur et les comportements des composants non-disponibles lors du test. Ces simulations sont utilis´ees pour stimuler le SUT dans un environnement le plus proche possible du contexte d’ex´ecution r´eel. Les bancs de test transmettent donc des informations vers le SUT et re¸coivent des donn´ees qui seront sauvegard´ees pour v´erifier ult´erieurement leur conformit´e.
L’int´egration de ces syst`emes suit alors une strat´egie d’int´egration. G´en´eralement, l’in-t´egration peut se faire de deux mani`eres :
– L’approche non-incr´ementale ou big bang int`egre tous les composants et syst`emes en mˆeme temps.
– L’approche incr´ementale int`egre un ou plusieurs composants `a chaque nouvelle ´etape d’int´egration. En ce qui concerne l’approche incr´ementale, on distingue :
L’approche d’int´egration ascendante est un processus d´emarrant depuis le niveau le plus bas, c’est-`a-dire le niveau ´equipement.
L’approche d’int´egration descendante est un processus d´emarrant depuis le niveau le plus haut, c’est-`a-dire le niveau avion.
L’approche d’int´egration en fonction des composants disponibles vise `a int´egrer uniquement les composants dont le d´eveloppement est termin´e. Les com-posants en cours de d´eveloppement sont simul´es.
L’approche d’int´egration par fonction de l’avion a pour but de r´ealiser l’in-t´egration des fonctionnalit´es s´epar´ement con¸cues.
L’approche d’int´egration de l’ext´erieur vers l’int´erieur vise `a cr´eer deux processus d’int´egration, un ascendant partant du niveau le plus bas et un des-cendant partant du niveau le plus haut. Le but ´etant de faire converger ces deux processus.
L’approche d’int´egration de l’int´erieur vers l’ext´erieur vise `a cr´eer deux processus d’int´egration, un ascendant et un descendant commen¸cant tous deux `a un niveau moyen de d´etail. Il divergent ensuite pour atteindre respectivement le niveau le plus bas et le niveau le plus haut.
L’approche par processus m´etier vise `a cr´eer un processus d’int´egration par type de m´etier. Les syst`emes seront int´egr´es en fonction de leur place dans la r´ealisation des cas d’utilisation du m´etier.
L’approche par complexit´e d´ecroissante l`eve les incertitudes li´ees `a une cri-ticit´e d’int´egration ´elev´ee.
Les approches incr´ementales demandent le d´eveloppement de simulations ou de stubs des composants qui ne sont pas encore int´egr´es. Une approche non incr´ementale est sou-vent trop contraignante du fait que tous les composants doisou-vent ˆetre d´evelopp´es avant l’int´egration. Cette strat´egie n’est pas viable pour l’int´egration de ce type de syst`eme.
Dans la plupart des cas, plusieurs strat´egies incr´ementales sont utilis´ees conjointement pour r´epondre aux retards de livraison des fournisseurs. La strat´egie la plus usit´ee est l’ap-proche ascendante qui commence au niveau ´equipement par l’assemblage de la plate-forme et des applications qui vont s’ex´ecuter sur cette plate-forme. Le processus d’int´egration vise
`
a int´egrer tous les composants de chaque syst`eme au niveau domaine et ensuite au niveau avion.
L’int´egration suit globalement une approche ascendante, mais d’autres approches sont utilis´ees parall`element. Par exemple, des strat´egies par processus m´etier pourront ˆetre envi-sag´ees en compl´ement au niveau domaine ou avion alors que des approches par complexit´es d´ecroissantes ou par composants disponibles peuvent ˆetre imagin´ees au niveau ´equipement. Parce que ces syst`emes sont tr`es difficiles `a int´egrer et que la phase d’int´egration est proche de la fin du cycle de d´eveloppement d’un avion, il s’av`ere n´ecessaire de faire au plus tˆot des tests d’int´egration avec les autres syst`emes simul´es dans un type de test particulier appel´e In-the-Loop testing.
1.2.2 In-the-Loop testing
Les tests d’int´egration utilisent un banc de test pour interagir directement avec le mat´ e-riel et permettre la simulation d’un mod`ele d’environnement. Pour les tests sans interaction avec le mat´eriel, le simulateur peut ˆetre h´eberg´e sur un ordinateur classique. Le mod`ele d’environnement simule, en partie ou compl`etement, la pr´esence des autres syst`emes de l’avion n´ecessaires `a la r´ealisation du cas de test souhait´e. Par exemple, pour les tests des diff´erentes configurations d’un calculateur IMA, le mod`ele d’environnement simule le comportement des syst`emes permettant la r´eception centralis´ee des messages d’erreur des calculateurs et la r´eaction du syst`eme par rapport aux diff´erentes erreurs. Ce mod`ele per-met de produire les donn´ees d’entr´ee dans le but de stimuler le SUT. Celui-ci r´eagit `a ces stimuli en produisant des donn´ees en sortie qui sont r´einject´ees dans le mod`ele d’environ-nement. Le mod`ele pourra alors prendre en compte ces donn´ees pour ensuite produire les nouvelles donn´ees qui seront de nouveau utilis´ees en entr´ee du SUT. Ces m´ecanismes per-mettent de simuler les ´echanges de donn´ees cycliques et ininterrompus des syst`emes test´es comme d´ecrit `a la figure 1.8.
On peut constater que le SUT est vu comme une ”boˆıte noire”. En effet, les tests In-the-Loop ne servent pas `a v´erifier si les m´ecanismes internes du SUT sont corrects, mais `a v´erifier que son comportement en interaction avec les autres syst`emes de l’avion l’est.
Le mod`ele de simulation est ex´ecut´e par un simulateur temps-r´eel et la connexion physique entre le simulateur et le SUT est prise en charge par le banc de test. La simulation temps-r´eel est utile pour remettre le SUT dans des conditions d’ex´ecution proches des conditions r´eelles. L’architecture physique du banc permet de reproduire la connexion du mat´eriel `a son environnement simul´e ou ´emul´e.
Il existe trois types de test In-the-Loop : Model-in-the-Loop (MiL), Software-in-the-Loop (SiL) et Hardware-in-the-Loop (HiL).
Le MiL est l’activit´e qui se produit le plus tˆot dans le cycle de d´eveloppement. Les tests sont r´ealis´es sur les mod`eles comportementaux des syst`emes. Ces mod`eles sont produits en fonction des besoins fonctionnels et des caract´eristiques des syst`emes en cours de conception. Il existe un mod`ele de simulation par cat´egorie de test. Un
Figure 1.8 – Boucle des donn´ees de test pour du test In-the-Loop
mod`ele peut, par exemple, permettre d’optimiser la longueur des cˆables pour alimen-ter ´electriquement tous les composants d’un avion. Un autre mod`ele peut simuler le r´eseau informatique produit par l’interconnexion des calculateurs IMA. Ces mo-d`eles peuvent donc simuler l’architecture interne des composants, tout comme les interactions entre eux. Ils sont d´evelopp´es initialement, avant tout d´eveloppement de mat´eriel et de logiciel. Ces tests ont pour but de valider les exigences et les choix de conception des mod`eles comportementaux.
Le SiL prend en compte le logiciel r´eel et l’ex´ecute sur une plate-forme simul´ee. Dans ce cas, le mod`ele d’environnement ´emule le comportement du mat´eriel et du syst`eme d’exploitation du calculateur qui contrˆolera ce logiciel. Ces tests ont pour but de valider que le logiciel s’ex´ecutera correctement sur la plate-forme mat´erielle, celle-ci ´
etant encore simul´ee par des mod`eles.
Les tests HiL sont r´ealis´es sur le logiciel r´eel qui sera ex´ecut´e sur le mat´eriel tel qu’il sera configur´e dans l’avion final. Cette phase intervient au d´ebut de la phase d’int´egration lorsque le mat´eriel et le logiciel ont ´et´e d´evelopp´es et test´es. Le mo-d`ele d’environnement ne simule que les interactions avec les syst`emes concourants `a l’ex´ecution d’un ensemble de cas de test pour un SUT donn´e. Les tests HiL visent `a s’assurer que l’assemblage logiciel-mat´eriel repr´esentant un syst`eme s’int`egre correc-tement aux syst`emes de l’avion.
1.2.3 Le banc de test
Le but d’un banc de test est de mettre en place des moyens de communication entre les syst`emes que l’on souhaite tester pour en v´erifier le comportement. Les bancs d’essai sont principalement utilis´es pour valider des syst`emes compos´es de mat´eriels et de logiciels. Un banc de test comprend un s´equenceur, une interface physique permettant de connecter le SUT aux ressources de test, un syst`eme d’alimentation du SUT, un simulateur temps-r´eel et un ensemble d’outils externes.
Le s´equenceur est l`a pour ex´ecuter les tests automatiques et semi-automatiques. Son but est d’ex´ecuter la liste d’instructions contenues dans les tests formalis´es. Ces tests formalis´es prennent la forme de proc´edures de test ´ecrites dans un langage informatique et sont donc ex´ecutables.
Le SUT est connect´e physiquement aux ressources de test grˆace `a une partie du banc de test appel´ee baie de test qui fait le lien entre le s´equenceur, le mod`ele de simulation et le SUT lui-mˆeme. Cette baie permet de simuler les communications avec le monde ext´erieur. Le SUT est aussi connect´e `a un module d’alimentation souvent int´egr´e `a la baie de test. Une baie de test est modulaire car les cartes de communication qui la composent peuvent ˆ
etre adapt´ees au syst`eme que l’on teste. Il existe plusieurs types de carte en fonction du moyen de communication utilis´e (ARINC, AFDX . . .).
Le simulateur temps-r´eel permet de simuler les interactions entre le SUT et les ´el´ements interagissant avec lui. Ce simulateur sera alors utile pour int´egrer de mani`ere artificielle le SUT dans un contexte d’ex´ecution le plus proche possible des conditions d’ex´ecution r´eelles.
Les outils externes sont soient des outils d´evelopp´es sp´ecifiquement pour les besoins particuliers du test, soient des outils du march´e (COTS1). Ils permettent de r´ealiser des actions sp´ecifiques sur le SUT ou d’enregistrer des donn´ees produites par le SUT. On peut par exemple citer l’analyseur de r´eseau Wireshark qui permet d’enregistrer des trames circulant sur le r´eseau entre le SUT et le banc. L’analyse des trames r´eseau par Wireshark procure des informations sur l’´etat du SUT au cours d’un test. Les outils permettront d’analyser les donn´ees pour v´erifier a posteriori si le comportement du SUT correspond au comportement attendu.
Un banc de test peut ex´ecuter des tests automatiques, semi-automatiques ou manuels en fonction du niveau d’automatisation du pilotage des outils externes au test et en fonction du niveau d’effort de formalisation engag´e pour la proc´edure de test. Les bancs de test sont de plusieurs types. On peut citer par exemple les bancs d’essai utilis´es en phase de d´eveloppement d’un syst`eme ou encore le banc de validation qui permet de valider le syst`eme avant la mise en production.
1. Les ´equipements commercial off-the-shelf sont des ´equipements facilement disponibles sur le march´e n’ayant pas ´et´e d´evelopp´es pour un domaine d’application particulier.
1.2.4 Des exigences aux proc´edures de test
Apr`es avoir pr´esent´e les sp´ecificit´es des tests syst`eme pour des syst`emes complexes en termes de strat´egie d’int´egration et de moyen d’essais, nous nous int´eressons maintenant au flux de donn´ees menant aux proc´edures de test et caract´erisant l`a aussi un processus particulier.
Les proc´edures de test prennent la forme de documents qui permettront d’ex´ecuter un test sur un banc de test pour un syst`eme donn´e. Elles sont ex´ecut´ees soit manuellement par un op´erateur de test soit automatiquement dans un langage interpr´etable par le banc de test. Elles sont souvent manuelles et r´ealis´ees au travers d’interfaces graphiques repr´ esen-tant le SUT. Toutes les donn´ees observ´ees sont logu´ees afin d’ˆetre analys´ees, de fa¸con plus d´etaill´ee par un data-viewer. Cette fa¸con de faire peut s’av´erer n´ecessaire dans le contexte de certification. Les proc´edures de test ont diff´erents niveaux de formalisation : le niveau informel, le niveau semi-formel et le niveau formel. Le niveau informel correspond aux pro-c´edures de test en langage naturel. L’utilisation du langage naturel pour la description des proc´edures de test peut entraˆıner des erreurs d’interpr´etation et d’incompr´ehension dues au fait qu’un mˆeme concept peut ˆetre d´ecrit de multiples fa¸cons. Les proc´edures semi-formelles utilisent des techniques de structuration pour r´eduire la variabilit´e et les ambigu¨ıt´es des descriptions informelles. Les proc´edures formalis´ees quant `a elles, sont produites `a partir d’un langage informatique formel, qui poss`ede donc une syntaxe et une s´emantique bien d´efinies. On peut par exemple citer le langage TTCN-3 (Testing and Test Control Nota-tion) [32] pour la sp´ecification des tests en boite noire dans un syst`eme distribu´e [69] ou des langages de programmation classiques comme Python, C, scripts shell, dialectes XML, . . .
Figure 1.9 – Flux de documents d’une proc´edure
Dans le cas des proc´edures de test d’int´egration, nous pr´esentons `a la figure 1.9 le workflow de documents associ´e `a la production d’une proc´edure de test HiL informelle. Ce
