Soutenue le 17 Fevrier 2008

Transcription

1 Soutenue le 17 Fevrier 2008 Année universitaire

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43 Chapitre 2 Etant donné qu on s intéresse à la simulation de systèmes complexes, dite souvent simulation large Scale, on ne reprend donc, dans ce chapitre, que les notions ou concepts en relation. Toutefois, le lecteur intéressé trouvera dans la littérature de la simulation les notions de base pour pouvoir se retrouver dans ce qui suit. On citera [Fek,97],[Ann, 99 ], [Meg, 99] [Khe, 01][Zei,00],[Fuj, 99] parmi d autres à titre de référence. Pour pouvoir arriver à une bonne définition de la simulation large scale et puisque celle-ci dépend de la simulation distribuée et de la simulation temps réel, on commencera d abord par citer la définition d une simulation, d une simulation distribuée et enfin d une simulation temps réel. CONCEPTS DE SIMULATION CONCEPTS DE SIMULATION La mise au point d une telle simulation nécessite des outils spécifiques dont une méthodologie d approximation successive MAS [Khe,01], [Zei, 95] qui consiste à raffiner le modèle d un système complexe par un processus incrémental et du formalisme DEVS [Zei, 00] qui permet la spécification d un tel système une fois raffiné. Pour cela, on relève également, dans ce chapitre, ces deux points importants et l avantage de leur fusion. Une conclusion explique l autonomie et l autosuffisance des concepts sous cités afin de développer et d implémenter une simulation large scale. Département d Informatique, Faculté des Sciences, Université d Oran 34

44 Chapitre II Concepts De Simulation Mokaddem I SIMULATION La simulation est l un des outils d aide à la décision les plus efficaces à la disposition des concepteurs et des gestionnaires des systèmes complexes. Elle consiste à construire un modèle d un système réel et à conduire des expériences sur ce modèle afin de comprendre le comportement de ce système et d en améliorer les performances. Dés l origine, l ordinateur s est avéré être un outil de grande valeur pour la réalisation de la simulation. En effet, une fois le modèle transcrit sous la forme d un programme, l ordinateur permet d étudier l évolution du système dans le temps. Cette étude se fait sans risque pour l expérimentateur, à un coût réduit et lui permet de tester aisément ses hypothèses. De même, lors de l étude de systèmes stochastiques, il est possible d effectuer rapidement plusieurs simulations en faisant varier les paramètres, donc cette technique est puissante. Elle est aussi irremplaçable lorsque l étude analytique ou numérique échoue en raison de l incapacité. Les applications de la simulation sont innombrables. Parmi les domaines dans lesquels elle est le plus utilisée, on peut citer : L informatique : recherche de configurations, réseaux, architecture de bases de données,... La production : gestion des ressources de fabrication, machines, stocks, moyens de manutention,... La gestion : marketing, tarification, prévisions, gestion du personnel,... l administration : gestion du trafic, du système hospitalier, de la démographie,... L environnement : pollution et assainissement, météorologie, catastrophes naturelles,... I.1 DIFFERENTS TYPES DE SIMULATION Un système temps réel est un système dans lequel on doit répondre aux événements dans une période de temps spécifiée finie. Un tel système ne doit pas seulement produire des résultats corrects, mais il doit les produire conformément au temps en respectant les contraintes temps réel hardware et software. Pour répondre aux contraints hardwares, le système utilise des taches hardwares, ces dernières sont de deux types, périodiques et non périodiques. Une tâche périodique se répète indéfiniment et respecte toujours un délai critique qui constitue sa période. Une tâche non périodique n apparaît qu une seule fois dans le système et doit également respecter un son délai critique. Les tâches hardwares ont des deadlines délais critiques- absolus, une fois dépassés, il y a écroulement du système. D autre part, pour répondre aux contraintes softwares, le système utilise des taches softwares. Ces dernières sont ordinaires et sont traitées une fois que le système trouve un temps creux (Idle Time). Dans un système temps réel les taches périodiques sont plus prioritaires que les tâches non périodiques et les taches softwares. Quand une tâche non périodique arrive à un nœud du système, on cherche sur ce nœud s il existe un idle-time pour la traiter dans son deadline, si cet idle-time existe et le délai est respecté elle est prise en charge à ce nœud elle est déroutée vers un autre nœud du système. Les tâches softwares attendent au nœud où elles arrivent jusqu à leur exécution. Il existe deux algorithmes de scheduling dans ce type de système. L EDF (Earliest Deadline First) qui sélectionne la tâche de plus court deadline d abord. Le LLF (Least Laxity First) calcule la laxity= (di-ci) où di est le deadline et ci est le temps d exécution de la tâche et sélectionne la plus petite différence. CONCEPTS DE SIMULATION I.1.1 Simulation temps réel Ces systèmes sont plus rigoureux que les systèmes interactifs qui exigent seulement l efficacité du temps de réponse [Chr, 90]. La simulation temps réel nécessite une fonction identité qui fait correspondre le temps du modèle simulé (temps de simulation) au temps de l horloge murale (temps du système réel). Plus généralement, un flot d événements dans un modèle doit se produire pendant la simulation au temps de l horloge murale correspondant à son temps dans le modèle réel avec une tolérance donnée [Zei 93]. Par exemple les temps Département d Informatique, Faculté des Sciences, Université d Oran 35

45 Chapitre II Concepts De Simulation Mokaddem associés aux activités d un modèle hétérogène, tel que le modèle de l opérateur humain, devraient êtres émulés en simulation. Une telle simulation temps réel est beaucoup souhaitée dans les applications intégrant l opérateur humain où, un modèle de l opérateur humain devrait remplacer un membre de l équipe et se comporter comme l opérateur lui-même, il doit répondre dans le même intervalle que les autres membres de l équipe de façon à assurer une totale intégrité avec confusion de l opérateur et du modèle. La gestion du temps doit être conforme que le modèle soit logique (Software) ou physique (l opérateur lui-même). Les spécificités hardwares et softwares ci-dessous facilitent une simulation temps réel : Déterminisme strict : les mêmes micro-opérations prennent toujours le même temps pour être exécutés, quelle que soit la charge du système. Un tel déterminisme rend possible la prédiction des temps des macro-opérations employées en simulation. Vitesse d'exécution suffisamment grande : si toutes les micro-opérations peuvent être garanties dans des deadlines compacts, les temps des macro-opérations peuvent être imposés puisque les événements peuvent être garantis à ne pas se produire si tard et retardés si nécessaire pour ne pas se produire si tôt. Hardware : évalué selon son support des opérations temps réel. I.1.2 Simulation distribuée : La simulation constitue un champ d application privilégié pour l expérimentateur de problèmes liés au parallélisme. La nécessité constamment affirmée de disposer de résultats de plus en plus rapidement sur des modèles de plus en plus complexes a conduit à rechercher toutes les voies possibles d accélération des traitements pour cela la simulation distribuée est caractérisée par [Fuj 99] : Le modèle est divisé en sous modèles, chacun de ces deniers est assigné à un processeur pour son exécution. Chaque sous-modèle a des états propres et une horloge de simulation personnelle. Pas de mémoire partagée, tous les processeurs communiquent exclusivement par messages. Les processeurs s exécutent concurremment jusqu à la fin de la simulation. Accélérer les parties opératives de simulation du modèle en utilisant des processeurs adaptés à la granularité des applications. On peut définir, dans ce domaine, la granularité comme la quantité de traitement nécessaire pour chaque entité du modèle sans synchronisation avec les autres. Plus cette quantité est faible, plus la granularité est fine. Accélérer les parties consommatrices en temps comme la génération de nombres aléatoires. Accélérer les opérations de contrôle et de synchronisation. Le majeur problème de la simulation distribuée à événements discrets est qu elle nécessite la gestion d un temps virtuel, partagé par les différents processeurs. Enfin pour gérer l interaction des processeurs il existe deux approches de base [Ann 99], [Jha, 94]: Conservatrice Opportuniste. CONCEPTS DE SIMULATION L architecture utilisée pour une simulation distribuée ouvre diverses possibilités que l on peut résumer ainsi : I Approche conservatrice Cette méthode, développée par Chandy et Misra [Cha 79,81], fonctionne selon les contraintes suivantes : Le couplage entre composants doit être statique (il doit être déterminé avant la simulation et ne doit pas changer en cours de simulation). Les messages envoyés par un simulateur sur un canal sont reçus dans le même ordre chronologique de leur envoi. Dans cette approche, la simulation d un modèle consiste en plusieurs composants modulaires qui communiquent entre eux par des messages à temps fixe obéissant à la contrainte de causalité [Fuj 99]. Département d Informatique, Faculté des Sciences, Université d Oran 36

46 Chapitre II Concepts De Simulation Mokaddem Les objets temporaires ne sont pas présents dans le modèle, mais ils sont remplacés par des messages. Les objets manipulés par le modèle sont représentés par des nœuds dans un réseau. Tous les objets avancent ensemble dans le temps de simulation. Chacun possédant une variable appelée "temps de simulation local (TL) qui enregistre le temps de simulation du dernier événement exécuté par cet objet. Les interactions entre les objets se réalisent par le biais des messages d'événement, chaque message possède un tampon de temps qui spécifie le temps nécessaire pour traiter un événement. Un objet dans un modèle peut recevoir plusieurs messages de la part de plusieurs objets, et peut à son tour envoyer des messages à d'autres objets, de ce fait, chaque lien de communication à sa propre liste de messages d'entrées B A D C Time 28Stamped Message 22 Local time of B Dans la figure FigII.1, on a quatre objets A, B, C et D qui appartiennent au système, et chaque objet possède un temps local mentionné dans le cercle. L objet A ne reçoit aucun message, il est appelé objet autonome. L objet B contient dans sa liste d entrée deux messages provenant de A, et qui attendent leur tour pour être traités par le processeur de simulation de B. Chaque message, possède un timbre de temps. L objet D, possède deux listes d entrée, car il reçoit des messages de B et de C. Dans l approche conservatrice, un objet n est autorisé de progresser que si : Aucun message ne lui arrive à un temps plus petit que celui de la simulation de cet objet. L ordre d arrivée des messages doit être réservé. Les timbres de temps des messages envoyés doivent former une séquence croissante Avantages Cette approche a de bonnes capacités de prédiction pour améliorer et préserver l'ordre des messages. Inconvénients [Fuj, 99],[Zei,00] Le couplage doit être statique. Le changement du modèle provoque la dégradation de la performance. La performance dépend sur les capacités de prédiction (i.e. l habilité de garantir une période de traitement sûr, dans le futur). L'existence du problème d'interblocage (deadlocks) si le réseau possède un cycle, en effet, pendant que des modèles se trouvent dans un état de blocage, les listes d'entrées vont déclarer des dépassements de capacité de mémoire" Overflows". CONCEPTS DE SIMULATION FigII.1 Diagramme de la simulation conservatrice Il existe deux façons de traiter les interblocages : Prévenir et éviter les interblocages en envoyant des messages nuls pour annoncer l absence de messages réguliers [Mis 86], mais ceci nécessite la communication de la topologie du réseau. Département d Informatique, Faculté des Sciences, Université d Oran 37

47 Chapitre II Concepts De Simulation Mokaddem Détecter et corriger les interblocages par un algorithme de détection. Plusieurs méthodes ont été proposées [ Sta, 05],[Cha, 81], [Sil, 94]. 50 A B 25 D C FigII.2 L interblocage dans la simulation conservatrice Dans la figure FigII.2 donnée par Jefferson [Jef, 85], les objets B, C et D sont toujours bloqués pendant que les liens entre : B et D, C et B et enfin entre B et C sont vides ce qui empêche C et D de progresser. Ce type d interblocage peut être résolu par les messages nuls. Une autre solution proposée par Chandy et Misra [Cha, 81] consiste à appliquer un algorithme de détection de l interblocage. I Approche opportuniste La plus importante implémentation de cette approche est le Mécanisme Time Warp (MTW). Cette approche s'appuie sur le mécanisme de ROLLBACK qui consiste en deux phases : phase de restauration phase d'annulation. Dans le MTW, les objets sont activés indépendamment les uns des autres, à l'exception des objets qui recevront des messages entrants dans leurs listes de messages, c'est pour cela qu'on remarque que les valeurs du TVL des objets sont différentes d'un moment à l'autre pendant la simulation. Le temps global est nécessaire pour mettre fin à la simulation, d'où la notion du temps virtuel global (TVG) est apparue. Le TVG est égal à la plus petite valeur TVL de tous les objets présents dans le modèle. Un problème apparaît dans cette approche, quand un message arrive à un objet ayant un TVL plus grand que le temps message, ce qui déclenche une erreur. Ce type de message est appelé "straggler". Cette erreur doit être corrigée, car l'objet peut envoyer d'autres messages aux autres objets. Pour corriger cette erreur, l'objet qui reçoit un straggler reprend un ancien état dont son temps est inférieur ou égal au tampon de temps du straggler. Puisque le MTW sauvegarde l'état et les messages d'entrées des objets, la reprise d'état précédente est possible. Mais cette solution reste impossible dans les cas où : Des messages arrivent pendant que l'objet reprend son état précédent. L objet envoi des messages à d'autres objets. Des anti-messages vont être envoyés pour annuler les messages erronés. Si les anti-messages sont reçus après le traitement des messages erronés, le processus du ROLLBACK est aussi tôt appliqué. CONCEPTS DE SIMULATION Dans le MTW, il n'y a pas de variable globale qui représente l'horloge de la simulation, mais chaque objet possède sa propre horloge locale du temps d'exécution. Donc, dans cette approche on parlera de temps virtuel où chaque objet a son propre temps virtuel local (TVL). Pour accomplir le ROLLBACK, on doit sauvegarder les informations suivantes : Le journal de l'état pour restaurer l'état. Le message d'entrée pour refaire les entrées après le ROLLBACK. Un anti-message pour chaque message positif, dans le cas du ROLLBACK, il est envoyé pour anéantir leurs messages positifs. Pour éviter ceci, deux solutions sont proposées : Département d Informatique, Faculté des Sciences, Université d Oran 38

48 Chapitre II Concepts De Simulation Mokaddem Un objet en ROLLBACK annule tous ses messages de sortie jusqu'à ce qu'il reprenne son état précédent. Cette stratégie est dite "annulation agressive ". L objet en Rollback doit tarder l envoi de ses messages aux objets qui suivent jusqu à ce qu il reprenne son état prétendu; ainsi le nombre des anti-messages est minimisé. Cette stratégie est connue par : «l annulation lente». Avantage La gestion du réseau de communication est facile, car chaque objet a une seule queue d'entrée. Inconvénient [Fuj, 99], [Zei, 00] Si le modèle contient simplement du parallélisme limité relatif au nombre de processus, un degré significatif de Rollback est inévitable. La vitesse de la simulation dépend du nombre des processeurs utilisés. Donc la sauvegarde d'état surcharge le travail ce qui dégrade la performance. En plus l'implémentation de cette méthode est très difficile et nécessite un matériel supplémentaire pour améliorer la vitesse. La méthode de simulation distribuée est typiquement inapplicable à la simulation temps réel. Les approches qui permettent l exécution asynchrone des composants d un modèle, en maintenant une synchronisation correcte des temps, ne devraient pas être contraintes de maintenir une correspondance stricte avec le temps de l horloge murale. Cependant, le simulateur abstrait issu du formalisme DEVS semble être une approche pour amener une simulation distribuée à se comporter en temps réel. I.1.3 Simulation Large Scale Large-scale est un qualificatif assigné aux problèmes nécessitant les plus grandes ressources d aujourd hui. Cette assignation varie avec le temps, ce qui était, il y a une décennie, large-scale, ne nécessite plus aujourd'hui que quelques ressources médiocres. De cela, la simulation Large Scale s intéresse à tout système qui co-évolue avec le problème, en conséquence, à son extensibilité. Pour mettre en évidence les caractéristiques d une telle simulation, il serait prudent de relever la complexité des modèles auxquels s intéresse cette simulation. En effet, étant donné que l être humain est le plus complexe des modèles et que son intégration, ou au moins son intelligence, est inévitable actuellement dans les systèmes contemporains, il s avère donc la meilleure plate forme pour évaluer une simulation dans ce contexte. Ces modèles connaissent déjà dans la communauté de la simulation Large Scale le nom de HPP (Human Performance Process). La définition du terme large-scale, et bien d autres super-computers, et computational complexity, semble changer avec le temps. Dans le cadre du développement de tels environnements de simulation, il faut essayer de concevoir des systèmes temporairement indépendants (Un environnement qui croît dans le temps pour garder sa propre définition : résoudre des problèmes large-scale). CONCEPTS DE SIMULATION Dans le cadre de l enseignement et la recherche scientifique, la simulation large scale a été classée par les congrès comme de grande challenge. Pour parler de problèmes de «grande challenge» tels que le développement de systèmes de simulation, large-scale, on doit se poser la question : Qu est ce que c est que large-scale? Enfin, on peut conclure d'après la définition que Les modèles large-scale nécessitent une simulation distribuée et temps réel. Département d Informatique, Faculté des Sciences, Université d Oran 39

49 Chapitre II Concepts De Simulation Mokaddem II. MODELISATION Une composante réalise une fonction spécifique, la manière dont elle réalise cette fonction et dont elle se comporte vis à vis des autres composantes détermine le comportement global du système et son efficacité d ensemble. C est pourquoi, la première étape de la modélisation est de préciser quel(s) critère(s) de performance on cherche à optimiser. Il n y a pas un seul modèle d un système réel donné : il peut être représenté de différentes manières, en fonction de l objectif que l on s est fixé (la modélisation de certaines composantes, comme par exemple les sources d énergie peuvent être, selon les cas, inutile ou indispensable). Le meilleur modèle est celui qui est à la fois simple et cohérent avec l objectif. Parfois, il est impossible d étudier un système directement du fait qu il est inaccessible ou trop coûteux pour qu on puisse faire des expériences directement dessus, cas des systèmes envisagés par ce projet ou du fait qu il change trop rapidement ou trop lentement. Dans ce cas, l étude est faite sur un deuxième système plus simple à manipuler dit modèle. Enfin, à l intérieur des modèles dynamiques, on distingue les modèles discrets, dans lesquels l état du système ne change qu à certaines dates (exemple : une file d attente devant un guichet), et les modèles continus ou ce changement est permanent (cas du réacteur). Un modèle qui contient à la fois des composantes discrètes et continues est dit mixte. La méthode de construction et d exploitation du modèle dépend de la nature du système réel et de sa représentation. La figure FigII.3 décrit la modélisation d un système réel pour simulation. II.1 Modèles Mathématiques Il y a plusieurs types de modèles mathématiques, ils sont présentés dans le tableau, Table 1, si dessous en termes de temps et d états. Pour les modèles continus, une variable d état continu change sur des intervalles de temps continu dans des modèles continus, ainsi les variables d état discret dans les modèles digitaux changent sur des intervalles de temps discret. Les modèles continus sont représentés par un ensemble d équations aux différences tandis que Les modèles à temps discret sont des modèles du temps continu dans lesquels les variables dépendantes sont rendues discrètes. Les modèles numériques (digitaux) peuvent être représentés par des machines d état fini. Les modèles à événement discret qui utilisent un état continu et axe du temps continu sont différents des modèles continus par le fait que seulement un nombre fini de changements d état peut se produire dans un intervalle fini qui dépend des événements instantanés. CONCEPTS DE SIMULATION Il existe différents types de modèles. Les modèles physiques sont ceux dans lesquels le système réel est représenté par une réplique ou maquette, à une échelle différente et éventuellement à l aide de matériaux différents (exemple : maquette de véhicules pour les essais aérodynamiques en soufflerie). Les modèles symboliques sont une abstraction mathématisée de la réalité. Ils sont en général exécutés sur un calculateur, qu il soit analogique ou digital. Une autre distinction concerne la prise en compte des aléas dans le modèle. Dans certains cas, qualifiés de déterministes, leur influence est considérée comme négligeable. Le plus souvent, ils doivent être représentés car ils jouent un rôle significatif (exemple typique : les pannes). On a alors affaire à des modèles stochastiques. Une troisième dichotomie sépare les modèles statiques et les modèles dynamiques. Dans les premiers, le temps n intervient pas (exemple : modèle comptable permettant de calculer un profit en fin d exercice à l aide d un tableur). Dans les seconds, il est un facteur essentiel du comportement et de l état du système (exemple : réacteur chimique régi par des équations différentielles). II.2 Processus de modélisation : [Meg, 99],[Khe, 01], [ Zei, 00] Le but à atteindre dans cette étape est de construire un modèle valide qui soit le plus simple possible, tout en restant cohérent avec les objectifs de l'étude. Il faut donc tout d abord formuler explicitement ces objectifs, et les divers scénarios à étudier. Le compromis difficile à trouver ; en effet, le concepteur du modèle cherche toujours la simplification, alors que l'utilisateur souhaite que soient finement représentés les constituants du système. Département d Informatique, Faculté des Sciences, Université d Oran 40

50 Chapitre II Concepts De Simulation Système Réel Modélisation Mokaddem Simulation Modèle FigII.3 Simulation et Modélisation S I M U L A T E U R R Caractéristiques Formalisme Mathématique & Etats Zone d application Modèles continus Equations différentielles Les circuits analogiques Continu Continu Modèle A événement discret Formalisme DEVS Système distribué Continu Continu Modèles qualitatifs Intelligence artificielle Continu Symbolique Modèles digitaux Machine d état Circuit digital Discret Discret TABLE 1 Modèle Mathématiques : en terme de temps et d états Cette dernière approche, si elle a l'inconvénient d'alourdir le modèle, présente cependant un avantage important : la condition indispensable pour que l'utilisateur accepte les résultats de la simulation est qu'il soit convaincu que le modèle construit est fidèle à la réalité, ce qui est beaucoup plus facile à obtenir lorsqu'il "reconnaît" son système. Il n'y a donc pas de méthodologie universelle pour conduire l'analyse, mais plutôt quelques principes dictés par l'expérience et de là on pourrait considérer un processus de modélisation comme un raffinement successif de nature, la figure FigII.4 illustre un tel processus appelé processus d évolution de méta-modèle. Mi-1 Mi CONCEPTS DE SIMULATION Types des modèles Temps Mi+1 space solution M FigII.4 Processus d évolution du Méta -modèle Département d Informatique, Faculté des Sciences, Université d Oran 41

51 Chapitre II Concepts De Simulation Mokaddem Dans ce processus, le concepteur, étant données des spécifications issues du cahier des charges, relève ou imagine le candidat le plus approprié avec des descriptions d ordre global. Ce candidat sera détaillé durant le processus de modélisation, et donnera finalement une solution à une description détaillée au stade ultime. Un méta-modèle, dans ce processus, est un ensemble de descriptions, à un certain instant, du candidat à détailler pas à pas jusqu à la dérivation du modèle fidèle par évaluation. Concevoir est, ainsi, une collection de petites procédures pour détailler un méta-modèle qui est, dans ce cas une description partielle d un modèle. Cette évolution du méta-modèle explore très bien le processus réel de conception. La figure FigII.5 montre une description plus formelle du modèle d évolution, elle cite plusieurs principes importants. Mi méta-modèle constitue un ensemble de description de l objet, ceci signifie qu on a un mécanisme central de stockage d information du modèle. Dij Procédures de stockage des connaissances du processus de conception. Noter que ce processus demande un test de fiabilité si le candidat peut exister sous forme d entité physique. Création de modèles selon différentes espèces d analyse à partir de méta-modèles par les connaissances de dij. Un modèle mij, crée par dij à partir de Mi, est utilisé pour analyser les propriétés du modèle candidat et représenté dans un type particulier d information. Le résultat de l évaluation ej, sert à juger si le candidat est approprié et favorable à la solution. Il y a trois endroits où l expertise heuristique est nécessaire : Heuristique Spécification Compromis backtrack NG/UK Mi Mi? Dij Mj dij Heuristique Compromis backtrack mij NG/UK ej OK Next evaluation Mn solution CONCEPTS DE SIMULATION Une telle expertise sert à planifier la conception. Elle sert également à la détermination du Dij qui sera utilisé dans l état de Mi. Si le test de fiabilité échoue, après une procédure d évaluation, on utilise aussi l expertise pour savoir vers quel état on doit faire retour (Backtrack) et comment ne pas compromettre entre les spécifications et la solution. Ce même type d expertise est nécessaire juste après l évaluation ej. Où : Mi :meta modèle dij :modéliser Dij : Détails ej : évaluation Mij : Modèle? : test de fiabilité. FigII.5 Formalisme d une évolution de modèle Département d Informatique, Faculté des Sciences, Université d Oran 42

