Techniques de simulation distribuée « non dédiées »

Télécharger le fichier pdf d’un mémoire de fin d’études

Formalisme DEVS

B.P. Zeigler définit, dans [ZEIGLER 76], une spécification formelle des modèles à évé-nements discrets : DEVS2. Ce formalisme a été introduit comme un formalisme abstrait uni-versel indépendant de l’implémentation. Il peut, par sa capacité d’abstraction, exprimer les systèmes définis dans des formalismes traditionnels comme les équations différentielles (temps continu) et aux différences (temps discret). Le concept de modèles atomiques et cou-plés, introduit par [ZEIGLER 84], fournit un moyen de construire des modèles composés, en réutilisant des descriptions stockées en librairie.

Modèle atomique

Le modèle atomique est un élément non décomposable. Le comportement de cet élémént est régi par un modèle à événements discrets.
Essentiellement, un modèle atomique possède une base de temps, des entrées, des états, des sorties et des fonctions pour déterminer les états suivants et les sorties à partir des états actuels et des entrées. Les événements d’entrées et sorties admissibles sont les seuils de trajectoires continues par morceaux. Les signaux d’entrée sont abstraits avec une trajectoire constante par morceau dont les seuils sont considérés comme des événements discrets.
Formellement, un modèle atomique M est spécifié par un septuplet : M = < X, S, Y, δint , δext , λ, D>.
X : ensemble des types des événements externes,
S : ensemble des états séquentiels,
Y : ensemble des types d’événements de sortie
δint : S → S fonction de transition interne définissant les changements d’état dus à des événements internes,
δext : ST × X → S fonction de transition externe définissant les changements d’état dus à des événements externes,
L’ensemble ST des états totaux du système est :
ST = {(s, e) s ∈ S, 0 < e < D (s)} où e représente le temps écoulé dans l’état s,
λ : S → Y fonction de sortie,
D : S → ℝ+ ∪ ∞ fonction durée de vie des états (ou ta3).

Simulateur de Modèles couplés DEVS

Parallèlement à l’élaboration des différents modèles DEVS présentés précédemment, B.P. Zeigler a développé le concept de simulateur abstrait [ZEIGLER 00]. L’architecture de simu-lation est dérivée de la structure hiérarchique des modèles couplés DEVS. Un simulateur abs-trait représente une description algorithmique permettant de mettre en oeuvre les fonctions du modèle, afin de générer son comportement. Un tel simulateur est obtenu en faisant correspon-dre à chaque élément du modèle un composant du simulateur. La construction d’un simulateur indépendant du modèle permet une séparation, au niveau réalisation, des parties modélisation et simulation.
Pour effectuer une simulation, une hiérarchie de processeurs, équivalente à la hiérarchie des modèles, est construite. A chaque composant du modèle (Figure 5 a) est associé un pro-cesseur de la structure hiérarchique du simulateur (Figure 5 b). Chaque processeur participe à la simulation en exécutant les fonctions qui expriment la dynamique du modèle. Les proces-seurs sont :
− le Simulateur qui assure la simulation des modèles atomiques en utilisant les fonc-tions définies par DEVS,
− le Coordinateur qui assure le routage des messages entre les modèles couplés en fonction des définitions de couplage,
− le Coordinateur Racine qui assure la gestion globale de la simulation. Il ordonne le début et la fin de la simulation et gère l’horloge globale.
La simulation s’effectue grâce à l’échange de messages spécifiques [ZEIGLER 00] entre les différents processeurs comme décrit dans la Figure 5 b). Les trois premiers types de mes-sages ci-dessous représentent les différents événements définis dans DEVS.
− Xmessage : utilisé lorsqu’un événement externe arrive sur un modèle,
− *message : utilisé pour simuler un événement interne,
− Ymessage : utilisé pour simuler un événement de sortie,
− Imessage : utilisé pour initialiser le modèle (intérêt uniquement informatique).

Notation graphique des modèle couplés G-DEVS

