• Aucun résultat trouvé

Les interfaces et les connections

2.3 Synth`ese

3.1.5 Les interfaces et les connections

Interfaces

Les interfaces des composants AADL sont d´ecrites par des ports ou des services permettant ou requ´erant l’acc`es `a un composant. On distingue trois cat´egories de ports, les ports data, les ports event, et les ports event data. Les ports sont directionnels, ils peuvent ˆetre en entr´ee, en sortie ou les deux. Les ports peuvent ˆetre regroup´es en groupe de ports, lorsque l’interface d’un composant est d´efinie par un groupe de ports le composant auquel il est connect´e doit poss´eder le groupe de ports dual. Un groupe de ports dual est d´efini comme un ensemble de ports de mˆemes types que le groupe de ports auquel il fait r´ef´erence, avec des directions duales. Les ports sont des points de connexions logiques entre les composants. Ils peuvent ˆetre utilis´es pour transf´erer des donn´ees (data) ou signaux (event). Les ports sont vus par un thread comme des tampons accessibles comme des variables locales. Les ports en entr´ee sont mis `a jour lors de l’activation du thread. La d´efinition d’instants pr´ecis o`u peuvent avoir lieu des communications est une des pro-pri´et´es essentielles d’AADL. Elle permet de d´efinir un comportement global

de l’application plus d´eterministe. On revient sur ces diff´erents m´ecanismes dans la partie pr´esentant le mod`ele d’ex´ecution AADL.

– Les ports data servent `a transmettre une donn´ee, ces ports n’ont donc pas de file d’attente, seule la derni`ere valeur est disponible. Un dra-peau (fresh) permet au thread de savoir si la valeur du port a ´et´e modifi´ee depuis sa pr´ec´edente activation. Si le port n’a pas re¸cu de nouvelle valeur, l’ancienne valeur reste disponible. Les donn´ees en-voy´ees par un port data en sortie le sont lorsque le thread termine son ex´ecution.

– Les ports event servent principalement `a transmettre des signaux : la r´eception d’un ´ev´enement peut d´eclencher l’activation d’un thread. Chaque port event dispose d’un compteur d’´ev´enements. Des propri´e-t´es permettent de d´efinir la politique d’acc`es au port, lors de l’activa-tion d’un thread le syst`eme peut mettre `a jour un port event en copiant le contenu du compteur d’´ev´enement ou un seul. De plus, on peut aussi d´efinir le comportement du port lorsque le compteur a atteint sa valeur maximale. Un port event en sortie peut envoyer un ´ev´enement `a n’im-porte quel instant de l’ex´ecution du thread. Cet instant est d´etermin´e par le code associ´e au thread.

– Les ports event data servent `a transmettre et stocker des donn´ees. Ils disposent d’une file pour stocker les donn´ees arrivant et ont le mˆeme comportement que les ports event. Lorsque la file est pleine, il peut effacer la donn´ee la plus r´ecente (queue de la file) ou la donn´ee la plus ancienne (tˆete de la file) et ins´erer dans la file la nouvelle donn´ee. L’exemple suivant d´efinit un thread PF et son interface compos´ee de 6 ports, un de chaque type. La figure 3.5 montre la version graphique de cette sp´ecification.

thread PF features

Port1 : in data port ; Port2 : in event port {

Qu eue S iz e => 5 ;

D e q u e u e P r o t o c o l => OneItem } ;

Port3 : in event data port { Qu eue S iz e => 10 ;

D e q u e u e P r o t o c o l => A l l I t e m s } ;

Port4 : out data port ; Port5 : out event port ; Port6 : out event data port ; end PF ;

L’interface sert aussi `a sp´ecifier qu’un composant propose (ou requiert) l’acc`es `a un service (sous programme), ou un sous composant (data ou bus).

3.1. PR ´ESENTATION DU LANGAGE 33 PF Port1 Port2 Port3 Port4 Port5 Port6

Fig. 3.5 – D´efinition d’un ensemble de ports

Un thread peut ainsi proposer `a d’autres threads d’ex´ecuter des sous pro-gramme ou d’acc´eder `a une partie de ses donn´ees. Sym´etriquement, il peut avoir besoin d’acc´eder `a une donn´ee situ´ee dans un autre composant. Dans le cas d’une donn´ee partag´ee, une propri´et´e du connecteur permet de d´efinir si le composant veut acc´eder `a la donn´ee en lecture ou ´ecriture seule ou en lecture et ´ecriture.

Connexions

Une connexion entre deux ports repr´esente un transfert de signaux ou de donn´ees entre deux composants s’ex´ecutant en parall`ele. Une telle connexion est en r´ealit´e une s´equence de une ou plusieurs connexions ´el´ementaires qui suivent la hi´erarchie des composants AADL. La source et la destination fi-nales d’une connexion sont soit un thread, un processeur, ou un p´eriph´erique. Dans le cas d’une connexion entre deux ports data ou deux ports event data, les connexions sont typ´ees, on ne peut ´etablir une connexion qu’entre ports transmettant un type de donn´ees compatibles1