52 Chapitre II Concepts De Simulation Mokaddem III. SPECIFICATION DES SYSTEMES A EVENEMENTS DISCRETS : DEVS Le formalisme DEVS (Discret EVent System) fut introduit par Zeigler [Zei,00], comme moyen mathématique pour la définition des systèmes composés d objets. Il fournit une manière simple de représenter les paramètres d un système à événements discrets. La puissance du formalisme réside dans sa représentation formelle rigide issue de concepts mathématiques. III.1 Historique de DEVS. A partir de l année 1965, le professeur B. Ziegler de l université d Arizona introduisit, pour la première fois, le concept de systèmes à événements discrets en se basant, pour sa validation, sur les automates cellulaires. Un modèle DEVS fut vu comme une boite noire recevant en entrée un événement fixe à un moment fixe pour fournir une seule sortie après un temps connu à l avance. La figure suivante schématise cette perception du système SYSTEM output input state t Quelques années plus tard, la notion de temps enrichit la représentation du modèle de base pour permettre à l entrée de devenir des segments d entrée aux temps variables pouvant produire des sorties à des moments séparément discernables c est à dire que la notion de temps de transition devint une fonction au lieu de tout simplement un pas fixe. La figure qui vient explique une nouvelle vue du système. SYSTEM output input t state A partir des années 1970, la communauté scientifique agréa deux genres de simulation à savoir discrète et continue. Et de ce fait, elle s appropria la même stratégie en séparant la spécification de chaque discipline dans un formalisme précis apte à être jumelé pour aboutir à ce qui sera appelé une spécification hybride ou mixte du système. Ce fut : (Voir figure suivante) la DESS (Spécification des Systèmes à base d Equations Différentielles) La DTSS (Spécification des Système à base de Temps Discret) DESS CONCEPTS DE SIMULATION 1965 SYSTEM Differential Equation System Specification DTSS Discrete Time System Specification Département d Informatique, Faculté des Sciences, Université d Oran 43

53 Chapitre II Concepts De Simulation Mokaddem B. Ziegler entama une longue thèse de recherche pour situer DEVS tel que formalisme standard de spécification. En premier lieu, DEVS fut, plutôt, une sous classe de DTSS. Le tableau Table 1 organise plusieurs types des modèles mathématiques sur l axe du temps et des états. Il est clair que les modèles à événements discrets utilisent le temps et les états de façon continue, or le nombre de changement d état est fini. Dès cette année là, DEVS devint l outil incontournable de spécification des DTSS puisque tout DTSS peut être représenté par un DEVS simplement par un changement de variable puisqu il y a corrélation entre temps et événement discret. Il suffit d admettre que l arrivée des événements dans le système d une manière discrète détermine des intervalles de temps discrets. Le formalisme DEVS agit sur le changement des variables et génère des segments de temps constants infiniment petits. Ainsi, un événement est un changement de variable occurrent instantanément. Un aspect important du formalisme est que les intervalles de temps entre les occurrences des événements ont variables, contrairement au temps discret ou le pas du temps, est fixe. SYSTEM DEVS Discrete Event System Specification DESS Differential Equation System Specification DTSS Discrete Time System Specification SYSTEM DEV&DESS DESS Differential Equation System Specification Discrete Event & Differential Equation System Specification DTSS DEVS Discrete Event System Specification Discrete Time System Specification Des études avancées ont montré que tout système dynamique causal, dont les segments d entrées et de sorties, sont infiniment petits peut être, représenté par DEVS, on appelle cette classe de système, DEVSreprésentable. En particulier, les systèmes DESS sont souvent utilisés pour représenter un système naturel contrôlé par des événements. Ceci donne à DEVS une validité universelle puisqu il a été également identifié comme outil de représentation des DEDS (systèmes dynamiques à événements discrets) puisqu il a été démontré qu ils ont les mêmes fondements mathématiques. CONCEPTS DE SIMULATION Quelques années plus tard, les résultats des études de Praehofer et Zeigler font constater qu une nouvelle classe de formalisme qui mixe les deux concepts était possible, pour aboutir à une forme de langage de spécification capable de définir n importe quel système. Ce fut le DEV&DESS. Désormais, DEVS est vraiment vu comme un repère pour spécifier des systèmes dont, l entrée, l état et la sortie, sont des trajectoires constantes infiniment petites. Les transitions pas à pas dans ces trajectoires sont identifiées comme événements discrets. Département d Informatique, Faculté des Sciences, Université d Oran 44

54 Chapitre II Concepts De Simulation Mokaddem DEVS REPRESENTABLE SYSYEMS 1993 DEV&DESS DEVS Originality as DEDS Representation PIECEWISE CONSTANT I/O SYSTEMS UNIVERSALITY of DEVS REPRESENTATION Computational Basis for Simulation, Design, control DEVS Tout récemment les théoriciens en contrôle ont développé leur propre formalisme à événement discret mais le titre universel de DEVS justifié par sa caractéristique à représenter la classe des systèmes dynamique demeura toujours fiable pour tout système dont les segments d entrées et de sorties, sont infiniment petits. Dans une telle situation, le comportement est DEVS représentable et également le contrôle est DEVS représentable. Distributed Simulation Predictive Contract-Based Filtering in HLA (DARPA) Logistics Base/depot collaboration (USAF) Watershed Hydrology NSF Grand Challenges Methodology for Abstraction (Roma) Le schéma suivant montre les nouvelles disciplines de l informatique qui ont opté pour une DEVS représentativité. Après 1997, l'environnement DEVJAVA prend le relais comme une mise en oeuvre du formalisme DEVS sous le langage Java afin de permettre au modeleur de spécifier des modèles dans un langage de programmation directement. PARALLEL/CONFLUENT DEVS 1996 DYNAMIC STRUCTURE DEVS SYMBOLIC DEVS CONCEPTS DE SIMULATION L année 1996 fut l année de l extension de l utilisation de DEVS. Ceci grâce à plusieurs organismes qui ont parrainé sur l universalité de DEVS comme formalisme de modélisation et de simulation capable de représenter tous les cas de figures possibles et nécessaires dans de grands projets de simulation (parallélisme, distribué, temps réel et dynamisme) tels que : DEVS REAL TIME DEVS FUZZY DEVS EXTENSIONS OF DEVS Département d Informatique, Faculté des Sciences, Université d Oran 45

55 Chapitre II Concepts De Simulation Mokaddem III.2 Structure de l'entité système (SES) La SES (System Entity Structure) ou structure d'une entité est un moyen de base pour l'organisation d une famille de configurations possibles de systèmes à modéliser [Ros 88]. La SES, basée sur une arborescence, est une représentation qui combine la décomposition, la taxonomie et le couplage tel qu il est décrit ci dessous : Décomposition : C est une représentation d un composant par ces constituants. Egalement, les constituants peuvent être représentés par leurs sous composants. Le niveau de décomposition est déterminé par les objectifs du concepteur. Taxonomie : est une méthode d organisation de l information sur la classification des composants. C est une méthode préliminaire pour classer les systèmes et sous système en classes et sous classes par spécialisation. Couplage : C est une représentation de l information sur la façon dont les modèles sont connectés ensemble pour former un modèle composé à différents niveaux de l arborescence. Une SES satisfait les axiomes suivants : Uniformité : deux nœuds de même nom ont des attributs identiques et des structures isomorphiques. Hiérarchie stricte : dans une branche de la structure les nœuds ne doivent apparaître qu une seule foi dans un chemin (branche) de la structure. Mode alternatif : les modes d un nœud et de ces successeurs sont toujours différents ( aspect et spécification de l entité). Ciblage valide : deux nœuds d un même parent (ciblage) ne peuvent avoir le même nom. Variables attachées : les variables attachées à des nœuds ne peuvent avoir le même nom. Le tri primaire du SES va servir comme un schéma représentatif de connaissance pour organiser une famille de modèle de base. Exemple : EF GENR TRANSD FigII.6 Exemple La SES de la figure FigII.6 affirme qu une entité EF, la racine de la structure est décomposée en entités TRANSD et GENR, en utilisant l aspect EF-DEC. Une SES est dit pure, si elle n a ni spécification ni aspect sous chaque entité. Cette SES peut être directement transformée en un modèle hiérarchique et facilement simulée, figure FigII.7. Exemple : SES modèle de base ABC A B AB C CONCEPTS DE SIMULATION EF-DEC C1 C2 A B C1 C2 FigII.7 Exemple Département d Informatique, Faculté des Sciences, Université d Oran 46

56 Chapitre II Concepts De Simulation Mokaddem III.3 DEVS Parallèle On définit deux types de modèles dans le DEVS Parallèle: III.3.1 Modèle de base C est le modèle de plus bas niveau comportant une structure dynamique, il est défini par : int, ext, con,, ta > où : M = < X, Y, S, X : Ensemble d événements d entrées externes. S : Ensemble des états séquentiels. Y : Ensemble des sorties. int : S S : fonction de transition interne. ext : x Xb : fonction de transition externe Xb : ensemble de bags (paquets) sur les éléments de X. ext ((s, e), ) = (s, e ) = {(s, e) / s S, 0 e ta (s)} et Xb con : S x Xb fonction de conflit de transition. = { int, ext } :S Yb : fonction de sortie. b Y : ensemble de bags sur les éléments de Y. ta : S : fonction d avancement du temps. : Ensemble des réels e : temps écoulé depuis la dernière transition. ta (s) : temps écoulé dans l état s si aucun événement externe n arrive. L ensemble total des états spécifiés dans M est : int : S S : Si aucun événement externe n arrive, le système passe de l état s à l état int (s) après que ta, temps du prochain événement interne, sera écoulé. ext : x Xb S : suite à un paquet d événements x X, le système transite de l état (s, e) vers l état ext((s, e), x). Il est resté pendant e dans s. e est remis à 0 après chaque transition. La relation entre la fonction de transition interne, la fonction de transition externe et les sorties, est montrée dans la figure FigII.8. Dans ce type de représentation, deux variables manipulent les parametres du modèle : Sigma : le temps du dernier evenement (interne ou externe) agissant sur le système. Phase : l état du sytème qui peut etre soit libre soit occupé. y x s = e x t (s,e,x ) s s D E V S = ta (s ) CONCEPTS DE SIMULATION = { ( S, e ) /s S, 0 e ta (s)} s = in t s < X,S,Y, in t, e x t, c o n, ta, FigII.8 Représentation schématique du modèle de base (atomique). Département d Informatique, Faculté des Sciences, Université d Oran 47

57 Chapitre II Concepts De Simulation Mokaddem La Figure FigII.8 est une représentation systématique des modèles de base. Par exemple, quand un paquet d entrées arrive dans un système à la file d attente, la variable S, qui est la longueur de la file et représente l état du système, est incrémentée par un. La fonction qui traite l entrée et change ensuite la variable S est ext. Après un temps écoulé donné par la fonction ta, le système contrôle la file en retirant certains paquets causant ainsi, la décrémentation de la file par le nombre de paquets retirés. En d autres termes, la variable S change intrinsèquement de l état précédent au prochain état par retrait de paquets. De la même façon, la fonction interne int change les variables internes de l état précédent au prochain. La fonction con décide que faire lorsque les événements internes et externes se produisent en même temps, elle devait par exemple, utiliser une priorité entre int et ext. La fonction produit la sortie Y à partir des variables d état. La fonction ta retourne le temps du prochain événement interne. int : un évènement externe ne se produit jamais avant la transition interne sauf dans le cas ou le temps de traitement de l événement expire très rapidement. Si bien spécifié, le système réside à n importe quel moment à l état S. Si aucun évènement externe n intervient le système demeure toujours à l état S pendant un temps déterminé par la fonction ta(s). ta(s) peut prendre au départ soit 0 ou bien la valeur défaut ta. Dans le premier cas, l évènement est tellement rapide qu il ne permet aucune entrée. On dit que c est un état transitoire. Dans le second cas, le système hiberne jusqu à l arrivée d un évènement ou l expiration du temps de «repos». Dans ce cas, S est appelé état passif. Remarque : Il n y a aucune manière de générer une sortie à partir de l évènement en entrée directement. III.3.2 Représentation Procédurale du modèle atomique Le modèle DEVS atomique est développé, à ce jour, sous Java studio et JDK compatibles, vu la portabilité de Java et son utilisation comme langage orienté objet par excellence. Cette forme de modélisation (en objets) impose de travailler uniquement avec des messages. Ceci dit, les évènements, jusque là, seront désormais définis comme des messages par analogie au concept objet. 1. la fonction d écoulement de temps ta. 2. la fonction de transition interne qui modifie la valeur de phase. L état du système se libère par la fonction de sortie en produisant un message et faisant passer phase à libre. F u n c tio n d e tr a n s itio n e x te r n e F u n c tio n v o id p r o c ::d e lte x t(tim e ty p e e,m e s s a g e * x ) { C o n tin u e (); if (p h a s e _ is (" p a s s iv e " )) fo r (in t i= 0 ; i< x -> g e t_ le n g th ();i+ + ) if (m e s s a g e _ o n _ p o r t(x," in ",i)) { jo b = x -> g e t_ v a l_ o n _ p o r t(" in ",i); h o ld _ in (" b u s y ",p r o c e s s in g _ tim e ); } } P r o g r e s s io n F o n c tio n d e tr a n s itio n v o id p r o c ::d e ltin t( ) { p a s s iv a te (); } A T O M IC d e s o r tie m e s s a g e * p r o c ::o u t( ) { if (p h a s e _ is (" b u s y " )) m e s s a g e * m = n e w m e s s a g e (); e n tity * v a l = jo b ; m -> a d d (m a k e _ c o n te n t(" o u t",v a l);); r e tu r n m ; } d u CONCEPTS DE SIMULATION La figure FigII.9, ci-dessous, complémente la figure FigII.8 précédente par plus d explications. Un message reçu en entrée par la fonction de transition externe stimule deux autres étapes : te m p s in te r n e in x o u t p h a s e jo b y s FigII.9 Représentation Procédurale d un modèle atomique Département d Informatique, Faculté des Sciences, Université d Oran 48

58 Chapitre II Concepts De Simulation Mokaddem III.3.3 Gestion des Conflits La figure FigII.10 si dessous explique la situation et la gestion des cas de conflit. Ce cas de figure intervient lorsqu il un évènement externe surgit au même moment qu une transition interne. Si la fonction de transition externe reçoit un message M1, ceci implique que la fonction de transition externe doit modifier la phase à busy, et après un temps ta, la fonction de transition interne doit la remettre à idle. Si, à ce moment là, un autre message M2 arrive au port d entrée et si le système écoute δext en premier alors le message va être omis car phase est à busy bien que ta a expiré. Si le système écoute δint en premier alors phase va recevoir idle puis le message M2 va être reçu. Par défaut, la priorité est donnée aux événements internes sauf si spécification oblige. x s = c o n (s,e,x ) s ta (s ). D E V S = < X,S,Y, in t, e x t, c o n, ta, FigII.10 gestion des conflits 1. Les ports sont représentés explicitement puisqu il peut y avoir autant d'entrées ou de sorties que de ports sur lesquels les valeurs peuvent être reçues ou envoyées. 2. Au lieu de recevoir ou produire une seule entrée ou sortie, DEVS Parallèle manipule des paquets (bag) d'entrées ou de sorties. Un bag peut contenir plusieurs éléments avec la possibilité de redondance de ces éventuels éléments. 3. La fonction de gestion de conflit décide, en cas de collision entre événement externe et événement interne, sur le prochain état. Nous avons vu le cas de telle collision dans le DEVS classique mais cette fois-ci, on considère une éventuelle possibilité de conflits multiple. III.4 Modèle couplé Un modèle couplé est composé d un ou plusieurs modèles atomiques ou couplés, il est déterminé par la spécification de ces composants et la définition du couplage qui crée les liaisons de communication désirées entre composants. Il est défini par : DN = < X, Y, D, {Mi}, {Li}, {Zj} > où : CONCEPTS DE SIMULATION A présent, on signale les avantages importants du DEVS Parallèle au-delà du formalisme DEVS classique : X : l ensemble des événements d entrée. Y : l ensemble des événements de sortie. D : l ensemble des noms des composants. Pour chaque i D : Mi : est le modèle du composant i. Li : est l ensemble des composants influencés par i. Pour chaque j Li : Zij : est la fonction de translation de i à j. Département d Informatique, Faculté des Sciences, Université d Oran 49

59 Chapitre II Concepts De Simulation Mokaddem III.4.1 Fermeture du modèle DEVS couplé Un des principaux facteurs de réussite du modèle DEVS est sûrement sa fermeture, c est à dire, que chaque modèle couplé généré sera à son tour considéré comme un modèle atomique apte à être utilisé dans la formation d autres nouveaux modèles couplés. Avec de nouveaux paramètres car il sera vu à l instar des détails de son couplage comme une boite noire ayant un certain nombre de ports d entrée et de sortie et réalisant une fonction bien spécifique. Closure of Coupling DN <X,Y,D,{Mi},{Ii},{Zij}> DEVS <X, S,Y, int, ext, con, ta,, DEVS <X, S,Y, int, ext, con, ta, DEVS <X, S,Y, int, ext, con, ta, DEVS <X, S,Y, int, ext, con, ta, Chaque modèle couplé est vu comme un modèle atomique équivalent FigII.11 Fermeture du couplage Du fait DN = {D, {Mi}, {Ii}, {Zij}} est équivalent à : òu X = {(p,v) p Є InPorts, v Є Xp} InPorts ensemble de ports d entrée; Y = {(p,v) p Є OutPorts, v Є Yp} OutPorts ensemble de ports de sortie; D ensemble des noms des composants. EIC:Extern Input Coupling, connecte les entrées externes aux entrées des composants: EIC = {((N, ip N ), (d, ip d )) ip N Є InPorts, d Є D, ip d Є InPorts d } EOC : Extern Output Coupling, connecte les sorties des composants aux sorties du modèle: EOC = {((d, op d ), ( N, op N )) op N Є OutPorts, d Є D, op d Є OutPorts d } IC: Intern Coupling, connecte les entrées des modèles aux sorties d autres modèles. IC =Í {((a, op a ), (b, ip b )) a, b Є D, op a Є OutPorts a, ip b Є InPorts b } Remarque Aucune récursivité n est autorisée dans ce type de représentation car il est fortement hiérarchique, c est à dire qu aucune sortie d un modèle ne peut être renvoyée vers sa même entrée Les valeurs envoyées par une source doivent être compatibles avec les valeurs acceptables par le modèle récepteur i e : Cette dernière remarque est la source majeure des erreurs de non exécution des modèles couplés c est pourquoi DEVSJAVA est devenu le formalisme incontournable car les types de valeurs reçues ou émises sont de même types c à d de type Message. CONCEPTS DE SIMULATION DN = (X, Y, D, {M d d Î D}, EIC, EOC, IC) III.4.2 Représentation du couplage La représentation du couplage peut être modélisée par différentes façons dont les plus connues sont : 1. La représentation par arborescence mais qui ne représente que la relation hiérarchique du couplage sans spécifier le couplage interne (FigII.12) 2. La représentation par la relation de couplage (FigII.13) 3. La représentation par structure (FigII.14) Département d Informatique, Faculté des Sciences, Université d Oran 50

