Comportements coopératifs d’auto-ajustement de paramètres ... · Comportements coopératifs...

Comportements coopératifs d’auto-ajustement deparamètres pour la surveillance maritime

Rapport de Master 2 RechercheInteraction, Coopération et Systèmes Complexes (ICSC)

à l’Université Paul Sabatier (UPS) – Toulouse III

15 juin 2009

Jérémy Rivière

Laboratoire d’accueil : Institut de Recherche en Informatique de Toulouse (IRIT)Directeur de recherche : Marie-Pierre Gleizes

Responsable(s) de stage : Jean-Pierre Georgé, Marie-Pierre GleizesEquipe d’accueil : Systèmes Multi-Agents Coopératifs (SMAC1)

Mots-clés : Système multi-agent, coopération , ajustement de paramètres, apprentissage , feedback

Résumé : La surveillance maritime observe les évolutions permanentes du trafic dense dans une zonemaritime globale pour suivre les flux de marchandise transportée, acquérir une meilleure connaissancesur ces flux, en améliorer le suivi, et finalement détecter les anomalies (flux de produits illicites, sinistres,violations à la règlementation, etc.) Le projet ANR ScanMaris est destiné à remplacer à long terme lesmoyens de surveillance actuels, insuffisants au vu de l’augmentation du trafic et des espaces d’échanges.L’architecture proposée pour détecter ces comportements anormaux au niveau des navires est compo-sée de deux Systèmes Multi-Agents (SMA) : OpMAS et PAMAS. Le rôle de OpMAS, pour OperativeMulti-Agent System, est de maintenir une criticité représentant l’état de chaque navire, et déclencherdes alertes pour assister le contrôleur dans sa tâche de surveillance. Le système PAMAS, pour Para-meter Adjuster Multi-Agent System, a pour rôle l’ajustement des paramètres réglant le mécanisme delevée d’alertes de OpMAS, dans le but d’obtenir une levée d’alertes fiable et efficace. L’objectif de monstage est d’une part d’implanter la partie décisionnelle d’un agent de OpMAS, et d’autre part concevoirle système multi-agent PAMAS.

1SMAC: Systèmes Multi-Agents Coopératifs

Sommaire

Introduction 1

1 État de l’art 31.1 Systèmes de levée d’alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Méthodes d’ajustement de paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Contexte de l’étude 112.1 Le projet ScanMaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Architecture de OpMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Fonctionnement de l’OpMAS 213.1 Concepts manipulés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Dépôt de marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Composition des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Expérimentations et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 PAMAS : Système Multi-Agent d’Ajustement de Paramètres 274.1 Les paramètres de levée d’alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Approche par Amas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Expérimentation et analyse des résultats 375.1 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Conclusion 435.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Annexe 45

Glossaire 55

Bibliographie 57

iii

Introduction

Les activités maritimes occupent depuis longtemps une place très importante au niveau commercialdans l’Union Européenne (UE). En effet, plus de deux tiers des frontières de l’UE étant côtières, 90 pourcent des échanges extérieurs, et près de la moitié des échanges intérieurs utilisent le transport maritime.On peut voir sur la figure 1 l’importance que prennent les routes maritimes (en bleu) en Europe.

FIG. 1 — Routes Commerciales Maritimes

Depuis plusieurs années cependant, les espaces maritimes sont de plus en plus exploités, et l’acti-vité s’éloigne de plus en plus des côtes. La surveillance et la gestion des eaux territoriales ne suffisentplus à garantir la sécurité et la fiabilité de la circulation. De même, le contrôle du trafic maritime n’estpas extensible efficacement aux Zones Economiques Exclusives (ZEE), qui s’étendent sur 200 miles parrapport aux 12 qui constituent les eaux territoriales.

C’est dans ce contexte particulier que le projet ANR ScanMaris a vu le jour, dans le but de comblerles insuffisances des systèmes de surveillance actuels, et de garantir une circulation fiable et sécurisée.Le projet ScanMaris doit mettre à la disposition de l’opérateur de surveillance maritime un systèmed’aide à la décision, dont la fonctionnalité principale est d’indiquer à cet opérateur les navires qui ont uncomportement suspect. Ces comportements peuvent être des avaries, des violations à la réglementation,des flux de produits illicites... La difficulté consiste à définir ce qu’est un comportement suspect, associéeau grand nombre de navires en circulation au même moment. L’objectif du projet est de mettre en placeun SMA adaptatif de détection d’anomalies.

Les anomalies détectées peuvent se cumuler pour un navire donné, et si ce cumul dépasse un cer-tain seuil d’alerte, le système doit informer l’opérateur sur l’état du navire concerné. L’objectif d’un telsystème est d’éviter au maximum les faux positifs et d’être efficace au niveau de la détection de cesalertes. Ce mécanisme de levée d’alerte est réglé par des paramètres dont l’ajustement permet d’obtenir

1

Introduction

le comportement global désiré, ou simplement afin de visualiser l’impact de leur modification.Habituellement, ces paramètres sont réglés manuellement, soit a priori par des experts, soit empiri-

quement au cours des exécutions successives du système. Toutefois la multitude de ces paramètres etleurs interdépendances rendent ces réglages très coûteux, et souvent irréalistes du fait du risque d’ex-plosion combinatoire. Nous allons voir que, de part la nature évolutive et complexe de ces paramètres,les méthodes manuelles, formelles [J. Ragot, 1999] , ou bio-inspirées [Werbos, 1974] , [Holland, 1975]d’ajustement de paramètres ne pourront pas s’appliquer ici.

L’objectif de ce travail de Master 2 Recherche est donc d’une part de concevoir la partie décisionnelledes agents du SMA de détection d’anomalies et d’autre part de mettre en place des mécanismes d’ajus-tement dynamiques (en cours de vie du système) et autonomes (non supervisés), basés uniquement surl’auto-adaptation du système à son environnement. Cela consiste à introduire un second système multi-agent en parallèle du premier, qui en réponse à des stimuli de son environnement, a la possibilité demodifier ces paramètres fonctionnels.

La première partie de ce mémoire fait un état de l’art des systèmes d’aide à la décision en général, etde levée d’alerte en particulier. Nous verrons également quelles sont les différentes méthodes d’ajuste-ment de paramètres qui peuvent exister. Nous détaillerons dans la deuxième partie le projet ScanMarisdans son ensemble et le système multi-agent opérationnel de surveillance. Nous présenterons les diffé-rentes méthodes et outils utilisés pour la réalisation de ce travail. La troisième partie présente le com-portement des agents qui détectent les anomalies et notamment l’approche réalisée pour cumuler lesanomalies. La quatrième partie concerne la mise en place du système multi-agent d’ajustement de pa-ramètres, l’approche effectuée et les modes de coopération utilisés. Enfin, la cinquième partie présenteles expérimentations effectuées et l’analyse des résultats obtenus, et nous verrons quels peuvent être lesbilans et perspectives de ce projet.

2

1 État de l’art

L’objectif de cette étude est de proposer une système de levée d’alerte pertinent et efficace, capabled’apprendre et de modifier ses paramètres fonctionnels suite à un rétro-contrôle de l’opérateur. Ce tra-vail porte sur deux domaines : les systèmes d’aide à la décision et de levée d’alerte, et les différentsmécanismes d’ajustement de paramètres.

Dans ce chapitre, nous verrons donc tout d’abord les principales méthodes utilisées dans les sys-tèmes d’aide à la décision, en commençant par les méthodes conventionnelles, puis en détaillant cellesqui utilisent des systèmes multi-agents. Ensuite, nous passerons en revue les méthodes existantes d’ajus-tement de paramètres les plus utilisées, en les séparant en trois types : les conventionnelles, les évolu-tionnistes et les méthodes utilisant des systèmes multi-agents.

1.1 Systèmes de levée d’alertes

Les systèmes de levée d’alertes sont une catégorie des systèmes d’aide à la décision, qui sont aujour-d’hui utilisés dans de nombreux domaines, comme le médical, la surveillance, ou encore en gestion. Lessystèmes d’alerte peuvent déduire par raisonnement plus ou moins dirigé, qu’il est nécessaire de leverune alerte, et la transmettre à un opérateur de surveillance, ou à un autre système. Nous allons voir danscette partie différents types de systèmes d’alerte, en commençant par ceux que l’on peut trouver commesystèmes de détection d’intrusion, puis nous verrons ceux qui utilisent des méthodes multi-agents.

1.1.1 Méthodes conventionnelles

La majorité des systèmes d’alerte concerne la surveillance des systèmes d’information et des réseauxassociés. Ce sont des systèmes de détection d’intrusion qui suivent soit des approches comportemen-tales soit des approches par scénarios. Des processus de corrélations d’alerte peuvent être couplés à cegenre de système, dans le but de limiter les faux positifs. Ces processus sont basés pour la plupart surdes modèles, des graphes ou de réseaux bayésiens, qui font le lien entre les différentes actions entre-prises par l’utilisateur.

Approche comportementale L’approche comportementale consiste à définir tout d’abord un compor-tement type de l’utilisateur, de ses activités ou de l’activité réseau, puis de détecter toutes déviations,ou anomalies, par rapport à ces modèles. On peut trouver trois méthodes pour définir ces modèlescomportementaux [Jacob and Ludovic, 2002] :

1. méthode probabiliste,

2. méthode statistique,

3. réseaux de neurones .

Cependant, il est difficile de définir un comportement normal pour les navires, étant donné la quan-tité de types de navire, que les règles ou les usages de circulation sont différents selon chaque type, etqu’il faudrait un corpus d’apprentissage conséquent et sans infraction pour que le système apprennecorrectement ce qu’est un comportement normal.

3

Chapitre 1. État de l’art

Approche par scénarios L’approche par scénarios consiste à comparer les entrées, les utilisations dusystème et les actions entreprises par l’utilisateur à des bases de scénarios (aussi appelées base de signa-tures). Si le comportement observé correspond à une des signatures, le système lève une alerte.

La difficulté d’une telle approche réside dans la construction de la base des signatures : en effet,il est nécessaire de former une base de scénarios pertinents, et suffisamment exhaustive pour couvrirla majorité des cas que l’on peut rencontrer. Or, dans un système ouvert tel que l’environnement deScanMaris, il est pratiquement impossible de construire une telle base, car le nombre de situations quel’on pourrait rencontrer est potentiellement illimité et évolue constamment.

1.1.2 Méthodes multi-agents

Les systèmes multi-agents coopératifs (2.2.1), de part leur nature coopérative et distribuée, semblentadaptés pour le raisonnement et la surveillance. Nous développerons d’abord un exemple de systèmemulti-agent dédié à la surveillance maritime et plus particulièrement à la reconnaissance d’intention.Puis nous verrons deux travaux de systèmes d’alerte multi-agents dans le domaine de la météorologieet de la médecine.

Surveillance maritime

Oliver Tan [Tan, 2005] propose en 2005 un système multi-agent composé d’agents surveillant cha-cun un navire. Ces agents sont eux-mêmes composés de deux types d’agents, des agents réactifs à unpremier niveau, et des agents cognitifs aux niveaux en-dessous (voir 1.1).

FIG. 1.1 — Agent de surveillance

Les agents cognitifs sont dotés de fortes capacités de raisonnement : règles et modèles de plan d’in-tention. Les agents réactifs reçoivent les informations de plusieurs outils récents de surveillance dontl’AIS 1, et les fait passer aux agents cognitifs qui appliquent sur ces informations des règles définies

1Automatic Identification System : système d’échanges automatisés de messages entre navires par radio qui permet auxnavires et aux systèmes de surveillance de trafic de connaître l’identité, le statut, la position et la route des navires en situation

4

1.1. Systèmes de levée d’alertes

préalablement par des experts. Concrètement, chaque agent cognitif représente une famille de règles, ettraite individuellement chaque information. Puis les résultats sont regroupés, et les agents d’intention,qui représentent le dernier niveau de l’agent de surveillance, donnent de la signification à ces infor-mations pour définir un modèle d’intention : le navire est-il amical, neutre, potentiellement hostile ouinconnu ? Le traitement de ces informations passe par un système de poids attribués en fonction de leurpertinence, et qui définissent le mieux les intentions probables de l’agent. Ces poids sont définis parl’utilisateur. Enfin, des agents de plus haut niveaux surveillent les plans d’intention que chaque agentde surveillance a déduit pour son navire, et à l’aide d’une base de plans d’attaques terroristes, peutdétecter les intentions globales de plusieurs navires.

On peut voir qu’un tel système dépend beaucoup des connaissances expertes relatives au domaine.Par exemple, les poids utilisés pour traiter les informations et en déduire les plans d’intentions doiventêtre soigneusement calibrés par des experts. Les règles et les modèles d’attaques terroristes sont égale-ment importantes pour la détection, et dépendantes de ces connaissances expertes. Ce système n’a pasde possibilité d’apprentissage ou d’adaptation. Une fois qu’un navire a été considéré comme potentiel-lement hostile, le système n’oubliera pas ses violations ni son comportement, ce qui, en cas d’erreur,peut parfois poser problème. De plus, il est nécessaire de retoucher au système si certaines règles denavigation changent, si de nouveaux plans doivent être rajoutés ou enlevés, ou si les poids attribuésdoivent être modifiés.

Autres domaines

