Contrôle de la conformité des comportements individuels d’agents cognitifs autonomes Caroline Chopinaud Amal El Fallah Seghrouchni Patrick Taillibert 23/25 Novembre 2005 – JFSMA’05 (Calais)

Contexte et Problématique Systèmes critiques Systèmes embarqués, temps réels Conception au moyen des systèmes multiagents Confiance dans le comportement du SMA En accord avec les spécifications Pas de comportements inattendus. Tolérance aux fautes : Car un agent prenant seul ses décisions peut se débrouiller lorsqu’un autre agent échoue dans le système. IL prend en compte le fait qu’il ne sait pas comment un agent va réagir à une requête, de ce fait il va pouvoir trouver quoi faire lorsqu’un agent ne lui répond pas. Simplifie le travail du programmeur : Car le développeur, du fait qu’il ne sait pas comment vont réagir les autres agents, ne va pas avoir à prendre en compte toutes les possibilités de comportement à suivre suite aux réactions des autres agents puisqu’il ne peut pas les connaître.

Caractère imprévisible des SMA Problème de confiance Caractère imprévisible des SMA Autonomie des agents Prendre seul ses décisions [Barber 99] Émergence du comportement du système Comportements attendus Comportements inattendus Possible échec de l’application Apparition de comportements indésirables Comportement attendus : Correspond à ce que l’on peut attendre du système. TOUT VA BIEN. Autonomie : nous avons vu précédemment que le fait de prendre seul ses décisions pour un agent est une caractéristique intéressante pour diminuer la complexité de conception des systèmes mais le caractère imprévisible des comportements que cela engendre est une particularité négative pour avoir confiance dans son système. Cela peut générer plus de comportement inattendus!

Problème supplémentaire Bugs du système Vérification classique pas sûre à 100% Model Checking sur un modèle du système (très coûteux) Tests non exhaustifs Démonstration automatique lourde et complexe SMA accroît les difficultés de validation Modélisation (explosion d’états) Indéterminisme Distribution Communication asynchrone Moins spécifiques aux SMA mais renforcer par l’utilisation de ceux-ci du fait de la difficulté à modéliser leur comportement. On se place dans un contexte ou le développeur aura tout mis en œuvre pour valider son application. Apparition d’erreurs en conditions réelle d’exécution

Garantir qu’un SMA ne génèrera pas de comportements indésirables Objectif! Garantir qu’un SMA ne génèrera pas de comportements indésirables Compte des problèmes inhérents à l’utilisation des SMA et du fait que l’on veut pouvoir avoir confiance dans le comportement du système (rappelons que l’on est dans un milieu industriel ou il est nécessaire de garantir que les applications ne vont pas faire n’importe, le fait d’avoir des comportements émergents fait forcément peur).

La description du contrôle Plan de l’exposé Le contrôle d’agent La description du contrôle Génération des agents autocontrôlés

Le contrôle d’agent 3 étapes : Surveillance du comportement des agents Détection des comportements indésirables Régulation du comportement des agents problématiques

Surveillance du comportement Monitoring (software) : Observation et compréhension du comportement d’un programme au cours de son exécution Instrumentation des programmes pour observer les événements Insertion de sondes logicielles Manuelle ou automatique Instrumentation automatique Comportement des agents Facilite le travail du développeur Réduit le risque d’erreur Il faut donc leur fournir dans un premier temps de quoi vérifier leur comportement. Pour ce faire on se place dans le cadre du monitoring software. En effet nous souhaitons surveiller le comportement des agents au cours de leur exécution. Le monitoring consiste en : l’observation… Pour pouvoir surveiller un programme il faut l’instrumenter pour ajouter des sondes permettant d’observer des événements. Cette instrumentation peut être fait manuellement par le développeur du système avec tous les pbs que cela engendre. Une telle technique d’instrumentation est difficile, longue et il y a des risques d’erreur. Cette instrumentation peut aussi être fait automatiquement. Soit grâce à un métalangage permettant d’insérer de facon transparente les sondes dans le programme. Soit à la compilation a partir de la description des événements à observer. Nous souhaitons pouvoir simplifier le travail du développeur donc nous nous orientons vers une instrumentation automatique du code de comportement des agents pour leur permettre de surveiller leur comportement.