60 Chapitre II Concepts De Simulation ABCV) A(BC) C ABC D In B in out A in D BC A Mokaddem In out out out InC ou t FigII.13 relation de couplage B C FigII.12 Arborescence BC A Composants BC, out ABC, out FigII.14 Structure de couplage ABC, in A, in Couplage A, out BC, in III.4.3 Représentation Procédurale du modèle Couplé 1. Spécification des composants atomiques entrant dans la formation du modèle : Ceci se fait en langage Java par un héritage des classes de modèles déjà déclarés (atomic Atom = new atomic() ;). Puis les intégrer dans la nouvelle classe ( add (Atom) ;) 2. Spécification des ports de sortie et d entrée : Ceci par l utilisation des instructions (inports.add(nom_de_l entrée) ; outports.add(nom_de_lasortie) ;) 3. Spécification du couplage interne : Ceci par la conjonction entre la sortie d un modèle et l entrée d un autre. En utilisant la syntaxe suivante : add.coupling (modèle1,port1,modèle2,port2) ; c re a te c o m p o n e n ts c la s s e f:p u b lic d ig ra p h { p u b lic : e f():d ig ra p h (){ g e n r * g = n e w g e n r("g ); tra n s d * t = n e w tra n s d (" t" ); s ta rt e f s ta rt o u t g r e s u lt a r iv a d d (g ); a d d (t); o u t t in a d d c o u p lin g a d d _ c o u p lin g (th is, " in ", t, " d o n e " ); a d d _ c o u p lin g (th is, " s ta rt", g, " s ta rt" ); t- > a d d _ c o u p lin g ( t," o u t",g," s to p " ) ; t-> a d d _ c o u p lin g (t, " o u t", th is, " re s u lt" ); g -> a d d _ c o u p lin g (g, " o u t", th is, " o u t" ); g -> a d d _ c o u p lin g (g, " o u t", t, " a riv " ); o u t d o n e CONCEPTS DE SIMULATION Pour la déclaration de n importe quel modèle couplé, il est nécessaire de vérifier trois principes : d e c la r e p o r ts in p o o u tp in p o o u tp rts -> a o rts -> rts -> a o rts -> d a d a d d d d (" in " ); d (" o u t" ); (" s ta rt" ); d (" re s u lt" ); D IG R A P H FigII.15 Représentation Procédurale d un modèle atomique Département d Informatique, Faculté des Sciences, Université d Oran 51

61 Chapitre II Concepts De Simulation Mokaddem III.5 DEVS étendu pour la simulation temps réel Les attentions récentes convergent vers l utilisation des concepts de modélisation afin de fournir une approche adéquate de modélisation pour le contrôle des processus industriels adaptés particulièrement aux exigences des applications à haute autonomie. L environnement de la simulation DEVS a été employé afin de développer et appliquer la méthodologie du contrôle d événements, qui fournit un contrôle par couche simple et robuste (il peut ressembler au raisonnement symbolique évolué par couche), dans les laboratoires d automatisation. L application de la technologie numérique dans le contrôle de processus industriel devint inévitable pour répondre aux exigences des opérations temps réel, un système temps réel est un système informatique répondant à une entrée externe générée par les stimuli en une période précise. Ce système doit non seulement fournir un résultat logique, correct d un calcul mais le fournir d une manière opportune. Dans cette partie nous voulons introduire le formalisme qui a été étendu pour supporter le contrôle de la simulation temps réel. Le contrôleur de la base de connaissance peut être conçu et testé comme étant un modèle à implanter. Les composants du modèle à implanter sont remplacés par les composants physiques actuels pendant que le même modèle de contrôle continue à être utilisé pour les contrôler. Ce contrôleur communique avec une unité d interface détecteur/dispositif de commande programmable dans le but d envoyer les commandes de contrôle, générées par le DEVS aux dispositifs de commandes physiques et recevoir les lectures du détecteur physique. On montrera comment cette méthodologie est supportée par l interprétation temps réel du formalisme DEVS. Une borne inférieure est dérivée sur la vitesse d exécution des systèmes d exploitation non déterministes relative aux événements périodiques ce qui garantit une durée de contrôle correcte. En connectant la simulation temps réel exécutive à travers une voie de communication, l architecture est applicable aux opérations semi-autonomes avec des éléments implantés (du système physique) sur un site éloigné. Que veut dire lancer la simulation DEVS temps réel? La simulation DEVS temps réel est l interaction permanente avec le monde réel, c est à dire que le simulateur doit garantir aux modèles simulés l interaction en temps avec les objets du monde réel (FigII.16). On détaillera dans ce qui suit le formalisme DEVS temps réel. Le formalisme DEVS temps réel est basé sur les concepts du formalisme DEVS [Zei, 00] et sur l extension pour la simulation temps réel effectuée par [Hon 97]. 1. Modèle atomique temps réel : RTAM = < X, S, Y, int, ext,, ta,, A > où : X : Ensemble d événements d entrées externes. S : Ensemble des états séquentiels. Y : Ensemble des sorties. int : S S : fonction de transition interne. ext : x X S: fonction de transition externe où est l ensemble total des états de M = {(s, e) / s S, 0 e ta (s)} :S Y: fonction de sortie. ta : S +0, +0, : fonction d avancement du temps. :S A fonction d activation de correspondance. A : ensemble d activités. Département d Informatique, Faculté des Sciences, Université d Oran CONCEPTS DE SIMULATION Un exemple est cité dans [Kim, ] sur un contrôleur intelligent qui sera promus comme prototype du système d extraction d oxygène prétendu opérer sur MARS. 52

62 Chapitre II Concepts De Simulation Mokaddem Modèles de simulation temps réel AM RO DM AM DM RO RO RO Objet du monde réel FigII.16 Simulation temps réel 2. Modèle couplé temps réel : Le modèle couplé est défini de la même manière que dans le formalisme DEVS. Modèle de pilotage (gestion) : où : X= XM U XE : l ensemble d événements d entrée. XM : événement d entrée du modèle. XE : événement d entrée de l environnement. Y = YM U YE : l ensemble d événements de sortie. YM : événement de sortie du modèle. YE : événement de sortie de l environnement. TME : XM YE : événement de la fonction de transition du modèle vers l environnement. TEM : XE YM : événement de la fonction de transition de l environnement vers le modèle. III.6 Processus de simulation Calcul des imminents : un composant imminent est un composant dont le temps du prochain événement est le plus petit. Déterminer les imminents consiste à tourner tous les composants dont le temps du prochain événement est le minimum. Calcul input() output() : chaque imminent atomique gère ses sorties par appel de sa fonction calcul inputoutput(). Un modèle couplé accumule toutes les sorties de ses composants et détermine si les sorties de ces composants sont pour usage interne ou externe (c est à dire sorties du modèle couplé). Tellall envoie deltfunct() : après que tous les imminents produisent leurs sorties, le modèle couplé demande à ses composants d exécuter leurs fonctions. Deltcon() : Puisque les composants travaillent simultanément, une entrée externe peut arriver pendant que le composant exécute sa fonction int ; c est à dire que int et ext de ce composant doivent s'exécuter simultanément. Ce cas de conflit, est résolu par con(), qui sélectionne l'approprié. Par défaut, int passe d abord (dans le cas ou l utilisateur ne définit pas de critères de priorité). Delint() : int spécifie le prochain état vers lequel le composant transitera, elle prépare la prochaine transition interne int. Delext() : ext spécifie également avec les entrées venant des influencés une transition d état. Structure dynamique : après que tous les messages ont atteint leur destination et que chaque modèle a changé son état, un changement dynamique, pendant l'exécution de la simulation, peut avoir lieu. Il consiste à ajouter, supprimer ou déplacer des modèles. Il peut être réalisé grâce à la fonction structure dynamique. Département d Informatique, Faculté des Sciences, Université d Oran CONCEPTS DE SIMULATION RTDM = < X, Y, TME, TEM > 53

63 Chapitre II Concepts De Simulation Mokaddem i=1 Calcul des imminents Calcul des entrées sorties Oui deltfunc() Tel lall_wrap_deltfunc() Couplée? Non i++ deltcon() Oui Interne abord? Non deltint() deltext() deltext() deltint() Structure dynamique pas d évén ou i > # itérations? Non Oui Fin de simulation FigII.17 Organigramme de simulation III.6.1 Schémas de la simulation DEVS CONCEPTS DE SIMULATION Temps mis à jour L organigramme ci-dessus, FigII.17, présenté illustre l algorithme des étapes d une simulation qui passe forcément par les différentes phases ci-dessous résumées : Calcul des imminents : un composant imminent est un composant dont le temps du prochain événement est le plus petit. Déterminer les imminents consiste à enclencher tous les composants dont le temps du prochain événement est le minimum. Ceci se fait par envoi de requête à la recherche de l éminent.en retour on récupère l élément sélectionné. Département d Informatique, Faculté des Sciences, Université d Oran 54

64 Chapitre II Concepts De Simulation S i m u l a t i o n C a l c u l d u C Mokaddem y c l e p r o c h a i n S t e p ( t N ) 1 : B l o c k ( U I ) T e l l _ a l l ( n e x t _ t N c o m i c o m i + c o m c o m i + 7 p u t e 3 p u t e L o w 1 p u t e i 8 i t N o d e i c o m c o m p u t e N ) E n s e m + c o m + 4 p u t e 9 p u t e t N c o m t N + i c o m 1 0 p u t e b l e M e s s a g e t N t N t N i + c o m t N + i p u t e i + c o m t N H 1 1 p u t e i g h N + i 5 p u t e + 2 p u t e t N c o m t N i p + u t 6e t N t N o d e FigII.18a 1ère étape de la simulation S im u la t io n C y c le S t e p 1 B lo c k ( U I ) C o lle c tio n o f M in im tn u m V a lu e s i i r e tu r n i + r e tu r n i + 1 r e tu r n M I N 3 M I N tn tn r e tu r n i tn I N tn N o d e i + r e tu r n r e tu r n 8 M tn i + + i + 7 L o w + r e tu r n M 9 tn i 4 I N r e tu r n tn i + r e tu r n 1 0 tn i M 2 M I N tn i I N tn + r e tu r n 6 tn 1 1 r e tu r n tn H ig h N o d e FigII.18b 2ème étape de la simulation Cette requête est assumée par le Root (voir algorithme du Root ) qui émet des messages en Broad-Cast (à tous les éléments du 1er niveau du modèle). A tour de rôle niveau par niveau la requête se propage jusqu à attendre des niveaux extrêmes. (Simulation Cycle Step1 ). En retour chaque coordinateur répond par un message Mono-Cast ( avec ciblage du destinataire ) pour informer et élire l élément imminent. (Simulation Cycle Step 1 ). Calcul input() output() : chaque imminent atomique gère ses sorties par appel de sa fonction calcul inputoutput(). Un modèle couplé accumule toutes les sorties de ses composants et détermine si les sorties de ces composants sont pour usage interne ou externe. Simulation Cycle Step2 consiste à redistribuer l information en Broad-Cast du composant élu (imminent) pour qu il enclenche ses fonctions de transfert. Les autres éléments mettent à niveau leurs horloges en ajustant les horloges tn. Tellall envoie deltfunct() : après que tous les imminents produisent leurs sorties, le modèle couplé demande à ses composants d exécuter leurs fonctions. CONCEPTS DE SIMULATION r e tu r n Tous les modèles mettent à jour la valeur des imminents en empruntant deux sous directions d information : Département d Informatique, Faculté des Sciences, Université d Oran 55

65 Chapitre II Concepts De Simulation Mokaddem Verticale : du coordinateur au coordonné où l imminent est ordonné de déclencher sa transition. Horizontale : du coordinateur à ses prochains éventuellement par échange de messages pour qu ils marquent des arrêts d attente tout en homogénéisant l ensemble du système sur les mêmes valeurs du temps du prochain évènement externe. Remarque : si la simulation est en mode parallèle, le Root peut sélectionner plusieurs éléments et lancer leurs simulations en même temps. S im u la tio n C y c le S te p 2 T e ll a ll c o m p o n e n ts g lo b a l tn : if c o m p o n e n t is im m in e n t g e n e ra te a n d s o rt o u tp u t m e s s a g e s L o w i + N o d e i T e ll_ a ll (c o m p u te _ I O ) E n s e m b le M e s s a g e c o m p u te _ IO i + 1 i + i + 3 c o m p u te _ IO i + 7 c o m p u te _ IO i + i i + 9 c o m p u te _ IO i + 5 i c o m p u te _ IO i + 6 c o m p u te _ IO c o m p u te _ IO c o m p u te _ IO c o m p u te _ IO 2 c o m p u te _ IO c o m p u te _ IO 1 1 c o m p u te _ IO H ig h N o d e FigII.18c 3ème étape de la simulation A cet état de lieu, les échanges de messages (la simulation) entre différents modèles atomiques commencent (Simulation Exchange Message). t e ll a ll im s o r t, a n d i + 1 i + a il E x c h a n g e m in e n t s, d is t r ib u t e o u t p u t m 2 i + in S t e p 3 e s s a g e s ( m a il) u s in g i + 3 S te p 1 : M a il M e s s a g e S te p 2 : M a il E x c h a n g e S iz e c o u p lin g 4 I n f o r m i + 5 a tio n FigII.18d 4ère étape de la simulation deltcon() : puisque les composants travaillent simultanément, une entrée externe peut arriver pendant que le composant exécute sa fonction int ; c est-à-dire que int et ext de ce composant doivent s'exécuter simultanément. Ce cas de conflit, est résolu par con(), qui sélectionne le approprié. Par défaut, int passe d abord (dans le cas où l utilisateur ne définit pas de critères de priorité). delint() : int spécifie le prochain état vers lequel le composant transitera, elle prépare la prochaine transition interne int. delext() : ext spécifie également avec les entrées venant des influencés une transition d état. Département d Informatique, Faculté des Sciences, Université d Oran CONCEPTS DE SIMULATION M 56

66 Chapitre II Concepts De Simulation Mokaddem Ensuite, les modèles couplés mettent à jour TL(temps du dernier événement), tn(temps du prochain événement). Le modèle couplé réitère le cycle de simulation jusqu à ce la condition fin de simulation soit rencontrée. A la fin du temps qu occupe l élément simulateur en cours ou à la survenue d un événement externe la boucle est réinitialisé. III.7 Simulateur abstrait Le concept de simulateur abstrait, associé au formalisme DEVS, est introduit par Zeigler [Zei 87] pour permettre une implémentation sur des architectures distribuées. Les modèles développés selon DEVS sont pratiquement prêts pour être portés sur des systèmes de simulation distribués, en accord avec les principes des simulateurs abstraits [Chri 90]. Un simulateur abstrait hiérarchique DEVS [Wra 87] consiste en deux types d éléments : les simulateurs et les coordinateurs. Ils sont assignés aux modèles atomiques et couplés, respectivement, d une manière univoque. La figure FigII.19 illustre cette correspondance pour le modèle ABC de la figure FigII.12. Le Root Coordinateur a la tache de superviser la simulation globale. Il est attaché au modèle couplé le plus externe (le plus grand). Son algorithme est donné en figure FigII.20. Root Coordinateur Coordinateur Simulateur Modèle Atomique A Coordinateur Simulateur Modèle Atomique C FigII.19 Simulation Abstraite Hiérarchique La simulation procède par envoi de messages entre simulateurs et coordinateurs. Il est important de noter que les simulateurs et les coordinateurs reçoivent le même type de message. En conséquence, un coordinateur n a pas à distinguer si le subordonné est un coordinateur ou un simulateur. L opération d un simulateur abstrait engage 5 types de messages : (*, t), (x, t), (y, t), (i, t) et (d, tn) (*, t) : Demande au modèle d'exécuter sa fonction de sortie et sa fonction de transition interne int (un événement interne doit être exécuté). (x, t) : Indique l arrivé d un événement externe. Le modèle calcule sa fonction de transition externe ext avec un ensemble des destinations des influencés. (y, t) : Rapporte les sorties ; envoyées par les simulateurs ou les coordinateurs, au parent coordinateurs ou Root Coordinateur. (d, tn) : Contient la notice (done) avec le temps du prochain événement. (i, t) : provoque l initialisation du simulateur qui nécessite le calcul du prochain événement CONCEPTS DE SIMULATION Simulateur Modèle Atomique B Ces messages sont échangés à travers le processeur du simulateur abstrait. Nous allons maintenant décrire les deux simulateurs abstraits sous formes d algorithme, respectivement l un pour un modèle atomique DEVS et l autre pour un modèle DEVS couplé. Département d Informatique, Faculté des Sciences, Université d Oran 57

67 Chapitre II Concepts De Simulation Mokaddem Un simulateur abstrait possède 5 variables : S : état séquentiel du composant DEVS. tl : le temps auquel le dernier événement est apparut. e : le temps écoulé depuis le dernier événement (elapsed time). sigma : temps restant au prochain événement interne (se calcule à chaque transition des états intermédiaires, jusqu à ce qu un événement interne arrive). tn : temps du prochain événement interne. Ces cinq variables simulation. réalisent la dynamique du modèle atomique DEVS et effectuent le processus de Root coordinateur : variables : global clock /* horloge globale de simulation */ initialise: /* phase d initialisation */ envoie message (i, t) à tous ses fils /* initialise ses fils */ Si message (d, tn) reçu alors Si (t < infinie ) alors clock :=t produire le message(*, t) et l envoyer à ses fils sinon terminer Fsi Si message (y, t) reçu alors afficher le contenu de ce message état passif Fsi Fsi FigII.20 Root Coordinateur On présente dans les figures FigII.21a et FigII.21b un simulateur pour un modèle atomique spécifié dans le formalisme DEVS et qui correspond aux taches exécutées par le modèle atomique M tel que : M=<X, S, Y, int, ext,, ta > a) cas d un évènement interne Si une entrée (*,t) reçue alors Si t = tn alors y := (S) ; Envoyer (y,t) au coordinateur ; S : = ðint(s) ; tl : = t ; tn : = tl + ta(s) ; Envoyer (d,tn) au coordinateur ; Fsi Sinon erreur ; Fsi CONCEPTS DE SIMULATION III.7.1 Simulateur abstrait pour un modèle atomique DEVS FigII.21a simulateur abstrait pour un modèle atomique Quand un simulateur reçoit un message interne c est à dire le message (*, t), il vérifie si le temps de simulation t est égal à tn, sinon une erreur est détectée et la simulation doit être stoppée. Autrement (si t = tn), le simulateur envoie sa sortie (y, t) (sortie qui est déterminée par l état transitoire juste avant la transition interne) à son coordinateur. En même temps, le simulateur calcule son nouvel état S avec la fonction de transition interne int, met à jour tl à t, et détermine un nouveau tn. A la fin du calcul, le simulateur envoie un message (d, tn) au coordinateur. Département d Informatique, Faculté des Sciences, Université d Oran 58

68 Chapitre II Concepts De Simulation Mokaddem b) cas d un événement externe Si une entrée (x,t) reçue alors Si tl <= t < tn alors e := t - tl ; S := ðext (S, e, x) ; tl := t ; tn := tl + ta(s)(sigma) ; envoyer (d, tn) au coordinateur; Fsi sinon erreur Fsi FigII.21b simulateur abstrait pour un modèle atomique Quand un simulateur reçoit un message (x, t), il vérifie si le temps global t est situé entre le temps du dernier événement tl et le temps du prochain événement tn, si ce n est pas le cas alors c est une erreur. Sinon (si tl t tn), le simulateur change la valeur du temps écoulé e et calcul son nouvel état avec la fonction de transition externe ðext. Ensuite, tl est mis à jour à t et un nouveau tn est déterminé. A la fin du calcul, le simulateur envoie un message (d, tn) au coordinateur. III.7.2. Simulateur abstrait pour un modèle couplé DEVS (coordinateur) On présente dans la figure FigII.22, un simulateur abstrait pour un modèle couplé MC : MC = <Ni, {Mi},{Ii},{Zij}, >. cas d un événement interne Si une entrée (*, t) reçue alors Si tl = tn alors Trouver les simulateurs imminents i (tel que tni=tn); Leur envoyer l entrée (*, t); Si une entrée y envoyée par i* est reçue alors Si y est utilisée dans le même niveau alors Envoyer (y, t) puis (*, t) à chaque influencé des i* par un couplage interne ; Attendre pour tous les simulateurs (composant i) leurs messages (d, tn) Fsi Si y est utilisée pour le coordinateur du prochain niveau alors Envoyer (y, t) au coordinateur du prochain niveau par un couplage de sortie externe. Fsi Attendre pour tous les messages (d, tn) des i* ; tl : = t ; tn : = le minimum des tn des composants ; Envoyer (d, tn ) au composant ; Fsi sinon erreur Fsi Fsi CONCEPTS DE SIMULATION a) FigII.22b Traitement de (x, t) par le coordinateur Comme le montre la figure FigII.22a, le coordinateur traite un message (*, t), il vérifie le temps de la simulation, puis envoie le message (*, t) aux composants imminents i*. Ces mêmes composants sont présumés posséder le temps tn minimal. Le coordinateur attend un message (d, tn) par les composants imminents. A ce moment, quand le coordinateur reçoit un message (y, t) envoyé par i*, il exécute sa tache. Si le message est utilisé dans le même niveau, le message (y, t) est envoyé comme un message (x, t) à chacun des influencés de i*, à l aide du couplage interne. Après, le coordinateur attend jusqu à ce que tous les influencés de i* renvoient leurs messages (d, tn). Si le message est utilisé en dehors du niveau courant, le message (y, t) est envoyé au coordinateur, du prochain plus haut niveau, par un couplage externe. Après, le Département d Informatique, Faculté des Sciences, Université d Oran 59

69 Chapitre II Concepts De Simulation Mokaddem coordinateur effectue la mis à jour du temps tl à t et détermine le nouveau tn et i*. Il envoie aussi un message (d, tn) à son coordinateur ou à son coordinateur racine à la fin. b) cas d un événement externe Si une entrée (x, t) reçue alors Si ( tl t tn ) alors Envoyer une entrée (x, t ) à tous les simulateurs influencés par i, par un couplage d entrée externe ; Attendre pour tous les simulateurs (composant i) leurs messages (d, tn) ; tl : = t ; tn : = le minimum des tn des composants ; Envoyer (d, tn) au coordinateur ; Sinon erreur ; Fsi Fsi Comme le montre la figure FigII.22b, le coordinateur traite un message (x, t), Il vérifie le temps de simulation en premier, et ensuite envoie le message (x, t) à tous les subordonnés par un couplage d entrée externe. Le coordinateur attend que tous les messages (d, tn) des composants soient remis. Après la réception de ces messages, le coordinateur met à jour la valeur de tl à t puis le minimum des tn des subordonnés est déterminé et (d, t) est envoyé à son coordinateur parent. III.7.3 Simulateur abstrait DEVS temps réel /* Boucle Principale */ Attente du signal jusqu'à ITO Si événement externe Alors When_ rcv_(x,t) ; Sinon Si temps de sortie interne Alors When_rcv_ (*,t) ; Fsi Fsi Fin concur-forever. FigII.23 Simulateur abstrait. a) Cas d événement interne CME : When_rcv_(*,t) : Si tn/min < t < tn/max alors y := (s) ; Envoyer (y,t) aux ports associés ; Le signaler ; S := int (s) ; tl := t ; tn := [tl+ta(s)/min, tl + ta(s)/max] ; A(s) ; Sinon erreur ; Fsi. CONCEPTS DE SIMULATION CME :main() : s = s0 /* initialiser */ tn := ta (s0) ; Concur-forever pour chaque modèle DEVS temps réel. FigII.23a Simulateur abstrait (événement interne). Département d Informatique, Faculté des Sciences, Université d Oran 60

70 Chapitre II Concepts De Simulation Mokaddem b) Cas d événement externe CME : When_rcv_(x,t) : Si tl < t < tn/max alors : e:= t- tl; S := ext (S,e,x) ; tl := t ; tn := [tl+ta(s)/min, tl +ta(s)/max] ; A(s) ; Sinon erreur ; Fsi FigII.23a Simulateur abstrait (événement externe). III.7.4 Sémantique de la programmation DEVS temps réel RTDS< M, {dtnimax}, {Pi}, > Où : M est l ensemble des modèles atomiques mi. Pour chaque modèle atomique i dans M on a : dtnimax = tnimax tli ; Pi est la priorité d exécution. Où Pi appartient à I+0, et la priorité la plus élevée est représentée par le plus petit des entiers. fonction de priorité dynamique M x{ dtnimax } {Pi} où mi avec le plus court dtnimax donne le Pi minimum. Algorithme de la programmation temps réel Les valeurs dtn dans le modèle DEVS temps réel varie durant l exécution. La priorité doit être donnée dynamiquement. Le modèle possédant le plus court dtn doit lui correspondre la priorité la plus élevé. Le modèle attendant des événements d entrée de l environnement doit être actif le plutôt possible (préemption) Caractéristiques : Mécanisme d exécution préemptif. Mécanisme d exécution de priorité dynamique. III.7.5 Architecture du Simulateur DEVS temps réel Dispositif Hardware Processus software Opérateur Hmain Interfaces modèles/environnements CONCEPTS DE SIMULATION Considération : Modèle DEVS temps réel Exécuter Multithread DEVS temps réel émulateur OS temps réel (Plate-forme Kernel) Multi-Tâche Couche OS d adaptation FigII.24 Architecture du Simulateur. Département d Informatique, Faculté des Sciences, Université d Oran 61

71 Chapitre II Concepts De Simulation Mokaddem III.7.6. Déroulement d exécution du simulateur DEVS temps réel Modèles DEVS temps réel Modèles atomiques et Modèles couplés Modèles atomiques DEVS temps réel Thread pour chaque modèle Le modèle possédant le plus petit dtn doit être activé en premier, tel que dtn change dynamiquement pour chaque modèle durant la simulation Exécution d un modèle thread basé sur la programmation temps réel FigII.25 Déroulement d'exécution. IV La Méthodologie de l Approximation Successive (MAS) Les méthodologies génie-logiciel proposent des paradigmes de cycle de vie pour le développement de programmes et des critères d évaluation de la progression [Svo 90]. En général, toutes ces méthodologies suivent les mêmes pas de base qui sont l identification des besoins, la conception, le développement, le test et la mise en œuvre. Les alternatives proposées diffèrent selon le temps de développement des produits, la gestion des risques et le rôle du prototypage. L évolution du modèle peut être étendue horizontalement et verticalement. En horizontal, on accroît le nombre de processus à représenter. En vertical, on accroît le niveau de détail de la représentation. En horizontal, la MAS ajoute de nouveau nœuds, incrémentalement, à la SES (System Entity Structure ) [Zei 90]. En vertical, on ajoute des branches (des nouvelles entités) à la SES. Pour contrôler l évolution de la complexité, la méthode peut également réduire l évolution par suppression des nœuds à la structure dont les entités attachées ne sont pas essentielles pour répondre aux besoins de la spécification. Besoin design maintenance développement Besoin design maintenance test mise en service / développement Besoin design maintenance test développement service / test CONCEPTS DE SIMULATION Le développement incrémental consiste en une série de cycle de développement, chacun se terminant avec un résultat utilisable. Dans la MAS, le développement incrémental est adapté au développement des modèles de domaine. Devant chaque cycle un modèle complet est développé, testé et validé, la méthode commence par le développement d un modèle initial du domaine qui est absolument compréhensif bien que limité en précision de son comportement. Plus exactement, plusieurs processus dans le modèle initial, peuvent être définis au plus bas niveau de la solution ou être totalement absents. service / FigII.26 processus incrémental de développement de modèles Département d Informatique, Faculté des Sciences, Université d Oran 62

