Nous avons implémenté l’architecture représentée par la figure5.1Dans le but de construire un
planificateur en mixed-initiative adapté à l’assistance dans la configuration des systèmes complexes
et répondant au critères d’évaluation exprimés dans le chapitre2. Comme on peut le voir, cette
archi-tecture se décompose en quatre parties :
1. Le gestionnaire d’interaction, qui comme son nom l’indique, gère les interactions, en mixed-initiative, entre l’utilisateur et le système, ainsi que les échanges entre les modules ;
2. Les bases de connaissances, qui contiennent les connaissances sur le domaine et les problèmes de planification représentés avec différents niveaux de détails ;
3. Le module d’instanciation et de simplification qui réalise les opérations de calcul et de transfor-mation des connaissances en effectuant le processus d’instanciation et de simplification pré-senté au chapitre 5.
4. Le module de planification qui s’occupe de la recherche de plans et de la production des infor-mations nécessaires pour une interaction en mixed-initiative.
L’architecture du système se concentre sur les modules d’interaction, de planification, de repré-sentation et de traitement des connaissances, sans détailler la ou les interfaces utilisées pour interagir avec l’utilisateur. Cela reflète l’objectif de cette thèse qui se concentre sur le développement des
mé-83 CHAPITRE5. MIP : UN SYSTÈME DE PLANIFICATION EN MIXED-INITIATIVE Utilisateurs Interfaces d’interaction 1. Gestionnaire d’interaction 4. Module de planification Connaissan-ces de haut niveau
Assistant de chargement des données
Gestionnaire d’interrogation des domaines / problèmes
Gestionnaire d’ajout / modification des données
Connaissan-ces de bas niveau Gestionnaire de planification 3. Module de grounding Interpréteur
du problème Calculateur d’inerties
Instanciateur Simplificateur
2.
FIGURE5.1 –Architecture du système de planification en mixed-initiative MIP.
canismes internes permettant une planification en mixed-initiative indépendamment de l’interface utilisée. Le développement d’une interface d’interaction adaptée pourra faire l’objet d’un nouveau sujet de recherche.
5.1.1 Gestionnaire d’interaction
Le gestionnaire d’interaction regroupe tous les modules qui prennent en charge les interactions en mixed-initiative avec l’utilisateur, pour cela :
— Ils reçoivent et interprètent les commandes de l’information, de modification, ou de planifi-cation qui sont exprimées par l’utilisateur en commandes internes du système ;
— Ils présentent les résultats et les réponses aux commandes de l’utilisateur ;
— Ils présentent les propositions de modification des connaissances du domaine ou du pro-blème qui sont à l’initiative du système.
Le gestionnaire d’interaction s’occupe aussi de la gestion des échanges entre les modules et des ap-pels de leurs fonctions afin de :
— Gérer l’affectation et l’ordonnancement des tâches nécessaires pour la résolution du pro-blème ;
— Récupérer, manipuler et raisonner sur les données contenues dans les bases de connaissances ; — Récupérer et formaliser les résultats des modules d’instanciation et de simplification ;
plani-SECTION5.1 ARCHITECTURE DU SYSTÈME 84
fication ;
— Récupérer et interpréter le résultat de la planification lorsqu’un plan solution est trouvé et même lors d’un échec.
En pratique, le gestionnaire de tâches traite et dispatche les requêtes en se fondant sur des com-mandes qui sont définies dans le système. Si par exemple l’utilisateur exprime une commande de planification cela passera par le mot clé « plan ». Il en est de même pour les autres commandes qui sont aussi définies par un mot clé. L’aspect modulaire du gestionnaire d’interaction permet de le faire évoluer et d’y inclure, par exemple, un module de reconnaissance de la parole qui induirait la requête et ces paramètres depuis une phrase en langage naturel.
Le gestionnaire d’interaction est composé de quatre sous-modules gérant chacun un ensemble de tâches précis. À chaque sollicitation du gestionnaire d’interaction, un ou plusieurs de ces mo-dules sont appelés à répondre en fonction de la commande reçue. Cela peut aller du chargement des connaissances nécessaires à la planification, jusqu’au raisonnement sur les données pour expliquer le résultat d’une demande de planification, en passant par la modification du problème et la ges-tion des foncges-tionnalités liées à la planificages-tion, comme par exemple : la décomposiges-tion pas à pas ou l’incitation au changement, que nous détaillerons dans la deuxième partie de ce chapitre.
5.1.1.A Assistant de chargement des données
L’assistant de chargement des données permet au système MIP d’être« domain-independant ».
Il permet de modéliser les propriétés et les états du domaine d’application, les connaissances sur les actions à réaliser, les tâches à accomplir, et de raisonner en se basant dessus, dans le but de résoudre les problèmes de planification liés à ce domaine. Par exemple, il peut être utilisé dans l’assistance de configuration de systèmes complexes, le pilotage de drones, ou tout autre activité nécessitant de générer automatiquement une suite d’actions permettant d’atteindre un but ou réaliser une tâche donnée. L’assistant de chargement interagit avec les utilisateurs afin de charger les données du
do-maine et du problème, sous forme de fichiersHPDDL contenant les définitions des prédicats, des
opérateurs, des méthodes, ainsi que l’état initial1et le but à atteindre2. Avoir un module
indépen-dant dédié au chargement des données permet une meilleure évolution et une adaptation plus facile au problème à gérer. Cela peut passer par la mise en place de procédures d’automatisation pour la récupération de l’état du système cible, ou encore l’ajout d’une interface pour récupérer les données
du domaine et du problème sous une forme différente (i.e.depuis une ontologie en OWL-S).
1. L’état initial englobe généralement l’ensemble des propriétés représentant l’état du système cible au moment du chargement des données.
85 CHAPITRE5. MIP : UN SYSTÈME DE PLANIFICATION EN MIXED-INITIATIVE
5.1.1.B Gestionnaire d’interrogation
Le gestionnaire d’interrogation permet principalement de traiter les requêtes d’interrogation sur la base de connaissances. Il offre ainsi la possibilité à l’utilisateur de mieux comprendre le problème à travers l’interaction avec le système. Contrairement à une interface qui permet uniquement de vi-sualiser l’immense quantité de données disponibles pour un problème, le gestionnaire d’interaction masque les données inutiles et présente à l’utilisateur les données les plus pertinentes pour la re-quête qu’il a exprimé. Pour cela, il interroge la base de connaissances sur deux niveaux d’abstraction,
que nous aborderons plus en détails dans la section5.2.1, et fournit ainsi les données pertinentes
en fonction du niveau demandé de détails. Les requêtes que gère le gestionnaire d’interrogation ne se limitent pas seulement à la récupération de données, puisqu’il réalise aussi des raisonnements pour fournir des données liées les unes aux autres et dont le lien n’est pas forcément visible pour
l’utilisateur. La figure5.2montre le fonctionnement du gestionnaire d’interrogation sur une requête
d’interrogation nécessitant un raisonnement sur les données.
Utilisateur
Affiche moi toutes les tâches qui peuvent produire la propriété "p"
Gestionnaire d’interraction d’interrogationGestionnaire
Domaines/ Problèmes en PDDL Ground-problems Définition de la requête Dispatch de la requête Interrogation et récupération des données
Interrogation, calculs d'atteignabilité et récupération des données Résultat
Affichage du résultat
haut-niveau d’abstraction bas-niveau d’abstraction