IDM pour une approche combinant synthèse et vérification de modèles

Transcription

1 1 IDM pour une approche combinant synthèse et vérification de modèles Thomas Collonvillé, Laurent Thiry, Bernard Thirion Laboratoire MIPS ENSISA - Université de Haute-Alsace, 12 rue des frères Lumière, Mulhouse Cedex, France {thomas.collonville, laurent.thiry, bernard.thirion}@uha.fr Résumé Deux approches classiques sont couramment utilisées pour la conception de logiciels de commande : la théorie de la supervision et le Model-Checking. La théorie de la supervision permet la synthèse d un superviseur à partir du modèle permissif du système et du modèle des spécifications. Une fois associés, le superviseur et le système satisfont par construction le comportement défini par les spécifications. Le Model-Checking permet de valider le modèle du système réalisé à partir de propriétés et d identifier des erreurs de conception. Ces deux approches offrent chacune des avantages et leur intégration doit permettre de concevoir des systèmes logiciels de manière plus simple et plus sûre. L Ingénierie Dirigée par les Modèles propose une approche fondée sur des concepts et des outils pour intégrer de façon rationnelle différents formalismes. Ce papier propose d utiliser l Ingénierie Dirigée par les Modèles afin d intégrer les approches par synthèse de superviseur et par Model-Checking afin de bénéficier des avantages des deux domaines et de l expérience des deux communautés. Mots clés Ingénierie Dirigée par les Modèles, Supervision, Model-Checking. I. INTRODUCTION Conditionné par des enjeux humains, économiques ou écologiques, le développement de systèmes logiciels critiques doit s assurer que la conception proposée satisfait les propriétés exigées et énoncées par le cahier des charges. Il existe différentes approches possibles pour réaliser des systèmes logiciels plus sûrs comme la théorie de la supervision [1] ou le Model-Checking [2], [3]. Initiée par P.J. Ramadge et W.M. Wonham, la théorie de la supervision permet la synthèse d un superviseur valide par construction à partir d un modèle non contraint du système et celui des propriétés souhaitées. Ce superviseur est associé au système initial pour lui garantir un fonctionnement conforme aux spécifications. Le Model- Checking propose une approche alternative permettant de répondre au problème de la vérification d un système logiciel en s assurant que son modèle satisfait des propriétés telles que la sûreté et la vivacité. Si les propriétés ne sont pas satisfaites, la modification du modèle est nécessaire. Ces deux approches, par synthèse de superviseur et par Model-Checking, proposent des concepts, des notations, des méthodes et des outils différents mais complémentaires. La théorie de la supervision s appuie sur les systèmes à événements discrets, par le biais de la théorie des langages et des automates à états finis [4] pour modéliser le système et les propriétés. Des outils tels que Supremica 1 [5], UMDES 2 ou UKDES [6] permettent alors la synthèse du modèle du superviseur. Le Model-Checking [7] utilise des systèmes de transitions [8] pour modéliser le comportement du système et utilise typiquement des logiques temporelles linéaires (LTL) ou arborescentes (CTL) pour décrire les propriétés à vérifier. Des outils tels que Spin 3 [9] ou LTSA 4 [10] permettent alors de vérifier que le système satisfait les propriétés. Bien que différents dans leurs approches, la supervision et le Model-Checking restent complémentaires. Il est important de chercher à les relier pour profiter des concepts et des outils de chacune des deux communautés. Cet article propose d appliquer les concepts issus du domaine émergent de l Ingénierie Dirigée par les Modèles (IDM) [11] pour réaliser cette intégration. L IDM propose l unification de différents domaines en s appuyant sur les concepts de méta-modèle et de transformation de modèles. Plus particulièrement, ce document propose d extraire les éléments communs aux deux domaines, puis d élaborer des transformations de modèles pour passer d une représentation dans un domaine à une représentation dans l autre domaine, ceci afin de bénéficier des avantages de chacun. Le document est structuré en cinq parties. La première partie est cette présente introduction. La seconde partie présente l Ingénierie Dirigée par les Modèles et ses principaux concepts. La troisième partie présente un problème lié à la locomotion d un robot hexapode, exemple sur lequel s appuie le papier pour présenter les différents domaines et notre proposition. La quatrième partie présente les deux approches considérées (théorie de la supervision et Model-Checking) pour en déterminer les avantages et les inconvénients. Enfin, la dernière partie présente le rapprochement de la théorie de la supervision et du Model-Checking au sein d un processus IDM. II. INGÉNIERIE DIRIGÉE PAR LES MODÈLES L Ingénierie Dirigée par les Modèles [11], ou IDM, offre un cadre méthodologique permettant de relier de manière

