Approche à base de modèles de calculs
Dans l’approche à base de modèles de calculs, la sémantique de chaque paradigme de modélisation est définie par un Modèle de Calcul (MoC). Les MoCs viennent principalement de Ptolemy II [Eker 2003, Brooks 2008a], une plateforme de conception et de simulation de modèles hétérogènes réalisée à l’université de Berkeley. Dans Ptolemy II, l’idée centrale est que chaque MoC définit la loi de combinaison des comportements des composants d’un modèle, selon un paradigme de modélisation approprié. Un modèle conçu selon cette approche est composé de deux principales parties :une structure qui regroupe les différents composants modélisant le comportement du modèle, et une instanciation d’un MoC (Director dans PtolemyII) qui définit la sémantique de ses composants, à savoir la nature des données échangées entre eux, la notion de temps qu’ils partagent, ou encore leur sémantique de comportement (séquentiel, concurrent, synchrone, etc).L’élément de base pour la conception d’un système hétérogène dans PtolemyII est appelé Actor (acteur). Un acteur est un composant ayant un comportement bien précis, il communique en consommant et en produisant des données à travers ses interfaces appelées Ports. Les acteurs d’un modèle sont structurés grâce à des relations connectées sur leurs interfaces. Une relation peut connecter plusieurs acteurs à la fois, mais ne possède aucune sémantique, elle permet simplement de modéliser un lien statique entre les interfaces des acteurs pour combiner leurs comportements.
Quand un acteur A réalise son comportement, il est susceptible de produire des données destinées aux acteurs qui lui sont connecté. Quand les acteurs destinataires reçoivent ces données et réalisent leurs comportements à leur tours, nous parlons ici d’un transfert de contrôle de l’acteur A vers les acteurs destinataires. Deux points importants doivent être définis :l’ordonnancement d’exécution des acteurs et la technique de communication entre eux. Dans la modélisation à base de composants, les composants d’un modèle sont indépendants, leur comportement est donc tout aussi indépendant. Il est dans ce cas essentiel de définir l’ordre d’exécution de ces composants selon le paradigme de modélisation auxquels ils appartiennent, il peut être séquentiel, parallèle, concurrent, synchrone, asynchrone, etc. Chaque MoC (Director dans PtolemyII) définit une sémantique de contrôle qui permet de déterminer l’ordre d’exécution des composants de son modèle.
Approche à base de connecteurs
Contrairement à l’approche basée sur les MoCs, dans un modèle orienté composants et conçu selon une approche à base de connecteurs, la sémantique associée à la structure d’un modèle est définie au niveau des interfaces de ses composants. Nous développons cette approche en se basant sur la plateforme de composition de modèles BIP (Behavior, Interaction, Priority) [Basu 2011]. Dans PtolemyII, le principe de modélisation est de spécifier une structure de composants définissant le comportement d’un système donné, et lui associer une sémantique grâce à un MoC (un paradigme de modélisation). Dans BIP, associer une sémantique à la structure d’un modèle consiste à définir des interactions entre ses composants et des priorités sur ces interactions. Un modèle dans BIP est un composant (Component) formé par des composants atomiques (Atomic Components) liés par des interactions (Interactions). La conception d’un modèle est réalisée en superposant trois niveaux de modélisation : le comportement de ses composants atomiques, les interactions entre les composants atomiques, et les priorités de ces interactions.
Un composant atomique est l’élément de base pour modéliser un comportement dans BIP. Son comportement est défini par un automate constitué d’états de contrôle et de transitions. Les transitions représentent un passage conditionné d’un état de contrôle à un autre. Les interactions permettent de spécifier un lien entre les composants atomiques. Pour cela, chaque composant atomique possède des connecteurs dans lesquels sont spécifiées ses différentes interactions possibles avec les autres composants atomiques du modèle.
Spécifier la sémantique de contrôle d’un ensemble de composants atomiques revient à synchroniser leurs comportements. Cette synchronisation est réalisée en spécifiant des interactions entre ces composants et des priorités sur ces interactions pour déterminer l’ordre de leurs exécutions. Les priorités permettent aussi de filtrer les interactions possibles pour optimiser les performances du système.
BIP est une plateforme qui permet de modéliser des systèmes synchrones (SDF, Rendez-vous, etc) [Bozga 2009] ou des automates finis (FSM, TFSM, PetriNet). Ces deux paradigmes reposent sur une même notion de donnée qui se résume aux jetons. La sémantique des données est donc implicite et se résume à la présence ou absence d’un jeton sur les interfaces d’un composant. De plus, BIP ne considère qu’une seule notion de temps : le temps discret. Cette notion est introduite grâce aux composants atomiques temporisés (Timed Atomic Components), des composants atomiques ayant un connecteur spécifique appelé Tick et une transition dans leurs comportements modélisant un pas de discrétisation [Basu 2006b]. Spécifier la sémantique de temps dans BIP revient à synchroniser les composants atomiques temporisés sur un même pas de discrétisation. Cela se résume par la présence d’une interaction avec un haut niveau de priorité spécifiant une forte synchronisation entre les différents ticks de ces composants. L’hétérogénéité dans BIP ne concerne donc que le contrôle entre deux paradigmes de modélisation, une seule notion de données et de temps sont considérés.
Des exemples de l’utilisation de BIP sur différents systèmes sont présents dans [Basu 2006a]. Le système complet est formé par trois composants atomiques (producteur, consommateur et fifo) et deux connecteurs C1 et C2 représentés par des cercles pleins. Ces deux connecteurs définissent une forte synchronisation du producteur et du consommateur avec fifo.
Notion d’instants
Le temps est une notion abstraite utilisée dans différents domaines. Le dictionnaire en donne des définitions variées, générales ou spécifiques à des domaines particuliers : « Notion fondamentale conçue comme un milieu infini dans lequel se succèdent les événements », « Durée considérée comme une quantité mesurable », « Chacune des phases successives d’une opération, d’une action », (Linguistique) «Catégorie grammaticale de la localisation dans le temps, qui s’exprime, en particulier, par la modification des formes verbales», (Mécanique) « Chacune des phases d’un cycle d’un moteur à combustion interne », (Physique) « Paramètre permettant de repérer les événements dans leur succession », etc ([Larousse ] consulté le 31-05-2013). Nous considérons le temps comme un ensemble d’instants auxquels nous pouvons nous référer ; l’intérêt ici n’est pas de proposer une définition commune du temps, mais plutôt d’avoir une structure concrète permettant de modéliser les différentes sémantiques de temps dans un modèle hétérogène. Pour cela, la première chose à définir est la notion d’instants. TSM est un modèle mathématique dénotationnel permettant la description, l’abstraction et la différentiation des MoCs. Il propose une modélisation du temps grâce à la notion d’évènements et d’étiquettes (tags) sur ces évènements. Intéressons-nous pour le moment aux évènements de TSM.
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. 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).
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 : l’utilisateur insère l’argent dans le distributeur, l’écran du distributeur affiche qu’il est prêt, l’utilisateur appuis sur le bouton de sélection pour choisir son café, l’écran du distributeur affiche que le café est en cours de préparation, 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 tructuré par deux composants : un premier composant User connecté à un deuxième composant CoffeeMachine.
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
