Aide `a la conception multi points de vue de syst`emes embarqués

Aide ` a la conception multi points de vue de
syst` emes embarqu´ es
Franc¸ois Revest1, Fr´ ed´ eric Boniol2, Claire Pagetti1
1ONERA-CERT - 2 av. E. Belin 31055 Toulouse
2ENSEEIHT - 2 rue C. Camichel 31071 Toulouse
{revest,pagetti}@cert.fr, [email protected]
11 avril 2007
R´ esum´ e
La conception de syst` emes complexes et critiques, tels que les syst` emes
avioniques, est un travail f´ ed´ erateur et collaboratif au sein d’une organisation
industrielle n´ ecessitant de nombreuses comp´ etences. La plupart des fonc-
tionnalit´ es sont aujourd’hui support´ ees par des calculateurs et des r´ eseaux de
type Ethernet.
L’objectif de ce papier est d’aider l’int´ egrateur ` a avoir une vision glo-
bale du syst` eme d´ evelopp´ e selon des points de vue essentiels pour la valida-
tion et la certification. Les premi` eres briques d’une m´ ethodologie g´ en´ erale
sont pos´ ees et quelques r´ eflexions sur une vision ex´ ecutive temps r´ eel sont
pr´ esent´ ees.
Concr` etement, le point de vue fonctionnel est d´ ecrit par un ensemble
de nœuds LUSTRE multi p´ eriodiques. Une r´ eflexion est men´ ee autour de la
s´ emantique de cet ensemble et de l’impact sur l’ex´ ecution r´ eelle. La partie
mat´ erielle est donn´ ee sous forme d’une description AADL. A partir des ces
donn´ ees, plusieurs ordonnancements de type EDF respectant les contraintes
fonctionnelles sont g´ en´ er´ es puis test´ es par l’outil Cheddar afin d’en v´ erifier la
correction temps r´ eel. Cette m´ ethode sera illustr´ ee sur un exemple simplifi´ e
des commandes de vol.
1 Introduction
Contexte Les syst` emes embarqu´ es sont des syst` emes de plus en plus com-
plexes, critiques, d´ esormais ` a logiciels pr´ epond´ erants, et souvent plong´ es
dans un milieu physique perturbateur. La conception de tels syst` emes n´ eces-
site de ce fait le concours de plusieurs ´ equipes sp´ ecialis´ ees dans des domaines
diff´ erents : la sˆ uret´ e de fonctionnement, la conception de plateforme d’ex´ e-
cution et de communication temps r´ eel.... Compte-tenu de la complexit´ e
globale induite, toutes ces ´ equipes ne peuvent avoir chacune qu’un “point
de vue” partiel du syst` eme qu’elles doivent pourtant concourir ` a sp´ ecifier,
r´ ealiser, et tester. La cons´ equence directe en est une plus grande difficult´ e du
processus d’int´ egration, de conception et de validation.
1

L’objectif de cet article est de d´ efinir les premi` eres briques d’une m´ etho-
dologie permettant d’avoir les informations globales n´ ecessaires ` a la valida-
tion et ` a la certification d’un syst` eme de type contrˆ ole-commande dans un
contexte multi vues.
Cadre conceptuel multi vues La formalisation d’un cadre conceptuel
multi points de vue clair et formel a ´ et´ e d´ evelopp´ e dans [The06]. L’id´ ee
d´ evelopp´ ee par les auteurs est de structurer l’organisation de conception entre
´
equipes diff´ erentes tout en permettant ` a l’int´ egrateur de conserver des pro-
pri´ et´ es globales de performances temps r´ eel, de sˆ uret´ e de fonctionnement ....
Nous reprenons dans le papier les notions formelles suivantes : une facette
correspond au point de vue des ´ equipes sp´ ecialis´ ees et un layer d´ ecrit une
pr´ eoccupation transverse permettant la v´ erification de propri´ et´ es globales.
Vision ex´ ecutive globale Notre but est de mettre en œuvre la th´ eorie
de [The06] sur la vue d’int´ egration globale et d’illustrer son avantage sur
l’aspect ex´ ecutif.
Les points de vue consid´ er´ es dans l’article sont d’une part la facette fonc-
tionnelle, c’est-` a-dire les fonctions attendues du syst` eme et d’autre part la
facette mat´ erielle, c’est-` a-dire le support physique r´ ealisant les fonctions.
Concr` etement, la partie fonctionnelle est repr´ esent´ ee par un ensemble de pro-
grammes LUSTRE mutli-horloges contraints par des pr´ ec´ edences, et la partie
mat´ erielle est donn´ ee sous forme d’une description AADL.
A partir de ces donn´ ees, plusieurs ordonnancements de type EDF sans
pr´ eemption respectant les contraintes fonctionnelles sont g´ en´ er´ ees puis tes-
t´ ees par l’outil Cheddar afin d’en v´ erifier la correction temps r´ eel. Ensuite,
un mod` ele du syst` eme complet peut ˆ etre g´ en´ er´ e automatiquement en AADL
permettant ainsi d’avoir une vision globale du syst` eme. Cette m´ ethode sera
illustr´ ee sur un exemple simplifi´ e des commandes de vol.
Plan Dans la section 2, nous pr´ esentons un exemple de commande de vol
simplifi´ e. Dans la section 3, nous formalisons les facettes fonctionnelle et
mat´ erielle. Dans la section 4, nous pr´ esentons une mani` ere de g´ en´ erer des
ordonnancements, respectant la s´ emantique synchrone de la facette fonction-
nelle. Ces ordonnancements sont ensuite valid´ es par l’utilisation d’un outil.
Puis, pour un ordonnancement correct, un mod` ele AADL est g´ en´ er´ e, per-
mettant ainsi ` a l’int´ egrateur d’avoir une vision globale du syst` eme encod´ e
r´ eellement.
2 Pr´ esentation de l’exemple
Nous nous situons dans le contexte de syst` emes p´ eriodiques de type
contrˆ ole / commande. Ces syst` emes sont en g´ en´ eral compos´ es de trois types
d’action :
– acquisition de donn´ ees, (par exemple dans le cas d’un a´ eronef, position
de gouvernes, position de l’a´ eronef, vitesse);
– traitement, ´ etant donn´ e l’´ etat observ´ e, quelles actions doivent ˆ etre r´ ea-
lis´ ees pour atteindre l’´ etat souhait´ e;
2

