chopinaudRJCIA05 PDF

Contrôle Dynamique d’Agent Autonome
Caroline Chopinaud1 ,2
1
Thales Systèmes Aéroportés - 1 boulevard Jean Moulin 78852 Elancourt
2
Laboratoire Informatique de Paris 6 - 8 rue du Capitaine Scott 75015 Paris
caroline.chopinaud@fr.thalesgroup.com
Résumé : Pouvoir avoir confiance dans le comportement d’un système

est primordial, en particulier dans le contexte d’applications critiques
telles que les systèmes embarqués, les systèmes temps réels... Notre ob-
jectif est d’assurer qu’un système multiagent a un comportement en ac-
cord avec ce que l’on peut attendre de lui. L’utilisation de méthodes
statiques pour la validation ne permet pas d’identifier toutes les situa-
tions où le système, une fois mis en condition réelle, sera susceptible
de générer des erreurs. Nous proposons une approche complémentaire
d’auto-surveillance et d’auto-régulation permettant aux agents de vérifier
la cohérence de leur comportement au cours de leur exécution et de
réagir en conséquence. Notre approche consiste à fournir aux agents un
ensemble de lois qu’ils devront respecter. Ces lois sont définies à l’aide
d’un langage déclaratif permettant de faire aisément évoluer le contrôle
auquel on souhaite soumettre le SMA. La vérification du bon respect
des lois est faite par les agents eux-mêmes dans le but de préserver leur
autonomie. Ce papier présente un générateur qui, à partir d’un modèle
d’agent, d’une description de comportement et de lois, va créer des agents
capables de s’auto-contrôler. Les principes de ce générateur sont illustrés
sur un exemple.
Mots-clés : Systèmes Multiagents, Contrôle, Vérification, Autonomie.
1 Introduction
L’autonomie est une caractéristique essentielle des agents cognitifs. Nous la
verrons comme la capacité d’un agent à prendre seul ses décisions 1 . Du point
de vue du programmeur cela signifie que la mise en place d’un agent nécessite
de prendre en compte le fait que le comportement des autres agents, s’ils sont
autonomes, ne peut être prédit avec certitude. Il faut donc programmer son agent
en ayant à l’esprit que les autres peuvent ne pas réagir de la façon attendue.
Aussi, une telle vision pose-t-elle le problème de la confiance que l’on peut avoir
dans le fonctionnement de son système. Dans les milieux industriels concernés
1 Sans qu’une entité extérieure prenne part à son processus de choix (Barber & Martin,
1999)
RJCIA 2005
par des applications critiques, telles que les systèmes embarqués ou les systèmes
temps réels, la mise en oeuvre de tel système risque de soulever des objections
en raison de cette imprévisibilité. Il est donc indispensable de pouvoir garantir
qu’un SMA et les agents le constituant respectent des exigences de comportement
préétablies, importantes pour le bon fonctionnement de l’application, tout en
préservant au mieux leur autonomie.
L’objectif de nos travaux est d’assurer qu’un SMA a un comportement en ac-
cord avec ces exigences. Une première approche serait d’utiliser des méthodes
classiques de validation des systèmes que l’on appliqueraient aux systèmes mul-
tiagents, telles que les techniques de tests, de model-checking et de démonstration
automatique. Mais, outre le fait que ces techniques ne sont jamais en mesure de
détecter toutes les erreurs possibles d’un système (Schnoebelen, 1999), elles ne
sont pas forcément adaptées à la validation des systèmes multiagents dans leur
globalité. Bien que ces techniques soient indispensables à la validation d’un SMA,
elles ne sont pas suffisantes car elles laissent la possibilité d’apparition d’erreurs
une fois le système mis en condition réelle d’exécution, du fait de leur applica-
tion sur un modèle abstrait du système et de son environnement. Pour détecter
ces erreurs il est intéressant d’effectuer une vérification dynamique du compor-
tement du système en complément des méthodes classiques. Cette vérification 2
consiste en la surveillance et la régulation des comportements incohérents dans
le but d’empêcher que le système échoue.
Nous pensons qu’il est essentiel de préserver l’autonomie des agents sous
contrôle. L’autonomie étant une caractéristique importante des agents cogni-
tifs, il n’est pas souhaitable de la limiter. En effet, si le contrôle tend à diminuer
cette particularité, il est fort probable que les agents soient d’autant moins en
mesure de réagir à des situations compliquées et incertaines. Pour préserver l’au-
tonomie des agents, la surveillance et la régulation de leur comportement seront
effectuées par les agents eux-mêmes.
Bien qu’il soit possible pour un programmeur d’inclure le code de contrôle
nécessaire à la surveillance et à la détection d’erreur au sein même des agents,
cela peut s’avérer complexe. L’instrumentation manuelle du code d’un système,
pour y insérer des détecteurs d’évènements particuliers, est difficile et enclin
à l’erreur (Mansouri-Samami & Sloman, 1992). De plus, lorsqu’une propriété
à valider concerne plusieurs agents, il apparaı̂t comme impossible de trouver
la cause et de résoudre le problème au moyen d’une implémentation simple et
claire. Aussi devient-il difficile de faire évoluer le comportement des agents mais
également le contrôle auquel ils sont soumis. En se basant sur les instrumenta-
tions automatiques pour le monitoring de systèmes distribués, il est envisageable
d’automatiser l’instrumentation des programmes de comportement des agents
pour mettre en place le contrôle, et ainsi faciliter le travail du programmeur.
Nous proposons un générateur qui, à partir d’une description des exigences as-
sociées aux agents et du code de leur comportement, va créer des agents capables
d’auto-contrôle. Dans une première partie nous allons présenter les principes de
notre approche, pour ensuite nous intéresser à l’architecture de notre générateur.
2 Nous emploierons par la suite le terme de contrôle pour désigner cette vérification
Contrôle d’agent
Nous illustrerons principes et fonctionnements sur un exemple.
2 Vérification de systèmes
Notre objectif étant de garantir qu’un système aura un comportement en ac-
cord avec ce que l’on peut attendre de lui, il est intéressant d’introduire avant
tout quelques-unes des techniques de vérification de logiciel afin de mettre en
avant ce qui semble se rapprocher le plus de ce que nous souhaitons appliquer
aux agents.
2.1 Techniques de Validation

