Model-checking avec un environnement découplé

Pour résoudre ces problèmes d’interférences, nous proposons d’introduire une seconde instance de l’interpréteur de modèles (Interpréteur EMI (environnement)) qui interprète seule-ment l’abstraction de l’environneseule-ment. Un tel découplage permet de connecter facileseule-ment diffé-rentes abstractions de l’environnement à l’exécution du système en remplaçant seulement l’in-terpréteur de modèles correspondant. Cela peut également être intéressant pour isoler chaque exécution dans des zones de mémoire séparées afin de préserver l’intégrité de leurs états d’exécution. Cette architecture logicielle est présentée sur la Figure 6.4. L’abstraction de l’envi-ronnement doit être composée de façon asynchrone avec le système ordonnancé produit par

6.4. Vérification formelle et exécution embarquée avec ordonnancement

FIGURE6.4 – Architecture de model-checking avec l’ordonnanceur dans la boucle de vérifica-tion et un environnement découplé.

l’ordonnanceur afin d’obtenir le modèle fermé nécessaire aux algorithmes de model-checking. Cette tâche est réalisée par l’opérateur de Composition asynchrone et non plus directement par la sémantique du langage de modélisation comme auparavant. Un Filtre peut ensuite être utilisé pour filtrer certaines actions et appliquer certaines hypothèses (p. ex. l’hypothèse de réactivité) sur la STR fournie par la composition asynchrone. Cette architecture est finalement contrôlée par un model-checker qui applique des algorithmes de vérification formelle exhaus-tive sur l’espace d’état du modèle.

Définition 6.9. L’architecture de model-checking avec le modèle d’environnement découplé du modèle du système est formellement définie de la façon suivante :

def model_checking_with_decoupled_env (C1 C2 A1 A2 S1 S2 : Type) (system : STR C1 A1) (environment : STR C2 A2) (scheduling_policy : SchedulingPolicy C1 A1 S1) (filtering_policy : FilteringPolicy ((C1×S1)×C2) ((S1×A1) ⊕ A2) S2) : STR (((C1×S1)×C2)×S2) (S2×((S1×A1) ⊕ A2)) := filter ((C1 × S1) × C2) ((S1×A1) ⊕ A2) S2

((scheduler C1 A1 S1 system scheduling_policy) ⊗a environment) filtering_policy

De plus, les unités d’exécution de l’environnement ont besoin d’échanger des données avec les unités d’exécution du système. Pour cela, les ports I/O des interpréteurs EMI sont connectés ensemble pour relier les sorties de l’environnement aux entrées du système et les sorties du système aux entrées de l’environnement. Dans notre architecture logicielle, la com-munication est réalisée via des variables partagées de façon à relier ensemble les données d’exécution des deux composants. Différents mécanismes de communication interprocessus (ou en anglais Inter-Process Communication (IPC)) doivent également pouvoir être utilisés en définissant d’autres opérateurs de composition en plus de la composition asynchrone.

Si les unités d’exécution du système et de l’environnement sont spécifiées dans le même langage de modélisation, l’Interpréteur EMI (système) et l’Interpréteur EMI (environnement) peuvent être deux instances du même interpréteur de modèles. Cependant, il est également possible de spécifier les unités d’exécution de l’environnement dans un autre langage pro-duisant ainsi une exécution hétérogène de modèles. Cette possibilité est un défi scientifique constituant une perspective de ces travaux de thèse. En pratique, l’exécution hétérogène de modèles n’est pas triviale à réaliser car elle nécessite de définir une conversion sémantique et structurelle des données échangées afin d’exprimer les données sources en termes de la sémantique cible et avec la forme appropriée. Ces conversions sont non seulement complexes mais elles doivent également être prouvées afin que nous puissions les utiliser en vérifica-tion formelle. L’exécuvérifica-tion hétérogène induit également d’autres problèmes comme la synchro-nisation et la coordination des exécutions du système et de l’environnement. Plusieurs tra-vaux [Buc+01 ; Var+15] dans la communauté de l’IDM se sont focalisés sur ces problématiques et ont proposé des solutions comme le langage de coordination BCOol [Var+15].

6.5 Synthèse

Les préoccupations liées à la concurrence font partie intégrante de la définition d’un langage concurrent et doivent, pour cette raison, être considérées à la fois en phase d’exécution et de vérification. Ce chapitre a présenté une approche permettant de définir une composition modulaire du système, de l’ordonnanceur et de l’environnement. Ainsi, l’ordonnanceur utilisé lors de l’exécution réelle peut désormais être intégré dans la boucle de vérification formelle afin de vérifier le comportement du système ordonnancé.

Cette composition modulaire est réalisée en utilisant différents opérateurs. Le filtre per-met de prendre en compte certaines hypothèses (p. ex. l’hypothèse de réactivité) en model-checking. L’ordonnanceur devient un composant explicite et pilotable pouvant être configuré par une politique d’ordonnancement. Ces opérateurs ont été formellement définis et peuvent être combinés pour définir l’architecture logicielle répondant aux besoins de l’activité réalisée. Ils permettent à la fois de redescendre certaines hypothèses de haut niveau (p. ex. l’hypothèse

6.5. Synthèse

de réactivité) dans les outils d’analyse et de remonter certains concepts propres à la plateforme d’exécution (p. ex. l’ordonnancement) à un niveau d’abstraction plus élevé.

Cette technique permet ainsi de réduire le problème d’équivalence entre ce qui est vérifié et ce qui est exécuté. Elle contribue également à améliorer les performances de model-checking en supprimant de l’espace d’état les chemins d’exécution devenus impossibles par rapport aux choix d’ordonnancement réalisés.

P

ILOTAGE ET OBSERVATION DE

L

’

EXÉCUTION DE MODÈLES

7.1 Introduction

Pour analyser le comportement d’un système logiciel, les outils d’analyse doivent (i) pilo-ter et (ii) observer l’exécution de ce système. Pour le pilotage, la section 7.2 présente l’inpilo-ter- l’inter-face utilisée pour piloter un interpréteur EMI. Cette interl’inter-face permet d’implémenter l’interl’inter-face STR utilisée par nos opérateurs et par les outils d’analyse pour contrôler l’exécution du mo-dèle. Pour l’observation, les outils d’analyse ont besoin de pouvoir évaluer des propositions atomiques portant sur l’exécution du système. Ces propositions atomiques sont souvent ex-primées dans des formalismes spécifiques (différents du langage de modélisation) qui sont difficiles à maîtriser par les ingénieurs. Pour faciliter cette tâche, la section 7.3 présente le lan-gage d’observation utilisé dans l’approche EMI pour exposer les objets du système et exprimer les propositions atomiques directement en termes des concepts du langage de modélisation. Le langage d’observation est donc propre à chaque langage de modélisation. Il reste néan-moins important de définir explicitement les caractéristiques générales de ce langage. Une