Les modèles atomiques ou couplés définis avec les formalismes DEVS / G-DEVS sont modulaires ; toute interaction avec l’environnement s’effectue par l’intermédiaire de ports d’entrée-sortie. Ce concept de port est fondamental car il permet, entre autres, de stocker des modèles en bibliothèque et de les réutiliser dans des descriptions hiérarchisées sans nécessai-rement connaître leur représentation interne [GIAMBIASI 95].
Ce concept a été formalisé par [CARSTEN 94] qui donne une représentation graphique de modèles couplés DEVS (Figure 8). Dans cette représentation, les modèles contenus dans le modèle couplé considéré sont représenté en bleu, les ports d’entrée et de sortie sont définis par les flèches à gauche et à droite des modèles, enfin les relations de couplage sont les lignes continues reliant des ports. Cette représentation a également été retenue pour la représentation des modèles couplés G-DEVS [ESCUDE 00].

Conclusion Modélisation & Simulation

Après avoir rappelé les principales notions sur la modélisation et la simulation, nous avons constaté que les méthodes généralement préconisées pour modéliser et simuler les sys-tèmes complexes se décomposent en plusieurs classes se différenciant sur les manipulations des variables d’état et de la représentation du temps.
Nous avons, ensuite, présenté les formalismes DEVS et G-DEVS qui sont à la base des travaux que nous présentons par la suite. Ces formalismes présentent l’intérêt d’une sémanti-que opérationnelle claire et précise et permettent la spécification de modèles de simulation sans aucun détail d’implémentation logicielle. Il est important de préciser qu’il s’agit bien de formalismes de spécification et non pas de langages de programmation.

Simulation distribuée

La simulation distribuée est apparue pour répondre à plusieurs attentes. Elle permet d’utiliser au mieux la puissance des ordinateurs, de travailler sur des ordinateurs distants et de réutiliser des simulations existantes en les interconnectant. Il existe plusieurs catégories de simulations distribuées que nous présentons ci-dessous.

Solutions architecturales disponibles

Parmi les solutions architecturales disponibles, nous pouvons retenir l’utilisation d’un or-dinateur  multiprocesseur qui partage sa mémoire. Il est également possible d’interconnecter plusieurs ordinateurs éventuellement distants (clustering). Nous opterons pour cette possibili-té qui offre le choix d’utiliser ou non une mémoire partagée, et fonctionne principalement par envoi de messages permettant aux différentes simulations d’échanger des données et de se synchroniser.

Méthodes de distribution possibles

Différents éléments peuvent être distribués dans une simulation. La première solution est la distribution des fonctions du simulateur. Une autre solution consiste à distribuer les événe-ments. Enfin, la dernière solution consiste à distribuer les éléments du modèle. Dans ce cas, on procèdera par échange de messages datés entre les processus, il sera donc obligatoire d’utiliser un mécanisme de synchronisation des messages échangés entre les processus. On utilise, dans ce dernier cas, au mieux le parallélisme du modèle [FUJIMOTO 00].

Simulation distribuée a événements discrets

Evolutions

De façon similaire à la simulation séquentielle, l’évolution des simulations parallèles (ou distribuées) à événements discrets peut être synchrones ou asynchrones. Pour l’évolution syn-chrone, le temps simulé correspond à une horloge globale. Toutes les horloges logiques loca-les (horloges de chaque processeur) sont donc dirigées par cette horloge globale. A chaque pas temporel, les différents processeurs logiques (LP5) exécutent des actions.
Dans le cas d’une évolution asynchrone, le temps logique de chaque LP évolue d’événement en événement. Mais les LPs ayant entre eux une relation « d’influencés-influenceurs » doi-vent, avant toute exécution d’un événement daté au temps T, être sûrs de ne pas recevoir dans le futur un message avec une date T’< T. Cette contrainte est la causalité.

Exécution distribuée : respect de la causalité

Un traitement en simulation distribuée doit s’assurer de reproduire les relations de causa-lité temporelles existantes dans l’exécution séquentielle équivalente.
La causalité temporelle impose donc un ordre partiel entre les événements. [LAMPORT 78] définit une méthode basée sur les horloges logiques locales de telle façon que, pour tout événement a et b, si a est arrivé avant b (a → b), implique que le temps logique local C(a) doit être strictement inférieur à C(b).

Types de synchronisation

Pour respecter la causalité, deux types de synchronisations entre les LP sont possibles. Ces simulations supposent que l’on considère la simulation comme composée d’un ensemble de LPs qui communiquent en échangeant des messages datés (événements). Chaque LP exé-cute une simulation à événements discrets locale, qui maintient un échéancier avec les événements locaux et ceux reçus des influenceurs, un état local courant et une horloge locale qui contient la date logique locale actuelle.