Il existe différentes techniques pour valider un système, comme les tests, le
model-checking et la démonstration automatique. Ces différentes approches sont
indispensables mais elles laissent subsister des situations dans lesquelles peuvent
apparaı̂tre des erreurs une fois le système mis en condition réelle d’exécution. Les
tests ne peuvent être exhaustifs, le model-checking, travaillant sur une abstrac-
tion du système, ne peut que détecter les erreurs de ce modèle et la détection
automatique est lourde et complexe. Néanmoins ces techniques ont fait leurs
preuves dans la validation des systèmes multiagents. B.Edmons et J.J.Bryson
(Edmonds & Bryson, 2004) mettent en avant l’utilisation des tests au détriment
des méthodes formelles, en raison des problèmes liés à l’abstraction et la modé-
lisation nécessaires pour les appliquer. M.Wooldridge (Wooldridge et al., 2002)
et M.Benerecetti (Benerecetti et al., 1997) montrent les possibilités de validation
des SMA grâce au model checking, mais pour des situations particulières (BDI,
protocole). Il n’est de toute façon pas envisageable de valider un SMA dans
sa globalité, du fait des difficultés à valider un comportement distribué et non
déterministe (Joyce et al., 1987) et des risques d’explosion du nombre d’états
de sa modélisation. Enfin certains se sont penchés sur la démonstration auto-
matique, mais bien qu’intéressante, cette approche ne peut être généralisable à
tout type d’agents et de problèmes (Burkhard, 1993).
Nous ne pouvons donc nier l’intérêt de ces techniques, mais il est évident que
pour avoir une totale confiance dans l’exécution d’un SMA il est indispensable
de s’attacher à une vérification en-ligne du système. De ce fait nous nous plaçons
dans le cadre suivant : un développeur a suivi l’ensemble des spécifications du
système pour mettre en place les agents et a tout mis en oeuvre pour valider un
SMA. Mais pour garantir que le comportement de ce dernier suivra les attentes
des clients et utilisateurs finaux, il est nécessaire de faire une vérification du
comportement du système en cours d’exécution. Pour cela, il est intéressant
d’utiliser les techniques de monitoring appliquées aux systèmes distribués.
2.2 Monitoring de systèmes distribués

Le monitoring est une technique pour observer et comprendre le comportement
dynamique de programmes à l’exécution. Il existe trois types de monitoring, le
RJCIA 2005
monitoring hardware, software et hybride. Dans le monitoring hardware ce sont

des objets séparés qui sont utilisés pour détecter les événements associés à un
objet ou un groupe d’objets. Ces monitors hardware effectuent leur détection par
l’observation des bus du système ou en utilisant des sondes physiques connectées
aux processeurs ou aux canaux d’E/S. Un monitor software partage les ressources
avec le système sous surveillance. Le programme est instrumenté en insérant des
sondes logicielles dans le code pour détecter les événements. Enfin, le monito-
ring hybride consiste en un dispositif hardware qui reçoit les informations de
surveillance générées par les sondes logicielles insérées dans le système surveillé
(de Sousa Dias & Richardson, 2002). Nous nous intéressons plus particulièrement
au monitoring software. Pour surveiller le comportement d’un système il faut
donc insérer dans le programme des détecteurs d’évènements. L’instrumentation
peut être faite manuellement par le programmeur (Marzillo et al., 1991) ou de
façon automatique. L’automatisation de l’insertion peut prendre deux formes,
soit le programmeur va utiliser un méta-langage (Lumpp et al., 1990) ou une li-
brairie de routines (Huang & Kintala, 1995) permettant d’insérer les détecteurs
de façon transparente, soit l’insertion des détecteurs se fera à la compilation
à partir de spécifications des événements (Liao & Cohen, 1992). C’est cette
dernière vision qui a attiré notre attention et que nous souhaitons appliquer aux
systèmes multiagents car elle permet de réduire le travail du programmeur au
maximum, en ce qui concerne la prise en charge du contrôle.
3 Contrôle d’agents autonomes

