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

15 end sspg_b;
Modélisation des systèmes temps-réel répartis embarqués
Listing VII.4 – Description d’un sous-programme avec deux séquences d’appel, correspondant au
réseau de Petri de la figure VII.8(a)
Le listing VII.4 décrit un sous-programme possédant deux séquences d’appel seq1 et seq2.
Chaque séquence appelle un seul sous-programme, qui prend un paramètre en entrée et ne rend
rien en sortie. La traduction en réseau de Petri est illustrée sur la figure VII.8(a). Nous voyons que
les deux séquences peuvent s’exécuter dans un ordre arbitraire, un nombre quelconque de fois.
La figure VII.8(b) modélise le comportement que nous souhaitons appliquer au sous-programme :
nous voulons d’abord exécuter la séquence seq1 puis la séquence seq2, puis terminer l’exécution
du sous-programme.
La figure VII.8(c) est le résultat de la fusion du réseau issu de la description AADL et du
réseau comportemental. Nous voyons que les transitions seq1 et seq2 sont fusionnées avec les
sous-réseaux de séquences correspondantes ; les places begin et end sont connectée à la transition
init pour que le réseau du sous-programme puisse contrôler le sous-réseau comportemental.
VII-7 Propriétés étudiées sur l’architecture
La traduction d’une modélisation AADL en réseau de Petri permet d’extraire les flux d’exécution
et de les représenter dans un formalisme facilitant leur analyse. Il est possible d’utiliser
les formules de logique temporelle afin de vérifier certains comportements sur l’architecture complète.
Ces vérifications sont spécifiques à la modélisation considérée, et notamment dépendent a
priori des modélisations comportementales fournies pour les différents composants.
Parallèlement, la vérification de certaines caractéristiques de l’architecture peut être effectuée
systématiquement. Ces vérifications concernent des propriétés structurelles concernant la viabilité
des flux d’exécution ; par exemple, nous voulons systématiquement nous assurer que la construction
architecturale ne fait pas apparaître de blocage dans les flux d’exécution.
Le réseau de Petri généré à partir d’une description AADL modélise la circulation des données
et des flux d’exécution. Nous pouvons donc l’exploiter afin d’analyser les éventuels dysfonctionnements
dans l’exécution de l’architecture.
Un dysfonctionnement dans l’architecture correspond à un arrêt de la circulation des données,
et peut se manifester de plusieurs façons :
– les communications entre les différents threads ne sont pas coordonnées ;
– l’absence d’une donnée dans l’exécution des séquences d’un thread ;
– la « famine » d’un thread ;
– le blocage de l’exécution d’un thread ;
– l’utilisation de données dont la valeur n’est pas déterministe.
L’apparition de ces situations dans l’architecture peut être traduite par des propriétés structurelles
sur le réseau ou des formules de logique temporelle. Dans la suite nous présentons les
différentes formules correspondantes.
VII-7.1 Cohérence des communications
Nous avons vu en section VII-4.2.3 que les réseaux de Petri que nous construisons sont censés
être bornés. Certaines configurations architecturales conduisent cependant à une surproduction de
jetons qui ne peut pas être régulée par la boucle de rétroaction. Le listing VII.5 est un exemple
d’une telle configuration ; la figure VII.9 représente de réseau de Petri correspondant.
142 c○ 2007 Thomas Vergnaud