2 2 rationnelle différents domaines. Elle permet cette unification grâce à l utilisation de méta-modèles et de transformations de modèles. Pour cela, l IDM relie les concepts de système, de modèle, de langage de modélisation et de méta-modèle [12], [13], figure 1. Modèle est conforme à appartient Métamodèle représente Langage de Modélisation codomaine le même langage de modélisation (le même métamodèle). Les transformations exogènes permettent de passer d un langage de modélisation à un autre. Ce changement de langage de modélisation permet de bénéficier des avantages de chacun des langages. Pour la réalisation des transformations de modèles, l IDM propose une architecture de transformation (figure 2) reliant les différents éléments des méta-modèles de façon à établir des règles de correspondance. Ces règles, appliquées au modèle à transformer, vont générer un nouveau modèle conforme au méta-modèle cible. représente Système FIG. 1. Relation entre modèle, langage et métamodèle. Un système est l entité étudiée dans le cadre d un processus de modélisation. Un modèle est l abstraction du système réalisé dans une intention et un contexte particulier. Un modèle représente le système et il doit pouvoir être utilisé pour répondre à des questions sur le système. La relation existante entre le modèle et le système est la relation de modélisation. Un langage de modélisation définit l ensemble des modèles réalisables comportant des caractéristiques communes. Un méta-modèle spécifie un langage de modélisation. Il définit les règles de construction de modèles pour le domaine qu il concrétise. Un modèle est alors dit conforme à un méta-modèle s il appartient à l ensemble des modèles modélisés par le méta-modèle. L IDM fournit alors des outils (MetaEdit+ 5, Eclipse EMF 6, GME 7, etc) qui peuvent être configurés à l aide de ces métamodèles et utilisés dans des domaines spécifiques. A. Rasse [14] utilise par exemple l outil MetaEdit+ pour modéliser des systèmes dynamiques et obtenir automatiquement une représentation pouvant être analysée par un outil de Model- Checking (en l occurrence LTSA) puis utilisée pour obtenir du code exécutable. Deux approches sont possibles pour relier deux domaines. La première consiste à définir un méta-modèle basé sur les concepts communs aux différents domaines. Cette approche a l avantage d être simple mais il importe que les domaines à unifier soient proches conceptuellement. L autre approche se base sur la définition de modèles de transformations. Cette seconde approche est plus générique et permet le passage d un domaine à un autre de manière plus systématique. Plus précisément, une transformation de modèles définie par l IDM est la modification ou la synthèse d un modèle suivant des règles définies au niveau de son méta-modèle. Les transformations sont de deux types : endogènes et exogènes. Les transformations endogènes sont des transformations ayant pour domaine et 5 http :// 6 http :// 7 http :// FIG. 2. Modèle de transformation de modèles. III. EXEMPLE DE SYSTÈME Le système utilisé pour illustrer les éléments proposés est un logiciel de commande assurant la fonction de locomotion d un robot hexapode [15], figure 3.a. Les informations complémentaires sur cette plateforme développée par notre groupe sont données par [16]. La fonction de déplacement d une patte suit un cycle de marche entre les positions pea pour position extrême antérieure et pep pour position extrême postérieure, figure 3.b. Une patte est dite en rétraction lorsqu elle est posée au sol et qu elle contribue au mouvement de la plateforme. Elle est dite en protraction lorsqu elle est levée et se déplace vers pea. Elle effectue un temps d attente jusqu à la survenue de l événement prot, pour protraction. Le modèle de comportement d une patte est résumé par la figure 3.c : les événements pea et pep sont non commandables et l événement prot commandable. La contrainte de stabilité statique nécessaire au bon fonctionnement du système énonce que deux pattes voisines ne peuvent être levées simultanément. Ceci implique la succession des événements tels que,, et ; les événements et n étant que des signaux de la fin du cycle du mouvement des pattes (1 et 2), leurs occurrences ne nécessitent pas de gestion particulière. a) b) Protraction aep Rétraction pep c) pea Rétraction pep Attente prot Protraction FIG. 3. a) Robot hexapode, b) Cycle de fonctionnement d une patte, c) Modèle de fonctionnement d une patte.

