Dans la figure 5.5, nous présentons deux propriétés de ce type déclarées dans la section properties de la description d’une implantation du composant

systeme_ABS. La première propriété est Compute_Execution_Time assignée à la valeur 7 ms.

system systeme_ABS

end systeme_ABS;

system implementation systeme_ABS.Impl

subcomponents

capteur_pedal: device capteur_pedal;

controleur_abs: system controleur_abs.impl; actuateur_frein: device actuateur_frein;

properties

Compute_Execution_Time => 7ms applies to

controleur_abs.actionner_frein.calcul_glissement;

Required_Connection => false applies to

controleur_abs.tester_entrees.test_vitesse.out_port ;

end systeme_ABS.Impl;

system implementation controleur_abs.impl

subcomponents

tester_entrees: process tester_entrees.Impl actionner_frein: process actionner_frein.Impl;

end controleur_abs.impl;

process actionner_frein

features

etat_pedal: in event port; vitesse_r: in data port;

cmd_frein: out event data port;

end actioner_frein;

process implementation actionner_frein.Impl

subcomponents

calcul_glissement: thread calcul_glissement.impl; calcul_cmd_frein: thread calcul_cmd_frein.impl;

end actioner_frein.Impl;

thread implementation calcul_glissement.impl

end calcul_glissement.impl;

Figure 5.5 : Exemple d’une assignation de propriétés par propagation test_vitesse

Required_Connection => false applies to

controleur_abs.tester_entrees.test_vitesse.out_port ;

Compute_Execution_Time => 7 ms applies to

controleur_abs.actionner_frein.calcul_glissement;

controleur_abs

tester_entrees  actionner_frein

Cette propriété s’applique au thread calcul_glissement référencié par le chemin controleur_abs.actionner_frein.calcul_glissement qui indique que le thread calcul_glissement est un sous-composant du process actionner_frein lui-même étant un sous-composant du composant system controleur_abs. La deuxième propriété assigne la valeur fausse à la propriété Required_Connection permettant au port de sortie du thread test_vitesse d’être non lié.

L’assignation par propagation concerne également les propriétés de déploiement. Le déploiement est spécifié par les propriétés AADL: Actual_Connection_Binding, Actual_Memory_Binding et Actual_Processor_Binding pour indiquer respectivement par quel bus, mémoire ou processeur est porté une connexion, une donnée ou un processus. La valeur assignée à de telles propriétés est spécifié par une référence, via le mot clé reference, à un composant de la plateforme d’exécution (à savoir : bus, memory, processor) suivi par applies to pour désigner le chemin relatif à l’endroit de la hiérarchie auquel l’association de propriété est indiquée.

system implementation systeme_ABS.Impl

subcomponents

controleur_abs: system controleur_abs.impl; cpu1: processor cpu1.impl;

actuateur_frein: device actuateur_frein;

properties

Actual_Processor_Binding => reference cpu1 applies to

controleur_abs.actionner_frein.calcul_glissement;

end systeme_ABS.Impl;

system implementation controleur_abs.impl

subcomponents

tester_entrees: process tester_entrees.Impl actionner_frein: process actionner_frein.Impl;

end controleur_abs.impl;

process implementation actionner_frein.Impl

subcomponents

calcul_glissement: thread calcul_glissement.impl; calcul_cmd_frein: thread calcul_cmd_frein.impl;

end actioner_frein.Impl;

thread implementation calcul_glissement.impl

end calcul_glissement.impl;

Figure 5.6 : Exemple de propriété de déploiement

5.3.3 Analyse et vérification des propriétés AADL

A chaque entité architecturale AADL, nous pouvons ainsi associer des propriétés présentant des valeurs les caractérisant. Les propriétés constituent donc un aspect fondamental et important dans la description du comportement des entités AADL. Cependant, leur description reste textuelle et aucune sémantique ne leur a été proposée. Certains travaux dans la littérature [SLN+04] [Axl07] ont accordé une

Actual_Processor_Binding => reference cpu1 applies to controleur_abs.actionner_frein.calcul_glissement;

controleur_ab

actionner frein

calcul glissement

certaine importance à la prise en charge des valeurs de quelques propriétés d’exécution pour simuler le comportement des threads, ou celui d’architectures de systèmes décrit par AADL. Jusqu’à présent, aucune recherche n’a abordé la formalisation de la sémantique d’une propriété rattachée à un composant donné quelque soit son type. Nous contribuons à travers la section suivante à la solution de ce problème, en montrant la capacité du modèle proposé (ABAReL) pour d’une part, formaliser la sémantique d’une propriété AADL déclarée et d’autre part, l’analyser et la vérifier formellement en exécutant le comportement du composant auquel elle se rattache.

