Conception du langage ATA 21

Le but du langage ATA 21 est de produire des cas de test simples et compr´ehensibles, o`u l’intention de chaque test est clairement d´ecrite. L’utilisation des identifiants r´eels des param`etres ICD rend complexe la lisibilit´e et la compr´ehension des proc´edures de test de haut niveau. Nous avons estim´e qu’il est pr´ef´erable de nommer ces variables diff´eremment pour masquer la complexit´e du nommage des triplets (application, bus, variable) corres- pondant aux param`etres de l’ICD. Pour ce faire, nous avons impl´ement´e des m´ecanismes d’alias des param`etres r´eels pour simplifier le nommage des param`etres avioniques et par la mˆeme occasion, la compr´ehension des proc´edures de test.

Figure 3.15 – Carte conceptuelle du DSTL ATA 21

La conception des instructions du langage s’est faite grˆace `a la carte conceptuelle de la figure 4.13, nous aidant `a communiquer avec les experts sur les besoins de formalisation de l’ATA 21. Les instructions visent `a r´ealiser des cas de test portant sur la validation des fonctionnalit´es logicielles pour le conditionnement de l’air et des calculateurs les h´ebergeant dans l’avion. L’installation de fonctions logicielles sur un calculateur forme un syst`eme qui, lors du test, agit sur le mod`ele de simulation de l’environnement. Ce mod`ele simule la variation de la temp´erature induite par le syst`eme sous test dans les zones de l’avion. Cette carte classifie les instructions propos´ees en quatre cat´egories : Temperature, Airflow rate, Environnement parameter etEvent.

Dans l’objectif de mettre en exergue l’intention des tests, toute instruction du DSTL ATA 21 doit proposer une syntaxe d´ecrivant r´eellement son objectif de test. La combinaison de ces instructions pour former les cas de test s’apparente alors `a des phrases en langage naturel. Le texte sera form´e d’une s´equence d’actions agissant sur le SUT ou sur le mod`ele d’environnement. Ces actions permettent aussi de v´erifier l’´etat et le comportement du SUT durant le test.

La carte conceptuelle montre que nous souhaitons proposer plusieurs instructions d’af- fectation d’une valeur `a un param`etre avionique ou de simulation. Ces instructions don- neront la possibilit´e aux utilisateurs de changer la valeur d’un param`etre d’entr´ee (In) du

syst`eme et de notifier si l’intention du test est d’augmenter (increase) ou de diminuer (decrease) la valeur du param`etre en question. Nous proposons aussi des instructions dif- f´erentes pour notifier si cette augmentation ou diminution impacte des temp´eratures ou des d´ebits d’air fournis par les canaux. De plus, pour augmenter l’expressivit´e des instructions, nous rempla¸cons le symbole ´egal de l’affectation par un groupe de mots-cl´es plus proches du langage naturel. Pour une hausse de la valeur, les mots-cl´es up to seront pr´esents avant la valeur ; de mˆeme pour une diminution avec down to. Lorsque la syntaxe concr`ete du langage ressemble `a une phrase en langage naturel, le test est plus compr´ehensible et lisible par toutes les parties prenantes et non simplement par les programmeurs. Voici un exemple d’instruction qui augmente la temp´erature de la zone B02 afin qu’elle atteigne 21,2°C :

Increase the temperature of Area_B02 up to 21.2 °C

L’instruction Set de la cat´egorie Airflow rate permet l’initialisation des d´ebits d’air en fonction de l’ouverture r´eelle des vannes d’alimentation en air. Cette instruction n’est utile que lors de la premi`ere affectation du d´ebit d’air pour une vanne. Par la suite, les changements seront notifi´es par les instructions Increase et Decrease. Il en est de mˆeme pour l’instruction Set de la cat´egorie Temperature.

Il est aussi possible de modifier directement la temp´erature simul´ee d’une zone de l’avion en influant sur le mod`ele de simulation de l’environnement grˆace `a une instruction Set. L’instruction Set de la cat´egorie Environment parameter permet de modifier l’´etat de n’importe quel param`etre du mod`ele de simulation. Cette instruction a pour but d’initialiser les conditions d’un test, sans avoir besoin d’attendre la r´eponse du syst`eme test´e. Un param`etre simul´e ne doit pas ˆetre modifi´e par une instruction une fois initialis´e, car il s’agit de v´erifier que ce param`etre est correctement r´egul´e par le syst`eme test´e.

Dans les cas o`u le syst`eme entre en d´efaillance, il doit pouvoir ´emettre un signal. L’ins- truction Wait de la cat´egorie Event rend possible la formalisation de l’attente d’un tel signal.

Il est possible de v´erifier l’´etat des param`etres de sortie grˆace aux instructions Check et Verify associ´ees aux cat´egories Temperature et Airflow rate. Ces instructions proposent deux types d’assertions : les assertions Check s’assurent qu’un ´etat du syst`eme peut ˆetre constant et les assertions Verify font de mˆeme vis-`a-vis des conditions pouvant ˆetre at- teintes par le syst`eme. Il n’a pas ´et´e jug´e pertinent de proposer un Check pour la cat´egorie Airflow rate car les valeurs du d´ebit d’air inject´e dans une zone sont ajust´ees en permanence par le syst`eme.

Chacun de ces cas possibles est incarn´e par une instruction sp´ecifique du langage afin de limiter la complexit´e combinatoire induite par des instructions param´etrisables couvrant un nombre important de cas possibles.