Gestion de l’implicite

Afin de simplifier la tâche de l’auteur de scénario, nous avons cherché à simplifier le

scéna-rio en permettant d’y insérer de l’implicite. Nous allons donc rendre implicite certaines actions

de base qui ne seront plus écrites dans le scénario et qui seront remplacées par la spécification

de pré et post conditions sur l’état des ressources (section 4.5.1). Nous allons aussi définir des

préconditions sur l’état d’une relation STORM (section 4.5.2). Nous allons également typer

les objets afin de pouvoir raisonner dans le scénario sur ces types et non plus seulement sur

les instances des objets (section 4.5.3). Mais ajouter de l’implicite dans le scénario implique

une complexité accrue à résoudre au niveau du moteur de scénario. En effet on ne peut plus

être certain que les actions implicites ont été réalisées ; il va falloir également désambiguïser

automatiquement certaines actions ce qui auparavant était le travail de l’auteur de scénario.

4.5.1 Pré et post conditions sur l’état des ressources

Dans la description des procédures industrielles (dans les cartes de travail par exemple)

certaines actions sont implicites, par exemple les actions de prise d’outils. Or notre langage de

scénario imposait à l’auteur d’extraire des procédures ces actions implicites afin de les écrire

dans le scénario. Pour nous rapprocher davantage de la description réelle de la procédure, nous

avons donc décidé de simplifier le scénario en rendant implicites des actions basiques comme

prendre un outil et poser un objet. Il faut alors préciser pour chaque action du scénario qui

requiert un état précis concernant une ressource de l’acteur une pré-condition et une

post-condition sur cet état.

Comme nous l’avons vu dans la section 3.1.1.1, pour le moment nous gérons uniquement

les mains comme ressources pour l’acteur. Il faut donc spécifier dans le scénario, là où cela est

utile, l’état des mains de l’acteur requis pour faire l’action (pré-condition) et l’état des mains

après l’action (post-condition). Cela permet de raisonner sur ces états afin de déterminer les

actions prérequises à l’action (prise d’outil et pose d’objets). Cela permet également d’identifier

les actions qui rendent une ressource occupée et qui sont donc potentiellement une source de

blocage. Chaque condition est donc un couple d’état, un pour la main droite, l’autre pour la

main gauche ; l’ordre n’a pas d’importance puisque nous avons décidé de considérer l’acteur

comme ambidextre (voir section 3.1.1.2). Ces états sont à choisir parmi les trois états que

peuvent avoir une main de l’acteur : libre, objet attrapé (l’objet peut servir d’outil) ou occupée,

auxquels s’ajoute l’état indifférent qui indique que la condition sera valide quelque soit l’état

effectif de la main. Pour l’état objet attrapé on précise également l’objet requis et pour l’état

occupée la cause de l’occupation (la relation concernée). La figure 4.7 illustre l’utilisation des

pré et post conditions.

En réalité la spécification des pré et post conditions est facultative (notamment afin de

gar-der la compatibilité avec les anciens scénarios) et seulement indicative. En effet la faisabilité

de l’action sera évaluée par le moteur d’interaction en fonction des capacités et des états des

relations et objets impliqués. Le moteur d’interaction ne vérifie donc pas explicitement la

pré-condition écrite dans le scénario, mais en pratique si elle n’est pas vérifiée l’action ne sera pas

possible. Le fait d’écrire la précondition dans le scénario pourrait alors paraître redondant avec

les informations contenues dans la définition des relations. Les pré et post conditions

explici-tées dans le scénario servent en fait pour raisonner : c’est grâce à elles qu’il sera possible de

déterminer les actions implicites nécessaires à la réalisation d’une action du scénario. Comme

nous l’avons vu dans la section 3.1.1.2, le gestionnaire de ressources va en effet se servir de la

précondition pour calculer une séquence d’action permettant d’atteindre cet état cible à partir

de l’état courant de l’acteur. Les post conditions vont servir pour effectuer des raisonnement

hors ligne par exemple (voir la section 4.6.2). En effet, là aussi c’est le moteur d’interaction

qui gère les conséquences des actions et donc l’évolution des objets et relations STORM.

F

IG

. 4.7 – Description XML d’une action avec pré et post condition sur l’état des mains

Les actions de prise et de pose d’objets sont des actions très courantes dans une procédure

de maintenance, le fait de ne plus avoir à les écrire dans le scénario permet donc de simplifier

considérablement l’écriture de ce dernier. Par ailleurs rendre ces actio ns implicites permet une

meilleure adaptabilité du scénario (possibilité de se resservir d’un outil déjà en main) et évite

des situations incohérentes. En effet, un acteur pourra alors choisir de reposer un outil s’il ne

s’en ressert pas tout de suite ou au contraire de le conserver s’il en a besoin pour réaliser une

autre portion du scénario. L’acteur ne sera donc pas contraint d’adopter la solution retenue par

l’auteur de scénario qui aurait pu conduire à des situations absurdes où il aurait dû reposer un

outil et le reprendre aussitôt.

4.5.2 Préconditions sur l’état d’une relation

En plus des préconditions sur l’état des ressources d’un acteur nous proposons pour les

actions du scénario des préconditions sur l’état d’un type de relation STORM donné sur un

objet donné. L’action correspondante ne sera alors possible que si la précondition est vérifiée.