Deux systèmes multi-agents vont être ici abordés, dans les domaines de la météorologie et de lamédecine, et nous verrons les avantages et les limites de ces systèmes.

Météorologie Les travaux de Sandy Dance [Dance et al., 2003] du Service des Bureaux australiens deMétéorologie présentent un système multi-agent distribué pour la levée d’alerte météorologique, basésur une architecture d’agent BDI (Belief, Desire, Intention) [Rao and Georgeff, 1995]. Le système doitlever une alerte lorsqu’il trouve des inconsistances ou des divergences entre les prévisions météorolo-giques et les observations en temps réels.

La communication entre agents se fait via une architecture publisher/subscriber 2, ce qui garantitla flexibilité du système en cas de panne de certaines parties. Les agents reçoivent les informationsà partir de plusieurs sources, comme des serveurs reliés aux senseurs météo et des boîtes mail, parabonnement. Ce système peut être assimilé à un système expert : une fois les données récoltées, lesagents, d’après leurs croyances et les événements déclenchés, suivent grâce à un moteur d’inférence desplans préalablement établis qui peuvent amener à communiquer avec d’autres agents pour partager ourechercher des informations, ou à lever une alerte.

Il est nécessaire dans un système comme celui-ci de spécifier ce qui va être détecté par les agents, etconstruire les plans qui vont être associés à des situations particulières. Etant donné le grand nombrede situations et d’actions possibles en réponse à une situation, un tel système n’est pas réalisable pourle système de surveillance ScanMaris.

Médecine Le programme européen Citizen Health System (CHS) mis en place en 2003 a pour but defaciliter le dialogue entre des patients à domicile atteint de maladies chroniques 3 et des équipes médi-cales de suivi. Les patients disposent d’outils multimédia pour communiquer avec un centre d’appelsqui recueille les informations des patients et leurs demandes, et les transmet si nécessaire aux équipesmédicales. Dans le cadre de ce projet, V. Koutkias [Koutkias et al., 2002] présente un système multi-agent destiné à traiter les informations transmises par le patient en temps réel, repérer celles qui sontpertinentes et alerter les équipes médicales sur la santé d’un patient. Les agents exploitent de règles

2Communication par abonnements3Concrètement le système couvre le diabète et l’insuffisance cardiaque

5


prédéfinies, extraites au préalable d’autres règles ou définies par des experts médicaux, pour fixer desseuils d’alerte des paramètres vitaux que le système contrôle.

L’intervention d’experts dans le développement du système limite toute flexibilité pour s’adapterou évoluer. De plus, la communication du système semble à sens unique avec les services médicaux :on pourrait imaginer la possibilité pour ces équipes de renvoyer des feedbacks, ce qui permettrait unemodification non-supervisée des règles pour limiter les faux-positifs, tout en assurant la détection d’unesituation nécessitant une alerte.

1.2 Méthodes d’ajustement de paramètres

Il existe de nombreux processus que l’on sait dépendre d’un nombre plus ou moins conséquents deparamètres, sans que l’on ait de modèles analytiques permettant de connaître et d’anticiper les valeursde ces paramètres. On ne peut pas toujours savoir quels sont les facteurs les plus influents, quellesdépendances les lient et dans quel sens le système va évoluer. C’est le cas par exemple des systèmescomplexes, dont le comportement global dépend de la valeur de ces paramètres fonctionnels. Il est alorsdifficile [Di Marzo Serugendo et al., 2006] de régler ces paramètres pour obtenir le comportement globaldésiré.

Le modèle multi-agent des fourmis fourrageuses présenté dans le projet Ants [Topin et al., 1999],montre bien l’importance de trouver un jeu de paramètres qui fasse correspondre la simulation au mo-dèle observé dans la nature. Parmi ces paramètres, on peut changer le nombre de fourmis participantà la simulation, les taux d’évaporation et de diffusion de la phéromone déposée par les fourmis. Lesfourmis interagissent indirectement par le biais de la phéromone, et de ces interactions locales un com-portement global peut être observé : c’est la définition du phénomène d’émergence. Ainsi, en modifiantle taux d’évaporation, on a un comportement global totalement différent [Calvez, 2007].

Il est donc nécessaire de donner des valeurs pertinentes à ces paramètres, et pour cela deux grandesfamilles de méthodes existent : les méthodes empiriques et les méthodes bio-inspirées.

1.2.1 Méthodes empiriques

Lorsque l’on peut définir un modèle mathématique des paramètres d’un système, la phase de para-métrage revient à une étude mathématique d’un ensemble d’équations, souvent fortement dépendantdu domaine étudié. Ainsi, pour ajuster les paramètres d’un multi-régulateur [J. Ragot, 1999], le régula-teur est ramené à une expression analytique. Ensuite, ses paramètres sont ajustés dynamiquement paridentification aux performances demandées par l’intermédiaire d’un modèle de référence. Le modèlemathématique nécessite une connaissance experte du domaine des régulateurs, et n’est applicable quepour ce domaine.

Ajustement manuel

De même que les systèmes modélisables de façon analytique, l’ajustement manuel nécessite souventune connaissance experte du domaine. Cela est nécessaire pour comprendre l’importance de certainsparamètres par rapport à d’autres, quelles sont les dépendances entre eux et quelles sont les valeursapproximatives que ceux-ci doivent prendre pour satisfaire le système. Cette méthode est souvent peuprécise, laborieuse, difficilement automatisable et non dynamique.

Les plans d’expérience

L’encyclopédie en ligne Wikipédia4 définit le plan d’expérience comme « l’organisation d’une expé-rience dont le déroulement lui-même sera conditionné par les résultats obtenus en cours de route ».

4http ://fr.wikipedia.org/wiki/Accueil

6

1.2. Méthodes d’ajustement de paramètres

La méthodologie des plans d’expérience ou protocole expérimental [Dagnelie, 2003] permet de ré-pondre aux questions délicates posées ci-dessus, à savoir :

1. Quels sont les paramètres qui ont le plus d’influence sur le comportement global ?

2. Quels sont les corrélations existantes entre les différents paramètres ?

3. Comment minimiser le nombre de points de mesure de l’expérience pour obtenir le maximumd’information ?

Une approche naïve, c’est-à-dire systématique, reviendrait à effectuer toutes les expériences pos-sibles en faisant varier chacun des paramètres dans son domaine de définition, ce qui entraine, avec ungrand nombre de paramètres, une explosion combinatoire.

Dans l’article de Treuillet [S. Treuillet, 2004], un plan d’expérience est défini d’un point de vue plusindustriel. Il est vu comme une suite d’essais rigoureusement organisés, afin de déterminer avec un mi-nimum d’essais et un maximum de précision, l’influence respective des différents paramètres de concep-tion ou de fabrication afin d’en optimiser les performances. L’objectif du travail est l’amélioration d’unsystème de vision qui permet la mesure du taux de collet d’un lot de betteraves. La mesure effectuéedépend d’une dizaine de facteurs et nécessite plusieurs minutes, le but étant d’extraire efficacement lesinformations de l’image pour des gestions de production.

Treuillet utilise les plans d’expériences factoriels fractionnaires, ce qui permet de ne pas tomberdans l’approche naïve en réduisant le nombre d’expériences, et de démontrer rapidement l’existenced’interactions entre les paramètres.

Les plans factoriels mettent en oeuvre les paramètres normalisés, il faut donc que soient définis lesminimums et les maximums de chaque paramètre. Ce type de méthode n’est pas applicable à notre pro-blématique, car il est nécessaire dans tous les cas de connaître les domaines de définition des paramètres,ce qui est impossible de savoir a priori dans ScanMaris.

1.2.2 Méthodes bio-inspirées

Nous allons voir ici deux grands domaines des méthodes inspirées de la biologie, les algorithmesgénétiques et les réseaux de neurones, et nous nous interrogerons sur leurs applications à l’ajustementdynamique de paramètres.

Algorithmes génétiques

Le domaine des algorithmes génétiques apparaît dans les années soixante, notamment avec JohnHolland [Holland, 1975] considéré par beaucoup comme le « père »des algorithmes génétiques. Le prin-cipe est simple : il s’agit de faire évoluer une population d’individus représentant des solutions possiblesdu problème posé, jusqu’à parvenir à (ou aux) l’individu solution. On caractérise cette évolution en deuxétapes, la sélection des individus les plus proches de la solution à chaque itération, et deux mécanismesgénétiques, les croisements et les mutations.

Chaque individu a un génome, et chaque gène représente un paramètre différent. Tous les individussont différents. Au départ, on crée un nombre X d’individus, avec des valeurs aléatoires pour les gènes.Puis, les meilleurs sont sélectionnés suivant des méthodes statistiques (sélection par roulette, tournoi), eten fonction du résultat obtenu à l’évaluation d’une fonction de fitness. Dans la théorie de l’évolution deDarwin, cette fonction serait l’environnement des individus. Elle permet de récompenser les individusles plus aptes (les plus près de la solution) et de punir les moins adaptés. Trouver une bonne fonctionde fitness est en général la principale difficulté des algorithmes génétiques [Merz, 2000]. La populationsélectionnée va alors subir des mutations aléatoires et certains individus seront croisés pour augmenterles chances de trouver la solution, en privilégiant la nouveauté et l’exploration.

Outre la fonction de fitness, les valeurs choisies du nombre d’individus que l’on garde à chaqueitération, la proportion de mutations et de croisements, peuvent avoir une grande influence sur le tempsd’exécution de l’algorithme, et le nombre d’itérations nécessaires à son aboutissement.

Dans l’optique d’ajuster dynamiquement les paramètres de notre système de levée d’alerte, les al-gorithmes génétiques poseraient principalement un problème de temps, et ne conviendraient pas à un

7


ajustement en temps réel. En effet, les individus étant chacun un jeu différent des paramètres pour lesanomalies, la meilleure fonction de fitness serait de faire jouer chaque individu dans la simulation, et desélectionner ceux qui obtiendraient le moins de feedback. De plus, au vu de la grande plage de valeurspossibles a priori pour chaque paramètre, il faudrait prendre un grand nombre d’individus à chaqueitération.

Réseaux de neurones

Les réseaux de neurones artificiels s’inspirent des neurones réels, de leur capacité d’apprentissage,de connexion et d’ajustement dynamique dans l’espace. Les réseaux tels que nous les connaissons au-jourd’hui ont été présentés par Rosenblat en 1958 [Rosenblatt, 1958], avec le principe du Perceptron etses trois couches, couche d’entrée, de sortie et cachée. Nous allons nous intéressés plus particulièrementaux réseaux introduits par Paul Werbos [Werbos, 1974] dotés d’un mécanisme de rétro-propagation.

Les réseaux de neurones peuvent-ils résoudre la problématique que nous nous sommes fixés ? Lepoint délicat pour les réseaux de neurones réside dans l’apprentissage. Il faut avoir un corpus de scéna-rios sur lesquels le réseau va apprendre qui soit exhaustif, où toutes les situations se retrouvent, et ennombre égal de fois pour éviter le sur-apprentissage, tout en ne tombant pas dans le sous-apprentissage,dans le cas de l’apprentissage supervisé [Georgé, 2004].

Le problème que cela pose pour nous dans le cadre du projet ScanMaris est le même que précédem-ment, avec les algorithmes génétiques. Au vu de la multitude des situations qu’un navire peut rencon-trer, et donc du nombre de scénarios nécessaires pour obtenir un apprentissage équilibré, le temps seraitl’inconvénient majeur de cette méthode.

1.2.3 Méthodes multi-agents

Les systèmes multi-agents, de part leur nature adaptative, autonome et coopérative, peuvent êtreune solution intéressante au problème de l’ajustement dynamique des paramètres. Plusieurs étudesvont dans ce sens, et nous en verrons ici deux : le projet Staff et le projet Mascode, tous deux réalisés parl’équipe SMAC. La théorie des systèmes multi-agents adaptatifs (des Amas) sera détaillée en 2.2.1.

Le projet Staff

Staff 5 est un système adaptatif de prévision de crues [Georgé et al., 2009]. Les agents composantce système représentent des capteurs réels collectant des informations telles que le niveau d’eau et lapluviométrie. Un agent, de part sa valeur, est donc un paramètre à ajuster, et il n’a a priori pas plusd’importance qu’un autre : il faudrait pour savoir cela des connaissances expertes dans ce domaine, quiconduiraient à des modèles physiques complexes et variés. Les théories multi-agents cherchent à évitercela. Dans ce projet, chacun des agents possède un poids associé (voir la figure 1.2), et, par une sommepondérée, ils produisent une courbe représentant la variation du niveau d’eau sur plusieurs heures àl’avance [Sontheimer et al., 2001].

Il s’agit ensuite, à chaque nouvelle mesure réelle de la station, de comparer la prévision du systèmeavec cette mesure : si la valeur prévue en est trop éloignée, alors les agents, en accord avec la théorie desAmas ( voir 2.2.1 ), vont ajuster leur poids pour produire une nouvelle somme pondérée dont la valeursuivra au plus près la courbe des valeurs réelles. Le système ajuste donc dynamiquement ses paramètresen réponse à un feedback qui est la distance entre la prévision et la courbe des valeurs réelles.

Le projet Mascode

Mascode [Welcomme et al., 2006] est un système multi-agent adaptatif pour concevoir des produitscomplexes. Ce système est associé à une application à la conception préliminaire d’un avion. Il a été misen place pour répondre à la complexité structurelle de ce problème par coopération et par adaptation.