72 Chapitre II Concepts De Simulation Mokaddem Tout compte fait, la MAS permet de distinguer quatre niveaux d abstraction : 1. Un modèle type du domaine pour guider et contraindre les formes possibles que puissent être prise par le SES. 2. Une des limitations des formalismes de DSS (Dynamique System Specification) : Spécification du système dynamique dans lequel seront exprimés les modèles atomiques et couplés. Le formalisme DEVS forme un premier cadre d expression de modèle selon le paradigme SEE/MB. Seulement, l inclusion de formalismes de modèles continus et la segmentation des formalismes symboliques stipulent une grande expansibilité [Zei 93]. 3. l environnement software de réalisation du processus de modélisation. 4. l architecture sur laquelle l environnement software est implémenté. Ici, on a intégré les niveaux hardware et réseau pour fournir une compréhension conceptuelle de la méthodologie. IV.1 Extensibilité hiérarchique Au fur à mesure que le modèle évolue dans l espace des modèles, l architecture initiale devrait être adaptable pour s accommoder à l évolution du modèle, sans exiger un changement radical vers une nouvelle plate-forme. Cette continuité tiendrait comme une relation de l exploration des alternatives de modèles dans le même rang de complexité et l accroissement de l évolution du modèle tendant à croître la complexité. Dans le cas de l exploration des alternatives, ceci nécessite que la plate-forme soit reconfigurable pour maintenir le niveau désiré de performance de la simulation. Dans le cas de l élaboration de la structure de modèle, ceci nécessite que la plate-forme soit flexible, c est à dire s accommoder aux ressources physiques complémentaires nécessaires à résoudre l accroissement de la complexité, ainsi par une relation continue entre le modèle et la plate-forme, on devait voir un chemin de développement de modèle sur plusieurs années supporté par une architecture évoluant continuellement sans changement radical dans l architecture de base. Modèles Architecture Au fur et à mesure que le modèle initial évolue dans l espace des modèles, l architecture initiale devrait être capable de s accommoder sans changement vers un autre système. Cette continuité devrait s exprimer comme une relation mixte, l exploitation des alternatives de modèles de même degré de complexité vers les espaces des reconfigurations, et l accroissement de la solution (progression) et sa complexité vers l extension architecturale. CONCEPTS DE SIMULATION On a vu comment la MAS peut guider la progression de modèle cohérent. Maintenant, on discute les moyens qui permettre à une simulation de co-evoluer continuellement et au fur à mesure. On appelle le fait qu un système qui croît de telle manière, une extensibilité hiérarchique. Afin d expliquer l approche, il convient de visualiser le processus de développement de modèle comme une trajectoire dans l espace des modèles. FigII.27 Mapping Continu : Modèles vers Architectures Etant donné ce schéma d évolution des modèles, on peut dire que l architecture est hiérarchiquement extensible si elle supporte une telle évolution des modèles de manière continue telle qu il est expliqué précédemment. C est plus spécifique que le concept conventionnel de l extensibilité pour les plates-formes parallèles ou une plate-forme est typiquement vu comme une évolution linéaire par ajout des autres processus. Seulement, dans ce contexte, il est plus naturel d exiger que la plate-forme s étende selon une Département d Informatique, Faculté des Sciences, Université d Oran 63

73 Chapitre II Concepts De Simulation Mokaddem manière basée sur une correspondance structurelle avec des compositions successives de modèle. Plus généralement, une telle extensibilité hiérarchique devrait offrir une approche effective et flexible pour satisfaire les besoins d hétérogénéité spécialement couplés au modèle temps réel. Une architecture réseau dont les nœuds acceptent l attachement de sous réseaux offre une architecture plausible pour implémenter l extensibilité hiérarchique. On commence par un réseau dans lequel à chaque nœud on peut joindre (attacher) le composant racine d un modèle. Pour assurer une nouvelle décomposition, ce nœud attaché au composant racine, est connecté à un sous réseau représentant les nouveaux composants. Evidement le nœud lui-même garde l interface originale avec ces pareils. Tandis que le nœud original génère la réponse aux entrées du composant de son modèle, il transmet maintenant ces entrées au cluster attaché et renvoie ces réponses aux autres composants de son niveau. IV.2 Exemple de DEVS Le simulateur abstrait DEVS donne déjà une logique adéquate pour réaliser l extensibilité hiérarchique. La figure FigII.28a illustre comment une décomposition initiale de modèle est translatée vers son simulateur abstrait correspondant. Cette structure abstraite est, en suite, réalisée par un réseau de stations, une pour chaque simulateur et une pour le coordinateur assurant la validité de toute la simulation. La figure FigII.28b illustre comment une décomposition d un composant de modèle est projetée vers une extension correspondante au simulateur abstrait et l expansion de réseau. Notez qu un bridge est employé pour lier le sous réseau au bon emplacement original figii.28. Comme possibilité intrigue, il est possible de laisser le simulateur original dans le réseau avec un relais qui accepte la plus rapide des deux réponses, du composant original ou du cluster représentant sa décomposition. Ceci aboutit à la représentation d une compétition de réponses automatiques et délibérées. Dans le cas de l amélioration de la solution, les composants nouvellement introduits nécessitent des ressources auxiliaires si on désire maintenir la performance. Dans le cas de l amélioration, ceci se fera pour exploiter le parallélisme dans le composant du modèle et nécessite le remplacement ou l ajout d un système de nouveaux processeurs. Dans les deux cas, l extensibilité hiérarchique concentre les ressources là où elles sont nécessaires, à savoir le cluster dédié à la nouvelle décomposition. V Conclusion Ce chapitre a résumé les outils de base pour mener ou implémenter une simulation. Le processus de modélisation tel que présenté en combinaison avec la MAS forme une très bonne base pour la conception de modèles performants. En faisant appel à des spécialistes de domaines tels que les systèmes experts ou en implémentant un modèle à blackboard, on peut aboutir par raffinement successif à des modèles répondant bien aux spécifications. CONCEPTS DE SIMULATION Cette approche a des avantages de poids naturel dont le niveau de décomposition qui peut être entrepris non seulement pour assure l amélioration de la solution du modèle, mais aussi pour améliorer la performance des applications temps réel et autres. Les modèles atomiques, qu ils soient issus de n importe quelle discipline ou métaphore, peuvent ainsi être intégrés aussi simplement grâce à la notion d extensibilité assurée par la MAS. Chaque métaphore peut présenter sa propre méthodologie de conception de modèles, il suffit de convertir ces derniers en modèles DEVS, pour assurer des modèles large scale. Le processus de simulation grâce aux simulateurs abstraits mène à bout toute simulation de modèles DEVS représentables. L effet d une simulation temps réel a donc un axe de recherche en pleine expansion. Département d Informatique, Faculté des Sciences, Université d Oran 64

74 Chapitre II Concepts De Simulation Mokaddem Depuis sa création, DEVS a connu plusieurs métamorphoses et davantage de modifications et d enrichissement mais il n a jamais fait l objet d une critique de fond qui remet en cause sa consistance et son efficacité. Ceci appelle à dire que désormais c est une référence incontournable pour toute étude de simulation. Mais toutefois, il demeure comme toute œuvre scientifique la cible de ses concurrents qui lui reprochent d être non adéquat aux systèmes nécessitant une représentation non hiérarchique. La forme DEVS discutée dans ce chapitre, offre une approche hiérarchique et modulaire de construction de modèles. Ceci étant, le formalisme DEVS renferme les concepts de modélisation et de la théorie des systèmes. Après l étude du processus incrémental de génération de modèles, on pourra conclure que DEVS est important non seulement pour les modèles discrets mais aussi il offre les principes essentiels pour implémenter des modèles DESS et DTSS. Cependant, la complexité des modèles nécessite une certaine assistance d experts pour mener à bien une simulation. Pour cela, il serait avantageux pour profiter des vraies capacités de DEVS de pouvoir développer des modèles réutilisables. Conservés dans des bases de données ou commercialisés, ces modèles enrichiront invraisemblablement la simulation. Songer donc à des environnements offrant une telle aptitude c est anticiper la recherche et en particulier la simulation. C :HCE HCE : DEC M :CM5 M :MP-2 M : MPP COORDINATOR C :HCE M:LAN Simulator S :CM-5 Simulator S :MP-2 Simulator S :MPP Simulator S :LAN b) Simulateur Abstrait SCI SCI S : MP-2 S : MPP SCI SCI S : LAN CONCEPTS DE SIMULATION a) Représentation SES SCI C : HCE S : CM5 c) Réseau SCI Ring FigII.28a Evolution hiérarchique I Département d Informatique, Faculté des Sciences, Université d Oran 65

75 Chapitre II Concepts De Simulation Mokaddem C :HCE HCE : DEC COORDINATOR C :HCE Ccccccccccccccccccc M :CM5 M :MP-2 M : MPP Simulator S :CM-5 M:LAN M :Clients Simulator S :MPP M : serveur Client1. Simulator S :MP-2 Simulator S :Serveur ClientN a) Représentation SES Simulator S :Client1 COORDINATOR C :LAN COORDINATOR C :LAN.. Simulator S :ClientN SCI SCI S : MP-2 S : MPP SCI BRIDGE SCI SCI S : CM5 SCI S : Serveur SCI BRIDGE SCI C : HCE SCI S : LAN SCI SCI S : Serveur SCI CONCEPTS DE SIMULATION b) Simulateur Abstrait.. S : ClientN c) Réseau SCI Ring FigII.28b Evolution hiérarchique II Département d Informatique, Faculté des Sciences, Université d Oran 66

76 Chapitre II Concepts De Simulation Mokaddem Bibliographie : [Ann, 99] F Annab, Simulation Distribuée, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1999 [Cha,79] K M. Chandy, J. Misra, Distributed Simulation: A case study in design and verification of distributed systems. IEEE Trans. On Software Eng. Vol 5 n 5, p ,1979 [Cha,81] K M. Chandy, J. Misra, Asynchronous distributed Simulation via a sequence of parallel computations. Comm. of ACM, Vol 24 n 11, Nov 1981 [Chr, 90] E R. Christensen, BP Zeigler, Distributed Discrete Event Simulation : Combining DEVS and Time Warp, Proc. The SCS Multiconference on distributed simulation, p , 1990 [Fek, 97] H Fekir, R Hebbar, Vers un environnement hétérogène et distribué de simulation, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1997 [Fis, 90] P A Fishwick, Towards and Integrated Approach to Simulation Model Engineering, Int. J. Gen. Sys. Research, Vol 17 N 1, p 1-20, 1990 [Fis02] Fishwick, P., XML Based Modeling and Simulation Using XML for Simulation Modeling, the Proceedings of the 34 conference on Winter Simulation; exploring new frontiers, pg , 2002 [Fuj, 99] Fujimoto, R.M., Parallel and Distribution Simulation Systems, Wiley, 1999 [Jef, 85] D R. Jefferson, Virtual Time, ACM Trans. Programming Language Systems, vol 7 n 3,p , 1985 [Khe,01] F Khebizat, K Sehaba, EasyDevs : un outil Blackboard pour une méthodologie intelligente d approximations successives des modèles DEVS, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2001 [Meg, 99] A. Meguedad, H. oucif, Human Performance Process & simulation, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1994 [Sil, 94] A Silberschartz, P B. Galvin, Principes des systemes d exploitation,, Addison-Wesley, France, S.A, 1994 [Sta, 05] William Stallings, Operating systems: Concepts & principles, 5th Edition, Prentice Hall,2005 [Zei, 93] B P. Zeigler, J. Kim, Extending the devs-scheme knowledge-based system environment for real-time event-based control, IEEE Trans. On Robotics and Automation,1993 CONCEPTS DE SIMULATION [Jha, 94] V. Jha, R I. Bargodia, a Unified Framework for conservative and optimistic distributed Simulation, Workshop on Par. And Dist. Sim., 1994 [Zei, 95] B P. Zeigler, M. Young, S. Vahie, Successive approximation in multifaceted modeling methodology: Human performance application, Int. J. of simulation, 1995 [Zei,00] Zeigler, B., Kim, T., Praehofer, H., Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems. Academic Press, 2000 Département d Informatique, Faculté des Sciences, Université d Oran 67

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113 Chapitre 5 La simulation web œuvre à résoudre les problèmes d interopérabilité entre les modèles mis en œuvre dans une simulation distribuée. La gestion d une simulation doit intégrer les dernières technologies du web telle que l architecture orientée service (SOA) où une simulation doit être exprimée comme un processus SOA. Ce chapitre décrit un environnement utilisant un serveur de recherche DEVSERVER et des serveurs de simulation DEVSORAN, DEVSMOSTA pour assurer une interopérabilité durant l exécution d une simulation à base de modèles DEVS. Ces serveurs utilisent des services web conformément à SOA pour effectuer les tâches requises respectivement. On décrira chaque serveur et on montrera comment cette approche couvre l interopérabilité et la communication entre différents serveurs appelés à piloter une simulation. Département d'informatique, Faculté des Sciences, Université d'oran DevServer DEVSERVER 113

114 DEVSERVER Chapitre V V.1 Mokaddem Introduction Dans [Aid, 03], on a ponctué sur un environnement collaboratif de simulation distribuée. Dans de tels environnements comme dans [Car, 05],[Hu, 05],[Weg, 02], les technologies de modélisation et de simulation peuvent être exploitées comme outil de développement d'une conception dirigée par les modèles. Le test et l'évaluation de modèles sont devenus une part intégrale du processus de modélisation. On simule au fur et à mesure que l'on modélise. L'intégration dans une simulation sur le web de telles technologies s'avère inévitable mais pose cependant des problèmes complexes quant à sa mise en œuvre. Le développement de tels environnements doit permettre une conformité entre les systèmes complexes récents et leur modélisation pour exprimer un haut niveau d'interopérabilité. Or ces systèmes ne sont pas jusqu'à présent exprimés sous une forme aménageable pour permettre de tels tests et évaluations. DevServer Dans [Gue, 02] on a montré le besoin de tester un nouveau paradigme qui pourrait apporter des réponses à plusieurs défis. Le paradigme J2EE en simulation permet d'exprimer une simulation sur le web en une structure multi tiers. Le premier tiers constitue les pièces individuelles d'un système, par conséquent les modèles simples pouvant spécifier un système selon le formalisme DEVS. Ce niveau ne pose généralement pas de problème, étant donné que DEVS a atteint une considération importante en matière de spécification de systèmes. Les modèles déjà validés se trouveront dans ce tiers, sous forme d'éléments de base de données gérés par un serveur de bases de données. Le deuxième tiers, pouvant être vu comme un système de systèmes, renferme la logique applicative de la simulation. A ce niveau l'interopérabilité des modèles devient critique, et nécessite donc une réflexion profonde. Le troisième tiers est la coalition des simulations disparates, donc la représentation dynamique des résultats de la coopération des différentes simulations, coté client. A ce stade la simulation est devenue comme une application multi tiers répondant aux normes J2EE. Les travaux avancés sur J2EE ont permis de mettre l'accent sur la répartition d'une simulation sue le web. Une base de données Oracle permet de stocker les modèles validés, une suite de Servlets gère la simulation et enfin des JSP aident à visualiser la simulation. Un serveur de recherche aide à localiser les modèles dispersés sur différents serveurs de simulation. L'idée des serveurs de simulation est devenue attrayante. Les environnements DEVS tels que DEVSJAVA et DEVSC++ et bien d'autres [1] sont essentiellement des implémentations orientées objets, et expriment l'exécution de modèles dans un langage de représentation objet. DEVS, étant une plateforme indépendante, adhère à un protocole qui permet aux modèles exprimés en C++ d'être facilement translatés en Java par exemple [Zei, 00]. DEVSJAVA emploie des librairies continuellement mises à jour et produit des évaluations graphiques conformes. DEVSJAVA a connu plusieurs extensions lui permettant actuellement de supporter différents middlewares tels que CORBA, HLA, Java RMI, SOAP et peut être facilement interfacé avec d'autres outils de modélisation et de simulation [Hu, 05],[1],[Cho, 01],[Wai, 01],[Zha, 05]. Les opérations DEVS sur un middleware tel que SOAP permettent à DEVS de participer totalement dans des environnements SOA. Parmi de récents résultats, DEVS peut supporter la continuité de modèles à travers un développement de simulation et un cycle de test de modèle [Hu, 05]. Ceci insinue que le mapping des spécifications des systèmes de haut niveau dans le formalisme DEVS de bas niveau permet à de telles spécifications d être conduites à travers des tests sur des environnements virtuels de simulation avant d être facilement intégrer pour opérer dans un environnement réel. [mes, 06] tente de remplacer les modèles DEVS (atomiques, couplés) par des agents mobiles JavAct [Arc, 05],[Arc, 03]. DEVSIMUL accède à la base de données, extrait les modèles et les soumet à des agents mobiles JavAct qui les prennent en charge. La communication entre modèles est couverte par la communication des agents inhérente à la plateforme JavAct. DEVSJAVA se limite à son langage d'implémentation par conséquent Java. En d'autres termes, le modèle et son simulateur sont exprimés dans le même langage. Un modèle qui hérite d'un autre doit être écrit dans le même langage, il est assez difficile de traduire un modèle d'un langage à un autre, en Département d'informatique, Faculté des Sciences, Université d'oran 114

115 DEVSERVER Chapitre V Mokaddem plus de la perte de temps et de tout ce qui en suit. La réutilisabilité des modèles devient une source capitale. La motivation de ce travail réside dans le besoin de réutiliser ces modèles et permettre une interopérabilité durant la simulation afin de rendre le simulateur transparent pendant toute l'exécution du modèle. [Che, 07] comme dans [Sau, 07] fait tendre DEVSERVER vers une architecture SOA. [Sau, 07] propose un langage de modélisation DEVSML (DEVS Modeling Language) [Sau, 07bis] construit autour de XML [3] pour couvrir l'implémentation transparente du simulateur. Egalement, les modèles doivent être assemblés dans des librairies et à travers des services web, on tente leur simulation. L idée principale réside dans l exécution du simulateur en tant que service web. Le développement d un pareil Framework aidera à mettre en œuvre la solution des systèmes et des simulations large scale, et garantit l interopérabilité entre les différents sous systèmes interconnectés qui ne sont autres que des modèles DEVS déjà validés. [Sau, 07] exclut mais soutient l usage des serveurs de simulation. Il focalise sur la description générale de l approche et ponctue surtout sur le client qui communique avec le serveur. Le modèle à simuler est décrit grâce à DEVSML par le client, on doit ensuite sélectionner les serveurs qui pourront participer à cette simulation et grâce à DEVSML on procède à l upload des modèles vers les serveurs respectifs ensuite un coordinateur gère la simulation. Contrairement à [Sau, 07], notre approche fait résider les modèles directement dans leurs serveurs respectifs. Le choix des serveurs à mettre en œuvre est obtenu suite à une recherche réalisée par le serveur de recherche de modèles qui agit comme un annuaire où les serveurs de simulation répertorient leurs modèles respectifs dans une base de données. DevServer [Bad, 04] propose un serveur de simulation à base de RMI/IIOP où la simulation se déroule coté serveur mais les résultats via RMI sont transmis au fur et à mesure vers le client. Une applet de style DEVSJAVA permet cette visualisation. Une application web (JSP, Servlet, EJB) permet de maintenir la mise à jour de la base de données des modèles. De nouveaux modèles peuvent, incessamment, être ajoutés à la base. Ces opérations, évidemment, sont distantes et intègrent les dernières technologies du web dans ce sens. Ce chapitre est organisé comme suit. La prochaine section rapporte les derniers résultats, en relation, des travaux de la simulation distribuée et de la standardisation de DEVS et explicite la séquence des travaux jusqu à aboutir à l idée d intégrer SOA en simulation. La section 3 relève les technologies sousjacentes nécessaires. La section 4 décrit le serveur de recherche DEVSERVER. La section 5 décrit les serveurs de simulation DEVSORAN et DEVSMOSTA. La section 6 décrit la globalité du système et montre comment se déroule une simulation à partir d un poste client. Enfin la section 7 est une conclusion avec certaines perspectives en vue de travaux futurs. V.2 Travaux en relation Il y a eu d énormes efforts dans le contexte de la simulation distribuée [Fek, 97],[Ann, 98], [Meg, 99],[Khe, 01] utilisant le formalisme DEVS parallèle. L effet de causalité [Zei, 00] et le problème de synchronisation [Fuj, 99] ont été traités par des solutions comme : la restriction de l horloge globale de simulation jusqu à ce que tous les modèles soient en synchronisation, ou l usage du rollback de la simulation du modèle victime de l effet de causalité. Notre approche ne ponctue pas sur ces problèmes vus leur appartenance à un domaine différent. Notre travail propose que le moteur de simulation tourne exclusivement sur le serveur. Par conséquent, le coordinateur et les simulateurs abstraits seront toujours en synchronisation. La plupart des simulations centrées sur le web sont composées des éléments suivants : Département d'informatique, Faculté des Sciences, Université d'oran 115

116 Chapitre V DEVSERVER Mokaddem 1. L application : le haut niveau du modèle couplé où il y a la visualisation des résultats de simulation, on appelle souvent ce niveau le niveau présentation conformément au paradigme J2EE. 2. Le Partiteur : l élément qui gère le partitionnement du modèle en sous modèles distincts et couplés exécutés sur des nœuds distincts du réseau. 3. Le Déployeur : l élément qui gère le déploiement du modèle couplé et maintient le couplage, les sous modèles sont déployés selon la politique instaurée par ce module. 4. L Initialiseur : l élément qui initialise le modèle et le rend prêt à une simulation. 5. Le Simulateur : l élément qui coordonne ses activités avec le root coordinateur en vue de réussir l exécution de la simulation. Dans certains cas, le Partiteur et le Deployeur peuvent être confondus pour ne faire qu un module ou être carrément absents. A cause des modèles déjà développés sous DEVSJAVA et qui feront notre banc de test, on utilisera le même langage pour l implémentation du moteur de simulation à base du DEVS parallèle. Le Simulateur et le modèle sont donc dans le même langage. L effort déployé dans se travail focalise plutôt sur l interopérabilité au niveau Simulateur et Application tout en gardant transparent le Simulateur. Les services web intégrés usent de XML et SOAP, par leur nature, pour maintenir la communication et l invocation de méthode à distance. Le middleware de communication est donc sous jacent à SOAP et par conséquent aux services web. Il serait plutôt intéressant de permettre au client de coder son modèle dans son/ses langages préféré(s) d une manière hétérogène et laisser la SOA gérer la communication, le couplage et la simulation elle-même. La tâche du client est donc restreinte uniquement à son codage de ses modèles indifféremment de toute contrainte. Le client ne doit pas avoir besoin d apprendre une nouvelle syntaxe DEVS ni un nouveau langage pour coder ses modèles à part la version DEVS standard [1]. DevServer Le Simulateur a pratiquement toujours la même conception et dérive directement du DEVS parallèle [Zei, 00]. Cependant, l implémentation des quatre autres éléments diffère d une configuration à une autre. DEVS/Grid [Seo, 04] utilise ces quatre éléments. DEVS/P2P [Che, 04] implémente l étape 2 en utilisant un partitionnement hiérarchique basé sur le coût. DEVS/RMI [Zha, 05] a un moteur configuré intégrant les fonctionnalités 1,2 et 3. DEVS/Cluster [Kim, 04] est un simulateur distribué multithread qui repose sur CORBA et dont le but est le développement de moteur de simulation puissant. [Bad, 04] utilise RMI pour faire communiquer le client et le serveur où s exécute la simulation du modèle. Cette aptitude de permettre au client d intégrer, durant sa phase de modélisation, des modèles existants stockés dans des bases de données accessibles via des serveurs dédiés, apporte beaucoup de bénéfice à la communauté industrielle et au client lui-même. Les modèles exposés sur le web ont déjà été validés et réalisent réellement la réutilisabilité de modèles tant attendue en simulation. Le paradigme de réutilisabilité [Che, 07] a fait l objet d inquiétude durant les dernières années. [Gue, 02] a mis au point le serveur de recherche de modèles sur le web dans sa première version, cependant la simulation se déroulait totalement du coté client. En réalité, on souhaitait voir ce qui se passe lors de l usage de J2EE en simulation. On a séparé une application de simulation en 3 niveaux : présentation, logique métier, et modèles. On a placé les modèles dans une base de données (oracle), chaque modèle était décrit par : nom, nombre d inports, nombre d outports, l auteur, la date de dernière modification, une description décrivant ce que fait le modèle. Cette base de données est accessible uniquement par le serveur de simulation via des EJB 2.0 permettant l ajout, la suppression et la mise à jour des modèles. Département d'informatique, Faculté des Sciences, Université d'oran 116

