Model-checking avec l’ordonnanceur

Les opérateurs du chapitre 6 peuvent également être utilisés dans la boucle de vérification formelle. Cette expérimentation vise à étudier l’impact de la prise en compte de l’ordonnanceur et de l’hypothèse de réactivité lors du model-checking. Pour réaliser cette évaluation, trois questions de recherche ont été considérées :

RQ#3 La prise en compte de l’ordonnanceur dans la boucle de vérification aide-t-elle les ingénieurs à choisir une politique d’ordonnancement en accord avec les exigences du système considéré ?

RQ#4 La prise en compte de l’ordonnanceur dans la boucle de vérification permet-elle de focaliser l’analyse sur les erreurs de conception essentielles ?

RQ#5 La prise en compte de l’ordonnanceur dans la boucle de vérification permet-elle d’améliorer les performances de model-checking ?

Pour y répondre, l’outil OBP2 a été utilisé pour explorer l’espace d’état du modèle de contrô-leur de passage à niveau, détecter des deadlocks et vérifier des propriétés LTL. Les deux va-riantes de l’implémentation de l’event pool (FifoEventPool et OrderedListDeferredEventPool) ont été utilisés pour étudier l’impact de l’ordonnancement sur le comportement du système.

Pour cette expérimentation, trois types d’ordonnancement ont été considérés : “sans or-donnancement” lorsque l’ordonnanceur n’est pas utilisé, “ordonnancement round-robin” et “or-donnancement à priorité fixe” lorsque l’ordonnanceur est utilisé avec les politiques d’ordon-nancement du même nom. Cette expérimentation prend également en compte l’Hypothèse de Réactivité (HR) pour étudier son influence sur les résultats de vérification formelle.

Le Tableau 10.1a montre les résultats obtenus via model-checking avec l’implémentation FifoEventPool et le Tableau 10.1b ceux obtenus avec l’implémentation OrderedListDeferred-EventPool. Pour chaque expérimentation, ces tableaux donnent le nombre de configurations (C) et le nombre de transitions (A) de l’espace d’état du modèle, le nombre de deadlocks (D), et le résultat de vérification de chaque propriété. Parmi ces résultats, la première ligne de chaque tableau correspond aux résultats de model-checking sans ordonnancement effectué dans la section précédente. Cette première ligne sert donc de référence. Les résultats avec ordonnancement montrent qu’inclure l’ordonnanceur dans la boucle de vérification aide à ré-duire l’espace d’état, tend à diminuer le nombre de deadlocks et tend à supprimer les chemins d’exécution qui entraînent la violation de la propriétéP4_CPN. Comme attendu, l’utilisation de

l’hy-Expérimentation C A D P1_CPN P2_CPN P3_CPN P4_CPN

Sans ordonnancement 173 276 2 3 3 3 7

Ordonnancement round-robin 26 25 1 3 3 3 3

Ordonnancement à priorité fixe 21 21 0 3 3 3 3

Sans ordonnancement avec HR 50 54 2 3 3 3 7

Ordonnancement round-robin avec HR 8 7 1 3 3 3 7

Ordonnancement à priorité fixe avec HR 21 21 0 3 3 3 3

(a) Avec l’implémentation FifoEventPool.

Expérimentation C A D P1_CPN P2_CPN P3_CPN P4_CPN

Sans ordonnancement 122 209 0 3 3 3 3

Ordonnancement round-robin 28 28 0 3 3 3 3

Ordonnancement à priorité fixe 21 21 0 3 3 3 3

Sans ordonnancement avec HR 32 48 0 3 3 3 3

Ordonnancement round-robin avec HR 27 27 0 3 3 3 3

Ordonnancement à priorité fixe avec HR 21 21 0 3 3 3 3

(b) Avec l’implémentation OrderedListDeferredEventPool.

TABLE 10.1 – Résultats du model-checking avec différentes implémentations de l’event pool (avec C : le nombre de configurations, A : le nombre de transitions, D : le nombre de deadlocks, et les résultats de vérification des propriétés).

pothèse de réactivité réduit l’espace d’état car elle diminue le nombre d’entrelacements avec les évènements venant de l’environnement.