5Software Tool for Adaptive Flood Forecast

8

1.3. Conclusion

FIG. 1.2 — Staff : Composition du SMA capteurs

Dans ce cas, les paramètres sont ceux des domaines qui interviennent dans la conception des avions,comme l’aérodynamisme ou la masse de l’avion. Il existe des interdépendances entre ces paramètres, etils peuvent être à la fois des entrées du système et des sorties. Le but de l’ajustement de ces paramètresest de satisfaire les contraintes en sortie du système émises par celui qui conçoit l’avion. Pour cela, àtous moments, les agents adaptent leur valeur par rapport aux feedbacks qu’ils reçoivent, et tentent desatisfaire l’agent qui est le plus critique dans le système, en accord avec la théorie des Amas ( voir 2.2.1). Ici, les feedbacks sont des modifications dans l’environnement de l’agent qui amènent à de nouvellessituations. L’agent au niveau local peut percevoir ces feedbacks comme positifs, c’est-à-dire que sesactions passées contribuent à améliorer l’environnement, ou négatifs, ses actions sont en contradictionavec les nouvelles situations.

1.3 Conclusion

Nous avons vu dans cet état de l’art que parmi les méthodes de levée d’alertes présentées, les plusintéressantes étaient celles à base de systèmes multi-agents. La nature même de ces systèmes constituésd’entités autonomes, distribués et coopératives pourrait permettre dans le cadre du projet ScanMarisune gestion globale et une surveillance améliorée. Dans la partie suivante, nous allons présenter lesystème multi-agent de surveillance développé par l’équipe SMAC, et nous allons voir les réponsesapportées aux inconvénients de certains systèmes, comme le besoin de connaissances expertes.

De même, les systèmes multi-agents semblent bien adaptés à la problématique d’ajustement des pa-ramètres. L’objectif de ce mémoire est d’utiliser les avantages apportés par les systèmes multi-agents etnotamment la théorie des Amas (2.2.1), pour développer un système autonome et dynamique d’ajuste-ment de paramètres.

9

2 Contexte de l’étude

Dans ce chapitre, nous allons voir dans quel contexte ce travail se situe. Une première partie présentele projet ScanMaris dans lequel s’intègre mon travail de Master Recherche. La seconde partie présenteles outils utilisés lors de cette étude, les théories sous-jacentes et la plateforme multi-agent qui a servi àimplémenter le système. Enfin, je décrirai l’architecture de OpMAS existant au début de mon stage.

2.1 Le projet ScanMaris

Le projet ScanMaris est un projet ANR 1 coordonnée par DCNS 2, en partenariat avec les entreprisesSOFRESUD et ECOMER, et les organismes de recherche ENSMP3, IRIT, ONERA 4 et CDMT 5. Le butde ce projet est d’augmenter l’efficacité de la surveillance et de la gestion des activités maritimes. Il doitamener à un prototype de système d’aide à la surveillance, dont l’objectif est d’indiquer à un opéra-teur humain les navires dont le comportement est suspect, et de quantifier cette suspicion. ScanMarisintègre des sources d’informations hétérogènes, dont de nouveaux capteurs comme les radars hautesfréquences qui permettent une plus grande zone de détection.

L’architecture du projet est présentée sur la figure 2.1. Le système multi-agent pour la générationd’alerte, appelé OpMAS, est relié par un bus de communication avec les trois principales entités duserveur d’application : la situation renseignée (SITU), le serveur de plages de normalité (NORM) et lemoteur de règles (MAN).

La situation renseignée (SITU) est une base de données dynamique qui recueille et fusionne tousles renseignements obtenus grâce aux moyens de détection, comme les radars sur les côtes, l’AIS6 et lesradars longue portée, qui couvrent ensemble de grandes zones maritimes. Ces données sont égalementcombinées avec des informations auxiliaires provenant de bases de données en ligne comme LLOYD’sRegister par exemple, qui est une société de classification maritime. A chaque mise à jour d’une situa-tion, c’est-à-dire quand un nouveau navire est détecté, ou une nouvelle position d’un navire, la SITUtransmet cette mise à jour à OpMAS et au serveur d’invariance, que nous allons voir. La SITU entretientles données de zone maritime, de temporalité et de position. OpMAS communique avec la SITU poursoumettre des marques créées par les agents, et pour indiquer à l’opérateur quels sont les navires quisont en alertes. L’opérateur utilise également la SITU pour transmettre les retours (feedbacks) négatifs.

Le serveur de plages de normalités (NORM), ou serveur d’invariance, définit pour chaque navirede la situation une plage d’invariance à partir des informations transmises par la SITU. Par exemple,pour un navire de type tanker qui avance à 50 noeuds, le serveur d’invariance peut définir une plage devitesse allant de 45 à 55 noeuds : le but étant d’indiquer à OpMAS à chaque sortie de plage d’invariance

1Agence Nationale de la Recherche2Direction des Constructions Navales3Ecole Nationale Supérieure des Mines de Paris4Office National d’Etudes et Recherches Aérospatiales5Centre de Droit Maritime et des Transports6Automatic Identification System : système d’échanges automatisés de messages entre navires par radio qui permet aux

navires et aux systèmes de surveillance de trafic de connaître l’identité, le statut, la position et la route des navires en situation

11

Chapitre 2. Contexte de l’étude

FIG. 2.1 — Architecture générale de la plateforme ScanMaris

que le navire concerné a changé de contexte de fonctionnement. Le moteur de règles (MAN), appeléMoteurs d’Analyse Navire sur la figure 2.1, permet de répondre à une demande d’analyse de OpMASconcernant un navire. Ce moteur contient des règles simples élaborées par des experts, souvent liées aucontexte juridique. On peut par exemple trouver [Littaye et al., 2009] des règles concernant des limita-tions de circulation pour des types de navires particuliers : « un navire de jauge >3000 tjb chargé n’estpas autorisé à emprunter le chenal de La Helle ».

Pour faciliter et unifier la communication entre OpMAS et le serveur d’application, des objets detransferts, appelés TObject, ont été mis en place : c’est dans le corps de ces différents objets que se-ront contenues les informations relatives à un navire (TOMobile), à une zone (TOZone) ou à une alerte(TOAlert).

La DCNS fournit un simulateur (SIMUL) et un outil de rejeu qui permettent, à partir de donnéesd’archives de la VMS 7 et de l’AIS8, de simuler la tenue de le situation SITU via l’interface externe EXT.Il est également possible de simuler des situations à partir de scénarios créés par des opérateurs et desexperts. C’est sur ces scénarios que le OpMAS sera testé.

La détection d’intrusion est une des principales fonctionnalités des systèmes d’alertes, comme ona pu le voir en section 1.1. Ces systèmes [Valeur et al., 2004] [Jacob and Ludovic, 2002] sont basés surl’apprentissage de comportements dits normaux et la détection de tous comportements déviant de cetteclassification. Les difficultés de ce projet résident dans la quasi impossibilité de définir un comportement

7Vessel Monitoring System : système de surveillance par satellite. Depuis 2006, chaque navire de pêche doit posséder undispositif électronique qui envoie automatiquement les données d’identification et de position du navire.

8Automatic Identification System

12

2.2. Contexte

« normal »commun à tous les navires, et dans la nature non explicite et évolutive des types d’anomaliesque l’on peut rencontrer en situation réelle. Les systèmes multi-agents et plus précisément la théorie desAmas, que nous allons voir ci-après, permet de se passer d’une fonction globale qui serait définie parun expert en connaissance totale de la situation, en résolvant les problèmes rencontrés par émergence.

2.2 Contexte

Dans cette partie, je vais décrire les outils théoriques et pratiques utilisés. Tout d’abord je développela théorie des Amas 9, qui permet de définir les types de SMA que nous allons utiliser. Ensuite, j’intro-duis la méthode ADELFE, basée sur cette théorie, qui permet le développement de ce type de SMA.Pour finir, je décris la plateforme MAY 10 qui a permis la création des agents du système.

2.2.1 Théorie des Amas

La théorie des Amas a été élaborée par l’équipe Smac à partir de 1995 [Camps and Gleizes, 1996,Glize, 2001] . L’objectif de cette théorie est de faciliter la conception de systèmes adaptatifs complexes,dont la résolution du problème n’est pas spécifié ou qui ont un environnement dynamique et ouvert. Lathéorie se base sur les concepts d’auto-organisation et d’émergence, et sur le théorème de l’adéquationfonctionnelle.

Théorème 1. Pour tout système fonctionnellement adéquat, il existe au moins un système à milieu intérieurcoopératif qui réalise une fonction équivalente dans le même environnement.

On est donc, d’après ce théorème, toujours capable de construire un système dont les parties quile composent ont un comportement coopératif, et qui résout un problème donné. La théorie des Amasindique qu’il faut se concentrer principalement sur la conception de ce système coopératif. La définitiondes situations coopératives et des interactions entre les agents autonomes de ces systèmes permet à lafonction globale du système d’émerger par auto-organisation.

Les systèmes multi-agents

Les prémices des systèmes multi-agents sont apparues au début des années 1970, dans le cadrede l’Intelligence Artificielle Distribuée. Venant de l’Intelligence Artificielle, ils ont été imaginés pourêtre la génération future des systèmes experts, en distribuant le module de contrôle et le module deconnaissances en plusieurs modules (voir figure 2.2). Ils palliaient ainsi les limites des systèmes experts,dans les domaines qui nécessitent des connaissances multiples.

Les premiers agents ainsi créés sont des entités autonomes, chacune ayant son propre module decontrôle et son propre module de connaissance.

Les systèmes multi-agents tels qu’on les connait voient le jour dans les années 1990. Ces systèmessont caractérisés par un contrôle décentralisé, ils sont autonomes, hétérogènes, ouverts et dynamiques.De part ces propriétés, ils sont utilisés dans trois domaines principaux : la simulation comportementale,la résolution de problème et l’intégration de l’utilisateur.

Les agents qui composent de tels systèmes interagissent ensemble pour résoudre une tâche ou unbut, avec des règles sociales simples. Ferber définit un agent comme « une entité physique ou virtuelleautonome agissant dans un environnement duquel il n’a qu’une connaissance partielle »[Ferber, 1995]. Un agentpossède :

1. des compétences : son savoir-faire,

2. des croyances : sa représentation de l’environnement,

3. des accointances : son environnement social,

9Adaptive Multi Agent System10Make Agent Yourself

13


FIG. 2.2 — L’évolution des systèmes experts

4. des aptitudes : ses capacités.

L’environnement a une place importante dans la théorie des systèmes multi-agents. Ce sont les in-teractions entre le système et l’environnement qui donnent de nouvelles tâches à résoudre au système,et qui modifient l’environnement. Chaque agent possède également un cycle de vie :

1. perception : les interactions avec l’environnement mettent à jour ses croyances,

2. décision : suivant ses nouvelles croyances, il décide en fonction de ses compétences,

3. action : l’agent utilise ses capacités pour appliquer sa décision.

L’auto-organisation et l’émergence

Il existe de nombreuses définitions de l’émergence, qui peuvent se résumer à une idée générale.On dit qu’il y a émergence d’un phénomène lorsque l’observation des propriétés des éléments qui lecomposent ne permet pas de déduire ce phénomène [Georgé, 2004]. Par exemple, l’observation des pro-priétés des atomes d’oxygène et d’hydrogène ne permet pas de déduire les phénomènes de transparenceou de changement d’état suivant la température de l’eau.

L’émergence d’une fonctionnalité d’un système dépend donc de l’organisation des composants dece système et de leurs interactions. Il serait alors possible de produire une fonction complexe, en définis-sant l’organisation et les interactions entre les composants. Cela suffirait-il pour résoudre un problèmecomplexe et dynamique ? Les systèmes émergents, placés dans un environnement dynamique, inter-agissent avec celui-ci. Ces interactions ont pour effet de changer l’organisation des composants de cessystèmes, et de créer de nouvelles fonctions émergentes. Dans l’exemple précédent, si l’environnementqui entoure l’eau devient très chaud, les atomes d’hydrogène et d’oxygène qui composent l’eau inter-agissent avec l’environnement, l’effet étant qu’ils vont bouger plus vite. La fonction qui émerge de cetteré-organisation est une augmentation de la température de l’eau, des mouvements de convection entreces particules, voire un changement d’état.

Dans le cadre de la conception des systèmes artificiels complexes basés sur l’émergence, il faut doncmettre en place des mécanismes d’interaction avec l’environnement et entre les composants, et doterces composants de capacités d’auto-organisation. C’est le cas des systèmes multi-agents adaptatifs, dé-veloppés avec la théorie des Amas. Ces systèmes sont constitués d’agents autonomes, ne connaissantpas la fonction globale (le but) du système, dotés de règles d’interactions locales, de comportements, etde capacités d’auto-organisation. Sur la figure suivante (2.3), la fonction globale fs émerge des actionslocales fpi des agents.

La mise en place des mécanismes d’auto-organisation dans les systèmes multi-agents adaptatifs sefait grâce au comportement coopératif dont sont dotés les agents. De cette façon, il est possible d’iden-tifier des situations de non-coopération que l’agent coopératif va chercher à éviter ou à résoudre. Cessituations peuvent apparaître au cours des trois phases du cycle de vie d’un agent défini ci-dessus :