117 DEVSERVER Chapitre V Mokaddem Une deuxième base de données est utilisée pour faciliter la recherche des modèles précédents. Chaque modèle, cette fois, est décrit par les mêmes champs précédents en plus de l adresse IP du serveur où il se trouve. Le processus de recherche était décrit comme suit figure 1 : Coupled Models 1. Search a model Models Description DB HTTP Search SERVER Internet Atomic Models 2. Model found on server Figure 1 DEVS Search Server Une fois le modèle trouvé, identifié par l adresse IP du serveur où il se trouve, on procède à son téléchargement vers le client où se déroulera la simulation. A ce stade, le modèle était stocké comme une classe (procédure) java dans une base de données oracle. Le serveur de simulation était doté d EJB pour rechercher la classe sur le serveur et la télécharger vers le client. DevServer HTTP [Aid, 03] a traduit les modèles DEVS en fichiers jar avant de les stocker sur la base de données. Elle a remplacé les procédures stockées en Blob oracle. La recherche se déroule de la même façon, sauf que le fichier retourné est extrait de la table sous un champ Blob pour être envoyé au client. Une tentative non réussie pour exécuter le modèle du coté serveur par usage des EJB a posé le problème de communication entre le client et le serveur durant le processus de simulation. Figure 2. Menu du serveur de simulation Figure 3. Serveur de recherche Département d'informatique, Faculté des Sciences, Université d'oran 117

118 DEVSERVER Chapitre V Mokaddem Le rôle des EJB est de chercher le modèle dans la base de données du serveur de simulation, vu que le modèle est un fichier Jar, Une fois le modèle trouvé, identifié par l adresse IP du serveur où il se trouve, on procède à son téléchargement vers le client où se déroulera la simulation. Figure 5. Résultat de la recherche [Bad, 04] a utilisé RMI/IIOP pour permettre la communication entre le client et le serveur. Un serveur JRUN a été utilisé pour gérer les modèles que ça soit pendant la recherche ou pendant la simulation. Le processus de recherche était transformé pour devenir multicritères et multi langage. DEV SERVER (figure 3) est né ainsi. DEVSORAN (figure 2), le serveur de simulation tourne également sur JRUN et permet d extraire les modèles et de lancer leur simulation du côté serveur par application de RMI/IIOP pour communiquer entre l interface cliente et le serveur. Les principes DEVSJAVA sont jusqu à présent bien respectés. Une phase d authentification est également obligatoire, le client doit être inscrit sur le serveur de simulation pour pouvoir payer sa session de simulation. Dans le serveur de simulation, doit tourner en permanence le programme DEVS RMI SERVER (figure 7) en attente des requêtes en provenance du client. DEVS/RMI a transformé DEVSJAVA en une application distribuée s exécutant sur le serveur et affichant ses résultats sur le browser du client (figure 6). Figure 6 DEVS RMI CLIENT DevServer Figure 4. Formulaire de recherche Figure 7 DEVS RMI SERVER Les informations systèmes ont été retenues avec l adresse IP pour des mesures de sécurité. Ces informations seront fournies à un serveur de sécurité spécialisé dans la détection d intrusion (IDS) en vue d agir en conséquence. [Mes, 06] a repris le même principe adopté par [Bad, 04] met réalise la communication entre modèles via un framework expérimental JavAct. Le processus de recherche de modèle est toujours le même mais le serveur de simulation DEVSORAN est remplacé par DEVSIMUL figure 8. Département d'informatique, Faculté des Sciences, Université d'oran 118

119 DEVSERVER Chapitre V Mokaddem JSF APACHE HTTP SERVER Web Client JAVACT AGENTS GENERATOR EJB 3.0 J2EE JRun Application Server DEVSIMUL JAVACT AGENTS DataBase Server 1 DataBase Server 2 DataBase RootServer Dans cette architecture orientée agents, les simulateurs de modèles et les coordinateurs sont des agents mobiles sur le réseau. Les modèles atomiques constituant un même modèle couplé doivent migrer vers le coordinateur pour simplifier la communication inhérente au couplage. Si le modèle couplé est lui-même un sous modèle d un autre modèle couplé, son coordinateur doit à ce moment migrer vers le coordinateur du modèle maitre. La figure 9 montre cette migration. SERVER A ATOMIC MODEL A SERVER B ATOMIC MODEL B ATOMIC MODEL A SERVER C COORDINATOR C ATOMIC MODEL B DevServer Figure 8 DEVSIMUL SERVER D COORDINATOR D SERVER E COORDINATOR C Figure 9. Migration des agents DEVSIMUL La figure 10 exprime le résultat d'une recherche, la figure 11 est une simulation obtenue grâce à DEVSIMUL. Département d'informatique, Faculté des Sciences, Université d'oran 119

120 DEVSERVER Chapitre V Figure 10. Recherche sur DEVSIMUL Mokaddem Figure 11. Une Simulation sur DEVSIMUL DevServer [Sau,07] fait le lien entre un langage DEVSML et une plateforme SOADEVS (figure 11). DEVSML est une nouvelle façon d'exprimer les modèles DEVS en XML. Il est construit autour de JAVAML qui est entre autre une implémentation de XML en Java, par conséquent la puissance de DEVSML dépend de JAVAML quant à la spécification de modèles DEVS. Les modèles DEVSML sont translatables en java et vice versa. On remarque que déjà il y a interopérabilité entre modèles en java et en DEVSML. Le client exprime ses modèles et fait usage de SOADEVS pour les simuler. Figure 12. Intégration de DEVSML et SOADEVS Les modèles peuvent être créés en langage naturel NLP (Natural Language Processing), en java ou en BPMN/BPEL (étape 1 et 2 de la figure 11). Les travaux pour exprimer les modèles en NLP et BPMN se déroulent actuellement au centre 'ACIMS et seront reportés ultérieurement. A l'étape 3, on est toujours du côté client, les modèles sont sous forme DEVSJAVA. A l'étape 4, les modèles java sont transformés en DEVSML. En 5, on fait appel au serveur DEVSML pour procéder à l'upload des modèles vers les serveurs sur le web. Finalement, la simulation distante est conduite par différents moteurs de simulation localisés sur le web (étape 6). SOADEVS est en deux niveaux. Le 1ier niveau supervise le 2ème et sert de coordination pour le client. Le bas niveau est le service réel de simulation. Il exécute le protocole DEVS de simulation comme service. Ce niveau est transparent au client qui ne peut communiquer qu'avec le haut niveau. Le haut niveau a 3 principaux services. Il procède à l'upload du modèle, sa compilation et à son exécution. Le bas niveau procède à l'initialisation du simulateur i, l'exécution des fonctions de transition interne et externe respectivement du simulateur i, gère, si conflit il y a, l'appel de la fonction de conflit du simulateur i, exécute la fonction λ, injecte des messages au simulateur i, Département d'informatique, Faculté des Sciences, Université d'oran 120

121 DEVSERVER Chapitre V Mokaddem obtient le temps du prochain événement et l'avancement du temps du simulateur i et enfin génère le log de tous les simulateurs pour finaliser le service. V.3 Technologies sous-jacentes Cette section prépare l'ensemble des outils utiles à mettre en œuvre une simulation à base de SOA. Ces technologies renferment, particulièrement, DEVS, la SOA en simulation, SOA Suite d'oracle, et JDeveloper. V.3.1 DEVS DEVS consiste de modèles, de simulateurs et de frame expérimental. On focalise sur deux types de modèles, les modèles atomiques et les modèles couplés. Le modèle atomique est l'entité irréductible que DEVS peut spécifier. Cependant le modèle couplé est une agrégation/composition de plusieurs, au moins, 2 modèles atomiques connectés par un couplage explicite. Un modèle couplé peut, à son tour, faire part d'un autre modèle couplé plus large permettant ainsi une structuration hiérarchique de modèles. Des descriptions détaillées sur le simulateur, le frame expérimental se trouvent déjà dans le chapitre III et [Zei, 00]. SOA en Simulation L environnement de mise en œuvre de simulation et son administration évolue rapidement. Dans ce contexte, le rôle du système de simulation est de supporter la flexibilité et la dynamicité des modèles mis en jeu dans une simulation. Le système doit valoriser le flux de données circulant entre différents modèles, tout en intégrant de nouvelles technologies permettant de réduire les coûts en temps et en synchronisation des évènements qui occurrent dans le système. C est à cet objectif que tendent à répondre aujourd hui les Architectures Orientées Services (SOA). Les environnements de simulation font face à d importants enjeux de croissance, d amélioration de la productivité et de réduction du délai de mise sur le marché (time-to-market) de leurs modèles. Les processus métiers doivent être plus flexibles pour supporter les évolutions stratégiques des modèles, l'exécution de leur simulation ou agir à titre de services composites avec des partenaires en vue de fusions /acquisitions de modèles bien appropriés. DevServer V.3.2 Les environnements de simulation les plus florissants du marché doivent s'attaquer à la complexité de leurs environnements applicatifs et informatiques par le biais de l'architecture orientée services (SOA), conçue pour simplifier le développement de services de gestion modulaires faciles à intégrer et à réutiliser, créant ainsi une infrastructure informatique véritablement flexible et adaptable. V Définition de SOA : L'architecture orientée services (SOA Service Oriented Architecture) permet de créer toute une nouvelle génération d'applications de simulation dynamiques (parfois nommées simulations composites). Ces applications offrent aux utilisateurs des informations plus précises et plus complètes sur les modèles de simulation ainsi qu'une meilleure connaissance de la façon dont ces modèles seront simulés, mais aussi la possibilité d'accéder à ces informations en utilisant la forme et la présentation les mieux adaptées, que ce soit par le biais du Web, d'un client riche ou d'un dispositif mobile. Les exécutions dynamiques de simulation permettent à ces environnements d'améliorer et d'automatiser les tâches manuelles, d'obtenir une vue cohérente des relations avec les clients exécutant une simulation à distance et les partenaires exposant leurs modèles sur le web, et d'orchestrer les processus de simulation métiers conformes aux exigences internes de leurs modèles et aux réglementations extérieures quant à la circulation du flux de données entre ces modèles. Ces environnements de simulation bénéficient ainsi d'une souplesse leur permettant d'être plus performants sur le marché. Département d'informatique, Faculté des Sciences, Université d'oran 121

122 DEVSERVER Chapitre V Mokaddem L'objectif d'une SOA est donc principalement de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma d'interaction entre ces services. L'idée sous-jacente est de cesser de construire la vie d'une simulation autour d'applications classiques mais plutôt faire en sorte de construire une architecture logicielle globale décomposée en services correspondant aux processus métiers gérant cette simulation. SOA n est pas une nouvelle entité qu une simulation doit adopter. Elle ne nécessite pas le remplacement des architectures en place. Une SOA est un moyen étendu de réutiliser les modèles existants et de les transformer en des services plus agiles. La base d une SOA repose sur des services répondant, notamment, aux critères suivants [Che, 07] : Faiblement couplés : Distribués : Les modèles et les services qui composent une simulation peuvent être physiquement répartis sur différents systèmes dans l environnement de simulation, mais aussi au-delà. Ils permettent une approche distribuée, à l opposé des systèmes traditionnels centralisés. Là où l environnement de simulation devait maintenir certaines fonctions et données comme les tarifs des fournisseurs de modèles, il pourra interroger directement, via son applicatif, le service du fournisseur de modèles sans se préoccuper de sa mise à jour. DevServer Les applications traditionnelles incluent dans leur code les données métiers d'une simulation. Elles sont complètement liées aux systèmes pour lesquelles elles ont été conçues. Toute demande de modification, qu elle concerne l accès aux modèles, les règles de gestion de leur simulation ou celles de présentation des résultats de la simulation, nécessitera une refonte du code entraînant coûts, délais, compétences spécifiques et surtout manque de réactivité et risque de déstabilisation des applications. Un faible couplage permet une scission des aspects métiers du code qui permettra une simple reconfiguration des processus quand les fonctions métiers évoluent. Invocables et publiables : Les services doivent être invocables et publiables quels que soient les systèmes utilisés. Orientés métier : Les services permettent de gérer les simulations avec une approche fonctionnelle, par l intermédiaire de processus métiers intégrés à l architecture, permettant de piloter les simulations sans développement conséquent. V Les bénéfices de SOA : La SOA est l aboutissement de plusieurs années de corrections des erreurs rencontrées dans les applications. Ce n est pas, à proprement parler, une révolution technologique. Elle permet de créer de manière incrémentale de nouvelles fonctions, de les combiner aux services existants pour créer des applications composites. L expérience montre que cela minimise les risques car elle capitalise sur les fonctions existantes [Che, 07]. La mise en œuvre d'une approche SOA au sein d'une infrastructure d'un environnement de simulation procure des avantages considérables en permettant, au final, au développeur de tels environnements de consacrer davantage de ressources et d'argent à l'innovation ainsi qu'à l'offre de nouveaux modèles et de services de leur gestion : Département d'informatique, Faculté des Sciences, Université d'oran 122

123 DEVSERVER Chapitre V Mokaddem Réduction des coûts de développement : Les services SOA sont aisément réutilisables et peuvent être rapidement assemblés, tels des composants, sous la forme de nouvelles simulations composites sans nécessiter aucune programmation manuelle coûteuse. Allégement des coûts de maintenance : Les modèles et services réutilisables diminuent le nombre et la complexité interne des services de développement, réduisant ainsi la charge de travail de maintenance requise pour l'intégralité de la gamme de modèles et de services. Optimisation de la qualité des services : La technologie SOA favorise considérablement la réutilisation accrue des modèles et des services, laquelle se traduit par une amélioration de la fiabilité et de la qualité des services par le biais de multiples cycles de test effectués sur les modèles par différents spécialistes en simulation. Les services normalisés fonctionnent parfaitement les uns avec les autres, garantissant ainsi la connexion rapide et aisée de simulations disparates. Minimisation des risques : Des services moins nombreux et réutilisables contribuent à améliorer le contrôle des stratégies de gouvernance de simulation et des tâches de modélisation et à diminuer les risques globaux de nonconformité des opérations. DevServer Diminution des coûts d'intégration : Modification en temps réel d'une simulation : Une simulation peut, en effet être, modifiée sans intervenir sur les processus métiers eux-mêmes. Le travail du développeur est simplifié et plus sécurisé. Préservation de l'avenir par le découplage : Les simulations sont conçues indépendamment de l infrastructure matérielle. Lorsque celle-ci évolue, le faible couplage entre hardware, modèles et processus de simulation métiers limite les risques liés aux modifications des fonctions et permet notamment la compatibilité avec toute interface actuelle et future : Linux, Windows, Internet, téléphone mobile L indépendance de l emplacement physique du modèle et de son service de simulation permet également d assurer performance, scalabilité et haute disponibilité des simulations. Possible réactivité grâce à l affranchissement des contraintes techniques : L orientation métiers donne aux responsables fonctionnels la capacité de faire évoluer les simulations sur la base des demandes et contraintes métiers, sans préoccupations technologiques. Développement : Le degré d implication des concepteurs fonctionnels est accru par leur maîtrise des processus de modélisation et de simulation métiers. Département d'informatique, Faculté des Sciences, Université d'oran 123

124 DEVSERVER Chapitre V Mokaddem Les développeurs se concentrent sur des fonctions élémentaires sans se préoccuper de l infrastructure d accueil. Ils sont plus efficaces et offrent une meilleure valeur ajoutée. Le développement collaboratif est également plus simple. Le travail sur plusieurs simulations simultanées et l affectation des ressources à des fonctions plus élémentaires facilitent le travail du chef de projet. Les tests unitaires sont facilités et la détection d erreurs au plus tôt dans le processus de développement de modèles limite les risques. La réutilisation des modèles ouvre naturellement les services à une consommation par des applications externes. L indépendance des fonctions par rapport aux processus métiers et à l architecture d accueil, préserve l évolutivité, la flexibilité et l intégration. Vers plus de sécurité : Le système de sécurité est basé au niveau du service. C est le point central qui permet de renforcer la sécurité (multi niveaux d authentification, authentification forte, ). A toute architecture correspond une méthodologie miroir et, réciproquement, toute méthodologie aboutit à une architecture [Che, 07], A la SOA correspond une méthodologie de développement orientée services (Service-Oriented Development of Applications ou SODA). SOA est une collection de services distribués au travers d'un réseau tel qu'internet. Comme les processus métiers, les présentations (écrans), les logiques applicatives et les modèles sont séparés dans des couches distinctes et faiblement couplées, il faut des outils complets de gestion de chacune de ces composantes Les processus métiers: Exécution de la simulation (Simulation Process Management) Les présentations: Visualisation de la simulation (Réalisation d interfaces utilisateurs) Les logiques applicatives (Réutilisation de modèles) L accès aux modèles. DevServer V Fonctionnement d une SOA : Principe de fonctionnement : L architecture des services Web a trois rôles distincts : un fournisseur de modèles : Le fournisseur crée le service Web intégrant le modèle et le met à la disposition des clients qui souhaitent l utiliser. un demandeur (consommateur) : Un demandeur est une application cliente (ou un poste utilisateur Windows ou web ) qui utilise le service Web. Le service Web demandé peut également être client d autres services Web. un agent (un référentiel) : L agent, qui peut être par exemple un registre de service, permet au fournisseur et au demandeur d un service Web de communiquer. Les trois rôles de fournisseur, de demandeur et d agent interagissent les uns avec les autres par l intermédiaire des opérations de publication, de recherche et de liaison. Le fournisseur informe l agent de l existence du service Web en utilisant l interface de publication de cet agent pour permettre aux Département d'informatique, Faculté des Sciences, Université d'oran 124

125 DEVSERVER Chapitre V Mokaddem clients d accéder au service. Les Informations publiées décrivent le service et spécifient son emplacement. Le Demandeur consulte l agent pour localiser un service Web publié. Grâce aux informations sur le service Web obtenues par l agent, le demandeur peut lier, ou appeler, le service Web. V Description de l architecture SOA en simulation Une SOA consiste essentiellement en une collection de services qui s'interagissent et communiquent entre eux via un SSB (Simulation Service Bus) et orchestré par un logiciel de SPM (Simulation Process Management), considérée comme étant des briques spécifiques fonctionnelles adaptées aux besoins des développeurs. SOA se base sur des standards d interopérabilité tels que les Web Services, les EJB (Enterprise Java Beans), CORBA ou tout autre moyen de communiquer supporté par le SSB choisi. Ce dernier est un intergiciel qui permet l'intégration de simulations utilisant des plateformes, des modèles des normes de messagerie différentes. Les services que les SSB devraient fournir sont notamment le transport, le routage dépendant du couplage, la qualité du service, la médiatisation, la gestion des événements, la composition et la décomposition, la gestion du système, la sécurité, les protocoles de données et la gestion des politiques de simulation. Ce bus peut être très basique ou plus complexe. Il est piloté par un logiciel de SPM (Simulation Process Management) conscient des problématiques métiers de gouvernance d une simulation. L SSB peut alors être décomposé en 3 parties plus ou moins développées selon les besoins et les capacités de celui-ci. La couche transport Elle peut se limiter à une simple couche HTTP/SOAP, mais peut aussi être plus développée et être capable d invoquer des fonctions J2EE,.NET ou encore CORBA, mais aussi réaliser des requêtes dans une base de données. DevServer V Le bus SSB : La couche conversion Elle a pour but de permettre le changement d enveloppe de transport. Elle devra changer le support du message (transformer du.net en EJB par exemple) sans changer la nature de celui-ci, l intégralité des informations partant d un modèle A vont à un modèle B sans aucune modification si ce n est le contenant. La couche Maping des données C est à ce niveau qu un SSB peut définir les règles de transformations des données métiers pour rendre les connecteurs compatibles entre eux dans le cas ou ils ne sont pas câblables directement. V Le SPM Utilisés ensemble, la SOA et le SPM permettent à une simulation d obtenir de la flexibilité en exécutant des processus métier (SPM). La SOA gère la connexion entre la conception des processus et leur implémentation opérationnelle. La simulation utilise SPM pour exécuter ses processus tandis que la SOA permet d implémenter ces processus et leur évolution à une vitesse cohérente avec la cadence des demandes d évolution nécessaires à la simulation. V Le service Département d'informatique, Faculté des Sciences, Université d'oran 125

126 DEVSERVER Chapitre V Mokaddem Un service est dédié à une fonction simple et n est pas alloué à un utilisateur en particulier mais à une multitude de clients qui le partagent. Il est défini par une interface qui peut être invoquée par un autre service ou une application. Il ne maintient pas une conversation avec le client. L aspect modèle est invisible pour le client. Au-delà, un service invoqué ne connaît pas les requêtes exécutées précédemment ni celles qui le seront en aval. Un service a seulement besoin des paramètres qu il requiert en entrée. Il s exécute ensuite en une seule phase car il ne stocke rien d une invocation à une autre. Cette organisation rend les systèmes capables de supporter des charges élevées. Le fonctionnement sous forme de services simples, sans mode conversationnel, facilite le Load Balancing de l exécution et la surveillance des erreurs. Il devient plus facile d augmenter la puissance de l'environnement de simulation par l augmentation du nombre d instances ou de serveurs. Le service subit trois phases : La description du service Elle consiste à décrire les paramètres d'entrée du service, le format et le type des données retournées. Le principal format de description de services est WSDL[4] (Web Services Description Language), normalisé par le W3C. La publication et la découverte des services La publication consiste à publier dans un registre les services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal Description Discovery and integration), normalisé par l'oasis. L'invocation DevServer Elle représente la connexion et l'interaction de la simulation avec le service gérant le modèle. Le principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access Protocol). V Le cycle de vie d'une SOA en Simulation Les principaux acteurs d'un environnement de simulation sont ses modèles, ses systèmes existants, ses applications métier, ses progiciels et ses partenaires commerciaux. Chacune de ces ressources constitue un fournisseur de services chargé de produire plusieurs résultats très spécifiques, tels que des inventaires ou des données client. L'orientation services relie ces sources d'informations hétérogènes et autonomes, créant ainsi un pont entre une gamme étendue de systèmes d'exploitation, de technologies et de protocoles de communication. Pour cela, l'orientation services utilise un processus itératif qui consiste à créer, une phase d'exposition de modèles, sous forme de nouveaux services, à regrouper, une phase de composition de modèles, ces services en simulations composites plus globales et à rendre les résultats accessibles aux utilisateurs. Figure 13. Cycle de vie d une SOA Département d'informatique, Faculté des Sciences, Université d'oran 126

127 DEVSERVER Chapitre V Mokaddem V Exposition : La phase d'exposition de l'approche SOA est consacrée aux services devant être créés à partir des simulations et données sous-jacentes. La création de modèles peut être effectuée de manière précise (un seul modèle est associé à un seul processus de simulation métier) ou globale (plusieurs modèles effectuent un ensemble de fonctions connexes). La phase d'exposition détermine également comment les services doivent être mis en œuvre. Les fonctionnalités des ressources informatiques sous-jacentes peuvent être accessibles en mode natif si elles sont capables d'interpréter les services Web ou peuvent être accessibles en tant que services Web par le biais d'un adaptateur. V Composition : V Consommation : Lorsqu'un modèle ou qu'un simulateur métiers a été créé, cette fonctionnalité doit être accessible (consommation) aux autres simulations ou aux utilisateurs. L'objectif du processus de consommation est de créer de nouvelles simulations dynamiques permettant une amélioration de la productivité et une meilleure connaissance des performances de la simulation. Les utilisateurs peuvent consommer le service composé via différents accès, notamment via des portails Web, des clients riches, des applications métiers et des dispositifs mobiles. DevServer Une fois créés, les services peuvent être combinés en services, applications ou processus métier plus complexes. Dans la mesure où les services existent indépendamment les uns des autres et de l'infrastructure informatique sous-jacente, ils peuvent être combinés et réutilisés avec une grande flexibilité. Et à mesure que les processus métier évoluent, la simulation peut ajuster ses règles et pratiques sans être contrainte par les limitations des applications sous-jacentes. V.3.3 Oracle SOA Suite A ce stade, il existe des conditions préalables à la mise en œuvre d'une SOA en simulation. Il ne faut pas songer à mettre en œuvre une SOA mais de répondre aux objectifs du projet. Adopter une approche hybride, vu qu'aucune des méthodes descendante ni ascendante ne fonctionne dans la réalité. Il est généralement préférable de scinder les scénarios d'utilisation en ensembles plus petits et de créer le scénario global en allant des modèles jusqu'à la simulation consommant les services. Le délai de mise en œuvre est une mesure essentielle, une approche de type 'trust me' n'est pas trop appropriée. Pour obtenir une grosse boule de neige, on commence généralement par une boule plus petite. C'est là, probablement le point le plus important pour parvenir à un déploiement efficace d'une SOA. On peut citer tout un ensemble de solutions éditeur permettant la mise en œuvre d'une SOA: Websphere ESB(IBM), Aqualogic Service Bus(BEA), Sap Netweaver(SAP), webmethods Fabric(webMethods), Sonic ESB(Progress Software), suite crossvision(software AG), SOA Accelerator(Casewise) et Oracle SOA suite(oracle). Cette dernière sera retenue comme exemple, vu qu'elle a été utilisée durant ce projet. V Présentation d'oracle SOA Suite: Le 12 janvier Oracle annonce la disponibilité d'oracle SOA Suite, une gamme complète de produits middlewares basés sur les standards permettant de développer, déployer et gérer facilement des architectures SOA. Les capacités Hot-Pluggable de cette suite, c'est-à-dire d'intégration native dans un existant hétérogène, permettent aux environnements de simulation de bénéficier des nombreux Département d'informatique, Faculté des Sciences, Université d'oran 127