Approche pessimiste (ou conservative)

Un LP sélectionne l’événement local (ou celui reçu d’un LP qui l’influence) dont la date T est la date minimum de son échéancier. Il traite cet événement en planifiant un nouvel évé-nement local ou à destination de ses influencés, en modifiant la valeur de zéro ou plusieurs de ses variables d’état, et en actualisant sa date logique actuelle avec la date de l’événement trai-té.
Lorsqu’un LP traite un événement de date T, il doit être sûr de ne pas recevoir d’autres événements de date T’ < T, et donc respecter le principe de causalité. L’objectif de ces pre-miers algorithmes de synchronisation est donc de déterminer les événements « sûrs » à traiter. Les premiers algorithmes permettant d’assurer lors du traitement d’un événement que le LP ne recevra pas d’autres événements de date inférieure ont été proposés par [BRYANT 77] et [CHANDY 79].
Dans cette solution, les LPs sont reliés par des liens (ou canaux) qui définissent la struc-ture des relations d’influence entre LPs. Sur la Figure 9, les cercles représentent les LPs et les flèches les liens. Il est supposé que les LPs émettent des messages (des événements) sortant dans un ordre non décroissant et que le réseau assure que les messages soient reçus dans le même ordre que lors de l’émission. Cette supposition garantie que le dernier message reçu sur un lien est une date minimum par rapport à la date des prochains messages à recevoir sur ce lien. Enfin le LP sélectionne le message de date minimum parmi ceux reçus sur ces liens in-fluenceurs et ses messages locaux.
Cependant, un problème survient dans les synchronisations conservatives si un des liens est vide lors de la détermination du prochain message à traiter. Dans ce cas, on ne connaît pas la date du prochain message à recevoir par ce lien et le LP attend indéfiniment cette informa-tion, cela se traduit par un interblocage (DeadLock), la Figure 9 illustre deux situations d’interblocage.

Eléments de l’implémentation (architecture)

Un fédéré est un programme informatique compatible HLA, pour cela le code du fédéré conserve ses fonctionnalités originales mais il doit être complété par un certain nombre de fonctions pour permettre la communication avec les autres membres de la fédération. Ces fonctions sont contenues dans le code de la classe FederateAmbassador qui permet de rendre interprétables par un processus local les informations reçues provenant de la fédération.
Le « Local RTI Components code » (LRC) fournit des fonctionnalités externes au fédéré pour l’enregistrement et l’utilisation des services du RTI tels que l’enregistrement d’objets et la gestion du temps, ces fonctionnalités sont fournies dans la classes RTIAmbassador.
Enfin, le composant central du RTI gère la fédération en s’appuyant notamment sur les informations fournies par le FOM pour définir les objets et les interactions participant à la fédération. La Figure 10 illustre une fédération composée de 2 fédérés A et B.

Gestion de la Fédération

Il est ici question de création et de destruction de fédération, les services définit ici per-mettent aux fédérés de créer une fédération avec le service createFederationExecution(), si la fédération n’existe pas ou de la joindre avec joinFederationExecution(). Il est également pos-sible pour un fédéré de quitter une fédération et de la détruire, à l’aide des mécanismes Re-signFederation() et DestroyFederation(). La gestion des déclarations permet également de sauvegarder l’état d’une fédération et de revenir plus tard à ce point de sauvegarde. Ces der-niers services ne sont pas détaillés ici.

Gestion des Déclarations

Un fédéré peut, au travers des services proposés par le RTI, publier PublishObjectClass() et souscrire SubscribeObjectClass() à une classe ou de la même façon à une interaction (Pu-blishInterractionClass() et SubscribeInteractionClass()). Le terme Publier signifie que le fé-déré a l’intention de diffuser la création d’instances de classe et la mise à jour des attributs de ces instances. Le terme souscrire signifie l’intention des fédérés de refléter certains attributs ou paramètres de certaines classes à d’autre fédérés.

Gestion des Objets