14

2.2. Contexte

FIG. 2.3 — L’auto-organisation du système fait émerger une fonction globale

1. perception : incompréhension ou ambiguïté des messages reçus,

2. décision : incompétence ou improductivité,

3. action : concurrence, conflit ou inutilité.

Pour faciliter l’application de la théorie des Amas, la méthodologie ADELFE présentée ci-après a étédéveloppée.

2.2.2 Méthodologie Adelfe

La méthode Adelfe, Atelier de DévEloppement de Logiciels à Fonctionnalité Emergente, est un outild’aide à la conception des systèmes complexes [Bernon et al., 2002]. Elle est basée sur la théorie desAmas que nous avons vu ci-dessus, et utilise le concept d’émergence pour apporter une solution viaune approche ascendante. Elle suit le schéma de conception système classique RUP (Rational UnifiedProcess) :

1. Besoins préliminaires,

2. Besoins finaux,

3. Analyse,

4. Conception,

5. Codage.

Elle ajoute cependant au cours de ces phases certaines activités pour permettre au développeur despécifier au mieux son Système Multi-Agent Adaptatif, en prenant en compte par exemple l’environ-nement du système, les situations possibles de coopération ou encore les langages d’interaction. Uneétape permet notamment d’aider à l’identification des situations non-coopératives, et à la spécificationdes comportements des agents pour sortir de telles situations. La méthode Adelfe propose un langagede conception étendu aux agents, AUML (Agent-UML), qui se rapproche du langage standard de mo-délisation UML, et un outil d’adéquation qui permet de savoir si le problème que l’on veut résoudrenécessite la mise en place d’un ou de plusieurs Systèmes Multi-Agents Adaptatifs.

2.2.3 Plateforme MAY

MAY 11 est un générateur d’API (Application Programming Interface) agent en Java. L’utilité de cet outilest la possibilité de générer une plateforme multi-agent manipulant des agents eux-mêmes spécifiés par

11http ://www.irit.fr/MAY

15


MAY. Le modèle d’un agent peut donc être créé grâce à MAY. Les niveaux de conception sont séparés :grâce à un langage fourni par MAY, muADL, l’utilisateur peut décrire le niveau opératoire de l’agent,c’est-à-dire quelles sont ses capacités et comment il fonctionne.

FIG. 2.4 — Architecture d’un agent : niveau opératoire

La figure (2.4) est composée de deux niveaux : les deux niveaux de conception d’un agent, le niveaucontenair ou opératoire, et le niveau fonctionnel. Le niveau fonctionnel représente le comportement del’agent, ce que propose d’implémenter toute plateforme multi-agent : c’est ce que l’agent fait avec sescapacités décrites au niveau opératoire. Les capacités de l’agent sont appelées composants. On peut ytrouver les facultés de perception de l’agent, les capteurs ; ses facultés d’actions sur l’environnement,les effecteurs ; puis son cycle de vie et les différentes représentations qu’il peut avoir. Le médiateur estl’élément central qui relie tous les composants.

La nouvelle version de MAY que nous allons utiliser dans ce projet possède un éditeur textuel per-mettant la spécification des composants des agents.

2.3 Architecture de OpMAS

Dans cette section, nous allons voir les différentes étapes qu’a nécessité la mise en place de OpMAS.Nous verrons plus précisément l’architecture de communication utilisée et le modèle des agents quicomposent ce SMA.

2.3.1 Architecture

La figure suivante (2.5) montre l’architecture de communication entre OpMAS et le serveur d’ap-plication, composé du serveur d’invariance, du moteur de règles et de la SITU (2.1). OpMAS est com-posé des agents navires (ScanMarisAgent) ; d’une IHM (IhmForAgent) qui permet de suivre l’activité desagents, les messages échangés, et l’évolution de la criticité de chaque navire ; et d’une classe appeléeAgentComLink qui fait le lien entre les agents et l’interface de communication (serveur JBOSS).

AgentComLink est le noyau de ce système. Le diagramme d’état-transition présentant son fonction-nement peut être vu en Annexe figure A.1. C’est cette classe qui permet la création et le lancement des

16

2.3. Architecture de OpMAS

FIG. 2.5 — Architecture de communication entre OpMAS et le Serveur d’applica-tion

agents navires et qui assure la communication entre la SITU, le simulateur et les agents. Chaque agentnavire est associé à un navire présent dans la SITU. Tous les messages qu’un agent veut envoyer vers leserveur d’application passent par AgentComLink, qui formalise ces messages et transmet si besoin estles réponses et les mises à jour du serveur aux agents concernés.

L’IHM a été mise en place pour permettre de suivre le comportement des agents, et du système engénéral : c’est un outil principalement destiné aux développeurs de OpMAS. Deux figures se situent enannexe (A.3 et A.4). Elle contient notamment la liste des agents navires en cours, la liste des messageséchangés et l’évolution de l’état de l’agent au cours du temps.

2.3.2 Modèle de l’agent navire

L’agent navire a été conçu avec les outils fournis par la plateforme MAY (section 2.2.3). Les compo-sants ont été créés en fonction des capacités que doit avoir l’agent.

La figure 2.6 représente l’agent navire créé avec l’outil graphique de MAY. Les quatre principauxcomposants concernent la communication : Invariance Server-Agent, SITU-Agent et Rules Motor-Agent.Ils permettent la communication des agents avec respectivement le serveur d’invariance, la SITU etle moteur de règles. Le dernier, Between Agent, permet la communication entre les agents eux-mêmes.L’agent possède également une représentation de ses propriétés, une vue sur l’environnement, un cyclede vie et une base d’anomalies comprenant les anomalies existantes fournies par le moteur de règles etcelles créées par le système (3.3).

Le cycle de vie garantit l’autonomie de l’agent grâce à un thread Java et définit son comportementglobal, le comportement local se situant au niveau métier dans la méthodologie de MAY. L’agent est syn-chronisé sur les messages qu’envoie la SITU en « push », et à chaque message reçu, il lance un traitementcomme on peut le voir sur la figure 2.7 .

Il est nécessaire d’interroger le moteur de règles à l’initialisation du fait de la nature de l’envoi desmessages du serveur d’invariance. En effet, pour chaque évènement de sortie du contexte d’invariance,

17


FIG. 2.6 — Architecture de l’agent navire

FIG. 2.7 — Cycle de vie de l’agent navire

18

2.4. Conclusion

le serveur envoie deux messages : un pour notifier le début de l’évènement et sa nature, et un deuxièmepour en signaler la fin. Un seuil de détection pour des évènements tels que le changement de vitesseou de cap a été mis en place par la DCNS, pour n’émettre que les variations significatives et ainsi éviterles envois de « faux »évènements. Á l’initialisation donc, si un agent prend en charge un navire quiserait déjà en-dehors d’un contexte, il n’aurait pas le message de début d’évènement pour lui indiquerd’interroger le moteur de règles. Il commence donc son cycle par demander une analyse, puis attend leprochain message de la SITU.

Le traitement qu’effectue l’agent navire est détaillé dans le diagramme d’état-transition situé enannexe figure A.2. A la réception de la mise à jour de la SITU, l’agent vérifie que le mobile est toujoursen situation. En comparant la date du message reçu et la date du précédent message, et connaissant lafréquence générale des envois de la SITU, il peut également vérifier qu’il a bien reçu tous les messagesenvoyés.

L’agent traite alors les messages contenus dans ses différentes boîtes aux lettres. Il peut avoir troistypes de messages différents :

1. Serveur d’invariance : les messages sont sous la forme d’un objet évènement, spécifiant sa nature,et si c’est le début ou la fin. S’il s’agit d’un début d’évènement, l’agent le mémorise et va demanderune analyse au moteur de règles. Le traitement des messages, faisant l’objet de mon stage, seradéveloppé dans la section suivante. Á l’inverse, l’agent met à jour sa liste d’évènements en courslorsqu’il reçoit la fin d’un évènement.

2. Autres agents : un agent peut demander à un autre agent d’enregistrer une anomalie qu’ils au-raient en commun.

3. Moteur de règles : le moteur de règles envoie des messages en réponse à des demandes d’analysede l’agent, suite à une sortie du contexte d’invariance.

2.4 Conclusion

Dans cette partie nous avons vu le projet dans lequel s’inscrit mon stage de recherche, et les outilsqui sont mis à ma disposition pour implanter le comportement de l’agent de OpMAS, et concevoir lesystème d’ajustement de paramètres PAMAS.

19

3 Fonctionnement de l’OpMAS

L’architecture générale de l’agent navire m’a été fournie et mon travail a essentiellement consistéà définir comment une alerte est levée par un agent et donc comment les anomalies sont composées.Dans un premier temps je présente les concepts manipulés au travers du mécanisme de levée d’alerte.Puis, nous verrons comment coopèrent les agents navires grâce au dépôt de marques, et comment ilscomposent les anomalies. Enfin, je montrerai les expériences menées et l’analyse des résultats obtenus.

3.1 Concepts manipulés

Les principaux concepts manipulés dans ScanMaris sont : l’anomalie, l’alerte, la criticité de l’agentet les marques.

Anomalie

Une anomalie est une situation anormale pour un certain type de navire dans un contexte donné. Lespropositions d’anomalies sont envoyées par le moteur de règles. Par exemple, le type Anchor concerneun mouillage interdit dans une zone spécifique, et Fishing signifie que le navire pêche alors qu’il n’a pasle droit. 15 anomalies sont répertoriées actuellement par le moteur de règles.

Alerte

Une alerte va être levée par un navire et sera signalée sur l’écran de l’opérateur humain, pour luiindiquer que ce navire a un comportement anormal. Le transbordement est par exemple un type possibled’alerte, car c’est une activité maritime illégale lorsqu’elle est pratiquée par des navires de pêche, dansdes zones où la pêche est soumise à des règlementations. Le transbordement consiste à pêcher une cer-taine quantité de poissons dans une zone de pêche règlementée, puis de transborder les poissons sur unautre navire pour revenir pêcher dans cette zone.

Criticité

La criticité du navire est une valeur calculée à partir des anomalies reçues, qui, lorsqu’elle atteintun certain seuil, permet de savoir que le navire a un comportement anormal et doit lever une alerte. Ceseuil est appelé seuil d’alerte et reste constant.

Marques

Une marque correspond à une information déposée par le navire sur la carte gérée dynamiquementpar le serveur d’application.

21

Chapitre 3. Fonctionnement de l’OpMAS

3.2 Dépôt de marques

La coopération des agents d’un système passe principalement par la communication. Celle-ci peutêtre de différentes formes, directe ou indirecte, publique ou privée. L’étude des systèmes sociaux du vi-vant, comme les fourmis, a permis de mettre en évidence un mécanisme d’auto-organisation, la stigmer-gie. Ce mécanisme est basé sur une forme de communication indirecte et ouverte, le dépôt de marqueou dépôt de phéromone. Ainsi, lors de la détection ou du dépôt d’une marque, il y a renforcement ducomportement. Grassé [Grassé, 1959] résume la stigmergie ainsi : « le travail de chacun stimule le travaildes autres ».

La communication par dépôt de marques a été largement reprise dans les travaux multi-agents.L’idée est la suivante : lorsqu’un agent perçoit une certaine situation dans son environnement, il déposeune marque. Cette marque est, comme la phéromone, volatile : elle possède un taux d’évaporation. Onpeut également imaginer que différents types de phéromones peuvent être mis en place, chacune avecune signification associée : danger, nourriture, nid ...

Ici, les agents déposent une marque dans l’environnement grâce à des envois de messages spé-cifiques à la SITU. Ces marques peuvent être de plusieurs types : Stop, Stop collectif, Danger... Ellescontiennent des informations sur les agents qui les ont déposés, essentiellement leur identifiant, le typede navire et leur criticité, et ont chacune une valeur d’initialisation et un taux d’évaporation. Nous allonsnous intéresser ici aux deux premiers types, Stop et Stop collectif.

La marque Stop collectif devrait durer plus longtemps car elle est plus importante qu’une marqueStop, elle aura donc une valeur initiale plus grande et/ou un taux d’évaporation plus faible. Ce seraau système d’ajustement de paramètres de fixer ces valeurs. Lorsque le navire représenté s’arrête dansune zone sans marque, cet agent va déposer une marque Stop contenant ses informations principales.Si la zone concernée contient déjà une ou plusieurs marques Stop, alors l’agent dépose en plus unemarque Stop collectif, ce qui déclenchera une anomalie en plus de celle déclenchée éventuellement parle moteur de règles. De plus, cet agent envoie un message à l’agent qui aura déposé la marque Stopavant lui, pour lui signifier qu’il doit également déclencher une anomalie Stop collectif. De cette façon,des comportements complexes comme le transbordement en mer peuvent être détectés, comme nous leverrons dans la section expérimentation (3.4).

3.3 Composition des anomalies

Il existe principalement deux types d’anomalies : celles qui sont envoyées par le moteur de règles etqui correspondent à des infractions aux règles de navigation maritime, et celles qui sont des anomaliespropres à OpMAS. Ces dernières correspondent à des situations complexes qui ne sont pas associées àdes règles simples, et qui sont détectées par la coopération des agents ScanMaris.

Chaque anomalie possède trois paramètres :