Contrôler un SMA revient à surveiller son comportement en cours d’exécution
et à le réguler en cas de détection d’anomalies, les agents surveillant et régulant
leur propre comportement. L’idée est donc d’insérer automatiquement un certain
“code de contrôle” à l’intérieur des agents pour leur permettre de vérifier la
bonne concordance de leur comportement avec les exigences associées. Ce code
de contrôle étant préalablement validé, il n’existe pas de risque que les erreurs
viennent de cette partie de l’agent.
3.1 Vérification de comportement

Nous avons vu la difficulté de modéliser le comportement d’un SMA et des
agents le constituant. Les agents étant construits à partir d’un ensemble d’exi-
gences, en nous basant sur des travaux de M.S.Feather (Feather et al., 1998),
nous pensons qu’elles peuvent être directement ou indirectement utilisées pour
représenter ce qui est correct ou non dans le comportement et l’état interne d’un
agent. Ces exigences sont, ce qu’on appellera par la suite, les lois du système.
Ainsi un agent capable d’auto-contrôle, s’assure que les lois qui lui sont attribuées
sont respectées tout au long de son exécution. Mais cette surveillance ne suffit
pas, lorsque l’agent détecte qu’une loi n’est pas satisfaite, il se doit de réguler
son comportement en conséquence, à partir d’actions et/ou d’informations de
réparation.
3.2 Aspects principaux

Avant tout nous souhaitons simplifier le travail du programmeur. Il ne va donc
pas se charger d’instrumenter le code des agents pour savoir s’ils respectent bien
l’ensemble des lois. Nous fournissons un générateur, qui à partir du code du
comportement des agents et de l’ensemble des lois va créer des agents en mesure
d’effectuer leur propre contrôle, en instrumentant automatiquement leur code de
comportement.
Nous souhaitons également que la personne chargée de définir et décrire les lois
ne soit pas obligatoirement le programmeur. Le client, ou l’utilisateur final, doit
aussi être en mesure de poser des lois sur le système, car c’est lui qui a défini les
exigences et qui va exécuter le système dans des conditions réelles. Or un client
ou un utilisateur ne peut réellement connaı̂tre ou comprendre l’implémentation
des agents. Pour qu’ils puissent poser des lois sur un système, celles-ci doivent
être décrites à un niveau tel que les choix d’implémentation n’aient pas à rentrer
en considération.
Enfin, nous ne voulons pas nous restreindre à un contrôle sur un seul type
de modèle d’agent. Il ne serait pas réaliste de n’en considérer qu’un seul, nous
avons pour ambition de permettre le contrôle d’un grand nombre de SMA. De
plus, les agents d’un même système peuvent être construits suivant des modèles
différents et, dans ce cas, une loi doit pouvoir être appliquée à ces agents sans
avoir à l’adapter en conséquence. Il faut se placer à un niveau d’abstraction
permettant d’englober un grand nombre de modèles d’agent.
Les lois doivent donc porter sur des concepts généraux, représentatifs des
différents modèles utilisés mais aussi de l’application. Les modèles utilisés pour
concevoir des agents sous contrôle doivent, dès lors, fournir un descriptif des
concepts qui font leurs spécificités. C’est à partir de cet ensemble de concepts
qu’il sera possible de construire les lois.
3.3 Mise en place du contrôle

Au niveau du modèle : le développeur du modèle doit fournir une description
des concepts le caractérisant ainsi que leur correspondance dans le programme
pour permettre la surveillance de leur état au cours de l’exécution.
Au niveau du SMA : le développeur du système construit les agents en suivant
les exigences préétablies.
Au niveau du contrôle : le client ou l’utilisateur final doit fournir un ensemble
de lois qu’il souhaite voir être vérifiées tout au long de l’exécution du système.
Ces lois peuvent concerner un ou plusieurs agents. Elles portent sur les concepts
décrits au niveau du modèle et du système. L’utilisateur doit aussi décrire des
actions de réparation en cas de non respect d’une loi pour permettre à l’agent
de réguler son comportement.
Au niveau de l’automatisation : le générateur traite les lois, récupère les liens
aux concepts pour injecter le code de contrôle et génère les agents. Ces derniers
s’auto-contrôlent pour détecter s’ils respectent les lois qui leur sont attribuées.
RJCIA 2005
Fig. 1 – Réseau de Petri modélisant les agents
Si une loi n’est pas respectée, les agents lancent un comportement de secours à
partir d’informations de réparation.
4 Un Exemple
Dans le but d’illustrer notre approche et le fonctionnement de notre générateur
nous allons introduire un exemple.
4.1 Le système multiagent