Ici sont définis les services permettant l’échange de données entre fédérés au travers du RTI. Ces messages représentent les événements de la simulation. Ces événements sont transmis au RTI, ensuite le RTI gère la distribution des messages vers les fédérés intéressés par ces informations. Les services les plus utilisés sont RegisterObject() qui permet de créer un nou-vel objet au sein de la fédération, Le callback associé est DiscoverObjectInstance()† qui per-met d’informer les fédérés de cette création. Les autres services permettent de mettre a jour les valeurs des attributs d’un objet avec UpdateAttributeValues() et ReflectAttributeValues()† ainsi que l’émission réception d’interaction avec SendInteraction() et ReceiveInteraction()†. Il est également possible de s’informer de la modification des valeurs d’attributs d’objet à tout moment. Enfin cet ensemble de services permet également de gérer le type de transmission de messages, garantie ou non. Les transmissions garanties sont définies par l’appel aux services changeAttributeTransportType(Reliable) et changeInteractionTransportType(Reliable), ce type de transport est assuré en utilisant le protocole TCP. Les transmissions non garanties de réception sont définies par l’appel aux services changeAttributeTransportType(bestEffort) et changeInteractionTransportType(bestEffort), ce type de transport est assuré en utilisant le protocole UDP.

Gestion de la Propriété

Les fédérés créent des objets, ils ont, à ce moment, la propriété de leurs attributs. Les fé-dérés souhaitant acquérir la propriété d’attributs d’objets en font la demande auprès du RTI qui la transmet au fédéré concerné, un fédéré recevant une telle demande peut accepter de céder cette propriété ou non. Un fédéré peut également céder la propriété d’un attribut d’objet sans demande, L’attribut se retrouve dans ce cas sans propriétaire. Il est à noter que cette ges-tion d’objets n’est pas forcement utilisée dans toutes les fédérations.

Gestion de la Distribution de Données

Il est possible d’affiner l’échange des données entre fédérés en définissant des régions d’influence, en reprenant les mécanismes de publication et de souscription mais en travaillant en termes d’instances de classes d’objets ou d’interaction. On peut ici déterminer plus préci-sément les messages à échanger entre les fédérés et ainsi diminuer les échanges.

Gestion du temps

Il est possible, en se conformant à HLA, de choisir la façon dont vont être échangées les données au sein de la fédération. Les messages peuvent être de type ReceiveOrder (RO), dans ce cas les messages ne sont pas datés, ils sont simplement envoyés et reçus sans contraintes temporelles. Une autre possibilité consiste à définir des messages datés TimeS-tampOrder (TSO). Dans ce cas, HLA utilise les algorithmes de synchronisation pessimistes et/ou optimistes de la simulation distribuée vus précédemment. Le RTI implémente donc des notions associées à la synchronisation du temps dans ses deux versions, seuls les noms de certaines notions ou services diffèrent parfois entre la norme 1.3 [DMSO 98b] et 1516 [IEEE 1516.2 00]. Les fédérés émetteurs, c’est-à-dire qui publient, des messages TSO sont dits ré-gulateurs de temps (Time Regulating) et les fédérés qui reçoivent, c’est-à-dire qui ont souscrit à, des messages TSO sont dits contraints de temps (Time Constrained). Il est à noter que les fédérés peuvent être à la fois régulateurs et contraints de temps.
HLA utilise la notion de Lookahead. Rappelons que le Lookahead L est la durée au delà de sa date actuelle pendant laquelle un fédéré atteste qu’il n’émettra pas de message. Les fé-dérés peuvent modifier la valeur de leur Lookahead en cours d’exécution. Dans le cas d’une augmentation par un fédéré de son L, le RTI prend en compte directement cette modification. Dans le cas d’une diminution le RTI prend en compte la demande mais elle ne sera effective qu’après que le fédéré est avancé son temps de l’ancienne valeur de son L, cela pour respecter la causalité.
A partir des Lookahead des fédérés, le RTI peut calculer pour chaque fédéré le LBTS17 ou GALT18. C’est la date jusqu’à laquelle le fédéré ne sera pas influencé par ces influenceurs, c’est donc le minimum des dates actuelles de ses influenceurs plus leurs Lookahead.
Les méthodes d’avancement du temps dans HLA peuvent être divisées en deux catégo-ries : par pas constant ou par événements.
La réponse du RTI dépend du mécanisme de synchronisation choisi pour faire évoluer le temps. Dans le cas d’un avancement par pas de temps « time stepped federates », le pas d’avancement dans le temps est constant tout au long de l’exécution. Les fédérés effectuent la demande avec la fonction TimeAdvanceRequest() indiquant ainsi qu’ils se sont acquittés du traitement des messages de dates inférieures. En retour, le RTI accorde un TimeAdvance-Grant()† lorsque tous les fédérés ont effectuée leurs demandes d’accord d’avancement pour une même date.
Si l’avance est définie par événement « event driven federates », l’avance dans le temps du fédéré est conditionnée par la réception d’un message. Un fédéré demande à avancer au temps du prochain message TSO local ou reçu. Dans le cas d’une évolution dirigée par les événements, les fédérés interrogent le RTI pour obtenir l’autorisation de sélectionner un évé-nement dans leurs échéanciers avec la fonction NextEventRequest() 1.3 ou NextMessageRe-quest() 1516. À cet appel le RTI répond en fonction du mécanisme de synchronisation choisi pour faire évoluer le temps. Dans le cas du choix d’une simulation pessimiste, le service Ti-meAdvanceGrant()† est activé uniquement si le RTI est sûr de transmettre les messages dans le bon ordre causal. Dans le cas où le RTI doit d’abord délivrer un message de date inférieure a la date d’avance demandée le RTI appellera ReceiveInteraction()† ou ReflectAttributesVa-lues()† plus un TimeAdvanceGrant()†. Ces notions seront reprises et détaillées dans le chapi-tre 3.