1. une valeur initiale,

2. une valeur de croissance,

3. une valeur de décroissance .

Formellement, la valeur d’une anomalie x au temps tcourant peut se traduire par la fonction :fx(tdebut, tcourant) = Vinitiale + (tcourant − tdebut) ∗Vcroissance si l’anomalie est en cours, etfx(tdebut, tcourant) = Vinitiale − (tcourant − tdebut) ∗Vdecroissance dans le cas contraire.Chaque anomalie est indépendante des autres dans son évolution. La criticité de l’agent résulte de

la somme des valeurs des anomalies à un instant précis. Ainsi, la criticité Ct au temps tcourant est égal à :Ctcourant = ∑tcourant

j=0 ∑nk=0 fxi,k(j, tcourant) avec n=nombre d’anomalies en cours et xi les différents types

d’anomalies.Le tableau 3.1 est un exemple de composition d’anomalies :La première ligne correspond aux pas de la simulation. Dans cet exemple, il y a trois types d’anoma-

lies, A, B et C. Une nouvelle anomalie apparaît à chaque pas : A0 au pas 1, A1 au pas 2 et ainsi de suite.L’anomalie A a une valeur initiale de 5, une valeur de croissance nulle et décroît de 3 à chaque pas. De

22

3.3. Composition des anomalies

FIG. 3.1 — Composition d’anomalies

même, l’anomalie B a une valeur initiale de 10, croît de 8 pendant 2 pas, puis décroît de 10 à chaque pas.Enfin, l’anomalie C a une valeur initiale de 50, et décroît de 5 à chaque pas.

La courbe correspondant au tableau 3.1 se trouve figure 3.2.

FIG. 3.2 — Composition d’anomalies

Les anomalies correspondent à des propositions d’anomalies envoyées par le moteur de règles ousont propres à l’OpMAS, mais sont toutes liées à un début ou une fin d’évènement détecté par le serveurd’invariance. Pour une anomalie Stop par exemple, l’agent lève cette anomalie lorsque le début d’unévènement d’arrêt est détecté et que le moteur de règles, interrogé suite à l’évènement, a proposé cetteanomalie. Intuitivement, la criticité de l’anomalie Stop devrait croître tant que l’agent n’a pas reçu la finde l’évènement d’arrêt et interrogé le moteur de règles, car on estime que plus un arrêt est prolongé plusil doit concerner un problème grave. Quand le moteur de règle ne renvoie plus d’anomalie, la criticitéde l’anomalie Stop en cours commence à décroître.

Dans la première version opérationnelle de OpMAS, les paramètres des anomalies sont basés surdes connaissances métier et des résultats d’expériences. Ainsi, la plupart des anomalies auront un com-portement de croissance tant qu’elles seront présentes dans le moteur de règles, puis un comportementde décroissance par la suite.

23


3.4 Expérimentations et résultats

L’expérimentation effectuée est un test de détection d’une situation complexe de transbordement.Le plus souvent, un navire de type frigorifique se poste à la limite des eaux territoriales, en dehorsde la zone de détection par l’AIS, près d’une zone de pêche réglementée où la quantité de poissonqu’un navire de pêche peut ramener au port est soumise à des restrictions. Le transbordement s’effectuelorsque un navire de pêche s’arrête à proximité du navire frigorifique invisible au radar, et transborde lespoissons sur ce navire pour pouvoir retourner pêcher et recommencer le processus (voir figure 3.3). Cetype de situation est dit complexe car très difficile à détecter par le serveur d’invariance ou le moteur derègles : le navire frigorifique demeure invisible pour l’AIS, et les opérations de transbordement peuventêtre très étalées dans le temps. C’est par conséquent une situation également difficile à détecter par unopérateur humain.

FIG. 3.3 — Transbordement en mer

La coopération des agents de OpMAS permet, par dépôt et détection de marques (voir 3.2), de re-pérer collectivement ce type de comportement. Les figures suivantes (3.4 , 3.5) montre une situation detransbordement détectée par OpMAS.

L’agent surveillant le navire qui va effectuer le transbordement est averti par le serveur d’invarianced’une décélération, puis d’un arrêt. L’agent interroge alors le moteur de règle qui lui indique la nécessitéde lever une anomalie de type Stop. Parallèlement, l’agent demande à la SITU de déposer une marqueStop aux coordonnées du navire, qui contiendra l’identifiant de l’agent, le type de navire et le type demarque. L’agent voit sa criticité augmenter le temps que le navire est arrêté, puis le serveur d’inva-riance lui signale une accélération du navire. La criticité de l’anomalie Stop en cours commence donc àdiminuer.

Lorsqu’un second navire s’approche de la zone de transbordement, l’agent associé va être prévenu,en plus de la décélération puis de l’arrêt, qu’il s’approche d’une marque. L’agent va alors traiter cettemarque : celle-ci est de type Stop, et contient l’identifiant de l’agent qui l’a déposée. Cet agent déposealors une marque Stop Collectif, en plus d’une marque Stop servant à réactualiser la première. Il lève uneanomalie Stop Collectif, en parallèle de ses échanges avec le moteur de règles, et envoie également unmessage au premier agent, pour lui demander de prendre en compte la même anomalie. La marque Stop

24

3.5. Conclusion

FIG. 3.4 — Dépôt d’une marque Stop

Collectif contiendra les identifiants des agents en cause, pour permettre à un éventuel prochain navirede contacter les précédents.

La levée de l’alerte a été fixée au troisième arrêt dans la zone de transbordement. Les paramètres desanomalies et des marques Stop et Stop Collectif ont été déduits après plusieurs exécutions, le systèmed’ajustement n’étant pas encore opérationnel.

3.5 Conclusion

Les paramètres des anomalies et des marques utilisés dans OpMAS ont été ajustés manuellementaprès plusieurs exécutions des scénarios de transbordement. Ainsi, les marques ont des valeurs d’ini-tialisation et des taux d’évaporation suffisamment élevées pour que la détection soit possible par lesautres agents, et inférieures à un certain seuil pour ne pas lever d’anomalies qui ne correspondraientpas à un transbordement. Les valeurs des anomalies ont été calibrées pour déclencher une alerte à uninstant pertinent pour l’opérateur de surveillance. Mais ceci n’a été possible que sur un exemple limitéet est irréaliste sur une application complète avec des centaines de navires et de nombreuses situationsdifférentes, et donc d’anomalies correspondantes.

Nous avons vu en 1.2.1 que l’ajustement manuel des paramètres dans un système a un certainnombre d’inconvénients importants. Le système final de surveillance du projet ScanMaris doit être dy-namique, automatique et ouvert à des modifications des règles de navigation. La séparation souhaitéedu système de surveillance muti-agent et du moteur de règle a été mise en place pour éviter au systèmede posséder des connaissances expertes dans le domaine de la navigation maritime. Il n’est donc pasenvisageable d’ajuster manuellement tous les paramètres d’un tel système.

La solution qui est proposée consiste à mettre en parallèle un second système multi-agent pourl’ajustement dynamique et automatique des paramètres (PAMAS). La conception de ce système, qui estdétaillé dans la partie suivante constitue, la deuxième partie de mon stage.

25


FIG. 3.5 — Levée d’une anomalie transbordement

26

4 PAMAS : Système Multi-Agentd’Ajustement de Paramètres

Dans ce chapitre, je vais détailler le système multi-agent d’ajustement de paramètres PAMAS (Pa-rameter Adjuster Multi-Agent System) développé durant mon stage. Une première partie présente lesparamètres à ajuster qui régissent le fonctionnement de OpMAS (voir introduction), puis précise l’ap-proche utilisée pour mettre en place le PAMAS. Enfin, le principe utilisé pour ajuster les paramètres etle rôle de la coopération des agents dans cet ajustement est détaillé.

4.1 Les paramètres de levée d’alerte

Nous souhaitons avoir un système de levée d’alertes fiable et efficace, basé sur le cumul d’anomalies.Pour obtenir un tel système, il faut que les paramètres qui entrent en jeu dans la levée d’alerte soientajustés de telle sorte qu’un maximum d’alertes qui doivent être détectées par le système soient levéeset qu’il y ait un minimum de faux positifs. L’approche que je propose et développe ici introduit l’auto-ajustement de ces paramètres à partir de feedbacks envoyés par un opérateur de surveillance humain.Ces feedbacks, datés, pourront confirmer ou infirmer la pertinence d’une alerte présente, ou deman-der au système de lever une alerte si elle est absente. A partir de ces réponses, le système ajustera lesparamètres.

Trois familles de paramètres interviennent dans la levée d’alerte. La première comprend les paramètresdes anomalies (voir section 3.3) :

1. La valeur initiale,

2. La valeur de croissance,

3. La valeur de décroissance .

Nous avons donc trois paramètres pour chaque anomalie. Aujourd’hui, le système comprend quinzeanomalies du moteur de règles, et deux définies par OpMAS, le stop collectif et le transbordement. Onpeut imaginer par la suite qu’un plus grand nombre d’anomalies sera pris en charge par le moteur derègles et le système.

Le second type de paramètres représente les paramètres des marques (voir section 3.2). Chaquemarque a :

1. Une valeur initiale,

2. Un taux d’évaporation .

Dans la version actuelle, trois types de marques peuvent être déposées par les agents. On pourraêtre amené à en créer de nouvelles par la suite.

Enfin, la troisième famille de paramètres concerne ceux liés aux types de navire. Les navires sontidentifiés par le système comme appartenant à un des trois types de navire suivants : ceux de petitetaille, ceux de taille moyenne, et les plus imposants. La catégorisation proposée fait la différence pour ledernier type, entre les navires qui transportent des passagers et ceux transportant des marchandises. Onobtient donc les quatre catégories suivantes : navires de pêches, navires de plaisance, ferry et cargo. Ces

27

Chapitre 4. PAMAS : Système Multi-Agent d’Ajustement de Paramètres

catégories sont directement basées sur les tailles de ces navires, liées à la manoeuvrabilité d’un bâtiment.Un cargo change de cap ou de vitesse avec plus de difficulté qu’un navire de pêche par exemple, et onpeut imaginer que des anomalies comme l’arrêt en pleine mer auront une importance relative suivantle type de navire. Les paramètres des navires sont donc des coefficients attachés à chaque anomalie et àchaque marque existante.

Au total, nous avons donc 51 (17 anomalies x 3 valeurs) paramètres pour les anomalies, 6 (3 marquesx 2 valeurs) pour les marques et 80 (4 types x 17 anomalies + 4 types x 3 marques) pour les navires, soit137 paramètres inter-dépendants à ajuster. L’espace de recherche correspondant dépend de la plage desvaleurs que peut prendre un paramètre et de sa précision sur cet intervalle, soit un espace total de 10242

valeurs possibles. Cet espace gigantesque nécessite donc un système permettant de le parcourir avecefficacité afin d’en extraire des valeurs pertinentes.

4.2 Approche par Amas

L’approche utilisée pour développer ce système suit les étapes de la méthode Adelfe (voir section2.2.2). Je ne présente dans ce rapport que les étapes de chaque phase liées aux SMA. Tout d’abord, dansla phase d’analyse je vérifie l’utilité de l’approche par les Amas pour la conception du PAMAS, en utili-sant l’outil d’adéquation de la méthode Adelfe. Puis la phase de conception définit l’agent du systèmed’après ses caractéristiques, ses représentations et ses compétences. Pour finir l’attitude coopérative del’agent sera présentée, ainsi que son implémentation avec la plateforme MAY (section 2.2.3).

4.2.1 Phase d’analyse : validation des Amas

L’adéquation des Amas se vérifie à deux niveaux : local et global. L’outil proposé par la méthodeAdelfe pose onze questions auxquelles l’utilisateur peut répondre avec précision (voir figure en annexeA.5). Un outil graphique synthétise les réponses et permet d’obtenir le résultat aux deux niveaux.

Niveau global

Les premières questions permettent de déterminer si le problème peut être résolu par une approchepar les Amas. Tout d’abord, nous ne savons pas a priori comment arriver à un système stable où tousles paramètres seraient ajustés. Nous ne connaissons pas en effet toutes les dépendances qui pourraientexister entre ces paramètres, ni la façon de les ajuster. De plus, le système est dynamique et ouvert, il peutévoluer au cours du temps dans le sens où les feedbacks représentent cet environnement, et qu’ils nesont pas prévisibles. De plus, comme nous l’avons vu en section 3.4, une méthode naïve d’ajustementserait d’effectuer de nombreux essais successifs, en faisant intervenir des connaissances expertes dudomaine, pour arriver à un jeu de paramètres cohérent pour une situation donnée. Les réponses auxquestions posées justifient ici la mise en place d’un système à milieu coopératif dont les entités aurontà s’auto-organiser pour résoudre la tâche globale. La granularité de ces entités sera définie grâce à lavérification de l’adéquation au niveau local.

Niveau local

Les composants du système coopératif déduit de la vérification de l’adéquation au niveau global de-vront être à une granularité suffisamment faible pour permettre d’ajuster leur comportement et pouvoireffectuer leur traitement à un niveau proche des paramètres. Cette étape nous indique que les agentsseront au niveau des paramètres, et qu’ils ajusteront les valeurs de leur paramètre respectif par coopé-ration.

4.2.2 Conception générale de l’agent paramètre

