7.1.1 Objectifs de la simulation de modèle
La simulation permet d’améliorer la compréhension d’un système sans devoir le manipuler réellement, soit parce qu’il n’est pas encore défini ou disponible, soit parce qu’il ne peut pas être manipulé directement en raison des coûts, du temps, des ressources ou du risque. La simulation est donc réalisée sur un modèle du système.
La simulation est généralement définie selon trois étapes (cf. figure 7.1). La première consiste à générer une représentation de la charge de travail, c.-à-d. l’en-semble des entrées à appliquer sur le système étudié. Cette représentation peut être une trace2 (ou un scénario2) décrivant une charge de travail réelle, ou plus syn-thétique et générée par une heuristique ou une fonction stochastique. La deuxième étape consiste à simuler le modèle à partir de la charge de travail définie en entrée pour produire les résultats. Enfin, la troisième étape consiste à analyser les résultats de la simulation pour acquérir une meilleure compréhension du système considéré.
FIGURE7.1: Les trois étapes de la simulation
Ces trois étapes peuvent être réalisées par un ou plusieurs outils, comme un constructeur de scénario (scenario builder) pour engendrer la charge de travail, un moteur de simulation (simulation engine) et un outil d’analyse des résultats.
Il est également possible de combiner dans un même outil deux ou trois de ces étapes. Par exemple, il est possible de créer interactivement une trace au cours de l’exécution d’un modèle. Il est aussi possible de coupler le moteur d’exécution
2. tel que défini dans la partie5.4
7.1. DESCRIPTION DES BESOINS ET DES APPROCHES 117
Visualize Drive / Replay
one scenario
Result Analysis
<<include>>
Scenario Builder Build one
scenario Save one
scenario
<<extend>>
<<extend>>
Simulator Simule one event
<<extend>>
Designer
Analysis
FIGURE7.2: Exigences pour la simulation de modèle dansTOPCASED
avec l’outil d’analyse des résultats afin d’offrir une représentation « à la volée » (c.-à-d. au cours d’une simulation) de l’évolution du modèle.
7.1.2 Exigences pour la simulation dans l’atelierTOPCASED
Les principales fonctionnalités exprimées dans le cadre de TOPCASED sont synthétisées sur la figure7.2. La simulation vise à valider les modèles construits à partir des DSML de haut niveau d’abstraction définis dans l’atelier. Il s’agit prin-cipalement de fournir les moyens au concepteur d’animer son modèle afin d’en avoir une meilleure compréhension et de le valider vis-à-vis des exigences de l’uti-lisateur. Il souhaite pour cela pouvoir visualiser l’évolution du modèle dans le même formalisme que celui utilisé pour le construire (Result Analysis). Cette ani-mation peut être guidée par un scénario pré-défini ou réalisée de manière interac-tive à l’aide d’un constructeur de scénario (Scenario Builder) permettant d’injecter des événements, dit exogènes. Le concepteur doit pouvoir contrôler l’exécution, à l’aide d’un panneau de contrôle permettant de la lancer, la stopper, revenir en arrière ou avancer.
Actuellement, les DSML envisagés dans TOPCASED se concentrent principa-lement sur des modèles asynchrones ou synchrones à événements discrets. Un mo-dèle de calcul à événements discrets peut donc être utilisé. Nous le présentons dans la partie suivante.
7.1.3 Simulation à événements discrets
Dans la simulation de systèmes discrets, le temps simulé est un temps virtuel discret. Deux mécanismes peuvent être considérés pour l’évolution du temps dis-cret :
– une approche basée sur une horloge périodique (évolution du temps par in-crément fixe) : le temps avance dans le modèle selon des intervalles égaux de temps réel,
– une approche basée sur les événements : le modèle est pris en compte et mis à jour uniquement à l’arrivée d’un nouvel événement (ou quand le système change d’état) ; le temps avance d’un événement à l’autre.
Les formalismes de modélisation traditionnels s’appuient sur des bases ma-thématiques et ont largement précédé l’arrivée des ordinateurs. Deux types de dé-marche ont été proposées pour modéliser les systèmes discrets [ZKP00] :
– La spécification de système à temps discret (en anglais,Discrete Time Sys-tem Specification– DTSS) a été proposée pour modéliser les systèmes dont l’évolution du temps est basée sur une horloge périodique, comme les auto-mates.
– La spécification de systèmes à événements discrets (en anglais, Discrete Event System Specification– DEVS ou DE) est apparue plus récemment et a été définie pour la simulation sur ordinateur. Il s’agit d’une approche basée sur les événements, plus facile à gérer par un programme exécutable qu’un modèle mathématique "pur".
Ainsi, nous avons deux principaux paradigmes pour modéliser la dynamique des systèmes discrets : les formalismes discrets périodiques (DTSS, également appelé "synchrone"), et discrets basés sur les événements (ou DEVS DE, aussi nommé "asynchrone"). Ces formalismes permettent de concevoir des systèmes mo-dulaires et hiérarchiques. Une telle construction consiste à coupler des modèle exis-tants afin de construire une modélisation plus large du système. Ces formalismes permettent de traiter un ensemble de modèles comme un modèle de base dans un ensemble de plus haut niveau d’abstraction.
7.1.4 Ateliers de simulation existants
Plusieurs outils supportent la simulation à événements discrets. Toutefois, il est assez difficile d’interfacer ces outils avec l’environnementTOPCASED, c’est-à-dire utiliser directement l’un de ces outils pour simuler et animer un modèle défini à l’aide d’un éditeur de l’atelierTOPCASED. En effet, il faudrait pour cela définir une traduction bidirectionnelle entre le DSML initial et le langage de l’outil de simulation. Nous avons mentionné la difficulté de définir une telle traduction dans le chapitre précédent. Néanmoins, il est intéressant d’analyser les principales caractéristiques de ces outils et d’en souligner les plus utiles pour les utilisateurs deTOPCASED.
Matlab/Simulink [Mat07a] et Scilab/Scicos [CCN06] sont principalement dé-diés à la simulation de systèmes physiques avec des modèles de temps continu.
Ils offrent toutefois certaines possibilités pour supporter un modèle à événements discrets, comme le moduleStateflowdans l’atelier Matlab/ Simulink.
Dans le cadre de TOPCASED, nous avons profité de l’expérience du projet RNTL COTRE [BRV+03,FBB+03] et des études sur l’animation de modèleétats/
transitionsà travers les fonctionnalités de Hyper-formix Workbench [Wor07], Sil-dex [Sil07], StateMate [Sta07] et Uppaal [BDL04]. Ces outils, basés sur des auto-mates simples ou temporels, offrent une représentation graphique mettant en avant
7.2. ARCHITECTURE GÉNÉRIQUE D’UN SIMULATEUR 119