Nous mettons ici en application notre processus de génération de modèles formels dans un contexte de déploiement multiplates-formes. L’exemple est adapté d’un cas d’étude d’une application multitâches [13] mise dans un contexte d’ordonnancement coopératif. Ce cas d’étude avait déjà été présenté dans une de nos contributions [51]. L’expérimenta- tion qui repose sur ce cas a pour objectif de valider notre processus en s’appuyant sur deux plates-formes aux comportements et aux APIs différents. Ces plates-formes sont la norme OSEK/VDX qui a servi d’illustration tout au long de ce mémoire et le noyau VxWORKS
[93] que nous venons d’aborder dans la section précédente.
6.3.1 Description du cas d’étude
L’application comporte trois activités concurrentes temps réel qui sont déployées sur trois tâches ordonnançablesTask1,Task2etTask3. La concurrence de ces trois tâches est mise en œuvre suivant une politique d’ordonnancement non préemptive basée sur des propriétés fixes. Leurs caractéristiques sont les suivantes :
– Task1est périodique de périodeP 1 = a avec a ∈ [0, +∞[ et un temps d’exécution C1 ∈ [10, 20].
– Task2est sporadique avec seulement un délai minimal deP 2 = 2a unités de temps entre deux activations. Le temps d’exécution deTask2estC2 ∈ [18, 28].
– Enfin,Task3est périodique de périodeP 3 = 3a unités de temps et a un temps d’exé- cutionC3 ∈ [20, 28].
Ces trois tâches sont définies dans cet ordre de priorités : Task1 >Task2> Task3. La période a deTask1est un paramètre qui détermine la condition limite d’ordonnançabilité des tâches. L’application est ordonnançable si chaque activité a au moins une instance en exécution. La condition suffisante d’ordonnançabilité en mode non préemptif exige alors une charge processeurU telle que :
U = n X
i=1
(Ci/Pi) ≤ 1 (6.1)
avecn représentant le nombre de tâches, Ciprécisant le pire temps d’exécution de chaque tâche et Pi indiquant la période (respectivement le délai minimal) de chaque tâche péri- odique (respectivement tâche sporadique)Taski.
À titre d’exemple, nous avons cherché à composer cette application déployée avec le comportement de la plate-forme considérée, à l’aide de notre processus. Puis, la pro- priété d’ordonnançabilité que nous venons d’évoquer a été vérifiée sur les deux modèles générés dans le but de retrouver le domaine de validité théorique (i.e., avant déploiement)
du paramètrea. Après calcul et conformément à une autre étude [40], le domaine attendu esta ≥ 44.
6.3.2 Composition en TPN
Comme nous avons pu le voir dans le chapitre précédent, la composition d’un RI_TPN peut très vite exploser d’un point de vue combinatoire. Pour cette raison et pour simpli- fier, les figures 6.3 et 6.4 donnent les compositions établies en RI_TPN, uniquement sur la tâcheTask3(NT ask3) après avoir respectivement considérer le comportement de la norme OSEK/VDXet du noyau VxWORKS.
Task3 a été préférée puisqu’elle présente le cas le plus complexe de composition due à sa priorité la plus basse. La localisation d’un mécanisme d’ordonnancement coopératif dans les PDMs a provoqué la création d’arcs d’inhibition sur la transition
resume_Task3. En conséquence, le RI_TPN NT ask3 cloné a subi l’extension suivante CoopSched(NT ask3, {T ask1, T ask2}).Task3, comme les deux autres tâches, pointe sur une routine très simplifiée qui consiste juste à s’exécuter dans le temps imparti. Sur les deux modèles, la routine est constituée soit d’un service de terminaison (Nterminate3(T ask3)) pour la norme OSEK/VDX, soit d’un service de prise du sémaphore (NsemT ake3(Sem3)) avec mise en attente de la tâche pour le noyau VxWORKS. Le temps d’exécutionC3 a aussi été intégré dans la description de ces services appelés, suite à la composition. Il est en effet possible, sur chaque prototype comportemental de service, d’assigner un rôle d’exécution (cf. rôle execu- tionElements, figure 6.2) à un élément de comportement pour valuer ce temps d’exécution. Dans notre exemple, ce rôle est assigné sur le bornage de l’intervalle statique de la transition située entre les places START_terminate3(Task3) (respectivement START_semTake3(Sem3)) et DEADLINE_terminate3(Task3) (respectivement DEADLINE_semTake3(Sem3)) du RI_TPN Nterminate3(T ask3)(respectivementNsemT ake3(Sem3)).
Rappelons aussi que les rôles apparaissent en gras, en haut à doite des places fu- sionnables, pour mettre en évidence les points de connexion utiles à la composition des RI_TPNs. Ces places fusionnables, toujours connectées par des arcs crochets, représentent celles localisées lors de la composition deTask3avec sa routine d’exécution conformément à l’équation (5.2)1. Les fragments associés issus des prototypes de conception sont ensuite composés en appliquant les équations (5.3) et 5.4. Le même raisonnement est évidemment appliqué surTask1etTask2avant d’être elles-mêmes composer avecTask3, toujours en re- spectant les équations (5.3) et (5.4).
Une fois les modèles composés, ils ont pu être vérifiés en utilisant Roméo. Les systèmes composés sont ordonnançables si les deux RI_TPNs sont saufs ; c’est-à-dire il existe au plus un jeton dans chaque place. Cette propriété doit par conséquent être satisfaite en appliquant la logique temporelle suivante :AG[0,∞]bounded(1) qui dénote que pour tous les chemins du réseau parcourus, le marquage des places doit être, au maximum, borné à 1, dans un temps infini [74] [62]. Les résultats obtenus sur les deux RI_TPNs avec Roméo sont les suivants :
——-
Checking property AG[0,inf]bounded(1) on TPN :
"/home/clelionnais/TPN/OSEKVDX_NonPreemptiveApplication.xml"Waiting for response...
Result : {a>=44 }
——-
ENABLE Alarm3 enable Task3 LAPSE Alarm3 ACTIVATION Alarm3 activation Task3 SUSPENDED Task3 terminatedState Task3 ACTIVATION Task3 activation Task3 [0;0 ] increment Alarm3 [3a;3a ] cycle Alarm3 [0;0 ] resume Task3 READY Task3 activatedState Task3 READY Task1 activatedState Task1 READY Task2 activatedState Task2 [0;0 ] activate Task3 PROCESSOR Task3 processor Task3 resumedState Task3 RUNNING Task3 start Task3 START Task3 [0;0 ] execute Task3 end Task3 END Task3 NT ask3 NAlarm3
PROCESSOR terminate3(Task3)
processor Task3
end Task3
END terminate3(Task3)
resumedState Task3
RUNNING terminate3(Task3)
terminatedState Task3
SUSPENDED terminate3(Task3)
start Task3 START terminate3(Task3)
[0;0 ] terminate terminate3(Task3)
DEADLINE terminate3(Task3)
[20;28 ] delay terminate3(Task3)
Nterminate3(T ask3) PROCESSOR Proc processor Proc NP roc (c) (b) (b) (b) (b) (b) (d)
FIGURE6.3 – Description en RI_TPN d’une tâche périodique déployée sur une plate-forme
OSEK/VDX
Checking property AG[0,inf]bounded(1) on TPN :
"/home/clelionnais/TPN/VxWorks_NonPreemptiveApplication.xml"Waiting for response...
Result : {a>=44 }
Les résultats correspondent bien à la valeur théorique mentionnée plus haut. Dans cet exemple, la vérification nous donne satisfaction puisque la valeur théorique du domaine de validité annoncée avant déploiement est respectée après déploiement, et ce dans les deux cas
ENABLE Watchdog3 enable Task3 [3a;3a ] cycle Watchdog3 ACTIVATION Watchdog3 activation Task3[0;0 ]
resume Watchdog3 ELAPSE Watchdog3
[0;0 ] execute Watchdog3 start Task3 START Watchdog3 END Task3 end Task3 STOP Task3 [0;0 ] stop Watchdog3 PROCESSOR Watchdog3 processor Task3 NW atchdog3
START wdStart3(Watchdog3)
start Task3
ENABLE wdStart3(Watchdog3) enable Task3
END wdStart3(Watchdog3) end Task3 [0;0 ]
wdStart wdStart3(Watchdog3) NwdStart3(W atchdog3)
START semGive3(Sem3)
start Task3
[0;0 ] semGive semGive3(Sem3)
END semGive3(Sem3) end Task3
FULL semGive3(Sem3)
countState Task3
EMPTY semGive3(Sem3)
discountState Task3
PENDED semGive3(Sem3)
suspendedState Task3 READY semGive3(Sem3)
activatedState Task3 [0;0 ]
wake semGive3(Sem3) NsemGive3(Sem3) PENDED Task3 suspendedState Task3 [0;0 ] resume Task3 READY Task3 activatedState Task3 READY Task1 activatedState Task1 READY Task2 activatedState Task2 PROCESSOR Task3 processor Task3 resumedState Task3 EXECUTING Task3 start Task3 START Task3 [0;0 ] execute Task3 end Task3 END Task3 NT ask3 start Task3 START semTake3(Sem3)
[20;28 ] delay semTake3(Sem3)
DEADLINE semTake3(Sem3)
[0;0 ] semTake semTake3(Sem3)
end Task3
END semTake3(Sem3)
PROCESSOR semTake3(Sem3) processor Task3 resumedState Task3
EXECUTING semTake3(Sem3)
[0;0 ] pend semTake3(Sem3)
suspendedState Task3
PENDED semTake3(Sem3) FULL semTake3(Sem3)
countState Task3
EMPTY semTake3(Sem3) discountState Task3
NsemT ake3(Sem3) countState Task3 EMPTY Sem3 discountState Sem3 FULL Sem3 NSem3 processor Proc PROCESSOR Proc NP roc (a) (b) (b) (b) (b) (b) (b) (b) (b) (c) (c) (c) (c) (c) (d) (d) (d)
FIGURE6.4 – Description en RI_TPN d’une tâche périodique déployée sur une plate-forme VxWORKS
proposés. Cette propriété de sécurité est ici nécessaire, mais bien évidemment, elle est loin d’être suffisante. D’autres propriétés pourraient être vérifiées montrant qu’un mauvais choix de plate-forme ou bien même de mécanisme au sein d’une plate-forme compromettrait le
déploiement.
Alternativement, nous aurions pu représenter le comportement de la périodicité autrement qu’avec une alarme. Avec le noyau VxWORKS par exemple, l’application d’un
délai permet de différer la suite de l’exécution d’une tâche pendant une durée spécifiée. En pratique, cette mise en œuvre pour le compte d’une tâche périodique peut engendrer une dérive temporelle qui biaiserait le domaine de validité théorique.