Coopération Homme-Machine dans les Systèmes Complexes

Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
Coopération Homme-Machine dans les Systèmes
Complexes : Agents et Aide à la Décision
Guy A. Boy
Institut Européen de l'Ingénierie et des Sciences Cognitives (EURISCO)
4, avenue Edouard Belin, 31400 Toulouse, France
Tel. +33-62 17 38 38 - FAX +33-62 17 38 39 - Email: [email protected]
RESUME
Cet article présente une approche basée sur le
développement d'agents logiciels d'aide à la décision dans
le contrôle de systèmes complexes dynamiques. Il
s'appuie sur des exemples dans le domaine aérospatial. Il
discute les raisons qui font la promotion du concept
d'agent. Il décrit l'évolution d'une interaction basée sur
l'énergie vers une interaction basée sur l'information. La
décomposition de la complexité d'une tâche se fait par
une coopération entre agents. Elle induit la définition de
rôles affectés aux différents agents mis en jeu. La notion
d'interface profonde est définie par l'ensemble des agents
logiciels assistant l'utilisateur dans la prise de décision,
et plus généralement dans le contrôle du système.
Différents modèles de prise de décision sont présentés.
Le modèle RSRA (Reconnaissance de Situation et
Raisonnement Analytique), la représentation par blocs
de connaissances et l'analyse en fonctions cognitives
sont présentées comme support à la conception d'agents
logiciels.
MOTS CLEFS
Agents, aide à la décision, coopération Hommemachine, fonctions cogntives.
INTRODUCTION
Il existe une littérature importante dans le domaine de
la prise de décision [13; 16; 18; 28]. Plus récemment,
Wayne Zachary a donné un état de l'art sur les systèmes
d'aide à la décision (Decision Support Systems: DSS)
[32]. Cependant, la prise de décision dans la conduite de
systèmes complexes présente des caractéristiques
spécifiques qu'il convient d'analyser et de mieux
comprendre. Le pilotage d'avion fait partie des processus
dans lesquels la prise de décision doit être effectuée de
façon dynamique. En aviation, prendre une décision est
parfois synonyme de survie. Il existe bien sûr différents
niveaux de prise de décision. On se réfère en général au
modèle de Rasmussen pour expliciter les différents
niveaux de décision : habiletés, procédures et savoir
[27]. Les habiletés se réfèrent aux bas niveaux cognitifs,
et le savoir aux hauts niveaux cognitifs. Ce que nous
constatons aujourd'hui c'est la place de plus en plus
importante que prennent les décisions à des niveaux
cognitifs élevés.
Cet article tente de montrer pourquoi et comment
l'évolution actuelle des technologies de l'information
tend à privilégier la construction de systèmes hommesmachines multi-agents. Il discute les raisons qui font la
promotion du concept d'agent logiciel comme système
d'assistance à l'opérateur [5]. La coopération entre agents
humains et logiciels pour la prise de décision offre une
solution de décomposition de la complexité d'une tâche.
Il conduit à la notion d'interface profonde spécifiée à
partir de certains principes de coordination entre agents
humains et logiciels. Le rôle des agents dans la prise de
décision est défini grâce à différents modèles de prise de
décision. Dans tous les cas, ces agents logiciels doivent
aider à la compréhension et à la prise de conscience de la
situation.
Dans la conception de systèmes Hommes-machines
multi-agents, il est utile de considérer la dualité entre les
procédures et l'interface Homme-machine. La genèse et
l'utilisation du modèle R S R A (Reconnaissance de
Situation et Raisonnement Analytique) sont présentées.
Ce modèle a donné naissance à une représentation des
connaissances qui permet de prendre en compte la
modélisation des agents. Il s'agit de la représentation par
blocs. Elle nous permet entre autre de formaliser les
fonctions cognitives mises en jeu dans l'exécution de
tâches. Elle a donné lieu au développement et à la mise
en oeuvre d'une nouvelle méthode: l'analyse en fonctions
cognitives (AFC). Cette méthode permet de séparer les
aspects liés à l'interaction des aspects purement liés à la
tâche à effectuer. Des critères d'évaluation sont donnés.
Nous illustrerons notre approche sur des exemples dans
le domaine aérospatial.
POURQUOI LE CONCEPT D'AGENT D E V I E N T IL AUSSI IMPORTANT ?
D'une interaction basée sur l'énergie vers
une interaction basée sur l'information
La cognitivisation du pilotage d'avion est devenue une
réalité avec l'informatisation progressive des cockpits.
Nous sommes passés d'une interaction basée sur des
notions d'énergie (contrôle de processus classique) à une
interaction basée sur des notions d'informations (plus
proche de la gestion). Sur les avions traditionnels, le
pilotage est en grande partie basé sur des retours
proprioceptifs et sensori-moteurs. Par exemple, si le
pilote entend l'intensité sonore d'un moteur diminuer, il
regarde immédiatement l'indicateur de vitesse pour
vérifier la sécurité de l'avion. Aujourd'hui, pour des
raisons de confort, beaucoup de bruits et de retours
proprioceptifs ont été atténués (et parfois supprimés),
l'information qui était disponible directement dans le
passé est certes accessible en vision centrale sur des
écrans cathodiques, mais le pilote doit souvent
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
reconstruire cognitivement certains paramètres physiques
qui jadis pouvaient être perçus directement. A ces
aspects liés au confort passager, se sont ajoutés des
aspects liés à la sécurité. Il en a résulté que le nombre
d'informations transmises a beaucoup augmenté. Le fait
que le nombre de paramètres à prendre en compte
augmente ne favorise pas le processus de prise de
décision puisque le traitement et la capacité cognitive
humaine est limitée. Nous pensons que cette tendance
est propre à l'évolution des systèmes actuels en général.
C'est pour ce type de raison que la contribution d'agents
logiciels s'avère souvent utile, et dans certain cas
nécessaire. Il existe plusieurs objectifs qui motivent
l'automatisation. Ces objectifs peuvent être classés
selon la liste suivante adaptée de Billings :
• sécurité: pour conduire des opérations, du début à la
fin, sans causer de dommages aux personnes et à
l'environnement;
• fiabilité: pour fournir des opérations fiables sans
interférence des variables environnementales;
• économie: pour conduire toutes les opérations aussi
économiquement que possible;
• confort: pour conduire toutes les opérations de
manière à maximiser la santé et le confort des
utilisateurs et des personnes de leur environnement
(Billings, 1991, page 68).
Agents
Un agent est une entité (humain ou machine) qui est
capable d'effectuer une tâche. Un agent doit remplir un
ou plusieurs rôles et atteindre un ou plusieurs buts dans
un environnement donné. Un agent humain ou logiciel
peut être représenté simplement par un processeur
d'information, une base de connaissance et des canaux
d'interaction (Figure 1). Un agent a ses propres
exigences en information pour agir. Ces exigences sont
acquises par l'intermédiaire des canaux de réception.
Donnons quelques exemples de propriétés de ces canaux
récepteurs humains : séquentialité de la prise
d'information; persistance des informations acquises dans
la mémoire sensorielle (250 millisecondes pour le canal
visuel, par exemple); faculté de conscience de la
situation (focalisation de l'attention); précision des
informations; etc.
Ces propriétés peuvent être améliorées ou modifiées
par l'introduction de dispositifs adaptés. Notre objectif
est de concevoir des agents logiciels qui étendent les
capacités humaines, et parfois permettent à leurs
utilisateurs d'accomplir des tâches qu'ils n'ont pas la
capacité d'accomplir. Par exemple, l'être humain ne sait
pas voler sans l'utilisation d'un avion. Le problème
crucial dans l'utilisation de tels agents est de mettre en
évidence quelles sont les informations requises pour
piloter l'avion sûrement et confortablement.
Le processeur et la base de connaissances de chaque
agent est représentée par un ou plusieurs blocs de
connaissances associés à des métaphores traduisant
l'attitude de l'agent (voir plus loin la définition de la
méthode d'analyse en fonctions cognitives).
Environnement
Canaux
Récepteurs
Canaux
Emetteurs
Processeur et
Base de Connaissances
Figure 1. Un agent comme processeur
d'information.
La définition de nouveaux agents met en jeu de
nouveaux types de comportements et de traitements. Les
êtres humains ont besoin de s'adapter à de nouvelles
situations induites par l'introduction de ces nouveaux
agents. Afin de mieux caractériser ces changements,
faisons la liste d'une série de propriétés d'agents:
• délégation : une tâche ou sous-tâche est déléguée à un
agent;
• valeur cognitive : résultats de l'interaction avec
l'agent;
• contexte : un agent logiciel est conçu dans un
contexte spécifique qui définit (implicitement en
général) les limites de l'agent; il convient de noter que
le contexte d'utilisation effective de l'agent n'est en
général pas le même que le contexte d'utilisation
prévu pendant la conception;
• adaptation : les agents humains peuvent s'adapter
pratiquement à n'importe quoi, alors que les agents
logiciels sont relativement rigides même si l'on peut
les doter de capacités d'adaptation dans des contextes
très limités;
• prédictabilité : lorsque l'utilisateur peut prédire le
comportement d'un agent, il lui fait en général
confiance;
• expertise de l'utilisateur : les agents logiciels sont
conçus soit pour des experts, soit pour un public plus
large;
• type : les agents logiciels peuvent être réactifs (c'est la
forme la plus simple) ou cognitifs; nous dirons qu'un
agent est cognitif soit lorsqu'il a une architecture
cognitive (point de vue du concepteur), soit lorsqu'il a
un comportement cognitif (point de vue de
l'utilisateur);
• complexité : les agents logiciels peuvent être plus ou
moins complexes en fonction de la complexité de la
tâche qu'ils ont la mission d'accomplir,
• spécificité: il est important de préciser qu'un agent est
construit pour l'accomplissement d'une tâche
spécifique bien identifiée.
Coopération entre agents pour le maintien de
la conscience de la situation
Le pilotage de l'avion est caractérisé par la notion de
boucle fermée. Le fait que l'on ne puisse pas arrêter un
avion pour prendre une décision change radicalement les
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
conditions liées à la prise de décision. Le pilote doit être
conscient de la situation à tout instant afin de pouvoir
bâtir une décision sur des informations correctes en
nature et en nombre. Le processus de prise de décision
peut être guidé par l'utilisation de procédures. L'aspect
"monde semi-clos" de l'aéronautique lui confère des
possibilités de prédictions de situations et de cas déjà
traités, et donc de bâtir des procédures réutilisables en
fonction de circonstances analogues. Le pilote doit être
dans la boucle à tout instant. En effet, le niveau de
vigilance tend à baisser dès que l'opérateur ne fait rien.
En revanche, quelqu'un qui agit sait nécessairement ce
qui se passe dans son environnement pour maintenir la
stabilité globale du système Homme-machine. Il est par
conséquent très important que le pilote soit actif afin
qu'il ait une conscience "active" de la situation.
Habituellement, dans un environnement de prise de
décision multi-agents il existe trois paramètres
essentiels [20] : le vitesse d'évolution de l'information
dans l'environnement; l'ignorance de l'environnement; le
nombre d'agents et la complexité des interactions entre
agents. Ces paramètres permettent d'établir des critères
dans la définition des agents logiciels entrant dans le
processus coopératif de prise de décision. Ils doivent
donner à tout instant l'état de la négociation entre agents
en terme de consensus par exemple. Si les agents
logiciels sont mieux informés des intentions de
l'utilisateur, peut-être pourront-ils mieux aider
l'utilisateur dans sa prise de décision. Par conséquent,
tous les mécanismes mis en oeuvre dans la
reconnaissance d'intention seront utiles pour assurer une
meilleure interaction entre agents humains et logiciels.
Enfin, les agents logiciels doivent rester simples, faciles
à comprendre et à utiliser.
Décomposition de la complexité d'une tâche
en favorisant la coopération entre agents
La répartition du traitement de l'information entre
plusieurs agents a déjà été décrite par Paterson [26]. Un
modèle, appelé MESSAGE, a été proposé pour prendre
en compte la gestion du vol d'un avion de transport
commercial [2]. MESSAGE distingue trois niveaux
d'interaction entre agents : syntaxique, sémantique et
sémiologique. Ces niveaux sont des attributs de
messages échangés entre agents. En général, plusieurs
agents sont regroupés au sein d'une société d'agents
(Figure 2) [23].
Cette société d'agents délègue une tâche à l'un de ses
agents. Un agent représente sa société et est responsable
des tâches qui lui sont confiées. L'accomplissement de la
tâche est limité par des contraintes externes à l'agent
liées à la société d'agents et à l'environnement, et des
contraintes internes à l'agent liées aux compétences et à
la personnalité de l'agent lui-même. Cette approche
sociologique de l'interaction met en jeu des mécanismes
comme la négociation, la coopération, la supervision, la
subordination, l'organisation, etc. Considérons qu'un
agent humain ait à effectuer une tâche complexe, par
exemple conduire 300 personnes d'un aéroport à un autre
en utilisant un avion moderne. L'agent en question
s'appelle un pilote qui est délégué par sa compagnie
aérienne (sa société d'agents) pour effectuer la tâche déjà
décrite. Sa compagnie définit les contraintes externes
qu'il va devoir suivre pour représenter au mieux la
compagnie. Le pilote va s'appuyer sur ses propres
agents (cognitifs) et une autre société d'agents fournie
par le cockpit pour accomplir sa tâche. De la même
façon, un agent avion est composé d'un certain nombre
d'agents dont le pilote, le copilote et le cockpit (liste
non-exhaustive). Un agent tour de contrôle est composé
par exemple d'agents contrôleurs et d'agents systèmes
d'aide au contrôle (Figure 2).
Figure 2. Société d'agents.
La notion d'interface profonde
Une interface profonde est définie par la société
d'agents logiciels servant à gérer l'interaction entre
l'utilisateur/décideur et le système à contrôler. Nous
faisons la distinction entre une interface profonde qui a
la capacité de coopération et de médiation avec l'extérieur
(utilisateurs et environnement), et une interface
superficielle qui est un simple système de connexion
entre agents. Le problème est de savoir dans quel sens
cette gestion se fait (Figure 3) : interprétation ou
amplification [6].
Utilisateur/décideur
Interface
Système à contrôler
AMPLIFICATION
INTERPRETATION
Utilisateur/décideur
Interface
Système à contrôler
Figure 3. Interface utilisateur comme amplifieur
des capacités de l'utilisateur ou comme
interpréteur du comportement du système à
contrôler.
Si l'interface profonde est ajoutée comme une partie
intégrante de la machine, il remplace certaines fonctions
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
cognitives humaines. Nous dirons qu'il interprète pour
l'utilisateur. Si l'interface profonde est une ressource à la
disposition de l'utilisateur, il augmente les capacités de
l'utilisateur. Nous dirons qu'il amplifie les capacités
cognitives de l'utilisateur. Le choix entre ces deux
alternatives est un soucis constant en aéronautique. Elles
conduisent à des comportement différents aussi. Dans le
premier cas, l'interface profonde devra présenter la bonne
illusion à l'utilisateur afin qu'il puisse avoir la meilleure
représentation de la situation. La notion d'illusion [30]
est extrêmement importante dans la mesure où elle
définit les mécanismes à mettre en oeuvre pour
reconstituer un phénomène réel (ou connu de l'opérateur)
pour fournir à l'opérateur l'illusion de ce phénomène. En
aéronautique, l'horizon artificiel en est un exemple. En
général, il s'agit de construire des métaphores qui
donnent au pilote la sensation d'une réalité (simulée).
Dans le second cas, l'interface profonde est un outil dont
l'utilisateur se sert. Souvent, l'apprentissage d'un
nouveau dispositif est un handicap à son acceptation. En
revanche, lorsque l'Homme sait utiliser un outil, sa
performance est amplifiée. L'apprentissage de
l'utilisation de l'outil reste donc un problème à part
entière.
LE ROLE DES AGENTS DANS LA PRISE D E
DECISION
Les différents modèles de prise de décision
Afin de mieux identifier comment aider l'Homme dans
la prise de décision et d'orienter l'aide à la décision vers
l'interprétation ou l'amplification, nous allons analyser
un certain nombre de points de vue. La prise de décision
peut être vue soit comme un processus de traitement de
l'information, soit comme un processus de gestion de
l'information, soit comme une activité sociale, soit
comme une activité cognitive, soit comme un processus
de planification [6]. Nous déduisons de l'analyse de ces
points de vue une typologie d'agents logiciels utiles
pour la prise de décision.
Vue comme un processus de traitement de
l'information, la prise de décision est un choix parmi
plusieurs alternatives en fonction d'un certain critère. Il
est clair que la nature et la qualité de l'information
requise pour effectuer la décision sont cruciales. Les
pilotes se basent généralement sur des procédures
comme règles de décision pour contrôler le traitement de
l'information. Des agents logiciels permettant de
faciliter l'interprétation permettront à l'utilisateur de
mieux comprendre la nature des alternatives et donc de
mieux gérer ses choix.
Vue comme un processus de gestion de l'information,
la prise de décision est un processus qui tente de gérer
des compromis entre exigences de traitement et
ressources disponibles pour effectuer ce traitement
(capacité). En général, le pilote est en surcharge
d'information. Il doit décider de stratégies pour traiter les
informations essentielles en fonction de sa capacité. Le
pilote peut omettre d'effectuer un traitement, réduire la
précision des informations et des traitements, mettre en
attente certains traitements, filtrer certaines informations
(ne pas les considérer), décentraliser le traitement
(délégation) ou tout simplement abandonner la tâche.
Dans tous les cas, trois conditions doivent être
satisfaites : la bonne information doit être disponible
sous le bon format et au bon moment, le pilote doit
attendre cette information pour pouvoir bien la recevoir
et surtout l'interpréter, et le pilote doit savoir comment
traiter cette information. Les deux premières conditions
plaident en faveur d'agents logiciels d'aide à
l'interprétation. La dernière condition suggère des agents
amplifiant le traitement des décisions.
Vue comme une activité sociale, la prise de décision
est un processus d'allocation de rôles et de
responsabilités (délégation). Le pilote délègue à la
machine un certain nombre de tâches. La notion d'agent
logiciel prend tout son sens dans le cadre de l'analyse
sociologique de la prise de décision. En général,
l'utilisateur suppose que l'agent logiciel sait bien faire la
tâche qu'il lui confie. La question de confiance est
essentielle. Si l'utilisateur n'a pas confiance en la
machine, il ne pourra pas bien interagir. En revanche,
s'il a une confiance trop forte en la machine, son niveau
de vigilance peut diminuer et sa surveillance peut chuter
de façon considérable. Dans les deux cas, les
informations peuvent être acceptées ou refusées de façon
irrationnelle. On s'oriente ici vers des agents logiciels
d'aide à la vérification croisée de diverses sources
d'information (gestion de la redondance).
Vue comme une activité cognitive, la prise de
décision humaine est un processus à capacité cognitive
limitée. Donnons trois types de critères conduisant à
l'automatisation des systèmes Homme-machine :
automatiser tout ce que l'être humain ne peut pas faire
ou traiter; accroître artificiellement la capacité en
introduisant des systèmes opérationnels d'assistance à
l'opérateur; réduire les exigences jusqu'à ce qu'elles
puissent satisfaire la capacité cognitive. La troisième
option de cette liste correspond à une automatisation
centrée sur l'Homme. L'activité cognitive concerne la
performance et la charge de travail mentale. Ces
variables sont affectées par les rythmes circadiens, le
rôle social des pilotes, la situation ambiante, la pression
temporelle, etc. Les agents correspondant à cette classe
permettent de prolonger la mémoire de travail de
l'opérateur.
Vue comme une activité de planification, la prise de
décision est liée à l'anticipation. On ne peut pas
anticiper une action si l'on de décide pas a priori d'une
stratégie. Inversement, construire une stratégie c'est
planifier le futur en prenant des options (décisions) qu'il
conviendra éventuellement de modifier en fonction de
leur utilisation. Les agents logiciels facilitant
l'anticipation de l'utilisateur sont des aides à la
planification. La planification met en jeu des calculs
combinatoires complexes que l'être humain a du mal à
gérer ou tout simplement à faire. Par contre, il est
capable de juger si le résultat d'une planification est
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
acceptable ou non. Par conséquent, il convient de
développer des agents logiciels prenant en compte ces
calculs combinatoires et présentant à l'utilisateur des
résultats que celui-ci pourra accepter, rejeter et/ou
modifier.
Divers types d'agents d'aide à la prise de
décision et heuristiques d'utilisation
associées
Kjaer-Hansen [20] a décrit la prise de décision en
termes de fins-moyens (means-ends) comme un
problème de gestion de ressources. Ces ressources
peuvent être considérées comme des agents : des agents
d'aide à la recherche d'information; des agents d'aide à
l'exécution d'actions; des agents d'aide à la construction
de modèles de l'environnement; des agents d'aide à la
construction de critères de décision.
Wilensky [31] a donné cinq heuristiques pour la prise
de décision : ne pas gaspiller les ressources; satisfaire
autant de buts que possible; maximiser la valeur des
buts atteints; éviter les buts impossibles; ne pas violer
les états intermédiaires.
Le besoin de prise de conscience de la
situation
Prendre une décision nécessite trois types d'exigences :
(1) disposer des informations nécessaires; (2) attendre ces
informations; et (3) avoir des agents pour les interpréter
et les traiter. La plupart des approches actuelles d'aide à
la décision sont centrées sur le traitement de
l'information et non sur les deux autres aspects [32].
Dans beaucoup d'accidents où la prise de décision a joué
un rôle fondamental, ce n'était pas tant le traitement de
l'information qu'il fallait remettre en cause, mais la
conscience de la situation (les anglo-saxons parlent de
situational awareness). L'accident de la centrale nucléaire
de Three Mile Island aux Etats Unis en est un exemple
[22]. Le présent article se centre plutôt sur les deux
premières exigences de la prise de décision.
Dans le contrôle de systèmes complexes, prendre des
décisions c'est surtout bien comprendre l'environnement
à tout instant. Avoir conscience de la situation courante
(situation awareness), c'est mettre en oeuvre un modèle
de l'environnement. Ce modèle est élaboré et raffiné pasà-pas à mesure que de nouvelles informations sont
disponibles et traitées. Il est important de noter que
même si les informations nécessaires sont disponibles,
si le décideur ne les attend pas, elles risquent fort de ne
pas être perçues. Par conséquent, l'attente des
informations nécessaires à la prise de décision est une
exigence critique, surtout en situation de contrôle de
processus où le temps joue un rôle fondamental. Donc,
tous les dispositifs qui permettent de favoriser l'attente
des bonnes informations, au bon moment et sous le bon
format seront les bienvenus.
Différents types de communication entre
agents
Comme nous l'avons déjà dit, la conception d'un
système d'aide à la décision passe par la conception d'une
interface profonde, c'est-à-dire une société d'agents qui
vont coopérer avec l'utilisateur dans la prise de décision.
Le type d'interaction dépend, en partie, de la
connaissance que chaque agent a des autres. Un agent
qui interagit avec un autre agent, appelé son partenaire,
peut appartenir à deux classes : (classe 1) l'agent ne
connaît pas son partenaire; (classe 2) l'agent connaît son
partenaire.
La seconde classe peut être décomposée en deux sousclasses : (sous-classe 2a) l'agent connaît son partenaire
indirectement (en utilisant une base de données
commune par exemple), (sous-classe 2b) l'agent connaît
son partenaire explicitement (en utilisant des primitives
de communication clairement comprises par le
partenaire). Cette classification conduit à trois types de
relation entre deux agents communicants : (A)
compétition (classe 1); (B) coopération par partage de
données communes (sous-classe 2a); (C) coopération par
communication directe (sous-classe 2b).
Dans le cas de la compétition, l'agent est totalement
ignorant de l'existence de l'autre agent. Ceci peut
conduire à des conflits pour le partage de ressources. Il
est donc nécessaire de définir un ensemble de règles de
synchronisation pour éviter des problèmes d'affectation
de ressources entre agents. Typiquement, ces règles de
synchronisation doivent être gérées par un agent de
supervision appelé un superviseur (Figure 4). Le
superviseur peut être l'un des partenaires ou un agent
externe. Bien sur, si les ressources disponibles sont plus
nombreuses que les exigences de tous les agents, les
conflits sont en général automatiquement évités. Dans
le monde réel, on ne connaît pas toutes ces exigences.
Figure 4. Compétition : les agents ont besoin d'un
superviseur pour gérer leurs activités.
Dans le cas de la coopération par partage de données
communes, l'agent sait que son partenaire existe par la
conscience qu'il a des résultats de certaines actions de
son partenaire. Les deux agents utilisent une base de
données communes (Figure 5). Une telle base de
données communes peut être elle-même un agent si elle
informe de façon active les différents agents mis en jeu
dans l'environnement, ou demande à ces agents de
nouvelles informations (auto-mise à jour). Les agents
utilisent et mettent à jour l'état de la base de données. A
titre d'exemple, tout se passe comme si deux agents
notaient toutes leurs actions sur un tableau noir auquel
ils se réfèrent avant d'agir. Les agents doivent coopérer
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
pour gérer la base de données partagée. Ce paradigme est
appelé système orienté-données. Un tel système doit
contrôler la cohérence des données communes. Les
relations de coopération entre agents n'excluent pas des
relations de compétition. En particulier, les données
communes sont généralement supportées par des
ressources pour lesquelles les agents correspondants
peuvent être mis en compétition. Dans ce cas, des règles
de synchronisation doivent être établies pour gérer les
conflits d'affectation et la cohérence des données
correspondantes.
Base de données communes
identiques. Au contraire, lorsqu'un professeur donne un
cours à ses élèves, ils ne partage pas nécessairement le
même modèle interne. En particulier, le professeur doit
"décompiler" sa connaissance situationnelle pour la
rendre intelligible aux novices, nous diront qu'il utilise
une explication analytique pour se faire comprendre.
LA CONCEPTION DE SYSTEMES
MACHINES MULTI-AGENTS
HOMMES-
La dualité entre les procédures et l'interface
Notre approche se centre sur la dualité
procédures/interface. Plus une interface est bien conçue,
conviviale et transparente au pilote, moins il a besoin de
procédures (si le pilote sait ce qu'il a à faire, il n'a pas
besoin d'aide).
"Voici les aides cognitives les plus communes dans
le cockpit: —Des curseurs de vitesse : petits
tabulateurs métalliques ou plastiques que les pilotes
peuvent déplacer autour de l'indicateur de vitesse
pour les aider à se souvenir des consignes critiques.
—Des équipements fournis par l'équipage; des notes
écrites, des tasses à café et un rouleau de papier
collant. —Des check-lists" [23].
Agents
Figure 5. Coopération par partage de données
communes : les agents gèrent la communication
par l'intermédiaire d'une base de données qui est
une interface entre ces agents.
Dans le cas de la coopération par communication
directe, les agents interagissent directement avec les
autres (Figure 6).
Cependant, le problème de la boucle fermée en
aéronautique impose d'éduquer les équipages à avoir des
actes réflexes appropriés. Les check-lists et les do-lists
ont été créées pour cela. Une étude sur l'utilisation des
check-lists est en cours à EURISCO [19]. Il est
important que le pilote accomplisse bien certaines
actions et au bon moment (rôle des do-lists). Les dolists guident le pilote en utilisant une approche pas-àpas. Les procédures anormales et d'urgence sont
généralement des do-lists. Les check-lists servent à
vérifier si la configuration de l'avion est correcte. Elles
servent à contrôler si les actions critiques ont été
correctement réalisées. Les check-lists assurent une
stabilité mentale et opératoire au pilote, même si elles
sont parfois rébarbatives. Elles revêtent aussi un aspect
juridique clair.
Le modèle RSRA
Figure 6. Coopération par communication directe:
chaque agent interagit directement avec les
autres.
Ils doivent partager un but commun et un langage
commun, par exemple, des experts d'un même domaine
coopèrent en utilisant un langage spécialisé pour
résoudre un problème. La qualité d'une communication
entre deux individus repose sur la compréhension
réciproque du modèle interne de l'autre. Par exemple, une
discussion entre experts du même domaine se réduit à un
langage opératif [17], c'est-à-dire très situationnel. Dans
ce cas, les experts ont des connaissances quasi-identiques
sur le sujet: on dit que leurs modèles internes sont quasi-
Il est très difficile de construire des agents logiciels
génériques. C'est la raison pour laquelle les applications
qui ont connu le plus de succès ont été celles qui étaient
supportées par un modèle fort de la tâche défini dans un
contexte particulier. Dans les applications aéronautiques
où les problèmes sont complexes et de nature
dynamique, il est très difficile d'anticiper à la fois les
situations et les contextes auxquels les agents vont être
confrontés dans leur utilisation. Il en résulte que la
connaissance en contexte (patterns situationnels et
modèles de tâche correspondants) doit être acquise enligne et pas-à-pas (incrémentalement) lorsque les agents
effectuent les tâches dans le monde réel.
Le modèle reconnaissance de situation / raisonnement
analytique (RSRA) a été développé pour donner un
cadre conceptuel à l'acquisition de connaissance en
contexte (Figure 7) [5]. RSRA est un modèle évolutif
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
d'opérateur. Il a été développé en 1986 à l'issue d'un
projet d'aide aux astronautes pour le diagnostic de pannes
du système de ravitaillement orbital de la navette
spatiale américaine [3]. Par la suite, il a été utilisé dans
diverses applications dont l'assistance aux astronautes en
télémanipulation spatiale [10; 21], l'assistance à la
conduite automobile [25] et le développement d'un
système de documentation électronique intégrée (CID :
Computer Integrated Documentation) [4; 5; 8].
Patterns
Situationnels
Novice
Expert
Connaissance
Analytique
s1
A1
s2
A2
sn
An
S1
a1
S2
a2
connaissances en contexte. Cet apprentissage peut être
effectué soit manuellement soit automatiquement en
utilisant un algorithme informatique. C'est le cas dans
CID [4; 5; 8].
Les composantes d'un bloc sont : son nom; son
niveau hiérarchique; une liste de préconditions; une liste
d'actions; une liste de buts et une liste de blocs associés;
une liste de conditions anormales (CAs) et leurs listes de
blocs associés. En fonction de son niveau d'abstraction,
une procédure peut être représentée par un simple bloc,
une hiérarchie de blocs ou un réseau de blocs. Nathalie
Mathé a présenté une description exhaustive de la notion
de bloc dans sa thèse [21].
Préconditions de Déclanchement
Actions
Procédures
Contexte
Conditions
Anormales
But(s)
SN
aN
Figure 7. Modèle de reconnaissance de situation
et raisonnement analytique .
Le modèle RSRA fournit un cadre formel pour
intégrer des connaissances situationnelles (patterns
situationnels de positions de problèmes) et analytiques
(ressources pour la résolution de problèmes). Au début
les agents sont "inexpérimentés" et doivent se reposer
sur des connaissances analytiques relativement étendues
(comme par exemple des modèles de tâches et des
procédures qui peuvent être incomplets et incorrects).
Ces modèles peuvent être construits en utilisant des
méthodes "classiques" d'acquisition de connaissances du
type KADS [30] par exemple. Les mécanismes
d'apprentissage associés à RSRA reposent sur le
renforcement des actions utiles, la découverte de
conditions anormales et la génération d'actions de
récupération pour améliorer la performance. Certains
éléments de la connaissance analytique sont transférés
dans les patterns situationnels. Ce transfert résulte en un
raffinement des procédures utilisées dans des contextes
particuliers et par des personnes particulières. Les
patterns situationnels se multiplient et deviennent plus
complexes dans le temps, alors que les connaissances
analytiques ont tendance à se structurer [10].
La représentation par blocs
Les connaissances individuelles et collectives sont
représentées dans chaque agent par un réseau de blocs
[4; 21]. La représentation par blocs (Figure 8) a été
conçue pour représenter des manuels d'opérations, des
procédures, des check-lists, des guides d'utilisation [3] et
autres outils en-ligne utilisés pour contrôler des
systèmes dynamiques complexes [11]. De plus, elle doit
permettre aux agents d'acquérir pas-à-pas des
Figure 8. Bloc de connaissance.
Les conditions anormales et les b u t s sont des
conditions finales qui sont testées après l'exécution des
actions du bloc. Un but est une condition qui doit en
principe être satisfaite après l'exécution des actions du
bloc, c'est une conclusion finale normale de l'exécution
du bloc. Dans certaines situations dites anormales, le
but peut ne pas être satisfait après l'exécution des
actions. Les conditions anormales correspondent soit à
des situations anormales de l'environnement, soit à des
dysfonctionnement de l'agent (des erreurs humaines dans
le cas d'agents humains).
Vol
Avant Décollage
Décollage Montée Croisière Approche Atterrissage
Avant V1
Arrêter l'avion ?
Avant Rotation
Avant V2 + 10
Figure 9. Simple hiérarchie de contextes.
Les conditions contextuelles d'un bloc définissent son
domaine d'applicabilité. Par exemple, les conditions
contextuelles peuvent être un ensemble de conditions
caractérisant une panne, le but courant de l'utilisateur ou
un mélange de conditions intentionnelles ou liées à
l'environnement. Les conditions contextuelles sont
organisées en hiérarchies. Par exemple, en aviation, un
vol est généralement organisé en phases, qui peuvent
être décomposées en sous-phases et finalement chaque
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
sous-phase est décrite sous la forme de blocs de
connaissances représentant des procédures (Figure 9).
Dans le contexte d'un vol (racine de la hiérarchie
correspondante de contextes), il y a plusieurs souscontextes (avant-décollage, décollage, etc.). Dans chaque
contexte terminal (par exemple, décollage), un ensemble
de blocs doit être mis en œuvre. Si tout est "normal", le
pilote accélère l'avion jusqu'à une vitesse de décision
appelée V1 après laquelle il ne pourra plus arrêter l'avion
même en cas d'incident majeur. Le pilote exécute le
premier bloc "Avant V1". S'il n'y a pas de condition
anormale déclenchée, il exécute le bloc "Avant
Rotation" et "Avant V2 +10". Si une condition
anormale est satisfaite pendant l'exécution du bloc
"Avant V1", alors il peut décider d'exécuter le bloc
"Arrêter l'avion".
Cette méthode utilisée pour la re-conception de
l'interface profonde du système de gestion de vol des
Airbus a montré son efficacité. Ceci est principalement
dû au fait qu'elle est basée sur le concept d'agent. La
principale difficulté est de déterminer le bon niveau de
granularité pour les FCs. Des compromis doivent être
faits à ce niveau. Cependant, puisque les utilisateurs
(experts) peuvent avoir une perception quasi-réelle de
l'interface du système d'assistance, ils ont la possibilité
d'évaluer la pertinence et l'exactitude de l'AFC. En
particulier, ils peuvent avoir accès au niveau de
granularité de la représentation afin de raffiner en
contexte les fonctions cognitives pertinentes et
nécessaires pour les utilisateurs.
Bloc courant
Vue d’ensemble de la
base de fonctions cognitives
L'analyse en fonctions cognitives
Afin de mieux cerner ces aspects de coopération
Homme-machine, nous avons développé une méthode
d'analyse en fonctions cognitives basée sur la notion
d'agent [7; 9]. Nous considérons que chaque fonction
(agent) mise en jeu dans l'accomplissement d'une tâche
peut être représentée par un bloc de connaissances [4].
Ces fonctions sont parfois confiées à l'utilisateur,
parfois confiées à la machine. Le problème est de bien
comprendre comment la société d'agents résultante est
organisée en fonction des caractéristiques des Hommes et
des machines. Une fonction cognitive (FC) est définie
comme une fonction qui transforme une tâche (ce que
l'utilisateur doit faire) en une activité (ce que l'utilisateur
fait effectivement). Cette fonction est caractérisée par un
certain nombre de paramètres tels que la charge induite,
la performance, la quantité d'information traitée, sa
demande en vigilance, son contexte d'utilisation, etc. Le
transfert d'une fonction cognitive de l'Homme vers la
machine est communément appelé automatisation. Le
contrôle de ce transfert par la prise en compte de critères
ergonomiques conduit à une automatisation centrée sur
l'Homme [1].
Les fonctions cognitives sont difficiles à expliciter.
L'analyse en fonctions cognitives (AFC) consiste à
raffiner un réseau de FCs par une évaluation de leur
simulation pas-à-pas sur ordinateur. Ce processus
progressif de proposition et d'évaluation de FCs permet
de tester des alternatives. Chaque FC est représentée par
un bloc de connaissances (processeur et base de
connaissances de l'agent correspondant) et une métaphore
d'interface (canaux récepteurs et émetteurs) (Figure 1).
L'enchaînement des blocs est présenté dans une fenêtre,
et les métaphores d'interface dans une autre fenêtre
(Figure 10). La première fenêtre permet au concepteur de
contrôler l'enchaînement des FCs. La seconde permet à
un utilisateur potentiel de donner son avis sur
l'enchaînement cognitif des métaphores à l'écran. Un
travail coopératif peut dont s'installer entre le concepteur
et des utilisateurs potentiels pour concevoir l'interface
profonde. Des outils hypertextes permettent de gérer ce
type de système d'aide à la conception.
Métaphores courantes
Fenêtre du concepteur
Fenêtre d’évaluation
(orientée utilisateur)
Figure 10. Une vue d'une simulation cognitive
utilisant la méthode de l'analyse en fonctions
cognitives.
La méthode AFC consiste en les étapes suivantes :
• définir un premier sous-ensemble de contextes en
utilisant des méthodes d'explicitation classiques du
type interview, brainwriting (Boy, 1991), etc.;
• développer un réseau de blocs de connaissances qui
décrivent les processus de prise de décision des
utilisateurs potentiels dans les contextes définis dans
la première étape;
• faire tourner une simulation cognitive et évaluer sa
pertinence et son exactitude;
• raffiner les contextes courants et les blocs de
connaissances;
• faire tourner une simulation cognitive et évaluer sa
pertinence et son exactitude.
La distinction interaction-tâche
Une fonction cognitive (FC) peut être décomposée en
des fonctions cognitives de granularité plus faible
(décomposition de blocs en sous-blocs). En particulier,
une FC mise en jeu pour accomplir une tâche spécifique
peut être décomposée en deux principales composantes
(Figure 11) : une FC chargée de l'interaction : elle est
liée à la syntaxe utilisée pour accomplir la tâche; une
FC chargée du contenu de la tâche elle-même : elle est
liée à la sémantique utilisée pour accomplir la tâche.
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
Fonction cognitive
FC interaction
Tâche
Activité
FC contenu de la tâche
Figure 11. Composantes interaction et contenu
de la tâche d'une fonction cognitive.
Plus l'interface est facile à utiliser et à comprendre,
moins la composante de la fonction cognitive est
complexe. Par exemple, si la tâche est de programmer
un plan de vol en utilisant l'interface actuelle appelée
MCDU, le pilote doit appuyer sur des touches (c'est-àdire, une sous-FC d'interaction est chargée de localiser
les touches, une autre de vérifier son nom, une autre
d'apparier ce nom à l'intention de l'utilisateur, une autre
à la réponse du système sur l'écran de contrôle, etc.),
naviguer dans des menus plus ou moins profonds (bien
souvent la récursivité des menus multiples n'est pas
aisée à percevoir et à comprendre), etc. La composante
interaction de la fonction cognitive globale peut être
complexe. On préférera souvent laisser les FCs relatives
au contenu de la tâche aux utilisateurs alors que les FCs
d'interaction devront le plus possible être confiées à la
machine pour justement rendre l'interaction plus
naturelle (Figure 12).
Certains critères d'évaluation
Le développement de nouveaux outils peut faciliter
l'exécution de telles fonctions cognitives en transférant à
la machine certaines fonctions cognitives effectuées par
l'Homme. Le principal problème est de s'assurer de
l'équilibre de l'interaction entre les différents agents mis
en jeu dans le système Homme-machine résultant. Les
fonctions cognitives sont vues comme des agents
coopérant (en particulier dans la prise de décision). Ceci
veut dire que la plupart des fonctions cognitives relatives
à l'interaction peuvent être confiées à la machine pour
faciliter l'interaction (Figure 12), tandis que les
fonctions cognitives relatives au contenu de la tâche
peuvent être avantageusement conservées par l'Homme.
La formalisation des fonctions cognitives est un
moyen de mieux comprendre et de maîtriser
l'automatisation en fonction d'une liste d'objectifs tels
que la sécurité, la fiabilité, l'économie et le confort. Des
critères plus fins et plus orientés vers la prise en compte
de facteurs humains plus sophistiqués sont actuellement
à l'étude. Nous avons utilisé certains d'entre eux dans
l'étude de la re-conception de l'interface MCDU.
Billings a donné un certain nombre d'attributs pour
caractériser l'automatisation centrée sur l'Homme. Nous
proposons d'utiliser ces attributs comme des critères
d'évaluation d'agents.
• Redevable. L'agent doit informer l'utilisateur de ses
actions et être capable de les expliquer sur demande.
• Subordonné. Sauf dans des situations prédéfinies,
l'agent ne doit jamais prendre le contrôle. Dans ces
situations, on doit pouvoir le déconnecter facilement.
• Prédictible. Le comportement de l'agent doit pouvoir
être anticipé à partir de l'observation et de l'expérience.
• Adaptable. L'agent doit pouvoir être reconfiguré selon
les préférences et les besoins d'une gamme étendue
d'utilisateurs.
• Compréhensible. L'agent doit être intelligible.
• Flexible. L'agent doit pouvoir s'adapter à des
exigences nouvelles, différentes ou changeantes.
• Dépendant. L'agent doit faire ce qu'on lui dit de faire.
Il ne doit jamais faire ce qu'on ne lui a pas dit de faire.
Il ne doit jamais aggraver la situation.
• Informatif. L'agent doit garder l'utilisateur informé
(situational awareness).
• Résistant aux erreurs. L'agent doit empêcher
l'utilisateur de faire des erreurs autant que possible.
• Tolérant aux erreurs. Certaines erreurs se produisent,
même avec des systèmes très fortement résistants aux
erreurs. L'agent doit détecter et minimiser l'effet de ces
erreurs.
Nous avons ajouté à cette liste le critère de simplicité.
Fonction cognitive
humaine
Machine
FC-I
FC-CT
Figure 12. Transfert d'un partie de la composante
interaction d'une fonction cognitive (FC-I) à la
machine.
CONCLUSION ET PERSPECTIVES
L'objectif de cet article était de montrer l'utilité de la
technologie des agents logiciels dans la coopération
Homme-machine pour la prise de décision. Nous avons
montré que l'assistance dans l'acquisition et
l'anticipation (attente) des informations nécessaires à la
prise de décision étaient au moins aussi importantes
sinon plus importantes que l'assistance au traitement des
ces informations.
La méthode d'analyse en fonctions cognitives s'est
révélée très utile et convainquante pour la conception
d'outils d'aide à la décision coopératifs. Basée sur la
représentation par blocs, elle revêt un caractère formel
qui lui confère des propriétés intéressantes comme la
réutilisabilité de certaines séquences de fonctions
cognitives, l'explication a posteriori de décisions de
conception (traçabilité), et la simulation cognitive avec
possibilité d'évaluation aisée par des utilisateurs
potentiels. Nous continuons à développer cette méthode
en l'appliquant à la conception ergonomique des
systèmes dynamiques complexes.
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
Carroll et ses collègues ont étudié plusieurs facteurs
influençant l'efficacité des systèmes d'aide à la décision
[12]. Ils ont observé que les opérateurs ont plus de
difficultés à résoudre un problème mettant en jeu des
relations temporelles (planification d'une mission par
exemple) qu'un problème mettant en jeu des relations
spatiales (aménagement d'un bureau par exemple). Ceci
est principalement dû au fait que les relations spatiales
sont facilement représentables graphiquement, alors que
les relations temporelles sont plus difficilement
représentables. Le développement d'aides graphiques
pour la représentation de relations temporelles pour la
prise de décision est donc un axe de recherches à
préconiser.
REMERCIEMENTS
Je tiens à remercier Nathalie Mathé avec qui nous
avons discuté un grand nombre d'idées présentées dans
cet article. D'autres personnes ont contribué de prés ou
de loin au développement du concept d'agent logiciel
pour le contrôle de systèmes complexes et la prise de
décision. Citons Jeffrey Bradshaw, Laurent Coquin,
Gabrielle De Brito, Mario Delail, Erik Hollnagel,
Laurent Karsenty, Morten Lind, Patrick Pleczon, Alain
Rappaport, Valérie Bigot. Qu'ils en soient remerciés.
REFERENCES
1.
2.
3.
4.
Billings, C.E. (1991). Human-Centered Aircraft
Automation: A Concept and Guidelines. NASA
Technical Memorandum 103885, August.
Boy, G.A. (1983). Le système MESSAGE: Un
Premier Pas vers l'Analyse Assistée par Ordinateur
des Interactions Homme-Machine, Le Travail
Humain, 46 (2), pp. 271-286.
Boy, G.A. (1987). Operator assistant systems. In
E. Hollnagel, G. Mancini and D.D. Woods (Eds.)
Cognitive engineering in complex dynamic worls,
Computer and People Series, London: Academic
Press, 85-98. Also in International Journal of ManMachine Studies, 27, pp. 541-554.
Boy, G.A. (1989). The Block Representation in
Knowledge Acquisition for Computer Integrated
Documentation. Proceedings of the 4th AAAISponsored Knowledge Acquisition for KnowledgeBased Systems Workshop, Banff, Canada, 1-6
October.
5.
Boy, G.A. (1991). Intelligent Assistant Systems.
Academic Press, London.
6.
Boy, G.A. & Hollnagel, E. (1993). Cockpit
evolution and human-machine interaction.
EURISCO Report no. T-93-002-GB-VI.
7.
Boy, G.A. & L'Ebraly, H. (1994). Modèle de Tâche
et Représentation de l'Expertise pour la Conception
de Dispositifs d'Interaction Homme-Machine Exemple d'Application en Aéronautique. EURISCO
Report No. T-94-009-VI.
8.
Boy, G.A. (1991). Indexing Hypertext Documents
in Context.Proceedings of the Hypertext'91
Conference, San Antonio, Texas, December.
9.
Boy, G.A. (1995). Supportability-based design
rationale.
Proceedings
of
the
6th
IFAC/IFIP/IFORS/IEA Symposium on Analysis,
Design and Evaluation of Man-Machine Systems.
Boston, MA, USA. June.
10. Boy, G.A. and Delail, M. (1988). Knowledge
acquisition by specialization/structuring: a space
telemanipulation application. Proceedings of the
AAAI Workshop on Knowledge Acquisition, Saint
Paul, Minnesota, USA.
11. Boy, G.A., & Mathé, N. (1989). Operator
Assistant Systems: An Experimental Approach
Using A Telerobotics Application. IJCAI
Workshop on Integrated Human–Machine
Intelligence in Aerospace S y s t e m s , Detroit,
Michigan, USA, August 21.
12. Carroll, J.M., Thomas, J.C., and Malhotra, A.
(1980). Presentation and representation in design
problem solving. British Journal of Psychology,
71, pp. 143-153.
13. Cyert, R.M. et March, J.G. (1963). A behavioral
theory of the firm. Prentice Hall.
14. Dennett, D.C. (1971). Intentional systems. Journal
of Philosophy, 8, pp. 87-105.
15. Dennett, D.C. (1987). The intentional stance.
Bradford Book, The MIT Press.
16. Edwards, W. et Tversky, A. (1967). Decision
Making. Penguin Modern Psychology.
17. Falzon, P. (1986). La communication Hommemachine : Les stratégies de dialogue et le langage
d'interaction. Colloque sur l'Interaction HommeMachine et l'Intelligence Artificielle dans les
Domaines de l'Aéronautique et de l'Espace, ENSAE,
Toulouse, 13-14 octobre.
18. Hammond, K.R. et McClelland, G.H. (1980).
Human judgement and decision making -Theories,
methods, and procedures. Hemisphere Publishing
Corporation.
Comptes Rendus de la Conférence Nationale Interaction Homme-Machine, Toulouse, 1995
19. Karsenty, L. & de Brito, G. (1995). L'Utilisation
des procédures écrites dans un système complexe :
le cockpit d'un avion de ligne. Rapport Technique
EURISCO No. T-95-016-V2.
20. Kjaer-Hansen, J. (1991). Decision structure of
multi-agent systems. PhD Thesis. Institute of
Automatic Control Systems, Servolaboratoriet,
Technical University of Denmark.
21. Mathé, M. (1990). Intelligent Assistance to Process
Control: A Space Telemanipulation Application (In
French). PhD Thesis Dissertation. ENSAE,
Toulouse, France.
22. Moll, T.H. & Sills, D.L. (1981). The Three Mile
Island Nuclear Accident: Lessons and Implications.
New York, NY: Academic Press.
23. Minsky, M. (1985). The Society of Mind.
Touchstone Simon and Schuster.
24. Norman, D.A. (1992). Turn Signals are the Facial
Expressions of Automobiles. Addison Wesley,
Reading, Massachusetts.
25. Pleczon, P. (1992). Methodological elements and
tools for intelligent assistance: Application to car
driving (in French). PhD Thesis Dissertation.
ENSAE, Toulouse, France.
26. Patterson, T.T. (1969). Management theory.
London: Business Publications Ltd.
27. Rasmussen, J. (1983). Skills, rules, knowledge:
Signals, signs and symbols and other distinctions
in human performance models. IEEE Transactions
on Systems, Man and Cybernetics, SMC-13, pp.
257-267.
28. Simon, H.A. (1977). The new science of
management decision. Engelwood Cliffs, N.J.,
Prentice Hall.
29. Tognazzini, B. (1993). Principles, techniques, and
ethics of stage magic and their application to
human interface design. Human Factors in
Computing Systems INTERCHI'93 Conference
Proceedings, pp. 355-362.
30. Wielinga, B., Van de Velde, W., Schreiber, G. &
Akkermans, H. (1992). The CommonKADS
Framework for Knowledge Modelling. Proceedings
of the Seventh Knowledge Acquisition for
Knowledge-Based Systems AAAI Workshop,
Banff, Canada, October.
31. Wilensky, R. (1983). Planning and understanding.
A computational approach to human reasoning.
Addison-Wesley Pub. Company.
32. Zachary (1988). Decision support system:
Designing to extend the cognitive limits. Handbook
of Human-Computer Interaction. Martin Helander
(Ed.), Elsevier Science Pub., North Holland, pp.
997-1030.