Le système multiagent est constitué au départ de trois agents : un agent A,
se chargeant de discuter avec un utilisateur ; un agent B, se chargeant de gérer
les problèmes proposés par l’agent A ; un agent C, se chargeant de résoudre
les problèmes. Lorsque l’agent B reçoit un problème il l’analyse et demande à
l’agent C s’il peut effectuer la résolution. Si l’agent C est disponible pour cette
tâche, l’agent B lui transmet le problème, dans le cas contraire l’agent B va créer
un nouvel agent de type C et lui transmettre le problème. Une fois le problème
résolu, l’agent C renvoie le résultat à l’agent B qui va le transmettre à l’agent A
pour le fournir, dans un format compréhensible, à l’utilisateur.
Chaque agent est construit sur un modèle de réseau de Petri (figure 1). A
chaque état, les agents se mettent en attente de réception d’un nouveau mes-
sage. Suivant le message reçu, le réseau va déclencher une action particulière
et se mettre dans un nouvel état. Les actions observables sont, par exemple :
la réception de message (au niveau des états), les actions de transition (l’envoi
d’un message, la création d’un nouvel agent, ...). Les données observables sont,
par exemple : la liste des accointances, les messages reçus.
4.2 Les lois du système

L’utilisateur final souhaite que certains comportements ou états de données au
sein du système soient bien respectés. Par exemple, il peut être souhaitable que
l’agent A n’envoie pas des demandes de résolution de problème à l’agent B à une
cadence trop élevée. Dans le cas contraire, l’agent B pourrait ne plus arriver à
suivre les demandes et par conséquent les agents C pourraient ne plus répondre
en un temps acceptable aux problèmes proposés. Dans le cas où cette exigence
n’est pas respectée l’utilisateur précise que l’envoi du message incriminé doit être
annulé. L’utilisateur peut décider de poser la loi suivante :
L1 : “Un agent de type A ne doit pas envoyer des messages, à un agent de type B, à
une cadence supérieur à 1 Hz.”
Un autre problème pouvant perturber le fonctionnement du système peut ap-

paraı̂tre au niveau de la création d’agent C par l’agent B. Ce dernier, demande
aux agents C qui est disponible. Si au bout d’un temps t donné, l’agent B ne
reçoit aucune réponse, il en déduit qu’aucun agent est disponible et en créé un
nouveau. Si le temps d’attente n’est plus adapté, l’agent B va se mettre à créer
des agents C quasiment à chaque soumission d’un problème. Le système peut
alors se trouver en surcharge et empêcher la bonne exécution de l’application.
Une action de réparation lorsque cette exigence n’est plus vérifiée pourrait être
de bloquer la création du nouvel agent. Une loi pour détecter ce problème serait :
L2 : “Un agent de type B ne doit pas lancer la création d’un agent de type C s’il en
existe un de ce même type qui est dans un état disponible ”.
Enfin le client veut pouvoir vérifier que certains protocoles qu’il a définis pour
le système sont effectivement suivis. Par exemple l’agent C peut s’attendre à
recevoir les messages suivants, dans cet ordre : l’identifiant du problème, le temps
maximum d’attente du résultat, les données d’un problème. Si ce protocole n’est
pas suivi par l’expéditeur, il se peut que l’agent C ne puisse pas résoudre le
problème ou échoue. Dans le cas où le protocole n’est pas respecté une solution
est de prévenir l’agent expéditeur de l’erreur. Pour détecter l’apparition de ce
problème une loi serait :
L3 : Un agent Solveur doit recevoir le message de durée puis le message d’identification
puis les données du problème.
5 SCAAR : un framework pour la génération

d’agents autonomes auto-contrôlés
SCAAR (Self-Controlled Autonomous Agent geneRator) est un framework per-
mettant la génération d’agents capables de s’auto-contrôler. Pour cela, il utilise
l’ensemble des lois associées aux différents agents d’un SMA, l’ensemble des
concepts utilisés dans ces lois, et injecte dans les programmes des agents, le code
de contrôle nécessaire à l’analyse du bon respect des lois. La figure 2 représente
l’architecture de notre framework. Sa composition est la suivante :
• Lois : L’ensemble des propriétés que l’agent doit respecter.
• Ontologie : L’ensemble des concepts représentant le modèle utilisé pour décrire
l’agent et ceux caractéristiques du SMA.
• Modèle d’agent : Les liens entre la description du modèle (l’ensemble des
concepts) et le programme en tant que tel.
• Programme d’agent : Le code du comportement de l’agent.
RJCIA 2005
Fig. 2 – Architecture du framework SCAAR
• Générateur : Le créateur de l’agent final à partir des éléments précédents.