Autres techniques de simulation distribuée « non dédiées »

Il existe d’autres types de simulations distribuées s’appuyant sur des techniques « non dédiées » à la simulation distribuée telles que les web services, le peer to peer, l’utilisation de sockets, etc. Cependant nous pensons que ces techniques de partage et de diffusion d’informations sont incomplètes car elles ne proposent pas de mécanismes de synchronisa-tions nécessaires à l’échange de messages datés. Dans la perspective de leurs utilisations dans notre étude, il serait donc nécessaire de mettre en oeuvre l’ensemble de ces mécanismes, re-mettant ainsi en cause l’expérience acquise et intégrée dans les normes dédiées à la simulation distribuée.
De part l’incapacité à manipuler les échanges d’informations datées, nous ne retiendrons pas les techniques non dédiées dans le choix d’une norme en soutient de la définition d’une simulation à événements discrets distribuée.

Conclusion Simulation Distribuée

HLA s’inscrit comme une norme définissant un environnement de modélisation et simu-lation. Cette norme se démarque des précédentes (DIS, ALSP…) et des techniques non dé-diées par les propriétés de réutilisation et de gestion du temps développées dans cette norme. En effet, la réutilisation des objets partagés est facilitée par la définition de documents décri-vant la structure de chaque objet partagé par un fédéré HLA. De plus, une partie des méca-nismes de synchronisation d’échange d’information est déjà présente dans le logiciel (RTI) spécifié dans cette norme, l’intégration d’un programme dans un fédéré est donc facilitée par héritage de classes prédéfinies et appel de fonctions du RTI dédiées aux services de gestion du temps proposés par le RTI. Pour ces raisons, nous utiliserons la norme HLA en soutient du développement de l’environnement de simulation distribué introduit dans cette thèse.
Malgré cela, il est important de retenir que la norme HLA n’est pas une implémentation, ce n’est qu’une spécification dont on suit les instructions dans la conception et la réalisation de fédérés et de fédérations.

Concepts et Terminologie Workflow fondamentaux

Les principaux termes associés aux Workflow proposés par la WfMC [WFMC11 99] sont présentés dans le diagramme du méta modèle Workflow ci-dessus, ce diagramme permet éga-lement de mettre en évidence leurs interrelations. Les termes présentés ci-dessous en français  avec la traduction anglaise originale associée, couvrent les notions plus importantes apparte-nant au Workflow et à son lexique [WFMC11 99].

Procédure Workflow (Workflow Process)

Une procédure Workflow est une procédure contrôlée par un Workflow. Une procédure est composée de plusieurs activités enchaînées pour représenter un flux de travail. Une procé-dure possède une structure hiérarchique et modulaire, en l’occurrence une procédure peut donc être composée de sous procédures et d’activités. Les sous-procédures peuvent être com-posée elles mêmes de procédures manuelles ou de procédures Workflow.

Activité (Process Activity)