128 Chapitre V DEVSERVER Mokaddem avantages que peuvent apporter les SOA, tout en protégeant et valorisant leurs investissements middlewares existants.[3 ] Avec cette suite, les environnements peuvent connecter, étendre et faire évoluer de façon transparente leurs modèles pour mettre en œuvre rapidement de nouveaux services de simulation métiers. Bâtie sur une architecture Hot-Pluggable, cette suite permet aux clients de faire évoluer leur environnement de simulation vers les architectures SOA sans passer par un projet long et coûteux de refonte. Réunissant les meilleurs composants SOA dans l'offre Oracle Fusion Middleware, cette suite est interopérable et supporte les serveurs d'applications ainsi que les bus de messagerie Oracle et nonoracle, notamment les serveurs d'applications IBM WebSphere, BEA WebLogic et JBoss. [3]. C est une gamme middleware complète regroupant les meilleures offres SOA et produits middleware Oracle sur le marché. Elle permet de créer, gérer et orchestrer les services pour constituer des simulations composites et des processus métiers. On obtient ainsi une simulation mieux en phase avec les enjeux métiers de l'environnement, capable de s'adapter plus rapidement aux nouvelles attentes de ses clients, à l'évolution de la concurrence et aux changements dynamiques au sein d'une simulation. Oracle BPEL Process Manager : le premier moteur natif BPEL (Business Process Execution Language) conçu pour l'orchestration des services Web et permettant aux environnements de concevoir, définir et exécuter leurs processus métiers. Oracle Enterprise Service Bus : un produit basé sur les standards assurant la connexion des modèles coté client et des partenaires de l'environnement pour constituer un ensemble de services. Oracle Web Services Manager : une console unique pour définir et appliquer les stratégies et règles de sécurité et gestion des services Web. Oracle Business Rules Engine : pour définir et administrer les règles de gestion. Oracle Business Activity Monitoring, :pour une visibilité en temps réel sur l'exécution des processus et la performance des activités métiers. Oracle Enterprise Manager : pour déployer et gérer des applications orientées services dans un environnement opérationnel. Oracle JDeveloper 10g : un environnement de développement intégré pour créer et composer des applications, qui constitue également une boîte à outils unifiée pour tous les composants d'oracle SOA Suite. Figure 14. Composants d Oracle SOA Suite Département d'informatique, Faculté des Sciences, Université d'oran DevServer Oracle SOA Suite regroupe les éléments suivants : 128

129 Chapitre V DEVSERVER Mokaddem Oracle SOA suit améliore la capacité d'une organisation pour prévoir le changement près améliorant sa visibilité aux événements dans l'environnement d'affaires en temps réel et pour répondre au changement en lui permettant de développer et optimiser des processus d'affaires rapidement. Elle accroît les investissements existants en étant modulaire, ouverte, et extensible ; ce peut lui être adopté dans un environnement hétérogène sans devoir enlever ou remplacer les systèmes existants aussi bien que dedans un mode par accroissement.[3] V Oracle BPEL Process Manager : «Directeur de processus de BPEL» : Le premier moteur natif BPEL est complet, standard et facile à l emploi pour une solution des processus métier afin de créer, de déployer et de contrôler plusieurs applications avec des étapes automatisées et humaines de déroulement des opérations. Le directeur de processus d'oracle BPEL peut être employé pour intégrer des applications et des systèmes de legs, composant des services à grain grossier des services granuleux plus fins, applications centrales composées de processus de construction, automatisant ainsi des processus métiers, et des applications de déroulement d opérations comprenant le cheminement et l'escalade sophistiqués. V Oracle Entreprise Service Bus : «Autobus de service d'entreprise (ESB)» : Oracle ESB fournit des possibilités de transmission de messages, de cheminement et de transformation qui permettent aux services d'être facilement intégrés au temps ou au temps d'exécution d'élaboration. DevServer Le directeur de processus d'oracle BPEL comporte un processus graphique et facile à utiliser, ce dernier est disponible par connexion à l'environnement de JDeveloper ou d'éclipse fournissant un environnement unifié de temps de conception. Des assistant faciles à utiliser sont fournis pour simplifier l emploie le déroulement des opérations. Il fournit une connectivité accroissant des adaptateurs d'oracle, qui fournissent les normes permettant l'accès à pratiquement n'importe quel point d'émission de données. Oracle ESB approuve pleinement la transformation de données et l'enrichissement en document. Oracle ESB comporte un autobus multi protocole de transmission de messages comprenant le soutien de JMS, le SOAP, JCA, WSIF, JDBC, HTTP, et ftp. L'autobus de message fournit des qualités configurables de JMS, de différents services de types magasins de persistance comprenant la base de données, dossier, et dans la mémoire. V Oracle Web Services Manager : «Directeur de services de Web» : Le directeur de services de Web d'oracle (OWSM) est une solution complète pour la fixation des architectures orientées service, elle permet la gestion des politiques de sécurité et d'identité à définir centralement sans être imposées globalement. OWSM permet la définition centralisée des politiques qui régissent des opérations de services Web telles que l'accès, la notation, et la validation du contenu, l'emballage de telles politiques autour des services sans la modification des services existants du Web. OWSM rassemble et surveille les statistiques pendant que les politiques s'exécutent et les affiche dans un format graphique en surveillant le tableau de bord. Les administrateurs peuvent placer la qualité des niveaux de service pour chaque application et OWSM affiche les alertes quand l'application excède les cibles établies. V Oracle Business Rules Engine : «Principes économiques»: Département d'informatique, Faculté des Sciences, Université d'oran 129

130 DEVSERVER Chapitre V Mokaddem Les principes économiques d'oracle permettent facilement aux analystes d'affaires de définir, mettre à jour, et contrôler les décisions principales et les politiques régissant des processus et des applications d'affaires, par exemple des politiques commerciales dans les processus metiers qui sont susceptibles de changer peuvent être capturées en utilisant des principes économiques. Les principes économiques d'oracle se composent d'un authoring tool de règle, d'un moteur de règles, et de SDK. Le SDK permet la génération de règles par des règles faites sur commande éditant des applications V Oracle Business Activity Monitoring :«Surveillance d'activité économique»: L'utilisateur peut également placer des conditions d alertes personnalisées qui peuvent être déclenchées et fournies à l'utilisateur à travers , fax, téléphone, ou tout autre canal de commode. V.4 Le serveur de Recherche DevServer Une recherche sous DevServer s effectue selon le diagramme suivant : DevServer Oracle Business Activity Monitoring (BAM) est une solution complète pour la construction des tableaux de bord opérationnels en temps réel pour surveiller des processus et des services metiers, niveaux de services, et indicateurs principaux d'exécution de voie (KPIs) des processus et des services, avec des possibilités pour prendre des modalités de reprise automatiques ou manuellement appelées. Oracle (BAM) permet aux utilisateurs d'affaires de construire les tableaux de bord interactifs et en temps réel, et alertes proactives. Il accroît la dernière technologie du Web pour livrer un riche, interactif tableau de bord opérationnel personnalisé dans lequel les données en temps réel et rapports personnalisés sont livrés aux utilisateurs d'affaires par l'intermédiaire d'un web browser standard. Recherche d un modèle dans la BD Client «extends» Mettre à jour la BD des modèles et de recherche Authentification «utilise» Administrateur Mettre à jour la BD de la banque «utilise» Banquier FigV.1 cas d utilisation du serveur de recherche Le client procède à une recherche d un modèle à partir d un formulaire qu il doit remplir. La requête est ensuite envoyée au serveur de recherche qui gère une base de données locale contenant tous les descriptifs des modèles enregistrés chez lui. Il faut rappeler ici que les serveurs de simulation responsables des modèles doivent, après avoir mis au point un modèle (conception, réalisation, validation, sauvegarde du modèle), enregistrer celui-ci sur le serveur de recherche. Département d'informatique, Faculté des Sciences, Université d'oran 130

131 Chapitre V DEVSERVER Mokaddem La base de données du serveur de simulation contient toutes les informations (nom, auteur, date de création, nombre de ports, une description du modèle, etc., en plus du fichier jar qui contient le code java du modèle écrit en DEVSJAVA, cependant la base de données du serveur de recherche contient toutes les informations sauf le jar du modèle qui est propriété de son concepteur. La manager du serveur de simulation doit maintenir sa base de données. Il doit assurer l authentification de ses clients. Un client sur ce serveur doit payer sa session de simulation. Donc, il faut vérifier la validité de sa carde de crédit, en plus de l authenticité de ses informations. Pour cela il doit disposer d un compte chez le serveur de simulation. Des services web sur serveur assurent la validité des dites informations. La figure fig V.1suivante résume ses opérations. La saisie d un modèle, sa suppression ou sa mise à jour sont réalisés sous forme de services web. Elle suit les techniques exposées par oracle ultrasearch[2], elle est multi critères. On peut chercher un modèle par son nombre d inports, d outports, son auteur, sa date de création etc. le client peut exprimer une conjonction ou une disjonction de ces critères. Le client peut donner une description du modèle qu il veut, le système retient les mots clés et les compare à la description du modèle sur sa base, il retiendra les modèles dont les descriptions sont proches de ce que demande le client. Ce serveur use des dernières techniques de recherche documentaire utilisées actuellement. DevServer La recherche d un modèle sur ce serveur procède comme suit : Fig.I.2 Architecture du serveur de recherche A figure figv.2 donne le cheminement que suit la requête de l utilisateur jusqu à son exécution. Département d'informatique, Faculté des Sciences, Université d'oran 131

132 DEVSERVER figv.3 formulaire de recherche Mokaddem figv.4 résultat de la recherche Si la recherche n aboutit pas le serveur renvoie une page d échec, sinon une page qui contient le résultat de la requête est affichée. Elle contient le prix d une session de simulation du modèle et l adresse du serveur où le modèle se trouve. Le client peut à ce stade procéder à la simulation. La programmation de l application a eu lieu sous JDeveloper d Oracle. Elle utilise une base de données Oracle où resident les modèles. Les differents formulaires ( Ajout, suppression, update de modèles et de clients ) sont des JSFs. Les procedures de recherches sont des services web. Dans ce serveur de recherche un service web principal est SearchModellWS (). Il contient la méthode qu on peut invoquer à distance : DevServer Chapitre V public Vector ChercheModell (String nom, String inports, String Outports, String auteur, String date1, String date2, String type, String serveur, String description){..} V.5 Le Serveur de Simulation Suite à la recherche, le client dispose d une liste de serveurs hébergeant l ensemble des modèles dont il a besoin pour composer son modèle. Il commence par créer son coordinateur et établir le couplage entre ses derniers et le coordinateur. Lorsqu il lance la simulation tous les serveurs disposant des modèles sélectionnés sont engagés. Chacun se lance et attend les évènements. La simulation se déroule comme suit : Initialisation de tous les simulateurs i chaque simulateur exécute sa fonction de transition interne int chaque simulateur exécute sa fonction de transition externe ext chaque simulateur exécute sa fonction de conflit interne conf chaque simulateur exécute sa fonction de sortie λ Injecter des messages au simulateur i demander le temps du prochain événement nexttn au simulateur i déterminer le simulateur i de tn minimal et incrémenter le temps par tn obtenir le log de tous les simulateurs Finaliser le service de simulation Département d'informatique, Faculté des Sciences, Université d'oran 132

133 DEVSERVER Fig V.5 distribution de la simulation par SOA Mokaddem figv.6 communication par message entre service Ces séquences sont schématisées par les figures fig 5 et 6. Comme il apparait, le coordinateur doit indiquer à ses simulateurs les ports des autres simulateurs sur lesquels ils vont router leurs messages. Le coordinateur se trouve évidemment sue le serveur principal initiateur de la simulation. Le coordinateur demande aux simulateurs de se lancer sous forme de services. Chaque service lance son propre simulateur pour simuler le modèle dont il est responsable. L information de couplage envoyée en fichier XML permet à chaque simulateur d identifier ses partenaires en communication. FigV.7 schéma d un simulateur DevServer Chapitre V figv.8 résultat retourné par un simulateur Chaque simulateur suit le schéma de la figure figv.7 pour retourner ses résultats dans la vue du frame expérimental coté client. V.6 Système global : Département d'informatique, Faculté des Sciences, Université d'oran 133

134 DEVSERVER Chapitre V Mokaddem 1. Search Services figv.9 schéma global de l application Du perspectif utilisateur, le processus de simulation se résume en 3 étapes : 2. Chercher des serveurs DEVS grâce au serveur de recherche. Sélectionner les serveurs à retenir. Actuellement, un seul serveur de recherche est implémenté avec 2 serveurs de simulation pour test, DevsMOSTA et DevsORAN. 3. Exécuter la simulation et attendre les résultats. Les modèles sont déjà précompilés sur les serveurs. V.7 Conclusion DevServer 1. Ecrire et héberger les modèles DEVS (actuellement seul DEVSJAVA est utilisé). On a développé un Framework SOA pour le test et l évaluation des modèles DEVS. Le processus de simulation est initié par le coordinateur et la propagation des messages se déroule entre les simulateurs conformément au couplage entre modèles. Les services web agissent au niveau des deux serveurs, les serveurs de recherche et de simulation. Le protocole de simulation est taillé selon SOA. Ce travail est la continuité de plusieurs travaux antécédents qui ont été à la base de celui-ci. Leurs apports ont été cités. L apport SOA a ouvert une porte à la simulation. Bientôt, chacun développe ses propres modèles, les place dans son propre serveur et les enregistre au niveau du serveur de recherche. Les modèles seront exploités durant des sessions payantes de simulation. Le parallélisme, la synchronisation entre modèles sont sous-jacents aux protocoles des systèmes d exploitation, à SOA et enfin au sein du simulateur. EasyDesvs, DevsJanet, DevSimul, DevsORAN, DevsMOSTA sont des produits de l environnement de simulation dans sa globalité. Ce travail est une preuve de la mise au point des concepts DEVS et la modélisation/simulation sur SOA. Département d'informatique, Faculté des Sciences, Université d'oran 134

135 DEVSERVER Chapitre V Mokaddem Travaux futures: Compléter le frame expérimental et ajouter des outils de génération de modèles par SOA. Ce qui revient à transformer EasyDevs, DevsJanet en application SOA pour en faire un environnement complet de modélisation/simulation sur le web. Transformer les modèles DEVS en agents pouvant s exécuter sur un réseau. Dés que l agent termine sa session de simulation il est détruit par le système. Ceci rejoint ce qua été fait avec les agents JavAct. L environnement ainsi voulu doit : specifier un scenario developer le modèle DEVS faire appel aux serveurs distants pour participer à la simulation du modèle exécuter le modèle sur l ensemble des serveurs corriger aussi que possible le modèle par des cycles de simulation et le frame expérimental transformer le modèle en ajoutant les services web adéquats générer le XML d couplage qui sera stoker avec le modèle. Publier le modèle sur le serveur de recherche DevServer Département d'informatique, Faculté des Sciences, Université d'oran 135

136 Chapitre V DEVSERVER Mokaddem Bibliographie : [Aid, 03] Z. Aid, F. Hifa : les Applications multi-tiers : Une nouvelle approche de simulation sur le web, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2003 [Ann, 99] F. Annab l: Simulation Distribuée, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1999 [Arc, 03] Arcangeli J.-P., Leriche S., Pantel M., «JavAne : partage et recherche d informations à base d agents mobiles adaptables», rapport n R, 2003, IRIT. [Arc, 05] Arcangeli J.-P., Hennebert V., Leriche S., Migeon F., Pantel M., «JavAct : principes, installation, utilisation et développement d applica tions», rapport n R, 2005, IRIT. [Car, 05] Carstairs, D.J., Wanted: A New Test Approach for Military Net-Centric Operations, Guest Editorial, ITEA Journal, Volume 26, Number 3, October 2005 [Che, 07] Z. Chergui, K. Djelloul: Approche de simulation DEVS à base de services web, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2007 [Che, 04] Cheon, S., Seo, C., Park, S., Zeigler, B.P., Design and Implementation of Distributed DEVS Simulation in a Peer to Peer Networked System, Advanced Simulation Technologies Conference, Arlington, VA, 2004 DevServer [Bad, 04] M. Badr, S E. Toumi : DEVSERVER: une solution pour distribuer la simulation sur le web, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2004 [Cho, 01] Cho, Y., B.P. Zeigler, H.S. Sarjoughian, Design and Implementation of Distributed Real-Time DEVS/CORBA, IEEE Sys. Man. Cyber. Conf., Tucson, Oct [Fek, 97] H. Fekir, R. Hebbar: Vers un environnement hétérogène et distribué de simulation, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1997 [Fuj, 99] Fujimoto, R.M., Parallel and Distribution Simulation Systems, Wiley, 1999 [Gue, 02] M. Guedda, A. Yazid : Une approche J2EE pour piloter une simulation sur le web, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2002 [Hu, 05] X. Hu, and B.P. Zeigler, Model Continuity in the Design of Dynamic Distributed Real-Time Systems IEEE Transactions On Systems, Man And Cybernetics Part A, Volume 35, Issue 6, pp , November 2005 [Khe, 01] F. Khebizat, K.Sehaba: EasyDevs : Un outil Blackboard pour une méthodologie intelligente d approximation successive des modèles DEVS, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2001 Département d'informatique, Faculté des Sciences, Université d'oran 136

137 DEVSERVER Chapitre V Mokaddem [Kim, 04] Kim, K., Kang, W., CORBA-Based, Multi-threaded Distributed Simulation of Hierarchical DEVS Models: Transforming Model Structure into a Non-hierarchical One, International Conference on Computational Science and Its Applications, ICCSA, Italy 2004 [Meg, 99] A. Meguedad, H.Oucif: Vers un environnement hétérogène et distribué de simulation, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 1999 [Mes, 06] A. Messous, I. Hankour : une simulation à base d agents mobiles sur le web, mémoire de fin d études pour l obtention du diplôme d ingénieur d état en informatique, Département d Informatique, Faculté des sciences, Université d Oran, 2006 [Sau, 07] Saurabh Mittal, José L. Risco, B P Zeigler: DEVSMLDEVS-Based Simulation Web Services for Net-Centric T&E. Summer Computer Simulation Conference, San Diego, California (USA), July 15-18, [Seo, 04] Seo, C., Park, S., Kim, B., Cheon, S., Zeigler, B.P., Implementation of Distributed Highperformance DEVS SimulationFramework in the Grid Computing Environment, Advanced Simulation Technologies conference (ASTC), Arlington, VA, 2004 [Wai, 01] Wainer, G., Giambiasi, N., Timed Cell-DEVS: modeling and simulation of cell-spaces. Invited paper for the book Discrete Event Modeling & Simulation: Enabling Future Technologies, SpringerVerlag 2001 DevServer [Sau, 07bis] Saurabh Mittal, José L. Risco. DEVSML: Automating DEVS Execution over SOA Towards Transparent Simulators. In Special Session on DEVS Collaborative Execution and Systems Modeling over SOA, DEVS Integrative M&S Symposium DEVS'07, March [Weg, 02] Wegmann, A., Strengthening MDA by Drawing from the Living Systems Theory, Workshop in Software Model Engineering, 2002 [Zei, 00] B. P Zeigler, H. Praehofer, T. G. Kim, Theory of Modeling and Simulation, Academic Press, 2000 [Zha, 05] Zhang, M., Zeigler, B.P., Hammonds, P., DEVS/RMI-An Auto-Adaptive and Reconfigurable Distributed Simulation Environment for Engineering Studies, ITEA Journal, July 2005 [1] ACIMS software site: [2] Ultrasearch : [3] [4] WSDL Département d'informatique, Faculté des Sciences, Université d'oran 137

138 C h a p i t r e 7 DEVSECURITY DEVSECURITY Mais avec l ouverture du monde sur les réseaux, ces derniers sont devenus des outils indispensables au fonctionnement des entreprises. Ils sont aujourd hui déployés dans tous les secteurs professionnels, en particulier en simulation où des serveurs de simulation sont exposés sur le réseau. Ces réseaux sont à présent interconnectés et le nombre de points d accès ne cesse de croître. La gestion de la sécurité de ces réseaux implique : la mise en place de mécanismes préventifs de sécurité pour protéger les données et les ressources du système ou du réseau contre tout accès non autorisé ou abusif; le déploiement des outils de sécurité pour détecter les attaques qui réussiraient à porter atteinte à la sécurité du réseau ou du système malgré les mesures préventives; la mise en place des mécanismes de réponse aux attaques détectées. DEVSECURITY La notion de sécurité n est pas prise au sérieux et elle est toujours reléguée au second degré et même ceux qui la défendent sont souvent accusés de paranoïa. Prévenir de toutes les violations de sécurité apparaît quelque peu irréel. En effet, il est pratiquement impossible d avoir un réseau complètement sûr et de le protéger contre toutes les attaques possibles. Malgré la mise en place de politiques préventives de sécurité, les réseaux et les systèmes restent sujets à des attaques potentielles [cer 95,96,98], entreprises par des personnes qui réussissent à contourner ces mesures préventives par des comportements frauduleux. Par conséquent, dans ce travail, on s est focalisé sur le second aspect qui concerne les mécanismes de détection d intrusions. Cependant, il faudrait mettre l accent sur le fait que malgré la qualité et la vigueur des défenses utilisées, le risque zéro n existe pas. On ne peut agir que sur le niveau résiduel du risque : plus on veut le diminuer, plus il faut faire d efforts. Autrement dit on essaie de définir des limites entre ce qui est acceptable et ce qui ne l est pas. Département d Informatique, Faculté des Sciences, Université d Oran 139

139 Chapitre VI DevSecurity Mokaddem Les IDS [kum 95], [me 96] existants ont été conçus pour des environnements connus et bien définis. Ils ne sont donc pas adaptés à des environnements dynamiques et c est là leur principale faiblesse. Dans ce type d environnement où les besoins en sécurité sont en perpétuelle augmentation, flexibilité et adaptabilité deviennent des critères primordiaux. L objectif de DevSeurity est donc de présenter une solution de détection d intrusion souple et flexible pouvant s adapter aux changements et à l évolution complexe et non prédictive des réseaux. Ces caractéristiques que l on recherche ont également fait l objet de nombreuses recherches notamment dans le cas de la gestion de réseaux et ce pour résoudre des problèmes tels que la gestion de fautes et l analyse de trafic. Des solutions récentes [has 01] ont montré que des approches à base d agents étaient adaptées pour résoudre des problèmes complexes. Dans la perspective d offrir un système de détection d intrusion pour les réseaux actuels mais aussi pour la nouvelle génération, on propose une nouvelle génération de systèmes de détection d'intrusions fondés sur les systèmes multi-agents avec agents mobiles pour modéliser et implémenter une détection d'intrusions intelligente. La fonction de réponse aux intrusions est également traitée parce qu on considère que cette fonction est déjà incluse dans un système de détection d intrusions. De plus, parmi les limitations des IDS actuel est qu ils détectent une intrusion et laisse l administrateur la tâche de répondre à l attaque détectée, et cela représente un vrai point faible. L administrateur doit donc être toujours présent auprès de l IDS! La fonction de réponse aux intrusions, même si elle est importante, elle reste limitée. Car un agent doit avoir une certaine intelligence (connaissances) pour pouvoir choisir la réponse adéquate à l attaque détectée. C est peut être la raison pour laquelle ils ne sont pas trop abordés dans le domaine de détection d intrusion. Mais ce qui est intéressant le plus, c est de pouvoir réaliser une réponse non pas à la machine attaquée, mais bien plus, ça serait intéressant si nos agents pouvaient se déplacer vers la machine attaquante, collecter des informations sur l attaquant et faire une contre attaque pour contrôler cette machine (par exemple: arrêter la machine) Pour réaliser ce système multi agents à base d agents mobiles, on a procédé par les étapes suivantes : Concevoir l architecture du système : l ensemble des agents, leur type et leur rôle Choix de la plate-forme d agents mobiles La politique de détection d intrusion (par scénario ou comportementale, HIDS ou NIDS) La coopération entre le système de détection et le système de réponse DEVSECURITY L objet de DevSecurity est basé sur une approche multi-agents, on va concevoir des agents mobiles et autonomes, mobiles parce qu'ils puissent se déplacer dans le réseau et passer d'un hôte à l'autre, et autonome parce qu'ils s'exécutent par leur propre chef (ils décident quoi faire et quand, et peuvent créer d'autres agents mobiles). Cet ensemble d agents va donc coopérer pour assurer la fonction de détection d intrusion d une manière distribuée, flexible, et surtout autonome. Dans cette section on va détailler les étapes de réalisation du travail ; on commencera par détailler l architecture du système multi agent de l IDS, la plate-forme d agents mobiles choisie, les outils utilisés et l interface permettant d interagir avec l application. I. L architecture du système Dans [adn 04], sont citées les différentes architectures d IDS à base de système multi agent (agents mobiles ou statiques). Les architectures des meilleurs IDS (AAFID [AAFID], SPARTA [SPARTA], Micael [Micael], MA-IDS [Ma-IDS], modèle phéromonal [Has, 01]) y sont étudiées. AAFID étant basée sur les agents statiques, son architecture est la base d inspiration de la plupart des autres IDS. L étude de chaque architecture, ses avantages, ses inconvénients et ses limites a permis de décider de définir l architecture propre de DevSecurity, en s inspirant évidemment des avantages de chacune, et bien sûr en paliant à ses inconvénients. Le diagramme de cas d utilisation suivant montre le rôle et les fonctionnalités de notre application : Département d Informatique, Faculté des Sciences, Université d Oran 140