5.4 Prise en charge des propriétés AADL par ABAReL

ABAReL modélise les aspects syntaxiques du langage AADL ainsi que la sémantique de comportement de ses composants en particulier celle d’un thread. Ce modèle formel est extensible et permet de prendre en charge la formalisation de toutes ces propriétés AADL grâce à l’expressivité et la flexibilité de la logique de réécriture. Donc, formaliser la sémantique d’une propriété déclarée dans une description AADL implique d’une part, un enrichissement de la signature d’ABAReL (aspects syntaxiques) et d’autre part, associer une interprétation sémantique à chaque concept syntaxique introduit (aspects sémantiques). L’implémentation du modèle mathématique étendu obtenu sous RT-Maude, permettra l’analyse et la vérification de ces propriétés en tirant profit des outils qui existent autour du système Maude. Nous nous restreignons dans le cas de notre étude à la formalisation de trois types de propriétés, les plus utilisées dans le cas de l’exécution d’un thread. Notre démarche est assez générique et pourra s’appliquer à n’importe quelle déclaration de propriété.

5.4.1 Sémantique d’une propriété de type Period

Dans la déclaration AADL ci-dessous de cette propriété, nous recensons les éléments les plus importants qui peuvent être pris en charge de façon assez naturelle par notre modèle pour procéder à sa formalisation.

thread implementation Nom du composant Thread

properties

Dans une première étape, nous proposons une extension [BB+09, BBB10] de la signature du modèle mathématique ABAReL pour la prise en charge des valeurs assignées à cette propriétés, dans ce cas il s’agit des valeurs de type temps. Ces valeurs sont alors spécifiées par la théorie équationnelle TIME [ÖM96]. Dans cette théorie qui sera importée par la théorie de réécriture orientée objet temps réel ℜTh

formalisant le comportement du thread spécifié, nous retrouvons des opérations et des équations spécifiques pour gérer l’aspect temps (telles que delta et mte pour l’interprétation de l’écoulement du temps sur la configuration d’un thread).

Dans une seconde étape, nous enrichissons la spécification des configurations de ce thread par un paramètre dit Clock-P modélisant sa période capturée à partir de la déclaration de la propriété associée (Period). Toutes les règles de réécriture modélisant le comportement concurrent de ce thread doivent prendre en considération l’évolution de ce paramètre.

5.4.2 Sémantique d’une propriété de type Compute_Execution_Time

De façon assez similaire, le modèle étendu d’ABAReL traite la formalisation de la sémantique d’une propriété AADL du type Compute_Execution_Time associée à un composant de type thread. Le paramètre à rajouter dans la configuration d’un thread donné est nommé Clock-C, il sert à modéliser son temps d’exécution. Evidemment, l’évolution de ce paramètre doit également être prise en considération par toutes les règles de réécriture modélisant le comportement concurrent de ce thread.

5.4.3 Sémantique d’une propriété de type Latency

Cette propriété AADL est déclarée pour une connexion établie entre deux threads, contraignant ainsi le passage de flux de données et/ou d’événements (transmission de messages) entre ces threads. Dans une théorie de réécriture formalisant une description architecturale constituée de plusieurs threads reliés par des connexions, nous introduisons alors la sorte DlyMsg qui modélise le temps de latence du flux (récupéré de la déclaration de la propriété Latency). Nous définissons aussi

l’opérateur dly(m,t) qui indique qu’il reste t unité de temps pour l’arrivée du message m à destination [BBB10, BB10].

Notons que pour cette étude, les valeurs des trois types de propriétés considérées sont déclarées dans la description des composants où elles sont exploitées. Il s’agit d’une assignation directe, les valeurs des propriétés sont donc capturées directement par la spécification. Quand la valeur d’une propriété nécéssite une référence à une autre partie dans la hiérarchie du modèle, on parle de la propagation des propriétés. Pour capturer les valeurs de ces propriétés et les affecter ensuite à la spécification du composant où elles doivent être exploitées, il faut expliciter leur chemin de propagation. Pour ce faire, nous proposons une extension du modèle mathématique d’ABAReL par une théorie de réécriture spécifiant le chemin de propagation pour pouvoir assigner la valeur déclarée à l’entité AADL référenciée. Le chemin de propagation doit être spécifié en fonction des sous composants déclarés dans la section subcomponents de chaque composant dans la hiérarchie.

Exemple 6. Pour clarifier la formalisation des propriétés à valeurs de type temps,