Une activité est une étape d’un processus au cours de laquelle une action élémentaire est exécutée. On désigne par « action élémentaire » (ou tâche) une activité qui n’est plus décom-posable en sous-procédures. La WfMC distingue une « activité manuelle », qui n’est pas contrôlée par le système Workflow, et une « activité Workflow » qui est sous le contrôle du Workflow. Un exemple d’une activité manuelle est l’ouverture d’un courrier. Une activité Workflow peut être le remplissage d’un formulaire électronique. Il existe donc des exemples d’activités manuelles intégrables dans un Workflow.
[VAN DER AALST 98a] présente l’activité Workflow comme l’intersection entre une ressource humaine ou matérielle et un bon de travail dans le cadre de l’exécution d’une tâche. Dans cette représentation, une ressource du modèle organisationnel est donc exigée pour qu’une tâche puisse être instanciée en activité et allouée à un participant de Workflow.

Acteur, Ressource (Workflow Participant)

Un acteur est une entité du modèle organisationnel participant à l’accomplissement d’une procédure. L’acteur est chargé de réaliser les activités qui lui sont attribuées via le(s) rôle(s) qui lui sont définis dans le modèle organisationnel. Les autres dénominations courantes dans la littérature de cette entité sont « ressource », « agent », « participant » ou « utilisateur ». L’acteur peut être une ressource humaine ou matérielle (machine, périphérique informati-que…).
Les ressources sont organisées en classes dans le modèle organisationnel. Ces classes sont des groupes de ressources possédant des propriétés communes. Une classe est basée sur :
Rôle : défini ci dans le § suivant.
Groupe : cette classification est basée sur l’organisation (département, équipe, unité).

Rôle (Role)

Un rôle décrit en général les compétences d’un acteur dans le processus ou sa position dans l’organisation. Un rôle est associé à la réalisation d’une ou de plusieurs activités. Plu-sieurs acteurs peuvent tenir un même rôle. La WfMC distingue deux types de rôles [WFMC11 99] :
Les rôles organisationnels définissent un ensemble de compétences qu’un acteur pos-sède. Ce rôle définit la position de l’acteur dans une organisation.
Les rôles procéduraux définissent une liste d’activités qu’un acteur est en capacité d’exécuter.
Il est à noter que certains travaux ne différencient pas les notions d’acteur et de rôle et ne par-lent que d’acteur. Cette opinion semble restreindre la clarté et la flexibilité des modèles Work-flow.

Données (Workflow Relevant Data)

Une donnée pertinente pour les procédures est une information en rapport avec la réalisa-tion des activités (en définition de la tâche, en entrée ou en sortie). Elle peut constituer l’objectif d’une tâche (manipulation de la donnée et définition de l’état de la procédure), être un élément essentiel pour activer les transitions d’état d’une instance Workflow ou être généré par la tâche et ainsi intervenir dans la détermination de la prochaine activité à déclencher. Ces données sont en général des objets au sens purement informatique mais peuvent également être une représentation d’objets physiques.
Notons qu’il existe deux autres types de données utilisées hors de la gestion de procédures : Donnée de contrôle (Control Data) : données gérées et utilisées par le système Workflow et les moteurs Workflow.
Données Applicatives (Applicative Data) : données propres aux applications, le système de gestion de Workflow n’y a pas accès.

Application externe (Invoked Application)

Une application externe est une application informatique dont l’invocation est nécessaire à la réalisation de la tâche ou à l’exploitation des résultats générés avant de déclencher la tâ-che suivante ou de recommencer cette première. On tiendra compte de l’allocation de ressour-ces, si l’application n’est pas uniquement informatique. Il faut différencier les outils (Tools), qui sont eux directement interfacés par le système Workflow, sans l’intervention d’une res-source du Système Workflow.

Table des matières