. Un port de data en entr´ee ne peut avoir qu’une seule source, les connexions de donn´ees sont de type 1-n. Les connexions entre ports event et entre ports event data sont de type n-n.

L’exemple suivant d´efinit deux threads, P et Q, le premier poss`ede un port en sortie et le second un port en entr´ee. Ces threads sont instanci´es dans deux implantations de process : A et B. `A leur tour ces process sont instanci´es dans un syst`eme. Pour d´ecrire une connexion entre ces deux threads on doit suivre toute la hi´erarchie des composants. Une version graphique de cet exemple est repr´esent´e par la figure 3.6

thread P features

PortThreadP : out data port ; end P ;

1

Le standard AADL ne d´efinit pas de notion de compatibilit´e entre types de donn´ees telle qu’on peut la trouver dans des langages de programmation. Cependant AADL permet de d´efinir des relations de compatibilit´e entre diff´erents types de donn´ee par une propri´et´e.

thread implementation P . imp end P . imp ;

thread Q features

PortThreadQ : in data port ; end Q;

thread implementation Q. imp end Q. imp ;

process A features

PortProcessA : out data port ;

end A; process B

features

PortProcessB : in data port ;

end B ;

process implementation A. imp subcomponents

thp : thread P . imp ; connections

cnx1 : data port thp . PortThreadP −> PortProcessA ; end A. imp ;

process implementation B . imp subcomponents

thq : thread Q. imp ; connections

cnx2 : data port PortProcessB −> thp . PortThreadQ ;

end B . imp ; system s i m p l e end s i m p l e ;

system implementation s i m p l e . imp subcomponents

procA : process A. imp ; procB : process B . imp ; connections

cnx3 : data port procA . PortProcessA −> procB . PortProcessB ; end s i m p l e . imp ;

Le transfert de donn´ee entre deux threads p´eriodiques ayant une mˆeme p´eriode, ou l’une des p´eriodes est un multiple de l’autre, peut ˆetre rendu d´eterministe. Une connexion entre deux ports data de threads p´eriodiques

3.1. PR ´ESENTATION DU LANGAGE 35

System simple

Process A Process B

Thread P Thread Q

Fig. 3.6 – Hi´erarchie des connexions

peut ˆetre imm´ediate ou retard´ee. Dans le cas de la connexion imm´ediate, le thread produisant la donn´ee l’envoie `a sa compl´etion (lorsque le thread rend le contrˆole au noyau ; ces aspects du mod`ele d’ex´ecution seront pr´esent´es dans la section 3.2) et le thread destination la recevra au moment du d´ebut de son ex´ecution. Si les deux threads sont de mˆeme p´eriode, la connexion est synchrone, `a chaque cycle, un thread produit une donn´ee, l’envoie `a sa destination qui la re¸coit au d´ebut de son ex´ecution. Si la p´eriode du thread r´ecepteur est un multiple de celle de l’´emetteur alors, le r´ecepteur fait du sur ´echantillonnage , il r´eutilise plusieurs fois la mˆeme donn´ee. Dans le cas contraire, il fait du sous ´echantillonnage, il ne consomme pas toutes les don-n´ees produites par l’´emetteur. Dans le cas d’une connexion retard´ee, l’´emet-teur transmet sa donn´ee au moment de la fin de son ´ech´eance. La donn´ee produite dans un cycle est consomm´ee au cycle suivant par le consomma-teur. Il ne peut pas y avoir de cycle de communications imm´ediates entre un ensemble de composants.

Les connexions servent aussi `a relier les connecteurs repr´esentant un ser-vice requis ou propos´e au composant final proposant ce serser-vice (donn´ee partag´ee, sous programme). Comme pour les connexions entre ports, il faut parcourir toute la hi´erarchie de composants AADL pour atteindre le compo-sant souhait´e ; on ne peut pas d´efinir directement une connexion entre deux composants ne faisant pas partie du mˆeme composant.