3 3 IV. SUPERVISION ET MODEL-CHECKING A. Théorie de la supervision La théorie de la supervision se fonde sur les Systèmes à Evénements Discrets (SED). Elle a été introduite par P.J. Ramadge et W.M. Wonham [1] et se base sur la théorie des langages et des automates à états finis (FSM, Finite State Machine) [4]. Elle définit trois entités : le modèle du système G, le modèle d une spécification souhaitée K et le modèle du superviseur S. Cette théorie définit la possibilité de synthétiser un modèle de superviseur dit valide à partir du modèle du système et du modèle de la spécification. Illustrée par l équation 1, cette synthèse du superviseur est réalisée à partir des deux opérations essentielles sur les automates à états finis que sont : l opération de produit ( ) qui retourne un premier modèle du superviseur et l opération trim qui supprime dans le superviseur les états non accessibles et les états dans lesquels le superviseur est bloquant. Comme exprimé formellement par l équation 2, la théorie de la supervision permet alors, par le couplage du système G et du superviseur S, de garantir ( =) les propriétés K voulues. menant à l état désiré 6). De plus, elle est susceptible de faire apparaître des situations de blocage (état 3 suivant l événement c) ; le Model-Checking présenté dans la partie suivante doit permettre alors de vérifier la vivacité du système. FIG. 5. état non voulu événement non commandable 2 état de dead lock événement interdit 0 a 1 c 3 d 4 f état voulu Problèmes liés aux événements non commandables. b e 5 6 S = trim(g K) (1) G S = K avec = : satisfait et : composition. (2) Conceptuellement, un système supervisé fonctionne de la manière suivante : à chaque étape de l exécution du système G, le superviseur est notifié par le dernier événement arrivé. Le superviseur notifie alors le système de l ensemble des événements qu il est autorisé à effectuer (figure 4). e Superviseur S Système G Ti Satisfait la Spécification K FIG. 4. Schéma de principe d un système supervisé (e : événement envoyé du système au superviseur, Ti : ensemble des événements autorisés pour le système). La théorie de la supervision prévoit que certains événements ne peuvent pas être interdits. Cette situation est définie sous le terme de commandabilité. Cette notion de commandabilité est importante car elle va conditionner la réalisation du superviseur. En effet, lors de l exécution, si le superviseur a été construit sans prendre en compte l aspect de commandabilité, alors il est susceptible de vouloir interdire un événement non commandable. Ceci étant impossible, la solution, nommée algorithme de Kumar, est de prendre en compte cet aspect lors de la synthèse du superviseur en interdisant les événements commandables qui mènent aux événements non commandables interdits par la spécification [17]. La figure 5 illustre cet algorithme en interdisant l événement d, afin de ne pas réaliser e, non commandable, et ne pas aller dans l état non désiré 5. Cependant, cette solution a l inconvénient de supprimer des états menant à des comportements éventuellement nécessaires au bon fonctionnement du système (événement f FIG. 6. DestKit : méta-modèle et transformations endogènes possibles. Sur les principes précédents et ceux de l Ingénierie Dirigée par les Modèles, nous avons réalisé un framework Java (Dest- Kit) pour capturer les concepts définis dans la théorie de la supervision [18]. Celui-ci repose sur un (méta) modèle résumé sur la figure 6 permettant de décrire puis transformer des automates à états finis. En particulier, DestKit intègre toutes les transformations nécessaires à la synthèse d un superviseur à partir d un automate à états finis décrivant le système non contraint et d un autre automate à états finis décrivant les propriétés que devra satisfaire le système supervisé. Il intègre de plus des opérations classiques sur les automates telles que les différents produits (produit ou composition synchronisée), l opération de déterminisation, l opération trim permettant de rendre l automate non bloquant, etc. FIG. 7. Modèle permissif du fonctionnement concurrent de 2 pattes voisines. A titre d exemple, et à l aide de DestKit, deux pattes du robot hexapode (partie III) sont modélisées dans son comportement le plus permissif par le produit des automates

4 4 FIG. 8. Modèle pour la propriété de stabilité du robot hexapode. décrivant le comportement de chacune des pattes (figure 7). Une spécification est également modélisée afin de définir la succession du mouvement des deux pattes (figure 8). Elle est ensuite enrichie par transformation en ajoutant les événements non commandables et. Enfin, le superviseur (figure 9) est obtenu par transformation endogène (équation 1) et en prenant en compte l existence des événements non commandables. Enfin le modèle du système couplé au superviseur est considéré comme identique à celui du superviseur (figure 9). FIG. 9. Modèle du superviseur et du système supervisé. Cet exemple montre que dans le cadre de la théorie de la supervision, il est possible de réaliser un modèle du système. Egalement, cela montre que la réalisation du superviseur impose une bonne connaissance dans la manière de réaliser une spécification. Cela dit, l algorithme de Kumar permet de construire une spécification K plus restrictive que K (donc un superviseur plus restrictif). Il est important alors de vérifier que cette spécification plus restrictive satisfait encore certaines propriétés telles que la vivacité. C est pourquoi il est intéressant de pouvoir combiner l approche par supervision avec le Model-Checking. B. Model-Checking L approche par Model-Checking est une approche fondée sur trois étapes successives : la modélisation du système qui fournit un modèle M, la spécification des propriétés fournissant un modèle de spécification K et l utilisation d un algorithme de Model-Checking qui vérifie si le modèle M satisfait K (équation 3). Dans cette approche, la phase de modélisation se fonde généralement sur des systèmes de transitions étiquetés (LTS pour Labelled Transition Systems), des algèbres de processus ou les automates à états finis [2], [3], [10] et [9]. La spécification de propriétés utilise des équations de logiques temporelles (LTL pour Linear Temporal Logic) ou arborescentes (CTL pour Computation Tree Logic ) mais peut également être réalisée à l aide d algèbres de processus ou d automates à états [7]. Cette phase va permettre de définir des propriétés telles que la vivacité ou la sûreté qui sont les plus employées dans la vérification des systèmes critiques. Enfin, la dernière phase est l étape de vérification. Elle est réalisée par des outils qui mettent en évidence les comportements du modèle qui "violent" les propriétés, ces outils fournissent généralement une trace conduisant à une situation non désirée. M = K (3) Dans le contexte de ces travaux, la validation des modèles s appuie sur une description sous forme d algèbre de processus du système avec le langage FSP [10] (Finite State Processes) et l outils LTSA. Le modèle du système supervisé (figure 9) et les propriétés de vivacité pour les deux pattes sont donnés en FSP sur la figure 10 ; le modèle FSP du superviseur peut être généré automatiquement par transformation de modèles. La compilation du modèle FSP permet alors de retrouver le modèle du comportement des deux pattes (figure 9). A partir de là, l outil LTSA permet à l utilisateur de simuler l évolution du système (phase de test par exemple) ou d obtenir de façon automatique les traces conduisant à une situation indésirable. FIG. 10. HEXAPODE=A, A=(->B ->C), B=(->D ->E), C=(->D ->F), D=(->G ->H), E=(->I ->G), F=(->J ->H),... progress P1 = {} progress P2 = {} Modèle FSP du système supervisé et d une propriété de vivacité. La vérrification, à l aide de l outil LTSA, du code FSP présenté par la figure 10 fourni le résultat concernant la satisfaction de la spécification. Le modèle réalisé du système est donc vivace (les deux pattes se déplacent une infinité de fois). Cependant, si la modélisation d un système comme le robot hexapode est une tâche difficile, la modification du modèle initial, ne vérifiant pas les propriétés exigées l est encore plus. Une synthèse automatique d une partie du contrôleur en utilisant la théorie de la supervision (partie précédente) devient donc pertinente. Enfin, dans le contexte de l IDM et dans le cadre de nos travaux sur le Model-Checking, A. Rasse a proposé une approche fondée sur l IDM pour la spécification, la vérification et l implantation des systèmes logiciels critiques [14]. Dans ce travail, un méta-modèle de FSP (figure 11) est proposé de façon à pouvoir établir des transformations de modèles entre les domaines de spécification, de vérification et d implantation.

5 5 FIG. 11. Méta-modèle de FSP. V. INTÉGRATION DES DEUX APPROCHES La partie précédente montre que malgré leurs différences, l intégration des concepts issus du domaine de la supervision avec ceux issus du domaine du Model-Checking doit permettre, d une part, de concevoir plus simplement des systèmes logiciels (par synthèse de superviseur), d autre part, de les rendre plus sûrs (par validation de modèle). Deux possibilités sont alors envisageables. L une prévoit la conception d un méta-modèle constitué des concepts communs aux deux domaines. Dans ce cadre, il est évident que les deux méta-modèles possèdent une structure et une sémantique proche permettant d envisager une telle démarche. Cependant, des restrictions sur les concepts utilisables au sein de cet unique méta-modèle sont à effectuer dans ce type d approche. Dans une autre démarche, il est envisageable de définir des règles de transformation permettant le passage d un modèle défini dans un domaine vers l autre domaine et réciproquement. Ceci permet de préserver les deux méta-modèles et de bénéficier de la totalité des concepts présents dans les deux domaines. Des transformations de modèles doivent être définies entre les deux méta-modèles, celui du Model-Checking et celui de la théorie de la supervision, comme illustrée conceptuellement par la figure 2. Ces règles vont être définies en établissant des relations entre les divers éléments des méta-modèles permettant ainsi de transformer des modèles d un domaine en des modèles dans l autre domaine. En première approche, ces relations peuvent être élaborées sous la forme d un tableau de correspondance définissant comment traduire un élément d un méta-modèle dans l autre méta-modèle (Table I). Méta-modèle des Méta-modèle de FSP automates à états finis FSM Système État Processus Transitions Choix Événement Action Événement non commandable Action (+ drapeau) Événement commandable Action TAB. I RÈGLES DE TRANSFORMATIONS. Ainsi, au niveau des modèles, lorsqu un automate à états finis devra être transformé, il faut suivre les correspondances du tableau afin de transformer les états en processus, les événements en actions préfixe (-> en FSP) combinées par l opérateur de choix ( ), etc.. Il n est pas possible dans le cadre de cet article de préciser toutes les règles nécessaires pour passer d une représentation dans un domaine à une autre représentation dans l autre domaine. Cela dit, dans l état actuel, l utilisation d un outil IDM configuré avec les métamodèles et les transformations proposés permet d une part de spécifier le modèle d un système non contraint et des propriétés recherchées pour d autre part obtenir le modèle du superviseur avec DestKit [18] puis obtenir le modèle FSP pouvant être analysé, simulé et surtout validé avec l outil LTSA. L approche proposée montre donc comment l IDM permet d intégrer de façon rationnelle les éléments issus du domaine de la supervision et celui du Model-Checking. Sur l exemple du robot hexapode, cette démarche IDM permet d avoir un point de vue global intégrant la théorie de la supervision et le Model-Checking dans une seule et même démarche. Ainsi, en première phase de la réalisation du logiciel critique, l IDM nous permet de se placer dans le contexte de la supervision et de réaliser la génération du superviseur illustrée par la figure 9. La présence d événements non commandables et l utilisation de l algorithme de Kumar ne permettent cependant pas de conclure sur la satisfaction de la spécification énoncée pour la synthèse du superviseur. Il est nécessaire de compléter la démarche par une deuxième phase dans laquelle l utilisation des transformations de modèles permet de transformer le modèle du superviseur en un modèle utilisable dans le domaine du Model-Checking. Cette phase fournit ainsi le modèle illustré par la figure 10. Enfin la dernière phase est la mise en pratique du Model-Checking. VI. CONCLUSION Ce papier présente une démarche d intégration des approches de deux communautés, celle de la théorie de la supervision et celle du Model-Checking. Cette intégration est réalisée grâce à un domaine émergent du génie logiciel : l Ingénierie Dirigée par les Modèles. En présentant les deux domaines au travers d un exemple lié à la locomotion d un robot hexapode, ce papier montre la complémentarité qui existe et met en avant les bénéfices que les deux communautés peuvent avoir en adoptant le point de vue modèle et métamodèle. Ces bénéfices sont d une part la possibilité d utiliser les compétences et les outils des deux disciplines dans une même démarche d élaboration d un système logiciel critique et d autre part l amélioration de la fiabilité et des techniques de modélisation. La démarche proposée sera complétée par un approfondissement des règles de transformations entre les méta-modèles et par un élargissement à d autres langages et techniques de Model-Checking incluant des logiques temporelles ou arborescentes. RÉFÉRENCES [1] P. Ramadge and W. Wonham, The control of discrete-event systems, IEEE Transactions on Automatic Control, vol. 77, no. 1, pp , [2] E.-M. Clarke, O.Grumberg, and D.Peled, Model-Checking. New York : The MIT Press, [3] P. Schnoebelen, F. Laroussinie, M. Bidoit, B. Bérard, and A. Petit, Verification de Logiciels : Techniques et Outils du Model-Checking. Paris : Vuibert, 1999.

6 [4] C. G. Cassandras and S. Lafortune, Introduction to discrete event systems. New York : Springer, [5] K. Akesson, M. Fabian, H. Flordal, and A. Vahidi, Supremica- a tool for verification and synthesis of discrete event supervisors, in The 11th Mediterranean Conference on Control and Automation, [6] V. Chandra, B. Oruganti, and R. Kumar, Ukdes a graphical software tool for the design, analysis & control of discrete event systems, in IEEE Transactions on Control Systems Technology, Submitted, [7] N. Navet, Systèmes temps réel 1. Paris : Hermes, [8] A. Arnold, Systèmes de transitions finis et sémantiques des processus communicants. Issy les Moulineaux : Masson, [9] G. J. Holzmann, The model checker spin, IEEE Trans. on Software Engineering, vol. 23, pp , [10] J. Magee and J. Kramer, Concurrency : state models & java programs. Chichester : John Wiley & Sons, [11] J.-M. Favre, J. Estublier, and M. Blay-Fornarino, L Ingénierie Dirigée par les Modèles au-dela du MDA. Paris : Hermes, [12] S. Gerard, J.-M. Favre, P.-A. Muller, and X. Blanc, Actes des 1eres Journées sur l Ingénierie Dirigée par les Modéles, [13] L. Duchien and C. Dumoulin, Actes des 2emes Journées sur l Ingénierie Dirigée par les Modéles, [14] A. Rasse, Approche orientée modèles pour la spécification, la vérification, l implantation des systèmes logiciels critiques, Ph.D. dissertation, Université de Haute Alsace Laboratoire MIPS, [15] A. Rasse, J.-M. Perronne, P. Studer, and B. Thirion, Vers une conception intégrée et orientée objet pour les logiciels de commande validés, in JDMACS2005, [16] B. Thirion and L. Thiry, Concurrent programing for the control of hexapod walking, ACM SIGAda Ada Letters, vol. 22, pp , [17] R. D. Brandt, V. K. Garg, R. Kumar, F. Lin, S. I. Marcus, and W. M. Wonham., Formulas for calculating supremal controllable and normal sublanguages, Systems and Control Letters, vol. 15, no. 8, pp , [18] T. Collonville, Approche orientée modèles et commande par supervision appliquée à la synthèse de systèmes logiciels critiques, Master s thesis, Université de Haute Alsace, Laboratoire MIPS,