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).
Adaptation sémantique du temps
L’adaptation sémantique du temps revient à spécifier des relations entre les différentes échelles de temps définies dans un modèle hétérogène, permettant à chaque pas de simulation du modèle global d’associer une date courante à chacun de ces sous-modèle temporisés selon leurs échelles de temps respectives. Quand un évènement DE est généré pour refléter un changement d’un signal SDF par exemple, une adaptation sémantique possible du temps est d’associer à cet évènement le temps courant du modèle DE lors du changement de valeur du signal SDF. Pour spécifier l’adaptation sémantique du temps entre un modèle DE et un modèle TFSM, nous pouvons supposer que TFSM réagit instantanément à la présence de symboles sur son interface, et qu’il utilise aussi le temps courant dans DE comme date pour les évènements qu’il produit. Toutefois, le temps peut aussi activer des transitions temporisées dans un modèle TFSM. Cependant, la durée d’une transition temporisé est exprimée sur une échelle de temps locale dans le modèle TFSM. En supposant qu’une telle transition puisse générer un évènement destiné au modèle DE, sa durée d’activation doit avoir une correspondance dans le temps DE. Si, pour des raisons de simplicité, nous considérons que le temps s’écoule à la même vitesse dans les deux modèles DE et TFSM, une adaptation possible du temps entre ces deux modèles consiste à remettre à zero un minuteur à chaque fois que le modèle TFSM rentre dans un nouvel état, et ainsi mesurer le temps écoulé dans DE depuis que l’automate est rentré dans cet état. Cette adaptation reste toutefois restrictive à un cas particulier.
Ptolemy II
Ptolemy II, introduit précédemment dans la partie 2.2.1, permet la conception et la simulation de modèles hétérogènes à base de MoCs. Ces modèles sont structurés hiérarchiquement grâce à des acteurs composites. Chaque acteur composite appartient à un modèle régi par un MoC donné et peut contenir un modèle interne régi par un MoC différent. Ptolemy II possède aussi un environnement graphique qui facilite la tâche des concepteurs lors de la modélisation et la simulation d’un système hétérogène. Il supporte un large choix de MoCs permettant de définir des modèles aussi variés que des modèles à temps continu, différentes sémantiques de modélisation à évènements discrets, différentes sémantiques de modélisation à flots de données, des machines à états finis et différentes sémantiques de modélisation de réseaux de processus. Cependant, l’adaptation sémantique permettant la combinaison des MoCs dans un modèle hétérogène est fixée et codée dans le noyau de la plateforme. Cela peut être considéré comme une restriction qui force le concepteur d’un modèle hétérogène à se baser sur cette adaptation sémantique par défaut pour obtenir le comportement attendu de son modèle lors de sa simulation. Algorithme de simulation de ModHel’X La simulation d’un modèle dans ModHel’X se déroule pas à pas : chaque pas de simulationcorrespond à 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.
|
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