Il faut donc préciser l’objet sur lequel porte la relation, le type de la relation ainsi que l’état

voulu. Par exemple, la figure 4.8 montre une action du scénario qui consiste à appuyer sur

un bouton pour stopper le moteur. En précondition on précise qu’il faut que le moteur soit en

marche en disant que la relation de type relationActif sur l’objet moteur doit être dans l’état

actif.

F

IG

. 4.8 – Description XML d’une action avec précondition sur l’état d’une relation

Contrairement aux préconditions sur l’état d’une ressource les préconditions sur l’état

d’une relation ne sont pas juste indicatives, elles sont discriminatoires. L’action sera en

at-tente tant que la précondition ne sera pas vérifiée. Une fois la précondition vérifiée, l’action

deviendra alors possible.

Ces préconditions ne servent qu’à faire une vérification pour pouvoir réaliser une action du

scénario, en revanche rien ne nous permet pour le moment de raisonner sur les actions pour

trouver les actions nécessaires à la vérification de la précondition. Grâce à ces préconditions il

est donc possible de faire des vérifications sur les actions réalisées jusque là et de proposer des

alternatives en fonction de l’état actuel de l’environnement. Le scénario est ainsi plus adaptatif.

4.5.3 Types

Dans une procédure de maintenance, certaines actions sont à répéter plusieurs fois mais

avec des instances d’objet différentes. Il peut alors être fastidieux de décrire toutes les

combi-naisons possibles pour enchaîner ces actions. Par exemple s’il faut planter 10 clous dans une

planche et qu’on en a 50 à disposition, peu importe les instances des clous utilisées et l’ordre

dans lequel ces clous vont être plantés. Il faudrait alors faire différents embranchements avec

les instances possibles à utiliser : cela serait extrêmement long et fastidieux et sans grand

inté-rêt. Pour simplifier le scénario, nous avons donc décidé de regrouper les objets par catégories

en leur attribuant un type. Dans le scénario il sera alors possible de préciser non plus

l’ins-tance d’un objet à utiliser mais son type. Dans notre exemple tous les clous de notre boite de

clou seront du type clou. Il suffira alors d’enchaîner (ou de mettre en parallèle) 10 actions qui

prendront toutes comme paramètre un marteau et un clou.

Par ailleurs l’utilisation des types est nécessaire pour certaines actions. Par exemple si l’on

veut décrire l’action tenir le clou. Les paramètres sont donc le clou et la main. Mais lors de

l’écriture de cette action on ne sait pas quel est l’acteur qui va réaliser cette action et donc

quelle sera l’instance de main qui va servir pour tenir le clou. Il est donc obligatoire d’utiliser

des types et non des instances dans ce cas là.

Les types sont précisés lors de la description d’un objet servant à initialiser le moteur

d’interaction, en plus de ces capacités. Un objet peut avoir plusieurs types. Les types peuvent

ensuite être utilisés dans la description du scénario pour un paramètre d’une action mais

éga-lement dans une pré ou une post condition de cette action. Dans le scénario il n’y a pas de

distinction sur l’utilisation des types ou des instances. C’est ensuite lors de l’analyse de

l’ac-tion qu’on cherchera d’abord si un objet porte ce nom, et si ce n’est pas le cas, c’est qu’il s’agit

d’un type.

A la réalisation du scénario, il est facile de vérifier que l’action demandée par l’apprenant

correspond bien à l’action décrite dans le scénario (vérifier que si l’apprenant veut planter le

clou3 cela correspond bien à l’action courante du scénario qui spécifie que l’apprenant doit

planter un clou) mais il est plus difficile de déterminer l’instance de clou à utiliser à partir de

l’action du scénario : si l’humain virtuel veut réaliser cette action il va devoir déterminer quelle

instance de clou utiliser. Pour cela le système va passer en revue les différents objets du bon

type. La première chose à vérifier est que cette instance peut effectivement réaliser l’action (par

exemple un clou déjà planté ne peut plus l’être à nouveau). Ensuite, suivant les actions, il sera

préférable d’utiliser une instance plutôt qu’une autre. Par exemple pour prendre un clou il vaut

mieux prendre un clou qui n’a pas de possesseur. Si ce n’est pas possible on pourra, en dernier

recours, voler un clou à quelqu’un. En revanche, pour l’action poser un clou, il faut poser un

clou que l’acteur possède.

4.5.4 Synthèse

Nous avons profité du fait de proposer une extension multi-utilisateur au scénario pour

simplifier son écriture. Il n’est désormais plus utile de préciser les actions de prise et de pose

d’objets dans le scénario. A la place nous avons introduit des pré et post conditions pour les

actions du scénario qui décrivent l’état des mains de l’acteur. Nous avons aussi proposé

d’intro-duire des préconditions sur l’état d’une relation STORM qui permettent ainsi de spécifier des

alternatives dans le scénario en fonction de l’état du monde. Nous avons également introduit un

typage des objets. Pour paramétrer les actions du scénario il est maintenant possible d’utiliser

ces types plutôt que de préciser l’instance d’un objet. La procédure devient ainsi plus simple à

retranscrire pour l’auteur de scénario.

Dans le document Contribution à la formation en réalité virtuelle : scénarios collaboratifs et intégration d'humains virtuels collaborant avec des utilisateurs réels (Page 104-107)