140 Chapitre VI DevSecurity Mokaddem FigVII.1 Diagramme de cas d'utilisation de DevSecurity Sous système de détection : on appellera cette parie IDS (Intrusion Detection System) Sous système de réponse : on appellera cette partie IRS (Intrusion Response System) On détaillera par la suite l ensemble des agents constituants chaque sous système et les moyens de communication entre eux. Mais avant cela on parlera de la base de données qu on a utilisée pour notre application (autre que celle de Snort). Et la plate forme d agents mobiles choisis. I.1 La plate-forme d agents mobiles DEVSECURITY Pour définir notre architecture, on va décomposer notre système en deux sous systèmes, chacun d eux englobe un ensemble d agents, les deux sous systèmes sont: Notre IDS étant basé sur une approche multi agents avec des agents mobiles[a1,,16] il fallait bien choisir la plate-forme adéquate à l application, et c était la première difficulté rencontrée durant cette phase du projet. Quelles sont les plates-formes d agents mobiles disponibles? Sur quels critères se baser pour choisir une plate-forme? Après une étude des plates-formes les plus utilisées, on a opté pour la plate forme Aglet [B1,,7]. Le concept d agent mobile ainsi que les raisons de ce choix, sont défini dans l annexe A. Les détails sur la plateforme Aglet sont dans l Annexe B. Pour mettre en œuvre une application basée sur la plat-forme Aglet, il faut installer le serveur d agents dans chaque hôte, par exemple dans DevSecurity on l a installé sur toutes les machines qu on veut surveiller. TAHITI est le serveur par défaut des Aglets. Il possède un viewer (une interface graphique qui affiche tous les agents qui sont en cours d exécution sur cet hôte). Département d Informatique, Faculté des Sciences, Université d Oran 141

141 Chapitre VI DevSecurity Mokaddem Dans DevSecurity, on n a pas réellement utilisé le serveur TAHITI, la première cause est qu il possède une interface graphique qui permet même de tuer un agent Aglet et la deuxième est qu on a voulu avoir un serveur qui, dés son lancement, va générer l ensemble des agents de l application. De ce fait, on a conçu un serveur d agent ne disposant d aucune interface graphique, et pouvant être lancé au démarrage, en tant que service dans les machines à surveiller. Un seul serveur parmi ces machines, celui qui est lancé par l administrateur réseau, aura la tâche de lancer le système de détection d intrusion (créer et lancer l ensemble des agents). Les deux serveurs sont en format d un fichier.bat (pour windows) ou scriptshell (pour Linux). I.2 La base de données DIAM Pour archiver et garder certaines informations nécessaires à l application, on a choisi d utiliser une base de données MySQL appelée DIAM. Voici l instruction de création ce cette base de données : requete="create DATABASE diam"; try { stmt.execute(requete); System.out.println("DB created"); } catch(sqlexception e) {System.out.println(" Erreur : DB not created");} // utilisation de la base requete = "USE diam"; try { stmt.execute(requete); System.out.println("DB in use"); } catch(sqlexception e) { System.out.println("Erreur : DB not in use");} La base de données et l ensemble de ses tables sont crées automatiquement par l application au premier lancement. Pour bien comprendre son utilité on va détailler l ensemble des tables qui la constituent: private void table_agents_presents()throws SQLException{ //La Table agent_present requete="create TABLE agents_presents(agentid VARCHAR(20),type VARCHAR(15), adresse_hote VARCHAR(16),origine VARCHAR(100),PRIMARY KEY (agentid))"; stmt.execute(requete); } 2. Agent_tues : cette table contient les agents qui on été tués (arrêté, disposés) durant leur exécution. Noter que l arrêt d un agent peut représenter une attaque, par exemple dans le cas ou un attaquant tue le processus qui représente l agent ou bien le serveur d agents. Voici la méthode qui nous permet de créer cette table private void table_agents_tues()throws SQLException{ //La Table agent_tues requete="create TABLE agents_tues (agentid VARCHAR(100), agent_killer VARCHAR(100), type VARCHAR(15), adresse_hote VARCHAR(18), origine VARCHAR(100), PRIMARY KEY (agentid))"; stmt.execute(requete); } DEVSECURITY 1. Agent_présents : comme son nom l indique, cette table représente l ensemble des agents présents dans le système (en cours d exécution) cette table n est pas trop importante, mais elle nous permet simplement d avoir une vue sur les agents qui circulent dans notre réseau (vidée au démarrage de l application). Cette table est créée avec la commande 3. hôtes : Cette table présente les hôtes (machines) qui doivent être surveillés par les agents HIDS. Pas de problème pour Snort, car il surveille tout le segment dans lequel il est installé, toutefois on peut le configurer pour qu il ne surveille que les hôtes désigné par cette table. Cette table est créée au premier lancement et pourra être modifiée par la suite, mais il est important de noter qu il faut mettre le nom de la machine au lieu de l adresse IP dans le cas ou les IP sont dynamiques, mais dans le cas contraire vous pouvez mettre les deux (nom ou adresse IP). private void table_hotes()throws SQLException{ //La Table hotes regroupant tous les hôte à surveiller requete="create TABLE hotes(hote VARCHAR(20),etat ENUM('outline','online'))"; stmt.execute(requete);} 4. IRS_SNORT : cette table ne contient qu un seul élément (enregistrement), qui nous permet de savoir si le système de réponse est activé ou pas (car l administrateur réseau pourra le désactiver s il Département d Informatique, Faculté des Sciences, Université d Oran 142

