Soutenance mémoire
MoC « Discrete Events » (DE)
Le MoC à évènements discrets (MoC DE) [Brooks 2008b] permet de modéliser des systèmes ayant un comportement orienté par le temps, pouvant être modélisé par des évènements discrets. Ces systèmes peuvent être logistiques comme les systèmes de gestions de services ou des réseaux de transport, ou encore techniques comme les systèmes de réseaux et de télécommunications ou encore des systèmes dédiés aux chaines de production. En modélisant un système à évènements discrets, nous ne nous intéressons qu’à certains instants particuliers au cours du temps durant lesquels des évènements se produisent (ex : début d’une action, arrivée d’une ressource, etc). Le mot discret ne fait référence ni au temps considéré par le système ni à son comportement au cours du temps ; dans un système DE, un évènement peut se produire à n’importe quel instant. Par abus de langage, nous appelons « modèle DE » un modèle régi par le MoC DE. Nous faisons de même pour chaque modèle régi par un paradigme de modélisation donné. Dans un modèle DE, les composants communiquent entre eux en postant des évènements DE. Quand un composant DE est exécuté, il réalise son comportement et fournit le résultat sur son interface. Si ce résultat est destiné à un autre composant, il est structuré dans un évènement DE composé de deux éléments : une donnée représentant le résultat du comportement du composant et une étiquette modélisant la date d’arrivée de cet évènement à l’interface du composant destinataire. Quand un composant reçoit un évènement DE sur son interface, il prend en considération la donnée de l’évènement DE et réalise son comportement. La sémantique des données dans un modèle DE est donc modélisée par des évènements DE. L’étiquette d’un évènement DE fait référence à un instant (une date) dans une échelle de temps locale à un modèle DE. Ces instants peuvent survenir à n’importe quel moment au cours de la simulation. La sémantique de temps dans un modèle DE est donc spécifiée par un ensemble d’instants discrets au cours d’un temps continu. L’étiquette d’un évènement DE est formée par une date et un micro-pas. Un évènement DE n’est posé sur l’interface de son destinataire que lorsque sa date coïncide avec la date courante du modèle au cours de la simulation. Si deux évènements on la même date, le micro-pas permet de les ordonner (temps super-dense [Lee 2005]). Une observation d’un modèle DE consiste à activer les composants concernés pour traiter tous les évènements qui possèdent la plus petite date. La sémantique de contrôle dans DE est donc spécifiée par un traitement chronologique des évènements, où l’objectif est de déterminer quels composants doivent être observés durant chaque observation d’un modèle, en se référant pour cela à la date des évènements qui leur sont destinés ou qu’ils doivent produire. Prenons l’exemple d’un système de machine à café en le limitant aux évènements suivants : (1) l’utilisateur insère l’argent dans le distributeur, (2) l’écran du distributeur affiche qu’il est prêt, (3) l’utilisateur appuis sur le bouton de sélection pour choisir son café, (4) l’écran du distributeur affiche que le café est en cours de préparation, (5) l’écran du distributeur affiche que le café est prêt. Si nous ne considérons que ces évènements à modéliser, le système de machine à café peut être représenté par un modèle DE (figure 2.6) structuré par deux composants : un premier composant User connecté à un deuxième composant CoffeeMachine.
MoC « Finite State Machine » (FSM) et « Timed Finite State Machine » (TFSM)
Le MoC de type machine à états finis (MoC FSM) [Brooks 2008b] permet de modéliser des systèmes à logique de contrôle séquentiels et plus précisément des automates à états finis. Ces systèmes sont modélisés par un ensemble fini d’états possibles où le passage d’un état à un autre est conditionné et peut générer des actions. De plus, chaque automate possède un état initial spécifiant l’état dans lequel il se trouve au début d’une simulation. Les transitions permettent de modéliser un passage conditionné d’un état à un autre dans un modèle FSM. Ce passage est supposé instantané : aucune sémantique de temps n’est alors définie. Nous reprenons l’exemple du système de machine à café introduit dans 2.3.1 où nous cherchons à présent à modéliser l’automate du distributeur (figure 2.7). Dans cet exemple, le distributeur peut se trouver dans trois états possibles : un état initial représentant l’état en veille du distributeur. Quand l’utilisateur insère l’argent pour payer le café, le distributeur réagit suite à cet évènement et passe à l’état prêt. Quand l’utilisateur appuie sur le bouton de sélection pour choisir son café, le distributeur se trouve à l’état prêt et peut donc servir le café à l’utilisateur, il réagit en passant à l’état servi. L’utilisateur prend alors son café et le distributeur retourne à l’état initial. Dans notre exemple, l’automate possède trois transitions différentes : (T1) l’automate passe de l’état initial à l’état prêt si l’évènement evtArgent est présent sur son interface d’entrée modélisant l’insertion de l’argent par l’utilisateur ; (T2) l’automate passe de l’état prêt à l’état servi si l’évènement evtCafé est présent sur son interface d’entrée modélisant l’appuie de l’utilisateur sur le bouton de sélection du café ; (T3) l’automate passe de l’état servi à l’état initial si l’évènement evtRécupéré est présent sur son interface d’entrée modélisant la récupération du café par l’utilisateur. Le comportement d’un modèle FSM est réactif, il dépend des entrées du modèle et de son état actuel. Les entrées sont des évènements FSM représentées par des symboles, la seule information qu’ils représentent sont leur présence ou leur absence sur l’interface d’entrée du modèle en question. Ces données sont susceptibles de faire réagir le système selon l’état actuel où il se trouve. En effet, l’automate du distributeur de café ne réagit et ne passe à l’état servi, par exemple, que s’il se trouve à l’état prêt et que evtCafé est présent sur son interface d’entrée. Les conditions de passage d’un état à un autre dans FSM sont modélisées par des gardes définies dans la transition entre les deux états. Ces gardes sont des conditions booléennes portant sur les entrées du modèle. De plus, l’activation d’une garde peut générer une action. Cette action est dans ce cas définie dans la même transition, elle est traduite par la génération d’un symbole,ou action FSM, sur l’interface de sortie adéquate du modèle. Un MoC TFSM est une extension du MoC FSM pour y introduire une notion de temps. Reprenons l’exemple du distributeur de café en considérant à présent le temps de préparation du café. Nous rajoutons donc un nouvel état prep au distributeur modélisant l’instant où ce dernier est en train de préparer le café (figure 2.8). Quand le distributeur se trouve à l’état prêt et qu’il reçoit l’évènement evtCafé, il passe à présent à l’état prep et y reste jusqu’à la fin de préparation du café. Cette durée de préparation est définie dans TFSM par une transition temporisée de l’état prep à l’état servi (transition rouge sur la figure).
Le langage de spécification de contraintes d’horloges CCSL
CCSL (Clock Constraint Specification Language) [Mallet 2008] est un langage déclaratif annexé aux spécifications du profil UML MARTE. Il se base sur les horloges définies dans MARTE qui peuvent être chronométriques ou logiques. Il offre des moyens pour spécifier des contraintes entre ces horloges qui peuvent être classifiées en quatre catégories : synchrones, asynchrones, mixtes et non fonctionnelles. Pour des raisons de clarté, nous utilisons une syntaxe simplifiée de CCSL tout au long de ce chapitre. (1) Les contraintes d’horloges synchrones se basent sur le concept de coïncidence, tel que Discretize, SubClock, Coincides ou FilteredBy :
• Discretize se base sur l’horloge IdealClock qui modélise un temps dense pour définir une horloge chronométrique. L’horloge obtenue par cette contrainte est une discrétisation de IdealClock suivant une période de discrétisation ; Discretize(IdealClock, 0.001) par exemple définit une horloge chronométrique avec une période de 0.001 secondes = 1 ms.
• SubClock(A, B) signifie que les instants de A sont un sous-ensemble des instants de B. Ainsi, tous les instants de A coïncident forcément avec des instants de B, mais il peut y avoir des instants sur B qui n’ont pas de correspondance sur A.
• Coincides(A, B) signifie que tous les instants de A coïncident respectivement avec des instants de B et vice versa.
• FilteredBy(A, w) permet de créer une horloge à partir des instants de A selon un motif binaire w formé d’une partie fixe wf ix et d’une partie répétitive wrep (w = wf ix(wrep) ω =wf ixwrep . . . wrep . . .). Chaque instant de A qui correspond (selon l’ordre de son apparition) à un bit 1 du motif w implique un instant de B. La contrainte FilteredBy(A, 01(100)) par exemple signifie que seul le deuxième instant de A implique un instant sur l’horloge déterminée (wf ix = 01), par la suite, seul le premier instant qui précède deux instants consécutifs de A implique un instant sur l’horloge déterminée (wrep = 100)(voir figure 3.5).
Modélisation hétérogène hiérarchique
La principale complexité lors de la modélisation d’un système hétérogène est l’adaptation sémantique entre les sous-systèmes qui le forment. Modéliser hiérarchiquement un système hétérogène permet de contrôler et de maîtriser cette complexité. Nous nous focalisons ici au cas de la modélisation hétérogène par composants basée sur les MoCs (2.2.1). Le principe de cette approche est de structurer le modèle d’un système hétérogène sous forme d’un arbre hiérarchique de sous-modèles comme représenté sur la figure 4.1 : le modèle global est formé par un modèle racine M1 qui englobe le reste des sous-modèles. Chaque modèle régi par un MoC donné est représenté par un cercle avec un motif différent. L’avantage d’une telle approche est qu’elle permet de réduire le nombre d’interfaces permettant la communication entre deux sous-modèles, contrairement à une modélisation horizontale où tous les sous-modèles sont mis à plat sur un même niveau. Sur la figure 4.1, chaque interface liant deux sous-modèles régis respectivement par deux MoCs différents est représentée par un trait distinct. Ainsi, l’adaptation sémantique dans un modèle hétérogène conçu selon cette approche est définie par paires de modèles au niveau de chaque interface ; nous développons le principe de cette adaptation dans la partie 4.4 de ce chapitre. Toutefois, cette approche impose que si un sous-modèle doit être observé à un instant donné au cours de la simulation pour réaliser son comportement, tous les modèles qui l’englobent hiérarchiquement doivent aussi être observés. L’observation d’un modèle peut ainsi impliquer l’observation d’autres modèles même s’ils n’ont aucun comportement à exécuter. Observer le sous-modèle M4 (voir figure 4.1), par exemple, implique l’observation de M3, qui implique celle de M1.
Simulink/Stateflow
Simulink [The MathWorks c] et Stateflow [The MathWorks d] sont deux plateformes interactives intégrées dans l’environnement MATLAB [The MathWorks b] et commercialisées par MathWorks. Simulink est un environnement de simulation permettant d’analyser des modèles hétérogènes impliquant à la fois un temps discret et un temps continu. Il offre un éditeur graphique permettant de modéliser des systèmes pouvant être linéaires, non linéaires, à temps discret ou continu, à variables multiples, etc. Un modèle dans Simulink est structuré par l’interconnexion de composants à travers leurs ports, chaque composant définit une opération donnée, tous sont regroupés dans une bibliothèque propre à Simulink et organisés selon leurs natures. Nous citons par exemple des composants impliquant un temps continu (dérivateur, intégrateur, fonction de transfert, etc), des composants impliquant un temps discret (intégrateur à temps discret, retardateur permettant de rajouter un délais sur un signal d’entrée grâce une période fixe ou variable, etc), ou encore des opérations mathématiques (gain, addition, division, soustraction, etc). Simulink permet une modélisation hiérarchique grâce à des composants appelés « soussystèmes » (subsystems). Un sous-système peut être défini par l’interconnexion de composants ou d’autres sous-systèmes et peut être utilisé comme étant un composant d’un modèle global.
Algorithme de simulation de ModHel’X
La simulation d’un modèle dans ModHel’X se déroule pas à pas : chaque pas de simulation correspond à un instant d’observation appelé snapshot, durant lequel le contrôle est donné aux composants sources à observer. Une observation d’un composant correspond à une mise à jour de l’état de ses interfaces : il traite les données reçues sur ses entrées et produit des données sur ses sorties selon la sémantique de son comportement. Les données produites sont propagées selon la sémantique et la structure du modèle en question, ce qui peut déclencher l’observation d’autres composants. Un snapshot est terminé quand il ne reste plus de composant pouvant être observé à cet instant. Pour simuler un modèle hétérogène dans ModHel’X, nous associons le modèle racine de ce dernier au moteur d’exécution de la plateforme. Les appels des différentes fonctions du modèle racine sont propagés tout au long du modèle global selon sa hiérarchie grâce au polymorphisme.
Description de la sémantique de TFSM avec CCSL
Dans CCSL, toutes les horloges doivent être des sous-horloges d’une horloge racine. Pour décrire un modèle TFSM, nous choisissons de définir explicitement une horloge chronométrique appelé chronoTFSM. Cette horloge sert à plusieurs fins : elle mesure les durées des transitions temporisées, les événements d’entrée du modèle TFSM (modélisés par des sous-horloges de chronoTFSM) se produisent à des instants de cette horloge, l’automate réagit donc à des instants de cette horloge. Pour simuler le comportement d’une machine à états finis, nous devons mémoriser son état courant. Pour chaque état S, nous utilisons une horloge enterS qui tique quand une transition permettant d’entrer dans S devient possible, ainsi qu’une horloge inS qui tique à chaque instant de chronoTFSM tant que l’automate est à l’état S. enterS représente ainsi la condition pour entrer dans l’état S tandis que inS permet de mémoriser l’état courant. Pour définir la famille des horloges enterS, nous devons d’abord décrire quand une transition est activée. Une transition non temporisée T sortante d’un état S à la réception d’un évènement E est activée quand sa garde est vraie (E se produit) et que l’état courant est S. Par conséquent, l’horloge modélisant les instants d’activations de T peut être définie comme étant l’intersection de E et de inS : T = Intersection(E, inS)
|
Table des matières
1 Introduction
1.1 Contexte
1.2 Objectif
1.3 Organisation de la thèse
I Modélisation et simulation des systèmes hétérogènes
2 Modélisation par composants et Modèles de Calculs (MoCs)
2.1 Introduction
2.2 Modélisation par composants
2.2.1 Approche à base de modèles de calculs
2.2.2 Approche à base de connecteurs
2.2.3 Approche à base d’opérateurs de composition
2.3 Modèles de Calculs (MoCs)
2.3.1 MoC « Discrete Events » (DE)
2.3.2 MoC « Finite State Machine » (FSM) et « Timed Finite State Machine » (TFSM)
2.3.3 MoC « Synchronous DataFlow » (SDF)
2.3.4 MoC « Continuous-Time » (CT)
2.4 Conclusion
3 Modélisation du temps
3.1 Introduction
3.2 Notion d’instants
3.3 Domaine de temps
3.4 Natures de temps
3.4.1 Temps continu
3.4.2 Temps discret
3.5 Contraintes temporelles
3.5.1 Le langage de spécification de contraintes d’horloges CCSL
3.5.2 Modélisation du MoC SDF avec CCSL
3.6 Conclusion
4 Modélisation hétérogène
4.1 Introduction
4.2 Modélisation hétérogène hiérarchique
4.3 Hétérogénéité des modèles
4.3.1 Hétérogénéité des données
4.3.2 Hétérogénéité du temps
4.3.3 Hétérogénéité du contrôle
4.4 Adaptation sémantique
4.4.1 Adaptation sémantique des données
4.4.2 Adaptation sémantique du temps
4.4.3 Adaptation sémantique du contrôle
4.5 Outils de modélisation et de simulation des systèmes hétérogènes
4.5.1 Simulink/Stateflow
4.5.2 MODELICA
4.5.3 Ptolemy II
4.5.4 ModHel’X
4.6 Conclusion
II Contribution
5 Première approche avec CCSL
5.1 Introduction
5.2 Modélisation des MoCs
5.2.1 Description de la sémantique de TFSM avec CCSL
5.2.2 Description de la sémantique de DE avec CCSL
5.2.3 Description de la sémantique de SDF avec CCSL
5.3 Adaptation sémantique des MoCs avec CCSL
5.3.1 Adaptation sémantique entre DE et TFSM
5.3.2 Adaptation sémantique entre DE et SDF
5.4 Limites de l’approche
5.5 Conclusion
6 Tagged Events Specification Language (TESL)
6.1 Introduction
6.2 TESL (Tagged Events Specification Language)
6.2.1 Horloges et Tics
6.2.2 Relations sur les instants d’horloges
6.2.3 Relations sur les étiquettes des instants
6.2.4 Résolution des spécifications TESL
6.3 Conclusion
7 Intégration de TESL dans ModHel’X
7.1 Introduction
7.2 Intégration de TESL dans ModHel’X
7.2.1 Adaptation sémantique du contrôle
7.2.2 Adaptation sémantique du temps
7.3 Algorithme de simulation de ModHel’X
7.3.1 Préparer le modèle global pour sa simulation
7.3.2 Déterminer les DrivingClocks susceptibles de déclencher un pas de simulation
7.3.3 Déterminer les occurrences des évènements associés au modèle global durant un pas de simulation
7.3.4 Réaliser le snapshot
7.4 Conclusion
III Mise en œuvre
8 Implémentation
8.1 Introduction
8.2 Implémentation des MoCs
8.2.1 MoC DE
8.2.2 MoC TFSM
8.2.3 MoC SDF
8.3 Implémentation des InterfaceBlocks
8.3.1 InterfaceBlock DE-TFSM
8.3.2 InterfaceBlock DE-SDF
8.4 Conclusion
9 Cas d’étude : Système de lève-vitre automatique
9.1 Introduction
9.2 Modélisation de l’exemple
9.3 Conception de l’exemple dans ModHel’X
9.3.1 Le modèle racine DE
9.3.2 Le sous-modèle TFSM
9.3.3 Le sous-modèle SDF
9.4 Simulation de l’exemple dans ModHel’X
9.4.1 Préparation du modèle global pour sa simulation
9.4.2 Détermination des DrivingsClocks
9.4.3 Premier pas de simulation
9.4.4 Suite de la simulation
9.5 Conclusion
10 Conclusion
10.1 Discussion
10.2 Perspectives
Table des figures
Bibliographie
Télécharger le rapport complet