Le contrôle d’agent 3 étapes : Surveillance du comportement des agents Détection des comportements indésirables Régulation du comportement des agents problématiques

Détection des comportements indésirables (1) Normes Définition des comportements ou des situations idéales Contraintes/indications sur le comportement Éviter des conflits Restreindre les possibilités d’action des agents Confiance entre les agents Accepter et respecter les normes au moment de la prise de décision Les normes servent à orienter le comportement des agents en définissant un comportement ou une situation idéale que l’agent peut choisir ou non de suivre. Elles servent à prédire le comportement des autres agents en supposant qu’ils vont effectivement respecter les normes.

Détection des comportements indésirables (2) Utilisation de lois Normes non prises en compte au moment de la prise de décision Séparation de la définition du contrôle et de l’implémentation des agents Matérialisent les exigences significatives du fonctionnement du système Définissent les comportements souhaités ou redoutés Nos lois sont des normes qui sont ajoutées après coup dans l’agent pour surveiller leur comportement et détecter lorsqu’un comportement ne respecte pas les spécifications et non pas pour restreindre les actions des agents. Fournir aux agents les moyens nécessaires pour leur permettre de détecter les comportements indésirables. Pour ce faire nous proposons d’utiliser des lois. Ces lois correspondent aux exigences à partir desquelles est construit le SMA. Une partie seulement, celles qui sont importantes. Les lois définissent des comportements souhaités ou redoutés. Ainsi détecter un comportement indésirable revient à détecter les violation d’une loi. Détection de transgression des lois

Le contrôle d’agent 3 étapes : Surveillance du comportement des agents Détection des comportements indésirables Régulation du comportement des agents problématiques

Régulation du comportement Effectuée par les agents eux-mêmes Capacité de raisonnement Informations de transgression Stratégie de régulation Fournie par le développeur Associée à la transgression d’une loi

La description du contrôle Plan de l’exposé Le contrôle d’agent La description du contrôle La génération des agents autocontrôlés

Fournit un ensemble de concepts de base Description des lois Fournit un ensemble de concepts de base Utilisés dans les lois Utilisés pour décrire l’application et le modèle d’agent Étendus pour raffiner la description Par le concepteur du modèle et de l’application Reliés à l’implémentation du modèle d’agent Définition de liens par les concepteurs Fournit un langage de lois Description d’actions ou d’états Redoutés Souhaités Notion de temps ou de relation temporelle Le concepteur du modèle décrit les liens entre les concepts et le code pour permettre l’instrumentation des programmes des agents. Elles ne sont qu’à faire qu’une seule par modèle et peuvent être validées pour être s’assurer que si un agent est soumis à des lois, elles seront forcément prise en compte si elles utilisent les concepts définissant le modèle. Le concepteur du SMA décrit les concepts caractéristiques de ces agents sachant que ces concepts doivent être des sous-concepts des concepts du modèle pour ne pas avoir à spécifier les liens entre ces concepts et le code des agents. Ceci pour éviter les erreurs et pour ne pas compliquer le travail du développeur du système.

Concepts de base Agent Caractéristique Action Message Objet But Plan Connaissance Action CreationAgent ReceptionMessage EnvoiMessage Migration Pour qu’un concept puisse avoir la possibilité d’être exprimer dans une loi, c’est-à-dire qu’il puisse être compréhensible. IL faut qu’il soit un sous-concept d’un des concepts de base que nous fournissons. Cet ensemble de concept comprends trois grande catégories : Agent, pour répresenter un agent. Etat, comprends les caractéristiques internes de l’agent. On y trouve les concepts de Message que peut envoyer un agent, des objets que peut manipuler un agent, les but que souhaite atteindre l’agent, les Plans qui suivent l’agent, les connaissances qu’a l’agent. Le dernier concept est action qui représente une action que peut effectuer un agent. Les sous-concepts de ce concept d’action sont La creation d’agent, la reception d’un message, l’envoi de message et la migration.