La phase de conception d’Adelfe préconise de définir l’agent du système à travers ses caractéris-tiques, ses perceptions, ses représentations et ses compétences. Ces quatre niveaux permettent par la

28

4.2. Approche par Amas

suite de faciliter l’implémentation de l’agent.

Ses caractéristiques

Les caractéristiques de l’agent sont ses propriétés intrinsèques. L’agent paramètre de PAMAS a lespropriétés de son paramètre, c’est-à-dire une valeur, un identifiant unique et un nom qui définit lafamille de ce paramètre. Ce dernier attribut fait le lien entre les agents dont les paramètres sont membresd’une même famille.

Ses perceptions

Comme nous avons pu le voir (section 2.2.1), l’environnement tient une place importante dans lathéorie des systèmes multi-agents. Ce sont les stimuli de l’environnement qui vont amener le systèmeà se réorganiser pour résoudre une nouvelle tâche, ce qui va modifier l’environnement et produire denouveaux stimuli. On peut distinguer deux types d’environnement pour un agent : un environnementsocial qui représente les autres agents que cet agent connait, et l’environnement physique. L’environ-nement social fera partie des représentations de l’agent paramètre. Je vais présenter ici ce que perçoitl’agent, les feedbacks, qui définiront les tâches à accomplir pour PAMAS.

Les paramètres que manipulent les agents participent à la composition des anomalies et au dépôt demarques dans OpMAS : ils font partie de la dynamique de l’environnement, dans le sens où ce sont cesparamètres qui vont interagir avec lui et le modifier. Les feedbacks que reçoit PAMAS peuvent être vuscomme les stimuli de l’environnement, ou plus généralement l’environnement lui-même. Les feedbacksnégatifs vont en effet contenir des informations comme la grandeur de l’erreur et la date à laquellel’alerte doit être levée ou ne pas être levée, et donc donner un nouveau but à poursuivre au PAMAS.L’absence de feedback contient également une information importante, qui est la validation des alerteslevées ou non précédemment, et donc des valeurs des paramètres à ces dates. Nous allons voir dans lapartie suivante comment ces feedbacks « silencieux »et les feedbacks négatifs, que ce soit pour demanderune alerte absente ou réfuter une alerte levée, sont pris en compte par le système.

Ses représentations

L’environnement social de l’agent représente ses accointances. Cet environnement peut évoluer avecle temps, et nous verrons par la suite comment les accointances de l’agent sont mises à jour en cours desimulation. Nous pouvons déjà distinguer deux groupes d’agents au sein de l’environnement social,de part la nature des agents. En effet, les paramètres liés aux agents étant divisés en trois catégoriesou familles, l’agent aura un premier voisinage composé des agents dont les paramètres seront de lamême catégorie que le sien. Ainsi, les agents dont les paramètres seront la valeur initiale, la valeur decroissance et la valeur de décroissance d’une même anomalie auront le même environnement social.Nous appellerons voisinage d’anomalie un tel voisinage. Un second voisinage de l’agent pourra êtrecomposé des agents appartenant à un même contexte. Il sera défini en 4.2.3.

Ses compétences

L’agent, pour pouvoir être coopératif, doit posséder un certain nombre de compétences : ce sont lesmoyens qu’a l’agent pour agir sur son environnement physique, social ou sur lui-même. L’agent para-mètre sera doté de capacités de communication, soit un mécanisme d’envoi de messages. Pour pouvoirajuster son paramètre, l’agent doit également être capable de modifier sa valeur, et de mémoriser sesanciens états.

4.2.3 Attitude coopérative de l’agent paramètre

Les agents utilisent un raisonnement coopératif basé sur la théorie des Amas. Ces décisions se fe-ront en fonction des connaissances locales de l’agent et de sa perception de l’environnement. Chaqueagent va, au cours de son existence, entretenir une criticité liée au paramètre dont il a la charge, et des

29


accointances lui permettant de connaître les autres agents de son voisinage. Ces connaissances serontcontenues dans des contextes, que nous allons détailler dans cette partie. Le raisonnement coopératifmis en place aura pour but de satisfaire l’agent dans le voisinage dont la criticité est la plus grande, enfonction des stimuli de l’environnement.

Dans cette partie, nous allons caractériser l’environnement des agents et introduire la notion decontexte. Nous verrons également comment est construite la criticité de l’agent, et comment cette criti-cité est le noyau du raisonnement coopératif. Conformément à la théorie des Amas, nous identifieronsles situations non-coopératives que peuvent rencontrer les agents, et les règles mis en place pour lesrésoudre.

Notions de contexte et de criticité

La notion de contexte a été mise en place pour permettre aux agents de prendre en compte l’absencede feedback au cours d’une simulation. Les contextes sont construits par les agents navires de OpMASlors du rejeu d’un scénario.

FIG. 4.1 — Courbe de suspicion d’un navire

Sur la figure 4.1, le feedback représenté par une croix concerne une demande de levée d’alerte à cenavire. Le seuil d’alerte est la droite appelée Alert Limit à la valeur 30000. La courbe de suspicion, appeléeCriticity, est le résultat de la composition des anomalies cumulées par ce navire. Un certain nombre deparamètres participent à l’évolution de cette courbe. Le feedback apparaît au pas de simulation 44, ce quisignifie que la courbe de suspicion doit dépasser le seuil d’alerte à ce pas, mais ne doit pas le dépasseravant ce pas.

Pour traduire cette contrainte au niveau des paramètres, les contextes ont été créés. Un contextecontient la liste des anomalies en cours et les différentes valeurs de la courbe à chaque pas de simulation.Un nouveau contexte est créé à chaque fois qu’une nouvelle anomalie apparaît, ou qu’une anomalie encours atteint la valeur zéro.

Si on reprend notre exemple ci-dessus, nous obtenons six contextes différents (figure 4.2). Au pas 0,une première anomalie Fishing est créée. L’agent navire cumule une deuxième anomalie, Anchor, à partirdu pas 5. Un premier contexte est donc créé, contenant l’anomalie Fishing, et les valeurs de la courbe auxpas 0 à 4. Puis, l’anomalie Fishing atteint zéro au pas 13. Un deuxième contexte est alors créé, contenantles deux anomalies Fishing et Anchor, et huit valeurs de la courbe dans l’intervalle [5-12] . Le contextesuivant ne contiendra que l’anomalie Anchor.

30


FIG. 4.2 — Courbe de suspicion du navire avec les contextes

Ces contextes sont transmis au fur et à mesure aux agents paramètres dont les paramètres sontconcernés. Ces paramètres sont identifiés par l’agent navire lors de la composition des anomalies : cesont les paramètres des anomalies présentes, les paramètres de ce type de navire liés à ces anomalieset les éventuelles marques qui ont contribué à créer une anomalie présente dans le contexte. Les agentsparamètres reçoivent donc différents contextes qu’ils mémorisent. A partir des contextes reçus, ils seconstruisent un environnement social propre à chaque contexte. Ainsi, lors de la réception d’un feedbackcorrespondant à un contexte, les agents qui chercheront à corriger l’erreur auront le même voisinage.Ce voisinage sera appelé environnement de contexte dans la suite de ce mémoire.

Grâce à ces contextes, les agents mettent à jour leur criticité suivant deux valeurs importantes : leurmarge d’augmentation et leur marge de diminution. Lorsqu’un paramètre contribue à une courbe quireste en dessous du seuil d’alerte, et que cela ne lève pas de feedback de l’environnement, alors ce para-mètre peut être ajusté en hausse jusqu’à un certain point, soit le seuil d’alerte. La marge d’augmentationd’un paramètre à un pas s est donc égale à :

Maug,s = Seuild′alerte− suspicionsDe la même manière, lorsqu’un paramètre contribue à une courbe qui lève une alerte et que cela ne

lève pas de feedback de l’environnement, alors ce paramètre peut être ajusté en baisse de :Mdim,s = suspicions − Seuild′alerteL’agent conserve ainsi ses marges d’augmentation et de diminution les plus critiques. La criticité

de l’agent dépend directement de ses marges : plus les marges seront faibles, plus la criticité de l’agentsera importante. Lorsqu’un feedback est reçu, les marges retenues à cette date et après le feedback nedoivent pas être prises en compte. En effet, après ajustement l’allure de la courbe et les contextes peuventchanger, et de nouvelles marges seront à prendre en compte.

Principe d’ajustement

Les agents suivent donc un même raisonnement coopératif, qui est de satisfaire le plus critiquedans leur entourage, lors d’une modification de l’environnement. Les feedbacks envoyés sont datés etindiquent la grandeur de l’erreur à cette date. Les paramètres concernés par le feedback sont identifiésgrâce aux dates contenues dans les contextes, et les agents de ces paramètres reçoivent ce feedback.

31


Chaque agent détermine ensuite l’importance de l’anomalie à laquelle il appartient à la date indi-quée. Il peut également savoir si l’anomalie était en croissance ou en décroissance, et donc si l’agent peutou non participer à l’ajustement. Suivant l’importance de l’anomalie, les agents correspondants aurontà ajuster une part plus ou moins grande de l’erreur globale.

FIG. 4.3 — Feedback au pas 24

Sur la figure 4.3, un feedback a été envoyé aux agents dont les paramètres composent les deux ano-malies présentes au pas 24, Anchor et Channel.

FIG. 4.4 — Anomalie Channel

Comme on peut le voir sur les figures 4.4 et 4.5, au pas 24 les deux anomalies ont des valeurs si-milaires : l’anomalie Channel compte pour 51% dans la valeur de la suspicion du navire, et l’anomalieAnchor compte pour 49%. Lors de l’ajustement, l’erreur devrait donc être partagée entre les agents liésaux paramètres de ces anomalies.

32


FIG. 4.5 — Anomalie Anchor

Une fois l’importance de l’anomalie déterminée, l’environnement social d’un agent est fixé : il estcomposé des agents qui ont à coopérer pour corriger une même erreur. L’agent détermine alors lequel estle plus critique de son environnement, puis cherche à le satisfaire en évitant de lui demander d’ajusterla valeur de son paramètre. A l’inverse, l’agent qui aura la plus faible criticité, c’est-à-dire les margesd’ajustement les plus confortables, cherchera à corriger l’erreur en ajustant sa valeur. Si cela ne suffit pasà combler l’erreur, alors le second agent le moins critique essaiera d’ajuster la sienne, et ainsi de suitedu moins critique au plus critique.

Situations non-coopératives

Suivant la théorie des Amas et la méthodologie Adelfe, il est important d’identifier les situationsnon-coopératives que peuvent rencontrer les agents du système. La liste des situations de non-coopérationdéfinissant le principe d’ajustement est détaillée ci-dessous. Pour chaque situation, les circonstances etle comportement suivi par l’agent pour sa résolution sont présentés.

1. Conflit : la réception du feedback et sa propagation dans le système traduisent une situation non-coopérative. L’agent concerné par cette situation cherche à la résoudre en suivant le raison-nement coopératif défini ci-dessus du « satisfaire le plus critique ».

Résolution : l’agent détermine celui qui a la plus faible criticité dans ses accointances et lui de-mande d’ajuster sa valeur pour corriger l’erreur contenue dans le feedback.

2. Incompétence : cette situation apparaît dans le cas où, lorsque il est le moins critique au seinde son environnement d’anomalie, l’agent ne parvient pas, en ajustant sa valeur, à corrigerl’erreur indiquée par le feedback.

Résolution : l’agent propage dans son environnement un nouveau feedback indiquant l’erreurqu’il reste à corriger. Les agents vont alors se retrouver dans la situation non-coopérativeConflit ci-dessus.

Ces situations non-coopératives peuvent en entraîner d’autres apparaissant au niveau collectif, quisont définies ici :

1. Concurrence : dans le cas où l’agent, a la même criticité qu’un autre au sein de son environnementd’anomalie.

33


Résolution : chaque agent compare cette nouvelle demande avec les demandes d’ajustement pré-cédentes, dans le but de conserver une certaine cohérence. Ceux dont les demandes sont tropcontradictoires augmentent leur criticité.

2. Improductivité d’anomalie : cans le cas où l’agent détecte qu’aucun agent de son environnementd’anomalie ne parvient à corriger l’erreur correspondant à la part de cette anomalie dans lefeedback.

Résolution : l’agent propage la situation non-coopérative dans le système. Par envoi de mes-sages, l’agent transmet son incapacité à corriger l’erreur aux agents de son environnementde contexte sous la forme d’un feedback. Ces autres agents, s’ils le peuvent, ajusteront leurparamètre pour corriger cette nouvelle erreur, en adoptant le même raisonnement coopératif.

3. Improductivité de contexte : l’improductivité de contexte survient lorsqu’aucun agent de l’envi-ronnement du contexte ne peut compenser l’erreur envoyée par le feedback.

Résolution : lorsque c’est possible, créer un nouveau type de navire du type du navire concerné,contenant de nouveaux paramètres attachés aux anomalies existantes. Si cela n’est pas pos-sible, il manquerait des informations, notamment au niveau des marques, qui permettraientde lever d’autres anomalies ou de diminuer l’erreur.

4.2.4 Phase d’implémentation

La plateforme MAY (section 2.2.3) nous permet de doter l’agent paramètre de capacité de communi-cation et de définir sa représentation de l’environnement. Les aptitudes et les compétences de l’agent quil’ont défini lors de la phase de conception (4.2.2) peuvent donc être implémentées ici. La figure suivante(4.6) montre les différents composants opérationnels de l’agent paramètre.