– contrˆ ole, envoi des ordres aux actionneurs.
Ces diff´ erentes actions se font en g´ en´ eral ` a des rythmes diff´ erents. La
recherche de la stabilit´ e d’une loi de contrˆ ole/commande est primordiale et
donc r´ ealis´ ee ` a un rythme rapide. Dans le cas d’un a´ eronef, il s’agit de ne
pas exposer la structure ` a des d´ eformations catastrophiques. D’autres sur-
veillances, comme le suivi d’un plan de vol, suivent un rythme plus lent.
A titre d’exemple, nous consid´ erons un cas tr` es simple de commandes
de vol d’un avion. Ce syst` eme est destin´ e` a contrˆ oler l’attitude, la trajec-
toire et la vitesse de l’avion en mode de pilotage manuel. Plus pr´ ecis´ ement,
cela comprend les organes de pilotage (manche, palonnier, ...), les organes
de transmission et de traitement des ordres de l’´ equipage (timoneries et les
cˆ ables dans le cas de commandes m´ ecaniques, calculateurs et des cˆ ablage
dans le cas de commandes ´ electriques), les actionneurs ou servocommandes
permettant de positionner les gouvernes.
Architecture fonctionnelle
Nous consid´ erons la partie logicielle des commandes de vol. Un calcu-
lateur de commandes de vol assure le calcul des ordres de pilotage effectu´ e
par les lois de pilotage, et l’asservissement des gouvernes sur ces ordres de
pilotage (lois d’asservissement).
FIG. 1 – Architecture fonctionnelle des commandes de vol
La figure 2 repr´ esente l’architecture fonctionnelle de l’application : une
boucle rapide ` a 10ms r´ ealise les asservissements des gouvernes, la boucle
interm´ ediaire ` a 20ms assure le guidage de l’avion et la boucle la moins rapide
g` ere le pilotage automatique. On constate que les tˆ aches communiquent entre
elles et que l’ordre des traitements peut ˆ etre important. Il existe donc des
pr´ ec´ edences entre elles sont d´ eriv´ ees d’exigences de fraˆ ıcheur des variables.
Architecture mat´ erielle
Parall` element au travail du bureau d’´ etude, les ´ equipementiers choisissent
un support physique r´ ealisant la fonction. Dans l’exemple des commandes
de vol, une architecture mat´ erielle solution est d´ ecrite dans la figure 2. Elle
3

