Modélisation des systèmes temps-réel répartis embarqués pour la ...

Modélisation des systèmes temps-réel répartis embarqués
VII-1.2.2 Analyse des réseaux de Petri
Lorsqu’une transition est activée, les jetons correspondants sont consommés des places en
entrée, d’autres jetons sont générés dans les places de sortie. En se basant sur cette évolution,
l’espace d’états associé au modèle peut être construit. L’étude de l’espace d’états du système
permet d’analyser son comportement et vérifier la présence d’états particuliers (par exemple pour
savoir si une situation donnée peut se produire) ou vérifier la relation causale entre deux états (par
exemple, si un état e1 du système est atteint, est-ce que un autre état e2 sera atteint par la suite ?).
Les réseaux de Petri permettent aussi une analyse structurelle. Des propriétés telles que les
invariants – c’est-à-dire les sous-ensembles de place pour lesquels le nombre de jetons présents
reste constant – ou les symétries sont calculées sur la structure du modèle et ne nécessitent pas
la construction de l’espace d’états. Ceci permet de vérifier des systèmes dont l’espace d’états est
infiniment grand [Girault et Valk, 2003].
VII-2 Principes de la traduction des constructions AADL en réseaux
de Petri
Les réseaux de Petri constituent un formalisme abstrait pour décrire les architectures concurrentes
; ils fournissent un support mathématique à leur analyse. La construction d’un réseau de
Petri pour modéliser une architecture donnée traduit un choix sémantique pour l’interprétation des
places, des transitions et des jetons. La construction des réseaux de Petri dépend en partie des
propriétés que l’on souhaite vérifier. Dans cette section nous présentons la traduction des éléments
architecturaux AADL de base.
La modélisation du comportement d’un système (réparti ou non) fait essentiellement intervenir
les éléments logiciels de la modélisation. De la même façon que pour la génération de code, la
traduction d’une architecture AADL en réseau de Petri doit s’effectuer sur l’architecture AADL
instanciée ; nous ne considérons que les instances des composants, et pas leurs déclarations. Par
ailleurs, contrairement à la génération de code, la traduction s’effectue cette fois sur l’architecture
globale : nous considérons tous les nœuds applicatifs en même temps, afin de rendre compte des
interactions entre eux. La traduction en réseaux de Petri n’exploite donc pas la description AADL
de la même façon que la production d’applications exécutables, étudiée aux chapitres V et VI.
Dans le cadre d’une modélisation en réseaux de Petri, nous nous intéressons principalement
aux composants applicatifs actifs, c’est-à-dire les threads et les sous-programmes, ainsi que les
instances de composants de donnée. Les composants décrivant la plate-forme d’exécution sont
ignorés. Les autres composants logiciels (groupes de threads et processus) et les systèmes sont
considérés comme de simple conteneurs.
Une description AADL est constituée de composants qui acceptent des données en entrée et en
produisent d’autres en sortie. Il en découle la sémantique suivante pour la construction des réseaux
de Petri :
Règle VII.1 (interprétation des places et des transitions)
Nous interprétons les éléments d’un réseau de Petri ainsi :
– les jetons correspondent aux flux de données et d’exécution circulant à travers l’architecture
;
– les transitions modélisent les composants actifs, qui consomment des données et en
produisent d’autres, ainsi que les connexions AADL ;
– les places symbolisent les entités permettant de stocker des données.
124 c○ 2007 Thomas Vergnaud