FIG. 4.6 — Architecture de l’agent paramètre

On retrouve les différentes catégories de composants définies en section 2.2.3. PAMASMessage per-met aux agents de s’envoyer et de recevoir des messages. Ces messages sont à la base de leur coopé-ration. Chaque agent possède également une représentation de lui-même et des caractéristiques de sonparamètre associé (composant Characteristics). A chaque réception de message, le composant de com-munication transmet l’information à un composant IHM. Ainsi, le développeur peur suivre les activitésdes agents du PAMAS.

34

4.3. Conclusion

L’agent étant autonome, il possède un cycle de vie (composant PAMASLifeCycle). Celui-ci se base surle modèle de perception, décision, action [Ferber, 1995] :

1. Perception : à chaque message reçu, le cycle de vie lance une itération de la boucle de perception,décision, action ;

2. Décision : l’agent reçoit le message, et en fonction de son sujet et de son contenu, décide de sesprochaines actions ;

3. Action : l’agent effectue les actions prévues lors de la phase de décision.

Le composant ParameterAdjuster contient les outils permettant à l’agent paramètre de prendre unedécision suivant ce qu’il a perçu. Le comportement de l’agent paramètre détaillé plus tôt (section 4.2.3)est représenté ici sur la figure par le composant Behavior.

4.3 Conclusion

Nous avons vu dans la partie 2.3 que les communications entre OpMAS et le serveur d’applicationpouvaient se résumer comme sur la figure suivante (4.7).

FIG. 4.7 — Architecture de communication entre OpMAS et le Serveur d’applica-tion

SITU renseigne la situation du navire, SI est le Serveur d’Invariance qui envoie les évènements dé-tectés aux agents concernés, et MDR le Moteur De Règles qui envoie des propositions d’anomalies enréponse à des demandes d’analyse de navires.

Pour garantir l’ajustement des paramètres en temps réel tout en continuant la surveillance de lasituation, il faut que OpMAS continue sa tâche pendant que PAMAS, en parallèle, traite les feedbacksreçus et décide des paramètres à ajuster. Pour cela, nous allons travailler ici avec une copie de OpMAS,capable de recevoir des feedbacks et d’adapter ses paramètres en fonction des mises à jour du PAMAS.On appelle ce système Adaptive MAS (AdMAS). La figure 4.8 détaille les mécanismes de communicationentre PAMAS, AdMAS et l’opérateur.

Lorsque AdMAS lève une alerte, l’opérateur peut valider ou réfuter celle-ci. Ce feedback est trans-mis aux agents du PAMAS, qui après auto-organisation, mettent à jour les valeurs des paramètres deAdMAS.

En appliquant les principes de la théorie des Amas, nous avons conçu le système PAMAS d’ajus-tement de paramètres. Il nous faut maintenant mettre en place des scénarios de tests, dans le but de

35


FIG. 4.8 — Levée d’alerte, réception d’un feedback et ajustement des paramètres

valider le système. Nous allons voir dans la partie suivante les résultats des expériences effectuées, etpourquoi ils sont intéressants pour la suite.

36

5 Expérimentation et analyse desrésultats

Nous allons présenter dans une première partie les différentes expérimentations menées afin devalider le système PAMAS. Plusieurs scénarios et une plateforme de test ont été imaginés, dans le butde faciliter ces expériences. Nous analyserons les résultats obtenus dans la seconde partie, notammentgrâce à un outil de visualisation pour le développeur permettant de suivre les actions des agents.

5.1 Expérimentation

Pour mener à bien ces expériences, une plateforme de test a été mise en place, ainsi que plusieurs scé-narios de tests. Ceux-ci ont pour but de montrer les différentes situations coopératives et non-coopérativesdécrites dans la partie 4.2.3, et la réaction des agents. Lors des expériences, nous travaillerons avec unagent navire, déconnecté du serveur, et en lien avec un simulateur d’anomalies. Ce dernier permet d’en-voyer à l’agent navire les propositions d’anomalies choisies par le développeur, qui décide des débutset fins d’évènements que l’agent rencontrera. Ces restrictions permettent de suivre au mieux le déroule-ment de l’ajustement effectué par les agents du PAMAS, et ont vocation à être levées par la suite.

5.1.1 Plateforme de tests

La figure suivante (voir 5.1) présente la plateforme à partir de laquelle les tests vont être effectués.Elle permet notamment d’observer la courbe de suspicion de l’agent navire, de ralentir, de mettre

en pause ou accélérer la simulation, et de générer des feedbacks négatifs aux pas choisis par le dévelop-peur. Lors de la génération d’un feedback, si la courbe de suspicion est en-dessous du seuil d’alerte, cefeedback indique que l’alerte doit être levée à ce pas là. Inversement, si la courbe est au-dessus du seuild’alerte, le feedback indique qu’il ne faut pas lever l’alerte. Comme vu précédemment en section 4.2.3,l’agent navire crée les contextes des paramètres au cours de la simulation, qui sont transmis aux agentsparamètres concernés.

Le PAMAS, après avoir reçu le feedback, le transmet aux agents paramètres, qui au terme de lacoopération, mettent à jour les paramètres appropriés. Il est alors possible au niveau de la plateformede demander une nouvelle itération grâce au bouton Itération suivante. L’agent navire rejoue alors lescénario de test à partir du pas 0, une nouvelle courbe de suspicion se superposant à la précédente.

5.1.2 Scénarios de test

Les scénarios de tests mis en place peuvent être classés selon la complexité de raisonnement, c’est-à-dire le nombre de situations non-coopératives, que va rencontrer un agent. Un premier scénario intro-duit deux feedbacks à deux pas de temps différents, qui sont dans le sens opposés : le premier demandeune levée d’alerte, le second de ne pas lever d’alerte (Expérience 1).

Au cours de ce scénario, les anomalies envoyées à l’agent navire par le simulateur d’anomalie sontdécidées de manière stochastiques par le programme. Elles ont une date de début et une date de fin,

37

Chapitre 5. Expérimentation et analyse des résultats

FIG. 5.1 — Plateforme de test

fixées aléatoirement, correspondant à un début d’événement et une fin d’événement. Les différents pa-ramètres du système sont également initialisés avec des valeurs aléatoires. Pour vérifier que le secondfeedback prévu est cohérent, nous avons déroulé plusieurs fois le scénario en déclenchant le premierfeedback à des pas différents : il faut en effet qu’une alerte soit levée après celui-ci, de façon prolongéeou ponctuelle, pour justifier un deuxième feedback interdisant la levée d’alerte.

Le deuxième scénario que mis place tend à valider le système PAMAS. L’expérimentation (Expérience2) se déroule ainsi :

1. On suppose les valeurs finales à atteindre de tous les paramètres connus ;

2. Le scénario proposé doit être relativement long, et le nombre d’anomalies levées dans ce laps detemps doit être significatif ;

3. De la même façon que le premier scénario, les anomalies et leurs dates de début et de fin sontfixées aléatoirement ;

4. En jouant le scénario, nous obtenons ainsi une courbe de criticité qui est la courbe témoin ;

5. Ce même scénario est rejoué une deuxième fois, avec de nouvelles valeurs initialisées de manièrealéatoire pour les paramètres ;

6. Au cours de ce rejeu, à chaque fois que les levées (ou non levées) d’alertes ne correspondent pas àcelles de la courbe témoin, un feedback est créé ;

38

5.2. Analyse des résultats

7. Nous mesurons alors l’écart entre la courbe témoin et la courbe obtenue après les ajustementssuccessifs.

5.2 Analyse des résultats

Dans cette partie les outils que j’ai développés pour l’observation du fonctionnement du systèmeet la visualisation des résultats sont détaillés. Les résultats eux-mêmes sont décrits et analysés dans undeuxième temps.

5.2.1 Outil de visualisation

L’outil de visualisation développé s’appuie sur le composant IHM des agents paramètres vu dansla partie 4.2.4. L’IHM contient une listes des messages échangés par les agents paramètres au cours dela simulation, et une vue précise des caractéristiques de l’agent détaillant l’évolution de la valeur deson paramètre. Cela permet de connaître le nombre moyen de messages échangés pour une itérationet le nombre d’itérations effectuées, et d’interpréter l’évolution au cours du temps de la valeur d’unparamètre.

5.2.2 Résultats

L’expérience 1 comprend quatre anomalies sur cinquante pas de temps (figures 5.2, 5.3 et 5.4). L’ano-malie Fishing est levée au pas 0, et n’est plus en cours au pas 8. L’anomalie Anchor apparaît au pas 5, ets’arrête en 25 (figure 5.3). L’anomalie Channel est en cours du pas 15 au pas 30, et la dernière anomalie,Stop in open sea, du pas 40 au pas 45 (figure 5.4).

FIG. 5.2 — Expérience 1, premier feedback au pas 17

39


Un premier feedback est envoyé au pas de temps 17. Il signifie aux agents que la courbe de criticitédoit être au-dessus du seuil d’alerte au pas 17. La figure en annexe (A.6) montre la liste des messageséchangés par les agents paramètres impliqués. Ces agents sont au nombre de 6, car le feedback en-voyé concerne les 2 anomalies Anchor et Channel. Les agents paramètres concernés sont donc ceux dela famille des 2 anomalies. Les 2 agents responsables des paramètres de décroissance des anomaliesne participeront pas néanmoins à l’ajustement, car ces anomalies n’étant pas en décroissance, ajusterces paramètres ne semble pas pertinent. En tout, les messages envoyés sans compter les mises à jourde contextes envoyées précédemment, sont au nombre de 6 messages pour le feedback puis 14 entre lesagents, et pour finir 2 pour la mise à jour de 2 agents paramètres. Ici, les agents des paramètres de valeurinitiale choisissent d’ajuster leur valeur, en l’augmentant. Le résultat est montré en figure 5.3.

FIG. 5.3 — Expérience 1, ajustement au pas 17 et second feedback au pas 40

La courbe est donc passée au-dessus du seuil d’alerte au pas 17. L’alerte est levée jusqu’au pas 26.Un deuxième feedback est maintenant transmis au pas 40, il signifie que les agents paramètres doiventajuster leur valeur de telle sorte que l’alerte ne soit pas levée au pas 40. Une deuxième liste des messageséchangés entre les agents paramètres impliqués se trouve en annexe (A.7). Les 9 agents paramètres desanomalies Anchor, Channel, Stop in open sea sont concernés par ce feedback. 33 messages sont échangésentre les agents. L’agent paramètre valeur initiale de l’anomalie Stop in open sea baisse sa valeur, et les 2agents des paramètres valeur de décroissance des 2 autres anomalies augmentent leur valeur. La figure5.4 montre les résultats obtenus en 2 itérations.

Les résultats de l’expérience 1 sont encourageants : en très peu d’itérations et peu de messages en-voyés, les agents ont ajusté leur paramètre pour résoudre les situations non-coopératives de conflit.

La première phase de l’expérience 2 décrite dans la partie 5.1.2 consiste à créer un scénario de testcommun à deux jeux de paramètres différents, et à construire la courbe témoin. La figure 5.5 montre lacourbe témoin obtenue. L’alerte est levée du pas 120 au pas 145.

40

5.2. Analyse des résultats

FIG. 5.4 — Expérience 1, courbe obtenue après ajustement au pas 40

FIG. 5.5 — Expérience 2, courbe témoin

Ensuite, le scénario est rejoué avec le nouveau jeu de paramètre : les feedbacks sont envoyés auto-matiquement si la courbe est au-dessus du seuil d’alerte avant le pas 120 et après le pas 145, et si lacourbe est au-dessous du seuil entre les pas 120 et 145. Les résultats obtenus sont les suivants :

1. 220 itérations

41


2. environ 12160 messages

3. soit environ 56 messages par itération

Les deux figures qui suivent (5.6 et 5.7) montrent respectivement les itérations successives à chaquefeedback, à l’itération 73, avec une nouvelle courbe à chaque itération, et la comparaison de la courbefinale obtenue et de la courbe témoin.

FIG. 5.6 — Expérience 2, itérations successives

FIG. 5.7 — Expérience 2, comparaison de la courbe obtenue (en noir) et de la courbetémoin (en bleu)

La courbe finale obtenue sur la figure 5.7 a un comportement similaire à celui de la courbe témoin.Lorsque l’on compare l’évolution des valeurs des paramètres, on peut voir que certains tendent vers lavaleur du paramètre témoin équivalent. Cependant, d’autres gardent des valeurs très éloignées. Cecis’explique par la taille de l’espace des valeurs possibles, que tendent à réduire les contextes par leurscontraintes, qui reste importante sur un scénario de 300 pas du fait que les anomalies soient composéespar un seul agent navire.

42

Conclusion

5.3 Bilan

Le stage réalisé a été effectué au sein d’un projet ANR de détection de comportements anormauxpour des navires. Dans ce rapport, j’ai présenté tout d’abord un état de l’art des principales théories dedétections d’anomalies dans les systèmes de levée d’alerte, et les principales méthodes d’ajustement deparamètres. J’ai pu également montrer que ces méthodes comportent les lacunes suivantes : nécessitéde connaissances métier, complexité, inadaptation au temps réel.