Langage de description (1) Opérateurs déontiques. Interdiction (FORBIDDEN) Obligation (OBLIGED) Actions Agent do Action Action ou changement de valeur d’une Caractéristique Etats Agent be State Etat résultant d’une Action ou valeur d’une Caractéristique Notion temporelle BEFORE/AFTER (une action ou un temps) IF (un état) Enchaînement d’actions/états THEN Conjonction d’actions/états AND LA deuxième étape est la description des lois du système. Nous fournissons un langage de description des lois utilisant la logique déontique. La logique déontique est un logique modale dans laquelle il est possible d’exprimer des obligations, des interdictions et des permissions. Notre langage permet d’exprimer des interdictions grâce au mot clés FORB et des obligations grâce au mot clé (OBLI). Une interdiction définit les événement redoutés. Une obligation définit les événements souhaites. Les lois décrivent des événements : de deux sortes, un agent exécute une action, ou un agent a un nouvel état. On peut détecter une exécution d’action et un changement d’état. Il est possible d’exprimer du temps. Soit directement en seconde, soit par relation entre événements. Il est possible d’exprimer une conjonction d’événement. C’est-à-dire qu’on doit avoir EV1 et EV2 sans ordre particulier. On peut exprimer une suite dans les événements : THEN

Langage de description (2) Sémantique Logique déontique dynamique [Meyer85] Variante de la logique déontique [vonWright51] Logique modale Obligation / Interdiction / Permission / Facultatif Exprime la différence en l’idéal et le réel (violation) Relation temporelle entre actions et états du monde

Langage de description (3) Logique déontique dynamique Soit A1,A2 des actions et E, un état du monde A1 ; A2 : A1 est suivie de A2 A1 & A2 : A1 et A2 sont simultanées E  A1/A2 : si E alors A1 sinon A2 A1 U A2 : A1 ou A2 A1 : not A1 [A1]E : E est vrai après l’exécution de A1 <A1>E : Il existe un moyen d’exécuter A1 pour que E soit vraie F : Interdiction O : Obligation P : Permission

Langage de description (4) Sous ensemble de la logique déontique dynamique Ne permet pas d’exprimer Permission Négation d’opérateurs déontiques <A>E A1 U A2 Permet d’exprimer des lois du type: FORBIDDEN (agt do EnvoiMessage) AFTER (agt do EnvoiMessage) AND BEFORE (1) FORBIDDEN (agA do Migration) IF (agB be Migration) OBLIGED (agA do EnvoiMessage and content = ‘A’) AND (agA do EnvoiMessage and content = ‘B’)

La description du contrôle Plan de l’exposé Le contrôle d’agent La description du contrôle La génération des agents autocontrôlés

Agent autocontrôlés (1) Génération automatique à partir de Programme de comportement Ensemble de lois associées Liens entre les concepts et l’implémentation Autocontrôle Principe de l’observateur Architecture d’agent spécifique Une fois les concepts définit et les lois exprimer dans le langage de description il reste à fournir aux agents les moyens nécessaires pour vérifier que leur comportement respecte les lois qui leur sont attribués. Pour ce faire on va ajouter deux composantes aux agents : Des points de contrôle. Pour détecter les événements exprimés dans les lois. Injecter dans le code des agents (tissage). Une partie contrôle. Pour vérifier le respect des lois. Relié au comportement de l’agent grâce aux points de contrôle. Utilisant le principe de l’observateur.

Principe de l’observateur CONNEXIONS PROGRAMME SOUS SURVEILLANCE MODELE Le principe de l’observateur consiste à détecter en cours d’exécution des erreurs dans les processus parallèles. On fait évoluer un programme et un modèle en parallèle. On a donc le programme sous surveillance relié à un modèle grâce à des connexions à l’aide de point de contrôle. Le modèle décrit par exemple à l’aide d’un réseau de Petri les propriétés sur le comportement du programme. Le contrôleur est activé à chaque passage du programme sur un point de contrôle. Il compare l’évolution du programme et l’état du modèle et fait évoluer ce dernier en conséquence. CONTROLEUR

Principe de l’observateur PROGRAMME MODELE Début S1 Fin S1 Début S2 Par exemple on modélise une propriété d’exclusion de deux séquences parallèles S1 et S2 sous forme d’un réseau de Petri, S1 et S2 étant lié au modèle au niveau des transitions du réseau. Lorsqu’on passe sur S1 le contrôleur se déclenche et il vérifie qu’il y a bien un jeton dans une place précédente. Etc… Si quelque chose ne va pas dans l’exécution des séquences alors le programme ne correspond pas au modèle et une exception est lancée. Fin S2