142 Chapitre VI DevSecurity Mokaddem ne veut pas une réponse automatique aux attaques), la table contient les paramètres de lancement de Snort : snort c /etc/snort/snort.conf, il suffit de les donner au premier lancement de l application, après ils seront chargés automatiquement de cette table pour permettre de lancer snort avec les paramètre spécifiés (ils pourront être changés). On n a pas besoin de donner la commande de lancement, car le lancement est toujours effectué avec la commande snort. Cette table représente un moyen d interaction indirecte entre l utilisateur et le système car elle notifie les paramètres de configuration qu il peut mettre à jour à n importe quel moment ainsi que la commande d arrêt du système. private void table_irs_snort()throws SQLException{ // contient un seul élément, qui indique si le système de réponse est activé ou non et les parametres de Snort requete="create TABLE irs_snort(irs VARCHAR(10), commande ENUM('0','1','2'), parametre VARCHAR(100))"; stmt.execute(requete); // ajouter le champ active; car le système de réponse est activé par défaut et // l initialiser avec les paramètres donnés par l administrateur requete="insert INTO irs_snort VALUES('active','0','"+getSnortParam()+"')"; stmt.execute(requete); } 5. Alertes : c est la table la plus importante, elle contient toutes les alertes générées par le système, ainsi que les alertes générées par Snort mais sous un autre format (autre format que celui de la table event de la base de données de Snort). Elle est vidée à chaque lancement après que son contenu ne soit sauvegardé dans une autre table : Archive, pour ne contenir que les alertes émises après le dernier lancement. protected void table_alertes() throws SQLException{ requete="create TABLE alertes(sid INT, cid INT, signature INT, sig_name VARCHAR(255), type ENUM ('reseau','hote'), sig_class_id INT, sig_priority INT, timestamp datetime, ip_source VARCHAR(16), ip_destination VARCHAR(16), protocole TINYINT(5), port_source Int(6), port_destination Int(20), traitement ENUM('0','1','2','3','4'), temps datetime, temps_traitement datetime, PRIMARY KEY(sid,cid))"; stmt.execute(requete); } Archive : l idée d archiver les alertes dans une table Archive, et mettre les dernières alertes détectées dans une autre table sera justifiée par la suite (agent de surveillance) 7. Users : cette table représente les utilisateurs ayant droit d accéder au système. Chaque utilisateur est défini par un nom d utilisateur (username), un mot de passe (password) et ses droits (droit de changer de configuration, lancer ou arrêter l application) le droit d ajouter ou de supprimer des utilisateurs n est accessible que par l administrateur. Cette option permet de sécuriser l accès à l application elle-même; private void table_users() throws SQLException,UnknownHostException{ //LA TABLE users : les utilisateurs enregistrés requete="create TABLE users (username VARCHAR(20), password VARCHAR(20),date_inscrit DATE, etat ENUM('online','outline'), machine VARCHAR(16), hote TINYINT(1), users TINYINT(1), lancer TINYINT(1), arret TINYINT(1),PRIMARY KEY (username))"; stmt.execute(requete); // ajouter le compte administrateur dans cet table requete="insert INTO users VALUES('"+getUserAdmin()+"','"+getPassAdmin()+"',CURRENT_DATE,'outline','"+ java.net.inetaddress.getlocalhost().gethostname()+"',1,1,1,1)"; stmt.execute(requete); } DEVSECURITY Historique : cette table maintient un historique des utilisateurs qui ont accédé au système. private void table_historique() throws SQLException{ //La Table historiqe requete="create TABLE historique(cle INT(11) auto_increment,username VARCHAR(20),date DATE,entree TIME,sortie TIME,hote VARCHAR(20),PRIMARY KEY (cle))"; stmt.execute(requete); } Département d Informatique, Faculté des Sciences, Université d Oran 143

143 Chapitre VI I.3 Système de détection DevSecurity Mokaddem Le système de détection représente l ensemble des agents assurant la fonction de détection d attaques, ainsi que les outils utilisés. Notre IDS est hybride, c est à dire qu il regroupe la fonction HIDS et NIDS. On va donc détailler chacune d elles, l ensemble des agents, leur rôle et leur type. I.3.1 NIDS On a déjà mentionné le principe de fonctionnement d un NIDS dans [adn 04] Notre NIDS se compose de deux parties : le détecteur d intrusion lui-même et son contrôleur. Le détecteur d intrusions n est autre que SNORT [c1,2,3,6] le plus répandu et le plus utilisé dans le monde (utilisé dans SPARTA, Micael et MA-IDS ), mais son inconvénient et qu il est monolithique (centralisé) il est composé d un seul module responsable de toutes les tâches de détection. Mis à part cela, il est le meilleur NIDS qui détecte un grand nombre d attaques et qui est configurable, c'est-à-dire, vous pouvez définir vos propre règles (voir [adn 04]). La partie contrôle est réalisée par des agents qui nous fournissent des informations sur le fonctionnement de la partie détection et nous permettent d interagir avec elle. En premier lieu, on a installé Snort [c8,9,10] et on l a configuré de manière à ce qu il met ses alertes dans une base de données MySQL (voir les détails d installation et de configuration de Snort et MySQL dans[adn 04],[ked 04][c5]. En deuxième lieu, on a créé deux agents: un agent qui surveille le fonctionnement de Snort, et un agent qui reste en écoute à la base de données utilisée par Snort pour savoir s il y a de nouvelles attaques détectées. A. Agent surveillant de Snort : Lancer Snort : cela peut être au lancement de l application, ou après un arrêt en cours d exécution. Cette fonctionnalité permet de lancer Snort avec les paramètres qui sont fournis par l administrateur du réseau. Arrêter Snort : par exemple quand l administrateur veut arrêter totalement le système de détection ou bien quand il veut changer la configuration de Snort (il doit l arrêter puis le relancer). Configurer Snort : consiste à changer les paramètres de lancement de Snort ou d ajouter de nouvelles règles (ces deux changements impliquent le redémarrage de Snort). Cet agent n est pas mobile, car il doit s exécuter dans la même machine où Snort est entrain de s exécuter. Le schéma suivant montre le diagramme de classes de cet agent qui s étend de la classe agent qui hérite de la classe Aglet. On a crée la classe agent pour regrouper les méthodes et les attributs communs entre la classe qui représente l agent surveillant de Snort et la classe de l agent surveillant de la base de données. L ensemble de ces agents est groupé dans le package ids. DEVSECURITY On va maintenant détailler le rôle de cet agent. En général, il doit : Note : le lancement, l arrêt et le contrôle d un processus peut être réalisé avec java par la commande suivante : Process snort = Runtime.getRuntime().exec(commande,parametre); Le champs commande désigne le chemin du fichier exécutable, et l attribut paramètre désigne les paramètre du lancement ; cette commande nous retourne un objet de type Process, qu on pourra s arrêter avec la méthode destroy() Département d Informatique, Faculté des Sciences, Université d Oran 144

144 Chapitre VI DevSecurity Mokaddem FigVII.2 : Diagrammes de la classe agent et de classe de l'agent surveillant de snort public void oncreation(object init) { Vector vect = new Vector(); vect= (Vector) init; vect.addelement("surveillantsnort"); // ajoute son nom vect.addelement(this.getagletid().tostring()); // et son identificateur String param=null; try {param= "Hote = " + java.net.inetaddress.getlocalhost().gethostname(); param = param + " IP = "+ java.net.inetaddress.getlocalhost().gethostaddress(); } catch (java.net.unknownhostexception e) { System.out.println("ne peut pas avoir l'adresse de cet hôte");} vect.addelement(param); // et son adresse pour s enregistrer super.oncreation(vect); // appel de oncreation de son parent try {Statement stmt=super.getconnection().createstatement(); stmt.execute("use diam"); //accés à diam ResultSet rs; rs=stmt.executequery("select parametre From irs_snort"); if (rs.next()) param = rs.getstring(1); ReturnParametre(param); } catch (SQLException e) { System.out.println("ne peut pas peut accéder à la base de données");} } // cette méthode permet de lancer snort sans lui indiquer les paramètres public boolean LancerSnort() { try { snort= Runtime.getRuntime().exec(commande,parametre); return true; } catch(ioexception ex) { System.out.println("impossible de lancer Snort"); return false;} } public void run(){ try { snort.waitfor(); } catch (InterruptedException ex) {//cas ou le process s est arreté LancerSnort(); run(); } } Département d Informatique, Faculté des Sciences, Université d Oran DEVSECURITY Pour comprendre l utilisation de cette commande on va citer l exemple de la méthode LancerSnort() et run() de la classe SurveillantSnort : 145

145 Chapitre VI DevSecurity Mokaddem B. Agent surveillant de la base de données snort : Son rôle est le suivant : Rester en écoute à de nouvelles attaques détectées par SNORT Extraire les informations des nouvelles attaques détectées dans une autre base de données que celle de Snort (dans la table alertes de la base de données DIAM). On a configuré SNORT de façon à ce qu il met ses alertes dans une base de données MySQL. Notre agent doit donc veiller à ce que cette base de données ne soit pas remplie de faux positif. Remarque : SNORT est un IDS très connu et Open Source, les attaquants l ont bien étudié pour pouvoir le rendre inefficace, ou l attaquer lui même. Effectivement, parmi les fameuses attaques effectuées sur SNORT est de réaliser une succession de faux positif afin d encombrer SNORT puis effectuer la vraie attaque. Cet agent est mobile, se déplace d un hôte à l autre et peut accéder à la base de données à distance, sa mobilité le protège et donc on ne pourra pas l attaquer si on ne connait pas sa place. Et dans le cas d un disfonctionnement un autre agent va le détecter. On appellera cet agent SentinelDB dont le diagramme de classes est décrit dans la figure suivante : DEVSECURITY FigVII.3 : diagramme de la classe de l agent sentineldb On va maintenant détailler les newattaques(): méthodes les plus importantes de cet agent run(), update() et // éxécution de l agent public void run() { setdatabaseinterface(); update(); try {this.getproxy().dispatch(prochaindestination(super.feuille.tableurln)); } catch (Exception ex){system.out.println("l'agent sentinelle ne peut pas se déplacer");} } // Écoute à la base de données private void update() { boolean newattaques; // traitement lecture newattaques= newattaques(); if (newattaques) // envoyer un message d'alerte à l'agent surveillant Département d Informatique, Faculté des Sciences, Université d Oran 146

146 Chapitre VI DevSecurity { Message msg = new Message("alerteN"); try { // aulieu de this mettre "Agent surveillant" AgletProxy surveillant; surveillant = (AgletProxy) super.feuille.autreagents.elementat(4); surveillant.sendmessage(msg); } catch(exception ex) { System.out.println("l'agent sentinelle ne peut pas envoyer un message d'alerte au surveillant"); } message au générateur } } // détecte s il y a de nouvelles alertes émises par Snort private boolean newattaques(){ String sql=null; Timestamp t=new Timestamp(0); boolean x=false; try { stmt.execute(usediamdb); sql = "SELECT MAX(timestamp) FROM alertes"; rs=stmt.executequery(sql); if (rs.next()) t=rs.gettimestamp(0); } catch (SQLException ex) {System.out.println("erreur dans la requete : " + usediamdb);} try { stmt.execute(usesnortdb); sql = "SELECT sid,cid FROM event WHERE timestamp >"+ t+""; rs = stmt.executequery(sql); while (rs.next()) {x=true; ajouteralerte(rs.getint(0),rs.getint(1)); } // ajouter un nouveau champs dans la base diam } catch(sqlexception e) { System.out.println("erreur dans la requete : " + sql);} // vider Snort si les champs dépasse 1000 try { sql = "SELECT Count(*) from event"; rs = stmt.executequery(sql); if (rs.next()) {int nombre = rs.getint(1); if (nombre>1000) viderbdsnort(t);} } catch (SQLException e) {System.out.println(" Ne peut pas vider la base de données de Snort");} return x; // si on a jouté de nouvelles attaques à la base Diam } Mokaddem // envoie un Ce sont les agents résidant dans les différents hôtes et s occupant de la détection des intrusions. Ils seront constamment surveillés par les EmmeteurRecpteur qui prennent en charge le poste dans lequel ils se trouvent. Ces agents ne sont pas créés dès le départ (avec les autres entités), ils ne le sont qu après que tous les autres l ont été. Ils se composent de deux types d agents : les AgentH et les Filtre. Chaque agent AgentH (abstraction de tous les agents qui effectuent la détection) est identifié par son attribut typesurveillance qui indique implicitement le type de source de données dont a besoin ce dernier pour exécuter sa fonction de détection. DEVSECURITY I.3.2 HIDS Quant aux filtres, se sont des entités spéciales qui ne s occupent que de la fonction d audit, autrement dit : se sont elles qui sont responsables de la récolte d informations (fichiers log, appels système) pour ensuite les fournir aux agents qui les utilisent (AgentH). Les aglets AgentH sont des agents qui exécutent des scripts Perl à cause des facilités qu il offre en ce qui concerne les expressions régulières et les accès aux fichiers. Nos agents ne s exécute que sur des hôtes Linux et donc, par conséquent, les agents de détection et de réponses n exécutent que des actions bien spécifiques (prendront en considération le système de fichier Linux). Les appels aux scripts sous java se font grâce à ces deux instructions suivantes : Runtime r=runtime.getruntime(); try { Process proc = rt.exec( nom_du_fichier_script); } catch ( IOException io ) { } Département d Informatique, Faculté des Sciences, Université d Oran 147

147 Chapitre VI DevSecurity Mokaddem Grâce au fait que ces agents s étendent des aglets, l accès à ces scripts est facilité, et ils ne se trouveront alors que dans un seul hôte : celui dans lequel se trouve le Controleur. Sous Linux, il existe le démon syslogd qui est n est autre que son historien et auquel chaque programme se connecte pour l historisation. Le comportement du journal système est contrôlé par /etc/syslog.conf qui contient un ensemble de règles dirigeant différents types d entrées du journal vers différents fichiers du système. Ex : /var/log/messages *.* -/var/log/message. Pour détecter les attaques, il suffit d analyser périodiquement ces fichiers d audits. Par exemple, pour détecter un Scan de ports, il suffit de trouver un ensemble de connections à différents ports à partir du même hôte dans un intervalle de temps réduit. Toutes les procédures de vérification sont réalisées avec Perl (facilite la description des expressions régulières). En cas d attaque détectée, elle sera enregistrée dans des fichiers logs par les agents responsables de cette détection. C est le Contrôleur qui aura pour rôle de signaler ces alertes au Surveillant. I.4 Système de réponse Le système de réponse est composé d un ensemble d agents, des agents de réponse IRA (Intrusion Response Agent), et d un agent surveillant de tous ces IRA Fermer le port de communication de la machine attaquée Arrêter/redémarrer la machine attaquée (si nécessaire) changer les droits de l utilisateur (cas d une attaque host détectée par HIDS) Filtrer les paquets en prévenance de la machine attaquante Envoyer un agent vers la machine attaquante pour prendre son contrôle et collecter des informations sur l attaquant. On peut envisager le fonctionnement de ce système de deux manières : 1- créer les agents de réponses au début du lancement du système, et les configurer de façon à ce qu il circule dans tout le réseau à la recherche d une alerte, (modèle pheromonal) 2- l agents de réponse n est crée que lors d une détection d attaque après la réponse il s autodétruit. DEVSECURITY Les agents IRA ont un seul rôle, effectuer une réponse à l attaque afin de l arrêter, les réponses qu on peut réaliser sont les suivantes : On a opté pour la deuxième solution, car on ne veut pas trop encombrer le réseau avec des agents momentanément inutiles, il vaut mieux les créer juste quand c est nécessaire et les détruire après. Après avoir décrit les 5 fonctions d un agent de réponse, on pourra distinguer deux types d agents : 1. L agent qui opère dans la machine attaquée : il effectue les 4 premières fonctions, le choix de la réponse est effectué selon le degré de l attaque détectée. Cet agent est, bien évidemment mobile, dés qu il est crée à la suite d une alerte, il va se déplacer vers la machine attaquée, il n aura pas de problème pour cela car elle sera sûrement muni d un serveur d agents, et effectuer la réponse appropriée à l attaque détectée. 2. L agent qui opère dans la machine attaquante : cette fonction n est pas obligatoire, mais elle nous permet d avoir des informations sur l attaquant et sur les outils qu il utilise. Si l attaquant ne fait pas partie de l ensemble des machines surveillées, il sera inutile de réaliser cet agent avec une Aglet car la Département d Informatique, Faculté des Sciences, Université d Oran 148

148 Chapitre VI DevSecurity Mokaddem machine de l attaquant risque de ne pas contenir de serveur d aglets pour héberger l agent de réponse. Dans ce cas on a deux solutions : Si la machine attaquante fait partie de l ensemble des machines du réseau surveillé, alors on est sûr qu elle contient un serveur d agents. On va donc créer un agent mobile de réponse, qui va se déplacer à cet hôte et nous fournir les informations nécessaires de l attaquant. Si la machine de l attaquant n appartient pas au segment surveillé, on ne pourra donc pas essayer d envoyer l agent mobile précédent, mais il faudra profiter du port ouvert de l attaquant, en lui injectant un trojan, et comme ça on pourra le surveiller et le contrôler à distance. On a dit que l agent de réponse IRA va effectuer une réponse selon le degré de l attaque. Au début, dés que l attaque est détectée, son degré est zero 0, cela veut dire qu elle n est pas encore traitée. Dés qu un IRA va prendre en charge cette attaque, il va mettre l heure de début de traitement (l heure ou il a commencé de traiter cette attaque) puis il va incrémenter son degré : Si le degré =1, quand il trouve que c est la première fois que l attaque est traitée, il va chercher dans la table archive (archive des attaques de la base de données diam), s il trouve que cette attaque a déjà eu lieu auparavant (pour la même machine), il va déduire que la réponse qui a été effectuée n a pas pu servir à protéger le réseau de cette attaque, donc il va effectuer une réponse avancée, sinon, s il elle n est pas dans l archive, cela voudra dire que c est la première fois qu elle se produit, il va donc effectuer une réponse simple, puis supprimer l alerte correspondante de la table alertes et la mettre dans la table archive Si le degré=2, c est le cas ou un agent IRA a déjà pris en charge cette attaque mais il n a pas pu effectuer une réponse, ou il a dépassé le temps limite d une réponse (5 min), et dans ce cas là, cet IRA (le deuxième) doit changer la réponse et effectuer une réponse plus avancée. Si le degré=3, c est le cas le plus dangereux, car cela veut dire que cette attaque vient d être traitée pour la troisième fois, dans ce cas là l agent IRA doit effectuer une réponse radicale. Pour illustrer le comportement d un agent de réponse, prenons l exemple d un cas de réponse simple, crée à la suite d une alerte émise par l agent SureviellantDB (base de données de Snort) : désactiver le service réseau ciblé par l intrusion. Presque toutes la gestion des requêtes réseau entrantes est réalisée par le démon : inetd. Ce dernier possède un fichier de configuration : /etc/inetd.conf qui est lu chaque fois qu il est lancé ou redémarré. DEVSECURITY Note : après avoir effectué une réponse à l attaque, chaque IRA doit supprimer l alerte correspondante de la table alertes et la mettre dans la table archive. On détaillera par la suite le type de réponse simple, avancée ou radicale. Le diagramme de la figure FigVII.4 représente le diagramme d activité d un agent IRA : Chaque ligne de ce fichier représente une règle complète composée de listes ou d une série de mots clés séparés par un espace blanc. Son format est le suivant : Service socket-type protocole flags utilisateur serveur args Ex : login stream tcp nowait root /usr/sbin/tcpd in.rlogind Le champ service correspond au nom du service qui est géré par le démon (ex : ftp ou telnet) quant au champ serveur, il indique le chemin d accès vers le véritable programme auquel inetd va passer le contrôle de connections entrantes (tels que : in.telnetd ou in.ftpd). Pour rendre un service inactif, il suffit de transformer la ligne correspondante à ce dernier en une ligne de commentaire en lui ajoutant le caractère #. Département d Informatique, Faculté des Sciences, Université d Oran 149

149 Chapitre VI DevSecurity Mokaddem FigVII.4 : Diagramme d'activité d'un agent réponse IRA Quand l agent de réponse aura relevé l adresse destination, le numéro du port et le type de protocole de la table alertes, il se déplacera vers l hôte en question. Et à partir du fichier /etc/services, il relèvera le nom du service associé aux ports et protocole en question. Pour accéder en suite au fichier /etc/inetd.conf et effectuer le changement dont on a parlé précédemment. Mais avant cela, il devra créer un fichier chez l hôte (qu il nommera : /motif) et dans lequel il va enregistrer le numéro du port et le protocole sous la forme port/protocole (exemple : 513/tcp) car c est le format qui est utilisé dans le fichier /etc/services. Public void extrairenomservice() { String[] commandline={"/bin/sh","-c","cat /etc/services grep -f /motif cut -f 1 > /motif"}; Process proc = null; Runtime rt = Runtime.getRuntime(); try { proc = rt.exec( commandline); } catch ( IOException io ) { } } DEVSECURITY Pour extraire le nom du service par exemple, il fera appel à une de ses méthodes : extrairenomservice() qui utilisera une commande Shell pour réaliser l extraction. Avant que l agent ne se dispose, il devra redémarrer le service inetd par la commande : /etc/rc.d/init.d/inetd restart Après avoir détaillé le fonctionnement d un agent IRA, on va maintenant expliquer le rôle d un agent surveillant IRS. Cette agent est crée dés la détection de la première attaque, son rôle est simplement de surveiller tous les agents IRA, il doit consulter le temps que va prendre un agent IRA pour traiter une attaque, s il détecte qu un agent a dépassé un certain temps (y temps = 5 min) il doit le disposer et demander de créer un autre agent IRA pour traiter cette attaque (automatiquement le deuxième agent ne va pas effectuer la même réponse que le premier). Département d Informatique, Faculté des Sciences, Université d Oran 150

150 Chapitre VI DevSecurity Mokaddem FigVII.5 diagramme d'activité d'un agent surveillant IRS Dans la table des alertes, il y a un champ qui indique le temps ou l attaque a été détectée (temps_alerte) et un champ qui indique le temps où le dernier agent de réponse a pris en charge cette attaque. Tout ce fonctionnement est bien expliqué dans le diagramme d activité si dessus. I.5 Les agents de contrôle Après avoir défini l ensemble des agents du système de détection et de réponse. On va maintenant définir le fonctionnement global du système. Mais avant cela, il faudra définir d autres agents, qu on n a pas cité auparavant : l agent surveillant et l agent générateur... Ce sont des agents très importants dont le rôle est de générer, contrôler, et surveiller l ensemble du système, on définira maintenant le rôle de chacun d eux. I.5.1 Les aglets FeuilleDePresence et Drapeau Ces Aglets sont les seules à être créées par le serveur principal. La première est responsable de la création et du déploiement des autres agents du système quant à la deuxième, elle a pour rôle bien précis de rendre possible la reconfiguration et l arrêt du système. DEVSECURITY Dans le diagramme si dessous, on distingue parfaitement le rôle de la classe FeuilleDePresence. Cette dernière est responsable d assurer trois fonctions principales (on parle ici de ses différents rôles) : FigVII.6 : diagramme d activité de la classe FeuilleDePresence Département d Informatique, Faculté des Sciences, Université d Oran 151

151 Chapitre VI DevSecurity FigVII.9 diagramme d'activité de la méthode run() de l'aglet Drapeau. Mokaddem l initialisation des paramètres nécessaires au fonctionnement des autres agents comme par exemple : ceux qui concernent la base de donnée, ou ceux qui définissent les URLs de toutes les machines concernées par le système. Cette fonction n est réalisée qu après avoir fait un accès à la base de donnée, afin d en extraire les informations nécessaires. Ces paramètres ne sont autres que les attributs décrits dans le diagramme de classes si dessous figvii.7. la création de l agent générateur ( qu on décrira ultérieurement). la réception des messages en provenance de l agent Drapeau. DEVSECURITY FigVII.7 : diagramme de classes de la classe FeuilleDePresence Ces deux derniers rôles sont entrepris par les fonctions : oncreation(object init) responsable de la création de l Aglet AgentGenerateur et handlemessage(message msg) qui réceptionne les différents messages adressés à la classe. L agent Drapeau a une fonctionnalité bien précise : consulter en permanence la table irs_snort de la base de donnée diam pour prendre en considération les ordres éventuels de configuration ou d arrêt du système. Comme il est décrit dans ce diagramme, grâce à la valeur du champ «commande», un message correspondant est envoyé à la classe FeuilleDePresence pour effectuer les traitements nécessaires. Ce champ peut varier entre : «0» (normal) qui décrit l état normal, «1» (configurer) qui indique que l utilisateur du système a choisi l option de configuration pour changer les paramètres du système. Autrement dit, toutes les entités du système devront prendre en considération ces changements. Et la valeur «2» (arrêter) qui implique que l utilisateur a choisi d arrêter le système et par conséquent tous les agents devront être détruits. Une partie de cette dernière action sera réalisée par l Aglet elle même, de la façon suivante : Département d Informatique, Faculté des Sciences, Université d Oran 152

152 Chapitre VI DevSecurity Mokaddem FigVII.8 : diagramme d'activité décrivant la procédure de réception de message de l aglet FeuilleDePresence FigVII.10 Diagramme d'activité décrivant la procédure de destruction des agents, exécutée par l'aglet FeuilleDePresence. Comme on le voit dans ce diagramme, l aglet commence d abord par détruire tous les agents à part les EmmetteurRecepteurs, à qui elle enverra ensuite des messages pour qu ils effectuent eux même la destruction des agents qu ils surveillent. C est l Aglet qui s occupe de l envoi des alertes au surveillant, ainsi que de la vérification du bon fonctionnement des agents présents dans les hôtes qu ils surveillent. Au cas où le surveillant ou le contrôleur ne leur répondraient pas, ils peuvent l indiquer au générateur. Mais avant chaque envoi de message ils devront vérifier la disponibilité des agents en question. DEVSECURITY I.5.2 Agent EmetteurRecepteur FigVII.11 diagramme d activité de la méthode run de l'agent EmetteurRecepteur Département d Informatique, Faculté des Sciences, Université d Oran 153

153 Chapitre VI DevSecurity Mokaddem Cet agent a un handlemessage qui définit l ensemble des messages qu il peut gérer. Le diagramme suivant illustre la méthode handlemessage de cet agent et les types de messages qu il peut recevoir, le message verif est envoyé par le surveillant pour savoir si l agent est en marche, le deuxième est envoyé par l agent HIDS pour demander un nouveau filtre. FigVII.12 Diagramme d'activité de la méthode handle message de l agent EmetteurRecepteur I.5.3 Agent Contrôleur Il fait partie des agents créés par le générateur, il s occupe de la création des agents responsables de la détection d intrusion dans chaque hôte. D abord il crée les agents EmmetteurRecepteur, pour les déployer ensuite dans les différents hôtes. Dés leur installation, il l indique au surveillant (par l intermédiaire de l attribut agentspresents de la classe FeuilleDePresence) car ce dernier ne peut être créé si ces agents ne seront pas disponibles. Il s occupe aussi du traitement des messages qu il peut recevoir des agents présents sur les hôtes. Ils peuvent indiquer des demandes de créations d agents spécifiques nécessaires à la détection. FigVII.13 diagramme d activité de la méthode run() de l'agent Controleur DEVSECURITY Le diagramme d activité suivant illustre la méthode handle message de cet agent : FigVII.14 Diagramme d activité de la méthode handlemessage de l'agent controleur I.5.4 Agent surveillant C est l Aglet créé en dernier, car c est la nature de sa fonction qui le demande. Il est responsable de la surveillance des agents qu on vient de citer. A chaque fois qu il se trouve dans un hôte, il envoie des message à tous les agents, et s il ne reçoit pas de réponse ; après trois reprise, de la part de chacun d eux, il alerte soit l agent Controleur (s il s agit des agents Emmetteurrecepteur) soit le générateur. Ce type d alertes, induit le remplacement des entités qui n ont pas répondu au surveillant. Après l envoi de ces messages, il se déplace vers un autre hôte et refait le même travail. Il a aussi la responsabilité de recevoir des alertes indiquant des intrusions, et de réunir les informations nécessaires avant de renvoyer le message d alerte au générateur. Département d Informatique, Faculté des Sciences, Université d Oran 154

154 Chapitre VI DevSecurity Mokaddem Figure 16 : Diagramme d'activité de l'agent surveillant FigVII.16 Diagramme de séquence du cas où un des agents ne répond pas. I.5.5 Agent générateur FigVII.17 Diagramme d activité de la méthode oncreation() de l'aglet AgentGénérateur DEVSECURITY C est l aglet responsable de la création ainsi que du remplacement de certains agents de notre système. C est le troisième agent créé, et ses principales fonctions résident dans deux méthodes : run() et handlemessage(). Lors de la création de ces agents, le générateur initialise la table autreagents de la FeuilleDePresence qui pour l instant était vide. FigVII.18 Diagramme d'activité de la méthode run() de l'aglet AgentGenerateur. Une fois la création faite, il se met à écouter les messages reçus, et suivant leur type il entreprend Département d Informatique, Faculté des Sciences, Université d Oran 155

155 Chapitre VI DevSecurity Mokaddem les actions correspondantes. Dans ce qui suit, un diagramme qui décrit un exemple d échange : entre lui, l Aglet FeuilleDePresence et le Surveillant. FigVII.19 Diagramme de séquences : exemple d échange. On peut dire que le générateur peut recevoir plusieurs types de messages : Des messages lui indiquant des alertes envoyées par l aglet AgentSurveillant, qui les reçoit lui même des agents responsables de la détection d intrusion. Le rôle du générateur ici est de créer les agents de réponses qui vont s occuper d effectuer les réponses nécessaires. Un message reçu de la part de la classe FeuilleDePresence, qui lui indique qu il faut reconfigurer le système. Des messages lui indiquant des problèmes rencontrés lors de la tentative de communication entre le Surveillant et les différents agents (qui seront expliqués plus tard). A chaque message reçu, l agent entreprend les actions nécessaires (un exemple est montré dans le diagramme de séquence de la figure FigVII.19) pour traiter les requêtes qui lui sont adressées. Et pour ce, il devra à chaque réception de message, en plus de mettre en attente la prise en compte du reste des messages, mettre l agent Surveillant en attente. Des attributs supplémentaires devront être marqués, pour indiquer la disponibilité ou non des agents concernés par le traitement. I.6 Fonctionnement Dans cette partie, on va définir le fonctionnement du système multi agents, et ceci dans 3 contexte : au lancement, en cas normal et en cas d alerte. I.6.1 Au lancement La figure FigVII.20 montre bien ce qui se passe après le lancement du serveur. Ce dernier va créer un seul agent, l agent feuille de présence, qui va initialiser tous les attributs nécessaire utilisés par tous les autres agents, puis va créer l agent générateur qui s occupe de créer l ensemble des agents nécessaires :agent générateur, agent surveillant, les agents HIDS, agent surveillant de snort, agent surveillant de la base de données de Snort. D autre part l agent surveillant de Snort va le lancer avec les paramètres désignés par l administrateur stockés dans la table IRS_SNORT de la base de données DIAM. Le serveur Drapeau DEVSECURITY C est le cas où l administrateur devra lancer l application (le serveur d agent), il pourra lancer simplement le fichier fourni (.bat ou script), mais on a préféré réaliser cela via une interface, on parlera de cette interface dans la suite de ce chapitre. FeuilleDePresence AgentGenerateur SurveillantSnort Controleur AgentSurveillant Département d Informatique, Faculté des Sciences, Université d Oran EmmetteurRecepteur 156

156 Chapitre VI NomAgent DevSecurity Mokaddem Indique que la source crée plusieurs entités de la destination. Indique que l entité au dessus, crée celle qui lui est sous-jacente. Indique la direction d un flot de communication. Indique un agent permanent dans le système. DEVSECURITY FigVII.20 Diagramme décrivant le déploiement des agents. FigVII.21 Diagramme d activité décrivant le lancement du système..6.2 En cas d état normal C est l état dans lequel aucune attaque n est détectée et aucun disfonctionnement n apparaît. Ceci englobe, en plus des fonctionnalités d initialisation et de configuration du système, les états dans lesquels les différents IDS n auraient détecté aucune attaque et les agents de surveillance n auraient pas signalé des problèmes de disfonctionnement. I.6.3 Cas d attaque Département d Informatique, Faculté des Sciences, Université d Oran 157

157 Chapitre VI DevSecurity Mokaddem Cette partie décrit la réaction du système en cas d attaque, cependant cette dernière peut être délectée de différentes manières. Si l attaque est détectée par Snort, l agent surveillant de la base de données va détecter qu il y a une nouvelle alerte (même s il y a plusieurs alertes en même temps il va les prendre en charge l une après l autre), il va donc collecter toutes les informations de l attaque (type, IP source, port source, IP destination, port destination, mettre un drapeau d attaque non traitée), puis il va mettre sa propre alerte dans la table Alertes de la base de données diam, puis envoyer un message à l agent surveillant pour lui indiquer qu il y a une nouvelle alerte, et il continue sa surveillance. En parallèle l agent de surveillance va envoyer un message au générateur pour lui demander de créer un nouvel agent de réponse pour une attaque spécifique, ce dernier une fois crée, va mettre le drapeau de cette alerte à en cour de traitement, puis il va se déplacer à l hôte attaqué, l agent surveillant doit aussi surveiller cet agent et voir combien de temps il va rester pour effectuer une réponse, s il dure longtemps alors il va le détruire et demander au générateur de créer un autre agent de réponse (qui doit effectuer un autre type de réponse). DEVSECURITY En cas de nouvelle alerte, l agent de surveillance doit aussi demander à l agent générateur de créer un agent de réponse qui opère dans le poste de l attaquant, si le poste de l attaquant fait partie du segment surveillé, l agent de réponse sera un simple agent mobile aglet qui, après sa création, va se déplacer à la machine attaquante et collecter le maximum d informations et les envoyer à l administrateur ou les mettre dans la table attaquants de la base de données diam, qui pourra être consultée par l administrateur via l interface web conçue à cet effet. FigVII.22 Digramme de séquence dans un cas d attaque II. L interface de l application L interface est réalisée avec des pages HTML pour un accès dynamique et une présentation ergonomique. Pour le reste de l application, on a utilisé des pages JSP et des Beans java (plus quelques pages incluant du java script). On va maintenant définir les différents menus et sous menu du site avec le schéma suivant : Département d Informatique, Faculté des Sciences, Université d Oran 158

158 DevSecurity Mokaddem DEVSECURITY Chapitre VI FigVII.23 : Diagramme d'activités pour l'accès aux différents menu et pages du site II.1. Premier lancement et authentification Pour accéder au système, l utilisateur procéder à une authentification, car le système n est accessible qu aux utilisateurs ayant droit. La page d accueil est login.jsp. Si c est le premier lancement, l administrateur sera redirigé automatiquement vers une autre page bienvenue.jsp où il devra donner la configuration initiale du système, et créer un nouveau compte (nom d utilisateur + mot de passe) qu il va utiliser pour s authentifier pour les prochaines sessions, puis le Bean de cet JSP va se charger d installer tous les composants : tous les packages nécessaires, la base de données diam et toutes ses tables. Si l utilisateur tente d entrer dans une autre page sans passer par l authentification login.jsp, il sera toujours redirigé automatiquement à cette page. Ceci est réalisé grâce à une JSP qui vérifie si l utilisateur Département d Informatique, Faculté des Sciences, Université d Oran 159

159 Chapitre VI DevSecurity Mokaddem s est authentifié ou non, cette JSP, inc_pass.jsp, est incluse dans toutes les autres pages JSP. Ceci évite de recopier son code dans toutes les autres pages. Ceci est dû grâce à la balise, ci-dessous, qui se trouve dans toutes les pages en questions : <jsp:include page="inc_pass.jsp"/> II.2. Configuration Une fois, l utilisateur authentifié, il pourra configurer le système, les options de configuration qu on a mis en œuvre sont les suivantes : Le réseau à surveiller : visualise toutes les machines surveillées dans le réseau (définies par l adresse IP ou le nom, et l état, allumé ou non, de la machine), on pourra donc ajouter d autres hôtes ou d en supprimer d autres, Configurer Snort : l utilisateur pourra configurer Snort en changeant ses paramètres de lancement, ajouter une nouvelle règle à la base de règles de Snort, etc Activer/désactiver le système de réponse : permet d autoriser ou non le fonctionnement du système de réponse, dans le cas où il est désactivé, une alarme sera émise dés la détection d une attaque. Menu de gestion des utilisateurs : notre système est accessible à différents utilisateurs, chacun possédant un username, password, et un ensemble de privilèges. Cette option permet donc d avoir un menu pour modifier les paramètres d un utilisateur, supprimer/créer un compte utilisateur. Seul l administrateur a tous les droits d accès (tous les privilèges), et il est le seul pouvant changer les privilèges d un utilisateur, les autres utilisateurs ne peuvent que changer leurs paramètres. Les privilèges conçus pour chaque utilisateur sont les suivants : o o o o droit de lancer le système ; droit d arrêter le système ; droit de reconfigurer le système droit de gérer les comptes utilisateurs II.3 Etat du système Pour archiver les états par lesquels passe notre système, on utilise notre base de donnée. L état du système est décrit par ses différents composants : les agents, les alertes, les utilisateurs et la configuration actuelle. On a déjà abordé ce point quand on a décrit les tables de la base de données, une partie de ces tables (agents_presents, agent_tues) est utilisée juste pour voire l état des agents et leur fonctionnement. L utilisateur pourra donc voir : DEVSECURITY Donc, les droits d accès des utilisateurs sont consultés et vérifiés avant d autoriser l accès. Pour cela, on a crée un Bean qui s occupe de vérifier si l utilisateur a les droits nécessaires ou non pour accéder à telle ou telle option. Le diagramme de la figure Fig.VII.24 montre la classe de cet agent : Les agents du système : les agents qui sont en cours d exécution et ceux qui ont été disposés. Les utilisateurs du système avec leur état (connecté ou non connecté) Les alertes émises par le système, et l archive d alertes. Les machines surveillées. FigVII.24 Diagramme de classes du bean de vérification des droits d accès. Département d Informatique, Faculté des Sciences, Université d Oran 160

160 Chapitre VI DevSecurity Mokaddem III.4 Aide Cette partie permet de faciliter l utilisation du logiciel. Dans cette section l utilisateur pourra voir toutes les actions possibles et comment les effectuer. III Vue du Système Après avoir décrit l architecture du système (Système multi agents et interface Web), on va maintenant décrire son intégration avec le serveur Web. Au début, assurez vous que tout est bien installé (Aglets, Snort, MySQL). L ensemble des agents Aglets doit être sauvegardé dans le répertoire public du répertoire d installation des Aglets (seulement dans le poste de l administrateur), assurez vous aussi que le serveur d aglets est bien lancé dans tous les postes qu on veut surveiller. Pour vous expliquer l accès à l interface du système, on débutera avec la page d installation. Mais il faut s assurer que le serveur Web TomCat soit en marche, et bien sûr l administrateur du système doit mettre les pages JSP de l interface dans le sous répertoire webapps du répertoire d installation de TomCat. Une fois le serveur en marche, l utilisateur doit ouvrir son browser et taper l adresse suivante : de l hôte administrateur> :8080/diam/login.jsp. Si l application n est pas installée : premier lancement, l administrateur sera redirigé vers la page d installation, où il devra donner une configuration initiale du système : compte administrateur, hôtes à surveiller etc. DEVSECURITY Puis valider tout, il doit cliquer sur le bouton Lancer, qui permettra de lancer l installation des packages nécessaires, la base de données Diam et toutes ses tables et un fichier diam.props, qui sera chargé au prochain lancement pour avoir les propriétés du système. (FigVII.25) Une fois l installation achevée, vous serez amené à vous identifier au système via une page d authentification, (FigVII.26) Département d Informatique, Faculté des Sciences, Université d Oran 161

161 DevSecurity Mokaddem DEVSECURITY Chapitre VI Figure VII.25 : Page d'installation Donnez la configuration initiale du système et cliquer sur le bouton Lancer, Département d Informatique, Faculté des Sciences, Université d Oran 162