L’approche choisie pour résoudre ces lacunes est la théorie des Amas. J’ai donc réalisé dans la pre-mière partie de ce mémoire une version opérationnelle du système multi-agent de détection d’anomaliesOpMAS, puis, dans la deuxième partie, le système multi-agent d’ajustement de paramètres PAMAS. Ladernière partie de mon travail concerne une validation expérimentale du prototype. Les résultats en-courageants obtenus lors des expérimentations valident l’utilisation et le choix de l’approche suivietout au long de la conception de ces systèmes. Le travail réalisé au terme de ce stage est une ébaucheintéressante du système opérationnel à atteindre dans le cadre du projet ScanMaris.

5.4 Perspectives

Concernant le prototype réalisé, plusieurs points sont à poursuivre. Il faut, d’une part, intégrer cesystème dans ScanMaris pour la version finale du projet, et, d’autre part, approfondir les tests surd’autres scénarios dans le but de lever les restrictions concernant notamment les conditions particulièresd’expérimentation : le temps relativement court des scénarios et le nombre limité d’agents navires. Lamise en place de tests en temps réel, sur des scénarios complexes basés sur des données réelles, resteune piste à explorer.

Concernant le travail théorique sous-jacent, il faudrait élaborer, à partir de ce travail de Master 2Recherche, un algorithme semi-générique ou générique pour doter des systèmes de mécanismes d’ajus-tement de paramètres et le valider sur différents domaines d’application.

5.5 Bilan personnel

Ce stage m’a beaucoup apporté en terme de nouvelles connaissances scientifiques et il m’a confortédans l’envie de travailler dans le monde de la recherche. Le rôle du travail d’équipe dans la rechercheet la découverte incessante de nouveaux concepts font de ce monde un environnement très attrayant.Mon stage ayant eu lieu dans le cadre d’un projet, j’ai su m’adapter pour travailler avec les contraintesdues à ce type de travail. J’ai pu me perfectionner dans la manipulation des systèmes complexes, desthéories sous-jacentes et des outils développés par l’équipe Smac. Ce travail a été satisfaisant d’un pointde vue personnel, car les résultats sont encourageants et je souhaite les améliorer au travers des travauxà venir si j’ai l’opportunité de continuer en thèse.

43

Annexe

45

Annexe

FIG. A.1 — Diagramme d’état-transition de AgentComLink

46

Annexe

FIG. A.2 — Traitement effectué par l’agent ScanMaris

47

Annexe

FIG. A.3 — Vue principale du fonctionnement de l’OpMas

48

Annexe

FIG. A.4 — Vue locale de l’agent 13

49

Annexe

FIG. A.5 — Résultats de l’utilisation de l’outil d’adéquation d’ADELFE

50

Annexe

FIG. A.6 — Liste des messages échangés lors du premier ajustement de l’expérience1

FIG. A.7 — Liste des messages échangés lors du second ajustement de l’expérience1

51

Table des matières

Introduction 1

1 État de l’art 31.1 Systèmes de levée d’alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Méthodes conventionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Méthodes multi-agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Surveillance maritime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Autres domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Méthodes d’ajustement de paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.1 Méthodes empiriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Ajustement manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Les plans d’expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2 Méthodes bio-inspirées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Algorithmes génétiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Réseaux de neurones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.3 Méthodes multi-agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Le projet Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Le projet Mascode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Contexte de l’étude 112.1 Le projet ScanMaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Théorie des Amas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Les systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13L’auto-organisation et l’émergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Méthodologie Adelfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Plateforme MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Architecture de OpMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 Modèle de l’agent navire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Fonctionnement de l’OpMAS 213.1 Concepts manipulés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Anomalie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Criticité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Dépôt de marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

53

Table des matières

3.3 Composition des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Expérimentations et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 PAMAS : Système Multi-Agent d’Ajustement de Paramètres 274.1 Les paramètres de levée d’alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Approche par Amas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 Phase d’analyse : validation des Amas . . . . . . . . . . . . . . . . . . . . . . . . . . 28Niveau global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Niveau local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Conception générale de l’agent paramètre . . . . . . . . . . . . . . . . . . . . . . . 28Ses caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Ses perceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Ses représentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Ses compétences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.3 Attitude coopérative de l’agent paramètre . . . . . . . . . . . . . . . . . . . . . . . 29Notions de contexte et de criticité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Principe d’ajustement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Situations non-coopératives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.4 Phase d’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Expérimentation et analyse des résultats 375.1 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Plateforme de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.2 Scénarios de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Outil de visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Conclusion 435.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Annexe 45

Glossaire 55

Bibliographie 57

54

Glossaire

Adelfe : Atelier de DévEloppement de Logiciels à Fonctionnalité Emergente, outil d’aide à la concep-tion des systèmes complexes développé par l’équipe SMAC.

Agent Navire : modèle d’agent du système multi-agent OpMAS.Agent Paramètre : modèle d’agent du système multi-agent PAMAS.AIS : Automatic Identification System, système d’échanges automatisés de messages entre navires

par radio qui permet aux navires et aux systèmes de surveillance de trafic de connaître l’identité, lestatut, la position et la route des navires en situation.

Amas : Adaptive Multi-Agent Système, théorie mise en place par l’équipe SMAC.API : Application Programming Interface.DCNS : Direction des Constructions Navales.IHM : Interface Homme-Machine.MAN (ou MDR) : Moteurs d’Analyse Navire (Moteur de règles), appartient au serveur d’application

de la DCNS.MAY : Make Agent Yourself, plateforme de conception d’API agents.muADL : langage de description de la plateforme MAY.NORM : serveur de plages de normalité, ou serveur de plages d’invariance, appartient au serveur

d’application de la DCNS.OpMAS : Operative Multi-Agent System, système multi-agent de surveillance maritime.PAMAS : Parameter Adjuster Multi-Agent System, système multi-agent d’ajustement de paramètres.SITU : Situation renseignée, base de données navires du serveur d’application de la DCNS.SMA (ou MAS) : Système Multi-Agent (Multi-Agent System).SMAC : Systèmes Multi-Agents Coopératifs.VMS : Vessel Monitoring System : système de surveillance par satellite. Depuis 2006, chaque navire

de pêche doit posséder un dispositif électronique qui envoie automatiquement les données d’identifica-tion et de position du navire.

55

Bibliographie

[Bernon et al., 2002] Bernon, C., Gleizes, M.-P., Picard, G., and Glize, P. (2002). The Adelfe Methodologyfor an Intranet System Design. In Giorgini, P., Lespérance, Y., Wagner, G., and Yu, E., editors, Interna-tional Bi-Conferenystems (AOIS-2002) at CAice Workshop on Agent-Oriented Information SSE’02 (AOIS -SSE), Toronto, Ontario, Canada, 27/05/02-28/05/02, page (on line), http ://ceur-ws.org. CEUR WorkshopProceedings. Pages de la publication : -.

[Calvez, 2007] Calvez, B. (2007). Le calibrage de modèles à base d’agents pour la simulation de systèmes com-plexes. PhD thesis, Universitè d’Evry-Val d’Essonne.

[Camps and Gleizes, 1996] Camps, V. and Gleizes, M.-P. (1996). Attitudes coopératives individuellespour l’adaptation collective. In Journées Francophones IAD SMA, Port Camargue, 01/04/1996-03/04/1996,pages 153–165, http ://www.editions-hermes.fr/. Hermès.

[Dagnelie, 2003] Dagnelie, P. (2003). Principes d’expérimentation : planification des expériences et analyse deleurs résultats. Edition électronique <http ://www.dagnelie.be>.

[Dance et al., 2003] Dance, S., Dance, Y., and Gorman, M. (2003). A deployed multi agent system formeteorological alerts. In Applications of Autonomous Agents and Multi-agent Systems, AAMAS’03, pages14–20.

[Di Marzo Serugendo et al., 2006] Di Marzo Serugendo, G., Gleizes, M.-P., and Karageorgos, A. (2006).Self-Organisation and Emergence in Multi-Agent Systems : An Overview. Informatica, 30(1) :45–54.ISSN 0350-5596.

[Ferber, 1995] Ferber, J. (1995). Les systèmes multi-agents : vers une intelligence collective. Informatique,Intelligence Artificielle. InterÉditions.

[Georgé, 2004] Georgé, J.-P. (2004). Résolution de problèmes par émergence, Etude d’un Environnement deProgrammation émergente. Thèse de doctorat, Université Paul Sabatier, Toulouse, France.

[Georgé et al., 2009] Georgé, J.-P., Peyruqueou, S., Régis, C., and Glize, P. (2009). Experiencing Self-Adaptive MAS for Real-Time Decision Support Systems. In Demazeau, Y., Pavon, J., Corchado, J. M.,and Bajo, J., editors, International Conference on Practical Applications of Agents and Multiagent Systems,Salamanca (Spain), 25/03/09-27/03/09, pages 302–309, http ://www.springerlink.com. Springer.

[Glize, 2001] Glize, P. (2001). L’Adaptation des Systemes a Fonctionnalite Emergente par Auto-OrganisationCooperative. Habilitation à diriger des recherches, Université Paul Sabatier, Toulouse, France.

[Grassé, 1959] Grassé, P.-P. (1959). La reconstruction du nid et les coordinations interindividuelles chez-bellicositermes natalensis etcubitermes sp. la théorie de la stigmergie : Essai d’interprétation du com-portement des termites constructeurs. Insectes Sociaux, 6(1) :41–80.

[Holland, 1975] Holland, J. (1975). Adaptation in Natural and Artificial Systems. University of MichiganPress.

[J. Ragot, 1999] J. Ragot, F. K. (1999). Ajustement automatique des paramètres d’un multi-régulateur.JESA, 33(2) :99–113.

[Jacob and Ludovic, 2002] Jacob, Z. and Ludovic, M. (2002). Les systèmes de détection d’intrusions,principes algorithmiques. MISC, (3) :24–30.

57

Bibliographie

[Koutkias et al., 2002] Koutkias, V. G., Chouvarda, I., and Maglaveras, N. (2002). Agent-based moni-toring and alert generation for a home care telemedicine system. In Proc. of the American MedicalInformatics Association Symposium 2002 (AMIA), pages 395–399.

[Littaye et al., 2009] Littaye, A., Giraud, M.-A., Mano, J.-P., Bonnot, A., Napoli, A., Botalla, M., Jangal,F., and Morel, M. (2009). ScanMaris : détection des comportements anormaux des navires TraficMa-ritime. In WISG.

[Merz, 2000] Merz, P. (2000). Memetic Algorithms for Combinatorial Optimization Problems : Fitness Land-scapes and Effective Search Strategies. PhD thesis, Department of Electrical Engineering and ComputerScience, University of Siegen, Germany.

[Rao and Georgeff, 1995] Rao, A. S. and Georgeff, M. P. (1995). Bdi agents : from theory to practice.

[Rosenblatt, 1958] Rosenblatt, F. (1958). The perceptron : A probabilistic model for information storageand organization in the brain. Psych. Rev., 65 :386–407. (Reprinted in Neurocomputing (MIT Press,1988).).

[S. Treuillet, 2004] S. Treuillet, D. D. e. P. R. (2004). Ajustement des paramètres d’une chaîne de traite-ments d’images par un plan d’expériences factoriel fractionnaire 2k-p. Traitement du signal, 21(2) :141–155.

[Sontheimer et al., 2001] Sontheimer, T., Cornuau, P., Vidal, J.-J., and Glize, P. (2001). Application d’unsystème adaptatif pour la prévision des crues dans le bassin de la Garonne - Un modèle émergent.SIRNAT 2001.

[Tan, 2005] Tan, O. (2005). A multi-agent system for tracking the intent of surface contacts in ports andwaterways. Master’s thesis, Naval Postrgraudate School.

[Topin et al., 1999] Topin, X., Regis, C., Gleizes, M.-P., and Glize, P. (1999). Comportements individuelsadaptatifs dans un environnement dynamique pour l’exploitation collective de ressources . In Intelli-gence Artificielle Située, cerveau, corps et environnement (IAS’99), Paris, France, 25/10/99-26/10/99. Hermès.Pages de la publication : -.

[Valeur et al., 2004] Valeur, F., Vigna, G., Kruegel, C., and Kemmerer, R. A. (2004). A comprehensive ap-proach to intrusion detection alert correlation. IEEE Transactions On Dependable and Secure Computing.,1(3) :146–169.

[Welcomme et al., 2006] Welcomme, J.-B., Gleizes, M.-P., and Redon, R. (2006). Self-Regulating Multi-Agent System for Multi-Disciplinary Optimisation Process. In Dunin-Kêplicz, B., Omicini, A., andPadget, J., editors, European Workshop on Multi-Agent Systems (EUMAS), Lisbon, 14/12/2006-15/12/2006,volume 223, page (electronic medium), http ://ceur-ws.org. CEUR Workshop Proceedings. ISSN1613-0073.

[Werbos, 1974] Werbos, P. (1974). Beyond Regression : New Tools for Prediction and Analysis in the BehavioralSciences. PhD thesis, Harvard University, Cambridge, MA.

58

Comportements coopératifs d’auto-ajustement de paramètres ... · Comportements coopératifs...

Documents

Transcript of Comportements coopératifs d’auto-ajustement de paramètres ... · Comportements coopératifs...