est constitu´ ee d’un calculateur r´ ealisant le traitement logiciel (calcul des as-
servissements, loi de guidage et pilotage), de diff´ erents capteurs permettant
l’acquisition de l’´ etat de l’avion (le GPS donne la position, l’acc´ el´ erom` etre
donne la vitesse, les capteurs ailerons et rudder1donnent les angles d’in-
clinaison des gouvernes) et des actionneurs r´ ealisant les modifications des
gouvernes (envoi de courant ´ electrique afin de d´ eplacer les ailerons et le rud-
der).
FIG. 2 – Architecture mat´ erielle des commandes de vol
3 Formalisation des facettes
Nous nous int´ eressons dans cette section ` a deux facettes particuli` eres :
les sp´ ecifications fonctionnelles fournies par le bureau d’´ etude et le support
physique choisi par les ´ equipementiers. L’objectif de cette section est de for-
maliser ces deux facettes afin de faciliter leur manipulation et l’extraction
d’information pour l’int´ egrateur syst` eme.
3.1 Facette fonctionnelle
Notre choix pour formaliser cette facette s’est naturellement tourn´ e vers
un ensemble de programmes synchrones multi-p´ eriodiques avec des contrain-
tes de pr´ ec´ edence. En effet, les langages synchrones sont souvent utilis´ es
par les ´ equipes du bureau d’´ etudes pour sp´ ecifier les fonctions et sont parti-
culi` erement adapt´ es ` a la sp´ ecification de syst` emes r´ eactifs, notamment ceux
de type contrˆ ole / commande.
Rappels sur Lustre
LUSTRE [CPHP87] est un langage synchrone flot de donn´ ees d´ evelopp´ e
`
a Verimag. Un programme r´ eactif r´ eagit aux stimuli de l’environnement. Un
programme est synchrone si les r´ eactions ` a un stimulus sont toujours suf-
fisamment rapides pour terminer avant le prochain stimulus. On dit alors
que les r´ eactions se font en un temps logique. Cette approche permet de
s’abstraire des contraintes temps r´ eel associ´ ees ` a l’architecture physique.
1Le rudder est une gouverne de direction. http ://en.wikipedia.org/wiki/Portal :Aviation
4

Nous verrons section 4 comment relier la facette fonctionnelle ` a l’architec-
ture physique : chaque op´ eration prend en r´ ealit´ e un certain temps qui sera
d´ eterminant dans les performances de la fonction et donc le choix des ordon-
nancements.
Pour trouver une description compl` ete et d´ etaill´ ee du langage, le lecteur
pourra se r´ ef´ erer ` a [Hal92]. De mani` ere informelle, un programme LUSTRE
exprime des relations entre les variables d’entr´ ee et de sortie, chaque variable
´
etant une suite infinie de valeurs. L’objet de base est donc la constante, ainsi
1vaudra un ` a tous les instants. On peut construire de nouveaux objets ` a partir
des op´ erateurs arithm´ etiques de base (+, -, ...), des op´ erateurs de comparai-
son (<, =, ...), des op´ erateurs d’horloge (pre retarde un flot de un instant, fby
retarde ´ egalement un flot tout en initialisant l’objet, current sur-´ echantillonne
un flot sur l’horloge de l’horloge du flot, when sous-´ echantillonne un flot sur
une horloge).
Voici quelques exemples de construction et la valeur des flots associ´ es :
1 11111...
x x0x1x2x3x4...
x+ 1 x0+ 1 x1+ 1 x2+ 1 x3+ 1 x4+ 1 ...
1→x1x0x1x2x3...
c t t f f f ...
if c then x else 1 x0x11 1 1 ...
D´ efinition de la notion de facette fonctionnelle
Une facette fonctionnelle est un ensemble de nœuds LUSTRE cadenc´ es
`
a des p´ eriodes diff´ erentes communiquant entre eux et avec l’ext´ erieur, as-
sujettis ` a des contraintes de pr´ ec´ edences. On suppose ´ egalement qu’il n’y a
pas d’op´ eration d’horloge (current,when) dans les nœuds (i.e., chaque nœud
est localement mono horloge). Soit une fonction f, on note Dom(f)son
domaine de d´ efinition et Im(f)son image.
D´ efinition 1 Une facette fonctionnelle Fonc =h(Ti, Ci)i≤n,Fd,Fpiest
compos´ ee d’un n-uplet et de deux fonctions :
– le n-uplet (Ti, Ci)i≤nd´ ecrit pour chaque p´ eriode Pi= 2Ci−1bd´ eriv´ ee
de la p´ eriode de base b, l’ensemble des nœuds LUSTRE Ti={ni
1,· · · ,
ni
ji}rythm´
es ` a cette p´ eriode. L’environnement est vu comme un nœud
particulier not´ e indiff´ eremment env ou n1
0et cadenc´
e` a l’horloge de
base;
– la fonction partielle Fd:in →out d´ ecrit les communications syn-
chrones entre nœuds (environnement inclus). On s’abstrait des noms
de variables en num´ erotant de fac¸on syst´ ematique les entr´ ees/sorties
de chaque nœud, en effet in (resp.out) correspond ` a toutes les entr´ ees
des nœuds (resp. les sorties des nœuds) :
in =ni
j.ink|ni j∈Ti, k = 1, . . . , ki j, ni jaki jentr´
ees
out =ni
j.outk|ni j∈Ti, k = 1, . . . , li j, ni jali jsorties
– la fonction partielle Fp:in →out d´ ecrit les communications entre
nœuds retard´ ees (le flot consomm´ e est l’avant dernier flot produit).
Les exigences de l’automatique portent sur la fraˆ ıcheur des variables,
par exemple un flot ne peut ˆ etre consomm´ eque s’il a ´ et´ e produit depuis
5