• Agent Auto-Contrôlé : L’agent final exécutable. Il surveille son propre com-
portement afin de vérifier s’il respecte les lois et le régule si une loi est trans-
gressée.
5.1 L’ontologie
Nous avons vu que les lois devaient porter sur des concepts de haut niveau
permettant de décrire les spécificités des agents et du système. Nous avons
donc cherché à mettre en place une ontologie de base représentative des modèles
connus pouvant être utilisés pour construire des agents. Une ontologie d’agent
est proposée par D.N.Lam et K.S.Barber (Lam & Barber, 2004) dans le cadre
de la vérification d’agent. Elle contient les concepts de but, croyance, intention,
action, événement, message. Nous reprenons une partie de cette ontologie (but,
action, message) et nous ajoutons d’autres concepts qui nous semble plus ca-
ractéristiques des agents vis-à-vis de l’étude que nous avons faites des modèles
(objet, connaissance, plan, création d’agent, envoi de message, réception de mes-
sage, migration). Enfin comme nous nous plaçons au niveau du SMA, nous ajou-
tons le concept d’agent.
Chaque concept a un ensemble d’attributs et de méthodes 3 permettant d’ex-
primer des tests sur les concepts au sein des lois. L’ontologie (Fig.3) peut être
étendue suivant les caractéristiques des modèles utilisés et de l’application.
Les concepts de base que l’on retrouve dans le modèle de notre exemple
sont ReceptionMessage, EnvoiMessage, CreationAgent, Action, Agent. Ceux
étendus des concepts de base et représentatifs du modèle sont : Croyance,
qui est une Connaissance, Etat qui est une Connaissance sur soi-même et
MessageRecu qui est un Message. Enfin, celui spécifique à l’application est par
exemple : Dispo qui est un Etat.
3 Elles ne sont pas décrites sur la figure

Fig. 3 – Ontologie d’Agent (sous forme de digramme UML)
5.2 Les Lois

On peut distinguer deux types de lois, celles représentant des situations où
quelque chose ne doit jamais se produire, et celles où quelque chose devant se
produire n’a pas eu lieu. Elles décrivent comment un agent doit se comporter
ou dans quel état il doit être pour correspondre à ce qu’on attend de lui. Nous
relions les lois à la logique déontique (von Wright, 1951). Cette dernière a sou-
vent été utilisée pour décrire les normes, qui se rapprochent de notre concept
de loi, dans les systèmes multiagents. Ainsi, le premier type de loi correspond à
une interdiction et le second à une obligation. Nous nous servons des opérateurs
déontiques pour exprimer ce qui est interdit et ce qui est obligatoire et ainsi
distinguer leur prise en compte au sein des agents. La structure que nous pro-
posons pour exprimer les lois est néanmoins la même pour les deux types. La
loi doit contenir les éléments nécessaires pour savoir quand la déclencher, quand
la vérifier, quels concepts sont mis en jeu et quelles propriétés vérifier sur ces
concepts. La loi est donc composée :
• ASSERTION DEONTIQUE - AD : correspond à ce qui est obligatoire (O)
ou interdit (I). Ce peut être une action faite par un agent ou l’état particulier
d’un concept que l’on souhaite vérifier.
• CONDITION EVENEMENT - CE : correspond aux événements déclen-
cheurs de la loi et sa durée d’application. Un événement est une action, une suite
d’actions ou l’état particulier d’un concept.
• CONDITION APPLICATION - CAP : correspond aux conditions d’acti-
vation de la loi. Une condition porte sur l’état des concepts utilisés dans le reste
de la loi ou sur d’autres agents du SMA.
• CONDITION ALLOCATION - CAL : définit les agents concernés par cette
loi.
RJCIA 2005
• REGULATION - REG : correspond aux actions à effectuer pour réguler le

comportement de l’agent lorsque la loi n’est pas vérifiée, i.e. l’assertion deontic
n’est pas satisfaite. Ce sont des actions simples portant sur les concepts du
système permettant de sauver temporairement les agents incriminés.
Si on reprend l’exemple vu au chap.4, nous pouvons écrire les lois suivant cette
structure 4 .
(L1) a : Agent, ev1 : EnvoiMessage, ev2 : EnvoiMessage

(AD) I(do(a,ev2))
(CE) begin{ do(a,ev1)) }, end{ begin + 1 }
(CAP) (ev1.dest).type = typeB, ev2.dest = ev1.dest,
(CAL) a.type = typeA
(REG) block{ do(a,ev2) }
(L2) a1 : Agent, a2 : Agent, ca : CreationAgent