CHAPITRE 1. ETAT DE L’ART
1 INTRODUCTION
2 MODELISATION & SIMULATION
2.1 INTRODUCTION A LA MODELISATION ET SIMULATION
2.2 LES NIVEAUX DE SPECIFICATION D’UN SYSTEME
2.3 LES FORMALISMES DE SPECIFICATION DES SYSTEMES
2.3.1 Le Système et son cadre expérimental
2.3.2 Le Modèle
2.3.3 Les Classes de modèles (formalismes)
2.3.4 Le Simulateur
2.4 MODELISATION ET SIMULATION A EVENEMENTS DISCRETS
2.4.1 Formalisme DEVS
2.4.2 Formalisme GDEVS
2.4.3 Classe de modèles G-DEVSPF
2.5 CONCLUSION MODELISATION & SIMULATION
3 SIMULATION DISTRIBUEE
3.1 SOLUTIONS ARCHITECTURALES DISPONIBLES
3.2 METHODES DE DISTRIBUTION POSSIBLES
3.3 SIMULATION DISTRIBUEE A EVENEMENTS DISCRETS
3.3.1 Evolutions
3.3.2 Exécution distribuée : respect de la causalité
3.3.3 Types de synchronisation
3.4 ARCHITECTURES DE SIMULATION
3.4.1 DIS
3.4.2 ALSP
3.4.3 HLA
3.4.4 Techniques de simulation distribuée « non dédiées »
3.5 CONCLUSION SIMULATION DISTRIBUEE
4 WORKFLOW
4.1 UNE INTRODUCTION AU WORKFLOW
4.2 ORIGINES
4.3 MOTIVATIONS
4.4 DEFINITIONS ET TERMINOLOGIES
4.5 DEFINITIONS DE BASE DU WORKFLOW
4.5.1 Définition d’un Workflow
4.5.2 Méta Modèle basique
4.5.3 Concepts et Terminologie Workflow fondamentaux
4.5.4 Concepts secondaires (Wider Workflow Concepts & Terminology)
4.6 DIMENSIONS
4.7 DESCRIPTION DES SYSTEMES WORKFLOW
4.7.1 Build time
4.7.2 Run time
4.7.3 Utilisateurs, outils et applications
4.8 MODELE DE REFERENCE DES SYSTEMES WORKFLOW
4.8.1 Interface avec les Outils de définition de procédures
4.8.2 Interface avec les applications clientes Workflow
4.8.3 Interface avec les applications invoquées
4.8.4 Interface avec les autres Workflow
4.8.5 Interface avec les outils de contrôle et d’administration
4.9 CLASSIFICATION DES SYSTEMES WORKFLOW
4.9.1 Processus collaboratifs
4.9.2 Workflow administratif
4.9.3 Workflow de production
4.9.4 Workflow adaptable ou Workflow ad hoc
4.10 MODELISATION DES PROCESSUS WORKFLOW
4.10.1 Aspects à modéliser
4.10.2 Modélisation de Workflow adaptable
4.10.3 Techniques et outils de modélisation de Workflow
4.11 OUTILS LOGICIELS POUR DECRIRE, ANALYSER ET VALIDER UN WORKFLOW
4.12 CONCLUSION WORKFLOW
5 CONCLUSION
CHAPITRE 2. MODELISATION & SIMULATION G-DEVS / HLA
1 INTRODUCTION
2 SIMULATION SEQUENTIELLE DE MODELES G-DEVS
2.1 SIMULATION DES MODELES DEVS
2.1.1 Rappel Simulateur conceptuel DEVS
2.2 MISE A PLAT DES MODELES DEVS/G-DEVS
2.2.1 Travaux précédents
2.2.2 Nouvelle structure de simulation
2.2.3 Spécification de mise à plat de modèles hiérarchiques
3 SIMULATION DISTRIBUEE DE MODELES G-DEVS
3.1 COMPOSANTS DE SIMULATION
3.1.1 Coordinateur local
3.1.2 Simulateur
3.1.3 Coordinateur Racine Distribué
3.2 ALGORITHMES DE TRAITEMENT DES EVENEMENTS
3.2.1 Coordinateur Local
3.2.2 Simulateur
3.2.3 Coordinateur Racine Distribué
3.3 DEFINITION DE MODELES COUPLES DISTRIBUES CONFORMES A HLA
3.3.1 Rappel d’Intégrations DEVS/HLA
3.3.2 Création d’une fédération suivant le FEDEP
3.3.3 Algorithme de communication avec le RTI
3.4 AMELIORATION DU CALCUL DU LOOKAHEAD DANS G-DEVS/HLA
3.4.1 Application du calcul du Lookahead à la classe G-DEVSPF1
3.4.2 Application du calcul du Lookahead à la classe G-DEVSPF2
4 PERSPECTIVES
5 CONCLUSION
CHAPITRE 3. ENVIRONNEMENT DE SIMULATION G-DEVS / HLA
1 INTRODUCTION
2 ENVIRONNEMENTS DE MODELISATION GRAPHIQUE DEVS EXISTANTS
2.1 CD++
2.2 JDEVS
2.3 ANALYSE
3 SPECIFICATION DE L’ENVIRONNEMENT LSIS_DME
3.1 CONTRIBUTIONS
3.2 SPECIFICATION DE L’EDITEUR GRAPHIQUE LSIS_DME
3.2.1 Edition de modèles atomiques
3.2.2 Edition de modèles couplés
3.3 SPECIFICATION DE L’ENVIRONNEMENT DE SIMULATION LSIS_DME
3.3.1 Fonctions de mise à plat de la structure hiérarchique de modèles
3.3.2 Algorithmes de simulation
3.3.3 Calcul de la complexité algorithmique
3.3.4 Mise en oeuvre de la version distribuée de l’environnement G-DEVS/HLA
3.4 ILLUSTRATIONS DE L’ENVIRONNEMENT DE SIMULATION
3.4.1 Exemple Commande Système commandé
3.4.2 Exemple de Modèle couplé distribué G-DEVS/HLA
4 PERFORMANCES
4.1 PERFORMANCES DES ENVIRONNEMENTS DEVSCLUSTER & DDEVSIM ++
4.2 MESURES DE PERFORMANCE REALISEES SUR LE SIMULATEUR G-DEVS « MIS A PLAT »
4.2.1 Exemples mis en oeuvre
4.2.2 Discussion
4.2.3 Amélioration de la gestion de listes
4.3 MESURE DE PERFORMANCE DE SIMULATIONS G-DEVS / HLA
4.3.1 Exemples mis en oeuvre
4.3.2 Réduction du surcoût en temps de simulation
5 PERSPECTIVES
6 CONCLUSIONS
CHAPITRE 4. APPLICATION A UN ENVIRONNEMENT WORKFLOW G-DEVS / HLA
1 INTRODUCTION
2 PRESENTATION DU CADRE DE TRAVAIL
2.1 RAPPEL DU MODELE WORKFLOW DE REFERENCE
2.2 DETAILS DE L’INTERFACE 1
3 TRANSFORMATION D’UNE STRUCTURE WORKFLOW EN STRUCTURE G-DEVS
3.1 PROCESSUS DE TRANSFORMATION WORKFLOW G-DEVS
3.2 SPECIFICATION TEXTUELLE D’UN WORKFLOW
3.2.1 Nécessité d’une spécification textuelle
3.2.2 Représentation d’une Procédure Workflow
3.2.3 Définition des éléments basiques liés à une Procédure Workflow
3.3 DEFINITION DE MODELES WORKFLOW SIMULABLES DANS LE FORMALISME G-DEVS
3.3.1 Choix du formalisme des modèles simulables des Workflow
3.3.2 Définition d’une Bibliothèque de modèles G-DEVS pour la définition d’un Workflow
3.4 ALGORITHME DE TRANSFORMATION
3.4.1 Structure source
3.4.2 Structure cible
3.4.3 Fonction de transformation
3.5 SIMULATION DU MODELE G-DEVS COUPLE OBTENU
4 DEFINITION D’UN ENVIRONNEMENT WORKFLOW COMPATIBLE HLA
4.1 TRAVAUX PRECEDENTS
4.2 MODELE DE REFERENCE WORKFLOW COMPATIBLE HLA
4.3 CREATION DES TABLES DE FOM DE LA FEDERATION WORKFLOW GDEVS HLA
5 APPLICATION A UN WORKFLOW D’ENTREPRISE
5.1 CAHIER DES CHARGES
5.2 EXEMPLE DE LA ROUTE H80SH27F ATTACHEE AU PRODUIT FDHB2AAG-03
5.2.1 Représentation du modèle à l’aide de l’outil de modélisation graphique LSIS_WME
5.2.2 Représentation textuelle de la route H80SH27F
5.2.3 Représentation des sous-modèles
5.3 TRANSFORMATION DU WORKFLOW EN MODELE G-DEVS
5.3.1 Résultats de simulation de la route H80SH27F
5.4 DEFINITION DU WORKFLOW COMPATIBLE HLA
5.4.1 Création des tables d’un FOM HLA
5.4.2 Mécanisme de Publication/ Souscription
5.5 CONCLUSION DE LA MODELISATION DE LA ROUTE H80SH27F
6 PERSPECTIVES
7 CONCLUSION
CONCLUSION GENERALE
BIBLIOGRAPHIE

Télécharger le rapport complet