Principe de l’observateur [Diaz 1994] Agent autocontrôlé (2) Principe de l’observateur [Diaz 1994] Installer au sein des agents Modélisation des lois sous forme de réseau de Petri Relier les lois au programme des agents par des points de contrôle La partie contrôle est ajoutée au comportement de l’agent pour permettre la vérification du respect des lois. Elle utilise la technique de l’observateur. Cette technique consiste à faire tourner un modèle et un programme en parallèle tout au long de l’exécution du système. Le modèle représente des propriétés sur l’exécution du système. Ce modèle est lié au programme. Par exemple les propriétés peuvent être représenté par des réseaux de Petri dont les transitons seront liéés au programme. Lorsque le programme génére un événement sur une transition du réseau et que les jetons ne correspondent pas dans les places, l’observateur génére une exception. Nous allons utilisé le principe de l’observateur en modélisant les lois sous le forme de réseau de Petri qui seront liés aux événements du programme correspondant aux événements décrits dans les lois.

Génération automatique (1) Insertion des points de contrôle (instrumentation) Utilisation du tissage Principe de la programmation par aspect [Wampler 2003] Injection de code à partir de la définition de point de jonction. Au niveau des événements décrits dans les lois A partir de la description des liens concepts/implémentation Les points de contrôle sont placés aux niveaux des événements décrits dans les lois dans le programme. Pour les mettre en place dans le programme on utilise la technique du tissage. Le tissage est un principe de la programmation par aspect. La programmation par aspect consiste à exprimer des structures transverses dans des modules séparés et à les tisser dans le programme de l’application au niveaux des méthodes ou des flux à l’aide de la définition de point de jonction. Nous allons donc injecter les points de contrôle dans le programme grâce à la définition des liens entre les concepts définissant l’application et l’implémentation du modèle. Ces points de contrôlés sont liés au transition du réseau de Petri représentant la loi.

Génération automatique (2) Génération automatique du réseau de Petri. LOI {Réseaux de Petri} RESEAU DE PETRI Utilisation d’une table de correspondance langage/réseau de Petri Ainsi pour pouvoir générer automatiquement des agents auto-contrôlés il est nécessaire de générer automatiquement les réseau de Petri utilisé pour vérifier le respect des lois à partir de la définition des lois. Pour ce faire on part des lois exprimés dans le langage de description, on en déduit une expression en logique grâce à un tableau de correspondance entre les mots clés du langage et la logique déontique. Puis à partir de l’expression déontique on génére automatiquement un réseau de Petri représentant la loi en utilisant une table de correspondance entre la logique et des réseaux de Petri.

Génération automatique (3) FORBIDDEN (ACT2) AFTER (ACT1) AND BEFORE (1) [ACT1]F(ACT2)[time(ACT1,1)] ACT1 ACT2 [1,1] [ACT1] [time(1)] F(ACT2) [ACT1]…[time(ACT1,1)]

Architecture de contrôle Partie Comportement Partie Contrôle Surveillance du comportement Comportement Informations Détection de transgression Stratégies de Régulation Infos transgression

Fonctionnement du contrôle FORBIDDEN (agent do action2) after (agent do action1) and before (1) Code de l’agent ClauseAction1(…) PC(EV1) … PC(EV2) ClauseAction2(…) [1,1] Information de transgression

Conclusion Contrôle d’agent Concepts de base pour décrire le système Au moyen des lois Effectué par les agents eux-mêmes Concepts de base pour décrire le système Langage de description des concepts Langage de description des liens concepts/code Langage de description des lois Générateur d’agent Instrumentation du code par tissage pour détecter les événements décrit dans les lois Génération de réseau de Petri représentant la loi pour vérifier son respect grâce à la méthode de l’observateur

Perspectives Application à des lois multiagents (contrôle distribué) Répartition des réseaux de Petri entre les agents Echange entre les parties contrôle pour détecter les transgressions (flux des jetons) Implémentation du framework SCAAR Le langage de loi Les langages de descriptions des concepts et des liens Le générateur d’agent (instrumentation et architecture de contrôle) Régulation des comportements

Fin… …MERCI!!!