(AD) I(do(a,ca))
(CE) null
(CAP) (ca.agentCrée).type = typeSolveur, a2.type = typeSolveur,
be(a2,dispo)
(CAL) a.type = typeB
(REG) block{do(a,ca)}
(L3) a : Agent, mr1 : MessageRecu, mr2 : MessageRecu, mr3 : MessageRecu,

ev : EnvoiMessage
(AD) O(have(a, mr2.cont = “ident(M2)”)
then have(a, mr3.cont = “pb(M3)”))
(CE) begin{ have(a, mr1.cont = “time(M1)”) }, end{ null }
(CAP) null
(CAL) a.type = typeSolveur
(REG) execute{ do(a, EnvoiMessage(mr1.exp, “pb toto”)}
5.3 Liens au modèle

La génération d’agents auto-contrôlés nécessite l’instrumentation des program-
mes des agents afin d’insérer les points de contrôle permettant de vérifier que
les lois sont respectées. Les concepts sur lesquels portent les lois doivent avoir
une signification au niveau du code des agents. Le concepteur du modèle fournit
les liens entre les concepts et le code du modèle pour permettre au générateur
d’insérer le contrôle à l’intérieur de celui-ci et par extension à l’intérieur des
agents.
Voyons sur l’exemple les liens nécessaires pour insérer le code de contrôle au
sein des agents. On suppose ici que les agents sont programmés en Prolog. Ils ont
accès à un ensemble de primitives permettant d’échanger des messages, de créer
des agents et de migrer. Ces primitives sont fournies avec le modèle de réseau
de Petri utilisé pour construire les agents.
4 do(a,b) : l’agent a exécute l’action b. be(a, c) : l’agent distant a, est dans un état tel que
c est vrai. have(a, d) : l’agent a est dans un état tel que d est vrai
Fig. 4 – Structure des agents générés
• ReceptionMessage : dans le modèle cette action correspond à l’appel de la clause

de réception de message se situant au niveau des états de l’automate.
link((receptionMessage == receiveMessage\3),
receptionMessage.cont == argument(1),
receptionMessage.dest == argument(2)).
• MessageRecu : dans le modèle, ce concept correspond à une variable pour laquelle
on fournit un accesseur.
link((messageRecu == call(getIncomingMessage\0),
(messageRecu.cont == call(getContent(messageRecu)),
(messageRecu.dest == call(getRemote(messageRecu))).
5.4 Structure des agents générés

Les agents générés doivent être en mesure de contrôler leur propre comporte-
ment. Ils doivent donc avoir une structure appropriée reflétant le caractère in-
trospectif de ce contrôle. Ce dernier consiste, nous l’avons vu, en la surveillance
du comportement des agents pour vérifier que des lois sont respectées et la
régulation du comportement lorsqu’une loi est transgressée. Les lois pouvant
porter sur plusieurs agents, il est important que ceux-ci puissent communiquer
entre eux pour vérifier le bon respect des lois et résoudre les problèmes. Leur
structure fournit un moyen de collaboration dans le contrôle. L’agent généré
est divisé en deux parties, une partie correspondant au comportement réel
de l’agent et l’autre dédiée au contrôle et qui va collaborer avec les parties de
contrôle des autres agents. La partie de contrôle est divisée à son tour en deux
blocs fonctionnels. Un bloc pour la surveillance et un pour le traitement des
lois transgressées. La figure 4 décrit la structure de deux agents auto-contrôlés
en interaction. Le comportement envoie des informations à la surveillance sur
son exécution et son état interne (i.e. les valeurs des concepts). La surveillance
vérifie si les lois sont bien respectées. En cas de transgression d’une loi, un mes-
sage de détection d’anomalie est envoyé à la partie traitement qui va exécuter les
actions et fournir des informations de réparation au comportement. Ce dernier
va en déduire les changement à effectuer pour être cohérent.
RJCIA 2005
5.5 Le générateur
Pour créer des agents capables de détecter la transgression des lois au sein de
leur propre comportement, le générateur utilise des techniques de tissage pour
mettre en place des points de contrôle. Le tissage est une part fondamentale
de la programmation par aspect, qui consiste à injecter dans un programme
un certain code à un endroit donné. La programmation par aspect utilise le
tissage pour injecter des aspects dans les classes d’une application, au niveau
des méthodes, de façon à modifier l’exécution finale des classes après compila-
tion. La programmation par aspect, grâce à AspectC++, a été montrée comme
particulièrement intéressante pour intégrer du monitoring dans une application
(Mahrenholz et al., 2002). Nous reprenons cette idée de tissage pour effectuer
une instrumentation automatique des lois et de leur analyse à l’intérieur du
programme représentant le comportement d’un agent.
Le générateur va extraire des lois, ce qu’il reconnaı̂t comme étant des concepts
faisant partie de l’ontologie associées au SMA. Pour chaque concept il récupère
le lien au code de l’agent et va déduire des mots clés du langage de description
des lois, le code à insérer au sein de l’agent pour permettre la surveillance. Par
exemple si on reprend la loi L1 :
• I(do(a,ev2)) : tissage avant l’appel à ev2 d’un point de blocage du comportement
pour tester si la loi est activée et dans ce cas si elle est respectée.
• begin{ do(a,ev1)) } : tissage d’un point d’activation de la loi juste après l’appel à
ev1.
• end{ begin + 1 } : mise en route d’un compteur à l’activation de la loi pour 1s. Au
bout de 1s la loi est désactivée.
• (ev1.dest).type = typeB, (ev2.dest).type = typeB : tissage d’un test de validité
d’application de la loi (d’activation au niveau de ev1 et de respect au niveau de ev2).
• a.type = typeA : tissage des lois uniquement dans les agents de type A.
• block{ do(a,ev2) } : tissage au niveau de ev2 d’un “saut” de l’appel à ev2.
6 Travaux similaires
Dans les travaux de M.S.Feather (Feather et al., 1998) il est également question
de comparer l’exécution d’un SMA à ses spécifications. Dans cette approche, un
unique monitor se charge de récupérer les événements envoyés par les agents et un
réconciliateur va, en cas de violation, non pas remettre le système dans un état tel
qu’il respecterait ses spécifications, mais modifier les spécifications pour qu’elles
soient en accord avec le nouveau comportement du système. Ici, il n’est pas
question de spécifications primordiales pour le bon fonctionnement du système,
les auteurs ne cherchent donc pas à empêcher les mauvais comportements mais
à faire en sorte que le système et les spécifications s’adaptent pour rester en
accord, tout au long de l’exécution.
D.N.Lam et K.S.Barber (Lam & Barber, 2004) propose une méthodologie, la
“Tracing Method”pour tester et expliquer le comportement des agents. L’objectif
de cette méthodologie est de s’assurer qu’un agent exécute une action pour de
bonnes raisons et si une action innatendue apparaı̂t, d’aider à expliquer pourquoi
l’agent a décider d’exécuter cette action. Les similitudes avec notre approche
viennent de l’ontologie d’agent que les auteurs proposent pour pouvoir facilement
comparer des modèles de spécifications (diagramme d’état, de séquences...) au
comportement réel des agents. Notre approche se distingue de la Tracing Method
du fait de l’automatisation que nous proposons au niveau de l’instrumentation
du code des agents, mais aussi au niveau de la détection des incohérences entre
le comportement attendu et le comportement observé. Enfin, notre approche
consiste à embarquer le contrôle au sein des agents pour permettre une détection
dynamique des erreurs de comportement et non une étude post-mortem des
traces de programme.
Enfin, nous citerons les recherches de J.Vasquez-Salceda (Vasquez-Salceda
et al., 2004) qui propose un langage de normes, dans le cadre d’applications
médicales, basé sur la logique déontique, permettant de détecter lorsqu’une
norme n’est pas respectée et de punir l’agent en conséquence. Même si nos lois
s’apparentent à des normes, leur finalité n’est pas d’orienter le comportement
des agents mais de vérifier qu’il correspond à des exigences. Contrairement aux
normes, les agents ne décident pas de suivre ou non les lois, car elles sont signi-
ficatives de leur comportement.
7 Conclusion
Nous avons présenté dans ce papier un système permettant la génération
d’agents en mesure d’effectuer une vérification de leur propre comportement.
Cette vérification consiste à s’assurer que les lois associées à un agent sont
bien respectées tout au long de son exécution. Ces lois correspondent aux des-
criptions d’exigences sur le comportement et les états des agents. L’intérêt de
notre approche est principalement de permettre à une personne extérieure au
développement du système de vérifier qu’il respecte bien certaines règles mais
aussi de simplifier le travail du développeur en lui épargnant l’instrumentation
de son code. Enfin, un point important tient au fait que cette vérification des lois
peut se faire sur n’importe quel agent et ce quelque soit le modèle utilisé pour
l’implémenter. Ainsi, même un SMA aux agents hétérogènes peut être soumis à
des lois.
La prochaine étape de nos travaux sera surtout axée sur la construction du
langage de description des lois. Ce langage doit permettre de déduire, de façon
générale, le code à insérer à l’intérieur des agents pour effectuer le contrôle du
respect des lois, tout en étant assez complet pour pouvoir exprimer un grand
nombre de type de lois. La génération du code à partir des lois pourrait passer
par une étape de modélisation automatique des lois sous forme d’un réseau de
Petri décrivant ce qui est interdit ou obligatoire pour un agent.
Références
Barber K. & Martin C. (1999). Agent autonomy : Specification, measure-
RJCIA 2005
ment and dynamic adjustment. In Proc. of the Autonomy Control Software

workshop at Autonomous Agents’99, p. 8–15.
Benerecetti M., Giunchiglia F. & Serafini L. (1997). Model Checking
Multiagent Systems. Rapport interne 9708-07, IRST, Povo, Italy.
Burkhard H. (1993). Liveness and fairness properties in multi-agent systems.
In Proceedings of Int. Joint Conferences on Artificial Intelligent : IJCAI’93.
de Sousa Dias M. & Richardson D. J. (2002). Issues on Software Moni-
toring. Rapport interne, Department of Information and Computer Science,
University of California, Irvine, CA.
Edmonds B. & Bryson J. (2004). The insufficiency of formal design methods
- the necessity of an experimental approach for the understanding and control
of complex mas. In Proceeding of AAMAS’04, New York, USA.
Feather M., Fickas S., van Lamsweerde A. & Ponsard C. (1998). Re-
conciling System Requirements and Runtime Behavior. In Proceedings of
IWSSD9, Isobe, Japan.
Huang Y. & Kintala C. (1995). Software fault tolerance in the application
layer. In Software Fault Tolerance, p. 231–248.
Joyce J., Lomow G., Slind K. & Unger B. (1987). Monitoring distributed
systems. ACM Transaction on Computer Science, 5(2), 121–150.
Lam D. & Barber K. (2004). Verifying and explaining agent behavior in
an implemented agent system. In Proceedings of the 3rd International Joint
Conference on Autonomous Agents and Multi-Agent Systems (AAMAS-2004),
p. 1226–7, New York City.
Liao Y. & Cohen D. (1992). A specificational approach ot high level program
monitoring and measuring. IEEE Trans. Software Engineering, 18(11).
Lumpp J., Casavant T. & H.J Siegle D. M. (1990). Specification and iden-
tification of events for debugging and performance monitoring of distributed
multiprocessor systems. In Proceedinfs of the 10th International Conference
on Distributed Systems, p. 476–483.
Mahrenholz D., Spinczyk O. & Schröder-Preikschat W. (2002). Pro-
gram instrumentation for debugging and monitoring with aspectc++. In Proc.
of the 5th IEEE International symposieum on Object-Oriented Real-time Dis-
tributed Computing, Washington DC, USA.
Mansouri-Samami M. & Sloman M. (1992). Distributed Monitoring Sytems
(a Survey). Rapport interne DOC92/23, Imperial College of Science Techno-
logy and Medecine, Departemnt of Computing, London, UK.
Marzillo K., Cooper R., Wood M. & K.P B. (1991). Tools for distribution
application management. Cornell University, IEEE Computer, p. 42–51.
Schnoebelen P. (1999). Vérification de Logiciels : Techniques et Outils du
Model-Checking. Vuibert edition.
Vasquez-Salceda J., Aldewerld H. & Dignum F. (2004). Implementing
norms in multiagent systems. In Proceedings of MATES’04, Erfurt, Germany.
von Wright G. (1951). Deontic logic. Mind, 60(237), 1–15.
Wooldridge M., Fisher M., Huget M. & Parsons S. (2002). Model che-
cking multi-agent systems with mable. In Proceedings of AAMAS’02, Bologna,
Italy.

chopinaudRJCIA05 PDF

Transféré par

Droits d'auteur :

Formats disponibles

chopinaudRJCIA05 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

chopinaudRJCIA05 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Contrôle Dynamique d’Agent Autonome

Résumé : Pouvoir avoir confiance dans le comportement d’un système

Nous illustrerons principes et fonctionnements sur un exemple.

2.1 Techniques de Validation

2.2 Monitoring de systèmes distribués

monitoring hardware, software et hybride. Dans le monitoring hardware ce sont

3 Contrôle d’agents autonomes

3.1 Vérification de comportement

3.2 Aspects principaux

3.3 Mise en place du contrôle

Fig. 1 – Réseau de Petri modélisant les agents

4.1 Le système multiagent

4.2 Les lois du système

Un autre problème pouvant perturber le fonctionnement du système peut ap-

5 SCAAR : un framework pour la génération

Fig. 2 – Architecture du framework SCAAR

• Générateur : Le créateur de l’agent final à partir des éléments précédents.

3 Elles ne sont pas décrites sur la figure

Fig. 3 – Ontologie d’Agent (sous forme de digramme UML)

5.2 Les Lois

• REGULATION - REG : correspond aux actions à effectuer pour réguler le

(L1) a : Agent, ev1 : EnvoiMessage, ev2 : EnvoiMessage

(L2) a1 : Agent, a2 : Agent, ca : CreationAgent

(L3) a : Agent, mr1 : MessageRecu, mr2 : MessageRecu, mr3 : MessageRecu,

5.3 Liens au modèle

Fig. 4 – Structure des agents générés

• ReceptionMessage : dans le modèle cette action correspond à l’appel de la clause

5.4 Structure des agents générés

ment and dynamic adjustment. In Proc. of the Autonomy Control Software

Vous aimerez peut-être aussi