Dans le cas spécifique de ce modèle de contrôleur de passage à niveau, l’ordonnancement à priorité fixe donne de meilleurs résultats que l’ordonnancement round-robin. Ceci peut être expliqué par le fait que l’ordonnancement à priorité fixe permet de mieux configurer les priorités des objets actifs du modèle. Il est aussi possible de remarquer que le cas “Ordonnancement round-robin avec HR” a très peu d’états dans son espace d’état. Après analyse, il s’avère que dans ce cas le scénario nominal aboutit à un deadlock qui bloque l’exécution du modèle et entraîne la violation de la propriété P4_CPN. Sans l’hypothèse de réactivité (“Ordonnancement round-robin”), un problème similaire est observé sauf que le deadlock qui entraîne la violation de P4CPN a été évité mais un autre deadlock est toujours présent. De notre perspective, il semble très intéressant pour les ingénieurs de pouvoir détecter ces problèmes dès la phase de vérification formelle. Pour les résoudre, les ingénieurs peuvent soit changer l’implémentation de l’event pool, la politique d’ordonnancement ou les deux.

Pour visualiser le comportement du système ordonnancé, le mécanisme de traces de EMI-UML permet également de produire des timing diagrams en utilisant le formalisme PlantEMI-UML.

10.4. Mise en œuvre des activités d’analyse de modèles

La Figure 10.7 montre un timing diagram illustrant une trace d’exécution du modèle de contrô-leur de passage à niveau avec un ordonnancement à priorité fixe et l’hypothèse de réactivité pour l’implémentation FifoEventPool.

controller:Controller (priority = 8)

Idle WaitRoadSignOnFarDetectionCloseDetection Idle WaitRailwaySignOn WaitGateOpen WaitRoadSignOffIdle railwaySign:RailwaySign (priority = 7)

Active Inactive Active

gate:Gate (priority = 6)

Open Closed Open

roadSign:RoadSign (priority = 5)

Inactive Active Inactive

tcEntrance0:EntranceTC (priority = 4) Detection Detection tcEntrance1:EntranceTC (priority = 3) Detection Detection tcExit:ExitTC (priority = 2) Detection Detection train:Train (priority = 1)

Idle Far Close PassingIdle

0 20 40 60 80 100 120 140 160 180 activation entranceDetection switchOn roadSignOn activation entranceDetection close gateClosed_switchOff authorization^activation

exitDetection_switchOnrailwaySignOn

open

gateOpen

switchOff roadSignOff

FIGURE 10.7 – Timing diagram d’une exécution du contrôleur de passage à niveau avec un ordonnancement à priorité fixe et l’hypothèse de réactivité pour l’implémentation FifoEventPool.

Avec ces résultats, on remarque également que toutes les propriétés qui sont vérifiées sans ordonnancement sont aussi vérifiées avec ordonnancement (le contraire n’étant pas vrai). C’est la raison pour laquelle les techniques de model-checking se sont affranchies des dépendances liées aux politiques d’ordonnancement réelles pour en considérer une abstraction. Cependant, les expérimentations réalisées montrent que l’approche proposée est intéressante à plusieurs niveaux.

Réponse à RQ#3 (Choix d’une politique d’ordonnancement) Inclure l’ordonnanceur dans la boucle de vérification permet de s’assurer que la politique d’ordonnancement choisie est appropriée pour le système considéré et qu’elle ne nuit pas aux exigences fonctionnelles auxquelles il doit satisfaire.

Réponse à RQ#4 (Analyse ciblée) La prise en compte de l’ordonnanceur dans la boucle de vérification permet de ne vérifier formellement que le comportement du système ordon-nancé et donc de ne se focaliser que sur les erreurs de conception qui peuvent se produire lors de l’exécution.

réactivité en phase de model-checking permet généralement de rendre les techniques de model-checking plus efficaces en réduisant la taille de l’espace d’état à explorer. Cette ten-dance a également été confirmée en appliquant l’approche à d’autres modèles UML. En gé-néral, l’espace d’état du modèle est plus petit car le non-déterminisme général de l’exécution du système a été résolu. Néanmoins, l’état d’exécution de la politique d’ordonnancement peut différencier des configurations par ailleurs équivalentes.