Christophe Kolski

Patrick Millot

Problems in telemaintenance and decision aid criteria for telemaintenance system design

Keywords: Telemaintenance, human factors, decision aid criteria, telemaintenance tools design

Decision making for the integration of telemaintenance tools into the maintenance of a man-machine system is presented. The Decision aid criteria for telemaintenance can be classified into four main classes: (i) possible, (ii) appropriate, (iii) justified, (iv) acceptable. After introducing the telemaintenance notion, this paper will outline such decision aid criteria.

RELEVANCE TO INDUSTRY

Telemaintenance notion has not been well applied in industry. Maintaining at a distance industrial installations has particular human and ergonomical problems. This paper provides help to potential designers of telemaintenance tools.

INTRODUCTION

The growing level of automation in industrial processes -continuous or not -includes particular telemaintenance problems. It is of paramount importance to insure the best possible productivity of equipment.

According to the AFNOR X60-010 norm, maintenance is defined as "the set of actions allowing to maintain or restore an installation in a specified state or in a state permitting to insure a determined service". Equipment maintainance consists of operations (repairs, lubrification, improvements, visits...) needed to insure the production continuity and quality. Two main forms of operational maintenance exist: corrective and preventive maintenance (figure 1). Many books, proceedings or specialized journals devoted to maintenance can be found in the literature (see for instance the journals: "Maintenance" or "International Journal of Quality and Reliability Management"). Many tools and methods have been developed to optimize maintenance, to insure a better availability of technical means and to decrease costs. Among these methods, the telemaintenance approach appeared in the 80s. It consists of maintaining installations at a distance.

MAINTENANCE

The purpose of this paper is to help in the decision making process to integrate a telemaintenance tool (also called telemaintenance system in the paper) into the maintenance of a man-machine system. The decision criteria can be classified into four main classes: (i) possible, (ii) appropriate, (iii) justified, (iv) acceptable. Considering all four classes together allows the recommendation for the integration of telemaintenance tools [START_REF] Kolski | Télémaintenance de systèmes automatisés, guide ergonomique de conception[END_REF]. After introducing the the notion of telemaintenance, this paper will outline such decision criteria.

TELEMAINTENANCE

Telemaintenance consists in carrying out some maintenance operations at a distance. This particularly interesting technique to optimize "the after-sales service" of an automated installation appeared at the end of the seventies. [START_REF] Gabriel | Maintenance assistée par ordinateur[END_REF] presented one of the first applications in this field: Digital Equipment put a telediagnosis center into service first in the States in 1977, then in France in 1980. Realizing the need for such a maintenance approach for both the installer and the user, the firm integrated a specific micro-computer into every system. This microcomputer served as an intermediary between the end system and the diagnostic center. A specialized console and modem were installed free of charge at the customer's end. Any communication costs were charged to Digital and the maintenance contract amount was reduced by 10 %. This telediagnosis system was first used for corrective maintenance. A 90 % success rate was achieved without the intervention of a nonsite technician. Furthermore, when ever this person did go to the site, most of the time he had the right components. Later preventive maintenance was included. This consisted, on the one hand, of storing technical faults in the telediagnosis center and, on the other hand, in regularly controlling this information regularly with a goal of prevention.

Currently, more and more telemaintenance systems are being developed and progressively installed on industrial sites. They are particularly interesting in the fields constituting some risks for the human beings, those fields where human intervention and/or the production stops are very expensive (off shore, mail order industry, "small" processes without a specific control room like...). Many operational systems are also found in "intelligent" buildings (repairing of lifts, adjustment of steam generator...) and in large computing systems (networks of computers, data processing systems...).

HUMAN FACTORS CONCERNS

Before the use of computing tools, the maintenance man-machine system consisted of two elements: the machine and the maintenance expert (figure 2). The corrective and/or preventive maintenance for such a man-machine system was done on the same work site. Telemaintenance can lead to particularly interesting human factors problems. Indeed, the telemaintenance expert uses a computing system from a site different from production (figure 4). So, the computing system always consists of a dialogue software and a console. It also integrates communication.

Figure 4: The basic telemaintenance principle Of course, an operator or a maintenance technician can be present on the production site. But the maintenance technician has less knowledge than the expert. In this case, a connection must be maintained between them. In most cases this connection is a telephone (figure 5). This is not a general case, but is the most typical for telemaintenance systems. According to the competence and/or to the function of the operator at the production site, he may also have access to certain functions of the telemaintenance computing system, and may collaborate with the expert by telephone and a console (figure 6). This last case is very rare, but is the subject of current research.

The operator who is on the production site is likely to perform some maintenance actions on the machine following expert instructions. Nevertheless, for certain repairs, the expert will probably need to go to the production site, or to send a specialist. "Intelligent", graphic and/or algorithmic computerized fonctions generally include the following [START_REF] Kolski | Télémaintenance de systèmes automatisés, guide ergonomique de conception[END_REF]: (1) alarms, (2) preventive failure detection, (3) shallow and/or deep diagnosis, (4) automatic action advices, (5) access to information about appropriate actions or task to perform, (6) graphic guidance and advice to the operator present on the production site, (7) preparing for visit on the production site, (8) calculations and statistics, (9) recording information related to failures, repairs, and so on, in database, (10) visits and/or actions planning, (11) continuous supervision of specific variables, (12) access to the life cycle of components, (13) analysis of numeric or symbolic data, and so on.

CRITERIA FOR INTEGRATION OF TELEMAINTENANCE FACTORS

There are four criteria for the integration of telemaintenance factor: (i) possible, (ii) appropriate, (iii) justified, (iv) acceptable. Considering all four classes together provide the final recommendation for integration of telemaintenance tool [START_REF] Kolski | Télémaintenance de systèmes automatisés, guide ergonomique de conception[END_REF][START_REF] Kolski | Decision aid criteria to integrate a telemaintenance tool into the maintenance man-machine system[END_REF]. Of course, this list of criteria is not exhaustive, since each company has its own proper constraints and objectives. Nevertheless, these criteria will provide potential designers with a decision base.

Each of these criteria is briefly examined below and explained in a synthesis diagram (see the figure 7).

For possible integration of telemaintenance factors

In this class, we include all the criteria which are essential for setting up of a telemaintenance system. It considers four sub-classes which correspond to the four entities (figure 7): (i) the telemaintenance operator (also called telemaintenance expert), (ii) the required operator expertise, (iii) the operator on the site, (iv) the information the telemaintenance operator needs to manipulate at a distance.

About the telemaintenance operator: First at all, he must be able to intervene at the right time at distant maintenance operations. Then he must be able to answer his informational needs, either by the way of the computer (by tele-measures) or by asking the onsite operator complementary information. Finally, if the telemaintenance operator concludes that it is necessary to intervene physically on the site, he may be able to guide the operator in the necessary actions.

About the telemaintenance expertise: The expert's reasoning process must be possible at a distance. For this reason, his reasoning must be essentially cognitive and can not require too many manipulations. To design a telemaintenance system, the knowledge used must be previously validated, and perfectly mastered. This knowledge may not be retained -consciously or not-by the telemaintenance expert and has to be accessible by the designer. About the onsite operator: This operator may be contacted in case of need by the telemaintenance operator. The fact that he is free must be sufficient. In other words, an operator present on the site must be able to answer the informational needs of the telemaintenance operator. For efficient co-operation, the operator must be able to formulate his observations. His competence and/or training levels must be sufficient. So, in each case, the operator must be able to understand the telemaintenance operator and to answer his informational and action needs.

About the telemaintenance information: All the measures useful to the telemaintenance operator must be instrumented, and therefore accessible at a distance: indeed the telemaintenance operator must quickly access the information without worrying about its reliability. Thus the information must be essentially of two following types: objective "signs" (taking the form of measures) and "symbols" (interpreting the information: too high, too low...) (for this notion, see [START_REF] Rasmussen | Information processing and Human-Machine Interaction, an approach to cognitive engineering[END_REF]. The information must not be of the subjective "signs" type such as smoke, smell, and so on: but, in this case, they have to correspond to well-known and explainable at a distance (for instance by using a telephone) by the operator present on the site.

For appropriate integration of telemaintenance factors

The criteria which are put together in this class must estimate if a telemaintenance system is better than a classic maintenance approach. These criteria are divided in two sub-classes corresponding to the two maintenance steps: (i) tele-supervision and tele-diagnosis, and (ii) actions of maintenance deduced from reasoning at a distance. About tele-supervision and tele-diagnosis: These two operations (the most classical in the field of telemaintenance) have to be faster than if they were performed by a maintenance expert which must move on site. The telemaintenance time has then to be inferior than the displacement time plus the maintenance time on the site. The reliability level of the system has to be as close as possible to the level which is reached when the maintenance operations are performed on the site.

About the resulting actions: The actions resulting from the telemaintenance, and which cannot be directly performed by the telemaintenance operator using his computing system, have to be workable in most of the cases by an operator present on the site. Indeed, if it is not possible, the telemaintenance operator (or a maintenance expert) must systematically move on site to make the maintenance actions. In this case, the profit-earning capacity of the maintenance approach decreases. Another telemaintenance criterion is to be able to optimize the displacement of the maintenance expert on the site: the expert has to move only if it is necessary and in this case he has to know the type of operation he will have to perform. For instance: a maintenance expert went on site only to press an "on/off" button to start a machine. The inexperienced onsite operator did not understand the situation at all !

Justified integration of telemaintenance factors

In this class, economical and strategic criteria are considered.

About the availability of the telemaintenance operator: If the operator in charge of the maintenance of a machine is not available, then telemaintenance is a possible solution. For instance, maintenance companies can insure the maintenance of machines for which a travel to the site may last two or three days because of geographical reasons whereas an intervention at a distance would have lasted just a few minutes. About temporal constraints of maintenance interventions: For some industrial sites, one day of machine unavailability can be disastrous. A telemaintenance system can then optimize the intervention time relating to the maintenance. About the profit-earning capacity: A telemaintenance system corresponds above all to a service, or even to a product. If this system is sold in sufficient quantities, the profit-earning capacity is ensured.

About the training: If it is envisaged to attribute to the telemaintenance system a double function, the second one may concern the training. For example, operators can learn diagnosis at a distance on the telemaintenance center. Furthermore, training of onsite operators is possible, for instance when they must exploit a new machine.

About the impossibility to send a maintenance expert on the site: It can be impossible to send an expert on the site, for instance when the system is closed or difficult of access (off-shore, nuclear or chemical processes, space...). In such conditions it is necessary to choose a telemaintenance approach.

About the volatility of the expertise: With a more strategic point of view, maintenance expertise could disappear. This situation may influence the design of a telemaintenance system.

Acceptability of integration of telemaintenance factors

The level of acceptability for choosing a telemaintenance approach is centered on the human factors linked to this new technique.

About the evolution of the work: It must be possible to insure the interest of the tasks of the onsite operators. This is true if we try to exploit as often as possible the dialogue between the two operators. Of course, this dialogue has to be possible and must not come down to actions asked by the telemaintenance operator to the onsite operator. Furthermore, the onsite operator has to find an interest due to the pedagogical aspects of the operations in which he is involved. About the motivation of the operators present on the site: The telemaintenance system must not be integrated from the opposite direction in the company's culture and of course it must not involve problems relating to the confidential aspect of certain information which are accessible on the site by the telemaintenance operator. Moreover, the operators present on the site may perceive the necessity of such a maintenance approach. More and more, the integration of such a system implies a participation of the end users to the design process [START_REF] Gould | How to design usable system[END_REF]. If the operators present on the site wish to take part in this process, it is a sign of the "human" success of the integration. Nevertheless, a telemaintenance approach involves changes in the work methods, the different operators must be conscious of this situation. Specific sessions organized to prepare the telemaintenance integration will here find their usefulness.

Figure 1 :

 1 Figure 1: The main forms of maintenance

Figure 2 :

 2 Figure 2: The maintenance expert in direct interaction with the machine

Figure 3 :

 3 Figure 3: The Computer Aided Maintenance principle

Figure 5 :

 5 Figure 5: Collaboration by telephone between the telemaintenance expert and an operator

Figure 6 :

 6 Figure 6: Collaboration by telephone and computing system between the telemaintenance expert and an operator

Figure 7 :

 7 Figure 7: Criteria for helping the integration of telemaintenance factor

CONCLUSION

This paper has first dealt with telemaintenance and its human factors problems. It is evident that the telemaintenance system is integrated into man-machine system in which the characteristics and the tasks of the telemaintenance expert will have a direct influence on the successful result of the project concerning the telemaintenance system design.

The designer of such telemaintenance systems will need to consider such notions. Our paper has provided criteria for deciding the integration of telemaintenance factors.

The classification proposed in this paper is part of a project supported by the French Ministry of Research and Technology. This work has led to a report entitled (in english) "Ergonomical guidelines for telemaintenance system design: application to automated machines" [START_REF] Kolski | Télémaintenance de systèmes automatisés, guide ergonomique de conception[END_REF].

ACKNOWLEDGEMENT

The authors would like to thank Dr. Andris Freivalds for his improvement of the manuscript.


C Kolski

E Le Strugeon

M Tendjaoui

Implementation of AI Techniques for "Intelligent" Interface Development

Keywords: Process control, man-machine systems, expert systems, knowledge engineering, inference processes, "intelligent" interface

This paper presents the implementation of AI techniques for the development of an original approach to "intelligent" interfacing. This intelligent interface is called: the Decisional Module of Imagery (D.M.L). The "heart" of the D.M.I. is an expert system that manipulates three main objects (the WHAT, WHEN and HOW objects) described in the paper. Knowledge specification and representation for the expert system are then explained. Finally, a first technical validation is presented and discussed.

I. INTRODUCTION

Due to growing computerization and automation of industrial processes, the human operator is less and less involved in manual control tasks. On the other hand, he has to perform complex problem-solving tasks in control rooms. These tasks often require a high level of knowledge. This complexity may lead to human errors, which can become catastrophic for the installations, for human beings and for the environment (see for instance Three Mile Island or Tchernobyl). l- [START_REF] Millot | Coopération homme-machine: exemple de la téléopération[END_REF] In control rooms, the human operator performs his tasks by the use of graphical means, providing him with a restricted image of the installation reality. The man-machine interface consequently plays a vital role in the system's reliability and efficiency. Furthermore, the present tendency consists of assisting the human operator by decision aid tools. These tools use generally artificial intelligence techniques) [START_REF] Boy | Assistance à I'Opérateur : une Approche de l'lntelligence Artificielle[END_REF][START_REF] Taborin | Coopération entre opérateur et système d'aide à la décision pour la conduite de procédés continus: application à l'interface opérateur système expert du projet ALLIANCE[END_REF][START_REF] Tendjaoui | Contribution à la conception d'interface "intelligente" pour le contrô1e de procédés industriels: application au Module Décisionnel d'Imagerie[END_REF] The dialogue between the assistance systems and the human operator has to be taken seriously into account during the man-machine system design. A solution consists in the development of "advanced" man-machine interfaces. Several advanced interface principles exist that are able to help the human operator during his dialogue with assistance systems and/or the process. The "advanced interface" notion can be found in the literature under a number of propositions to characterize (i) the interfaces using the "intelligence" notion, or (ii) "intelligent" decision aid tools integrating a user interface management system. [START_REF] Tendjaoui | Contribution à la conception d'interface "intelligente" pour le contrô1e de procédés industriels: application au Module Décisionnel d'Imagerie[END_REF][START_REF]A cognitively based functional taxonomy of decision support techniques[END_REF][START_REF] Hancock | Intelligent Interfaces: Theory, Research and Design[END_REF][START_REF] Hefley | Architecture for adaptable human-machine interface[END_REF] Note that an advanced interface deals exclusively with the problem of dialogue between all the potential partners (humans and machines) of the man-machine system.

With the aim of improving the cooperation between the human operators and the decision aid tools in the control rooms of industrial processes, the research described here concerns the study of an intelligent interface and is aimed at realizing such an interface supervised by an intelligent manager called the D.M.I. (Decisional Module of Imagery). 11- [START_REF] Kolski | An "intelligent" interface approach[END_REF] The approach consists of using an expert system to ensure this cooperation. It has currently been validated in the laboratory and is integrated into an experimental platform. [START_REF] Tendjaoui | Contribution à la conception d'interface "intelligente" pour le contrô1e de procédés industriels: application au Module Décisionnel d'Imagerie[END_REF][START_REF]A cognitively based functional taxonomy of decision support techniques[END_REF][START_REF] Hancock | Intelligent Interfaces: Theory, Research and Design[END_REF][START_REF] Hefley | Architecture for adaptable human-machine interface[END_REF][START_REF] Tendjaoui | Interaction between realtime aid expert system, intelligent interface and human operator[END_REF][START_REF] Kolski | An "intelligent" interface approach[END_REF][START_REF] Tendjaoui | An "intelligent" approach for ergonomic design of man-machine interfaces in process control[END_REF] This paper presents the implementation of AI techniques for the development of this original approach to "intelligent" interfacing. It first describes the D.M.I. and the objects manipulated. Then it explains how the "heart" of the D.M.I. is implemented using artificial intelligence techniques. Finally, a first technical validation is presented and discussed.

THE DECISIONAL MODULE OF IMAGERY

The approach is tailored for the area of supervisory process control. Its goal is to design an intelligent imagery manager called "Decisional Module of Imagery" (D.M.I.). This approach can be integrated into the global model of the Man-Machine system in automated process control rooms to obtain an overall assistance tool (Fig. 1). The supervisory calculator centralizes all of the process scored data. These data are accessible by both the decision support expert system and the D.M.I. Using these data, the decision support expert system infers information such as predictive, diagnosis or recovery procedures. This set of information is transmitted to the D.M.I., which selects those that can be presented to the operator. This selection is based on a task model to be performed by the operator, and on an operator's "model" containing information about the operator. Fig. 1. Global man-machine system integrating module of imagery. [START_REF] Tendjaoui | Contribution à la conception d'interface "intelligente" pour le contrô1e de procédés industriels: application au Module Décisionnel d'Imagerie[END_REF] The task model is currently restricted to problem solving tasks and results from a previous analysis of fixed tasks that have to be performed by the operator. This model is based on the qualitative general model of Rasmussen, 14 whereby a task is built through four information-processing steps: event detection, situation assessment, decision making and action. This task model contains a set of process significant variables used by the operator while performing his different tasks.

The operator model integrates a set of ergonomic data which is currently limited to: (i) three possible levels of expertise for the human operator (unskilled, experienced, expert), (ii) the type of displays associated with each type of operators' cognitive behavior, corresponding to Rasmussen's model, (iii) the representation mode associated with each type of display.

The aims of the D.M.I. are: (i) to select the data that can be displayed on the screen, taking into account both the operational context of the process and the informational needs of the operator, in order to enable the operator to supervise the process and to define possible corrective actions when a failure appears; (ii) to define the ergonomic parameters associated with the presentation of this information for the human operator to understand more easily; (iii) to add to this supervisory imagery the corrective advice given by the decision support expert system to justify its reasoning and thus to prevent possible conflicts between the system and the human operator.

THE OBJECTS MANIPULATED BY THE INTELLIGENT INTERFACE

The aim of the D.M.I. is to behave in a self-governing way, and to be able to adapt itself to the operators' needs. Thus, it must include knowledge about: (i) the various operating contexts of the supervised system, (ii) the operators who are going to use the interface to supervise the system, (iii) the cognitive and sensorimotor tasks of the operators. This knowledge will allow the giving of answers to the three ergonomic problems that follow (Fig. 2):

(i) WHAT must be displayed to the operator? This question means: what is the relevant and useful knowledge to display, taking into account the human perception limits and the bounded size of the screen? The authors believe that the "What" question includes the "Why" question by explanation levels in the displayed information.

(ii) WHEN will the selected information be displayed? The right time for a particular display will vary, especially in taking into account the process operating context. The "What", "When" and "How" problems are successively described below.

What

The point of "what to display to the operator" represents the information set that the human operator is due to have at his disposal, on his screen, in order to carry out his supervisory and control tasks. So, the answer to the question of "what" must consider a set of functioning parameters of the human-machine system (see Fig. 2). It depends essentially on three criteria:

-The operator's requests They are connected to the information set that the operator may need at a given stage of the task execution. The operator explicitly asks for these information displays. However, their appearance may differ according to the current context. If the operator asks for one particular type of information, like the current state of a variable or some justifications about the action advice, then the D.M.I. must respond to the request.

-The operator's class

This parameter expresses the differences existing between the system users. These differences can be felt at the level of the functions of the human operators (maintenance technician, supervisor, watch keeper, control room operator), at the level of their respective experience in that function, or at the level of any other professional consideration. If the decision support tools perceive an error in the system and propose advice or an action, the operator can (i) be in agreement with this advice and act accordingly, or (ii) disagree and request some justification for the advice. The level of detail in this justification will depend on the operator's skill level, e.g. a novice operator will tend to require more detailed justification than an experienced operator. The D.M.I. must take this into consideration.

-The operator's task

The operator's tasks and therefore his informational needs will change according to the state of the process. Indeed, with the aim of responding to the operator's requests during the execution of one of his tasks, the D.M.I. must know what is the current execution stage of the operator's task. The D.M.I. uses this data to select and prepare the most useful information. With this goal, the D.M.I. is based on the knowledge of the process functioning situation. In Fig. 3, the various intervention types of the D.M.I. are displayed, as well as the types of messages and displays that can be required by the operator, according to the possible functioning states of the process. For example, in a transition situation, the operator may need some advice on the way to start the process, whereas, to assess the effects of a corrective action, the operator needs information about the progression of the correction. During an abnormal process state, alarms are automatically selected and displayed, but where an "uncommon" abnormal situation develops, the D.M.I. can focus on the variables that can affect the production and/or the security of the system, by suppressing all of the information and alarms that do not affect either production or safety.

When

The question of "when information will be displayed to the operator" concerns the choice of the time when the information is most useful. This question is of great interest because it can contribute to the management of the operator's workload, in modulating the data flows coming from the decision aid modules, in accordance with the situation severity of the man-machine system (Fig. 4). According to which information to display and to the operator's requests, the D.M.I. must evaluate the situation severity to determine if the information is going to be displayed instantaneously or later.

The reaction to the problem concerning "when" relevant information has to be presented to the operator depends on the nature of the information that he has requested and on the seriousness of any impending situation. Production targets and security constraints bound the severity evaluation. To know when the D.M.I. has to display information, it is first necessary to know what this information represents (the "What"). For example, alarms are displayed to the operator as soon as they occur, whereas information on action or advice, proposed by the decision support tools, are only displayed to the operator when requested or when a process situation becomes hazardous. The "When" problem depends on the information to display (the "What"), on the operator's requests and on the process situation severity (Fig. 2). The evaluation of the situation severity is linked particularly to the risk of breaks in the security and the production constraints.

Such behavior also allows the operator, in some cases, to maintain his knowledge and, eventually, to enrich it. As an example, following the raising of a default, if the corrective plans proposed by the decision aid module are not already displayed, the operator has to elaborate his own plans, without waiting for those of the decision aid module. In these circumstances, the operator uses his own knowledge and avoids, in particular, the problem of "blind trust", that consists in his waiting for, and automatically applying, the plans proposed by the aid module, without any verification of them. That could lead him to lose some of his knowledge, and he would therefore no longer be able, in some cases, to establish a correction plan if the assistance module fails.

How

The answer to the question of "how to display the information" has great significance. Indeed, it is important that the information is presented under predefined ergonomic and a priori evaluated formats. These can be centralized in an ergonomic graphical base, as shown in Fig. 1. If more than one representation mode is available with the same efficiency and in a similar functioning context, the operator must have the possibility of customizing his interface. He can customize it according to his preferences and habits, before the effective realization of his tasks in the process.

From one representation to another, the information may, moreover, lose its importance and relevance. So, many studies have revealed the effectiveness of the choice of the representation modes. 14-17 As an example, some short definitions of "How" follow:

-To visualize the evolution of a variable, a representation using curves is suitable. Indeed, such a representation allows the operator to know about the variable's trends. Additionally, it produces a historical account of the variable;

-if the situation is severe, the red color can be used to attract the operator's attention to this severity; -the main information is displayed in the top right area of the screen; -if the functioning situation is deteriorating and if the operator cannot reach any agreement with the aid module about a corrective plan without requiring justifications, these are automatically displayed in a secondary window.

THE EXPERT SYSTEM

The "heart" of the D.M.I. is an expert system that is in charge of giving to the supervisor a means of controlling screen displays. Its function is, more precisely, to give answers to the three questions What, How and When (described earlier). It contains (Fig. 5):

-an inference engine; -a knowledge base on the "What"; -a knowledge base on the "When"; -a knowledge base on the "How". The inference engine handles nine types of fact. These facts represent:

(i) What must be displayed, when and how: "What" (what must be displayed), "When" (when the screen modifications will occur) and "How" (how has the information to be displayed);

(ii) The process functioning state, by the use of the facts: "Functioning_ situation", "Situation severity", "Operator's-task";

(iii) The type of the operator and his eventual requests: "Operator's_class", "Operator's_request";

(iv) The previous state of the interface: "Previous _What" (was displayed at the last step).

These facts may have several values simultaneously because they are used in the management of the screen displays on which more than one change can occur at the same time. For example, in an abnormal situation of the process, with a novice operator supervising the process, the system may have to display, at the same time, a view showing the evolution of the variables and a view with action advice. In that case, two answers are given to the question (What): "What must be presented to the operator?" Figure 5 explains which are the input and output data used by the inference engine. 7, [START_REF] Strugeon | Knowledge specification and representation for an "intelligent" interface devoted to process monitoring and supervision[END_REF] It runs in a data-driven mode because of the need to obtain the highest possible number of facts: all inferable facts are inferred. Facts (ii) to (iv) are part of the initial fact base. A supervisor gives to the expert system the data that is necessary for the constitution of this base. The inference engine uses this knowledge base to deduce new facts: the facts What, When and How that correspond to what must be displayed, when and how it must be displayed. The engine starts by inferring on the fact What. The inferred value(s) of the fact What are added to the fact base and then, the facts When and How are deduced. The rule base is split up into three sub-bases corresponding to those three resulting facts.

"One of the attractions of the expert-system approach lies in the possibility of 'teaching' progressively the initial system in revising or completing the knowledge base put at its disposal". [START_REF] Farreny | Eléments d'lntelligence Artificielle[END_REF] For all that, it is essential for the rule base to be easily modifiable, aiming at a progressive refining. Some rules are added, deleted or modified to improve the rule data base, step by step. With that goal, the rules manipulated by the inference engine are created, compiled and brought up to date, using a methodology developed in the laboratory, 7, 20 see Fig. 6. Four steps compose this methodology:

• The first step leads to a census of all the possible values that are linked to decision criteria about the display management, i.e., the process severity levels, the functioning situations, the needs for assistance tools for the operator's tasks, and so on. This data defines a set of descriptors characterizing the man-machine system. A descriptor is a pair of elements, composed of an attribute and a value. For example, several values can be associated with the "process functioning situation" attribute, such as the values: normal, abnormal and critical. This step leads to the creation of a "Possible Fact Base". It is used to check the validity of the associations between a fact and a value. It contains all the possible values for each fact.

• With the Possible Fact Base, a connection was built between the registered decision criteria and the potential decisions of the D.M.I. These decisions concern "What", "When" and "How". A base of examples is generated during this second step. The description of the examples is made with the help of nine attributes related to the studied problem. Each attribute owns a finite number of mutually exclusive values.

• On the example base, techniques derived from the machine learning domain were used to generate optimized decision trees. The Artificial Intelligence tool FirstClass creates the trees. This tool is based on the algorithm ID3 (Iterative Dichotomizer 3), that develops classification procedures expressed under the shape of decision trees, from a set of examples, called the learning set. [START_REF] Quinlan | Discovering rules by induction from large collections of examples[END_REF] • The last step is aimed at compiling these trees into a usable form for the D.M.I. They are therefore changed into production rules, used by the previously described inference engine. The technique used is based on syntactic analysis, which necessitated the definition of an appropriate grammar. The program that "reads" the decision tree and produces the corresponding rules, is a kind of "transducer" or "compiler": with a stack system and with pointers, the tree from FirstClass is translated and the production rules are built in a useful format for the expert system. This operation is repeated three times to build the three modules of the rule base (the modules "What", "When" and "How"). All of the rules belonging to the module "What" have, in the conclusion part, a descriptor as follows: What = a value. Both the other modules are built the same way. In the current state of the D.M.I., the rule base is composed of 335 rules for the three modules.

Three examples of rules are given below: To evaluate the D.M.I., a testbed was developed. This experimental phase is described below.

IF Operator_Class = 3, AND Severity=2

GLOBAL PRESENTATION OF THE EXPERIMENTAL PLATFORM

The experimental platform, developed in the laboratory on a VAX/VMS computer, is composed of a set of computerized modules sharing a common memory zone, Fig. 7. • The Decisional Module of Imagery, that integrates:

-a set of knowledge bases answering the 3 ergonomic questions: "What", "When" and "How"; -an inference engine that exploits rules contained in the 3 knowledge bases; -a graphical task able to manage and to animate continuously all the views of the interface, using the D.M.I.'s answers concerning the "What", "When" and "How" questions; -a database about the operators. At present, this one essentially contains information about experiments such as: the subject name, the starting hypothesis for the experiment (novice, experienced or expert), a list of the failure situations used, and a list of the files modified during the experimentation.

• A supervisor module managing the coordination and the communication through the common shared memory.

• A module able to manage failure situations. In an experimental way, each failure situation can be described with a special editor.

• A module able to manage operators' actions and requests. It interprets and saves them into files.

The experimental platform integrates a laboratory simulated process. This one simulates the functioning of a simplified power plant cooling circuit (Fig. 8). It is principally composed of two circuits: a primary circuit (called the Sodium circuit) and a secondary circuit (called the Water circuit). These two circuits communicate through a vapor generator, considered here as a heat exchanger.

The next part of this paper presents some results produced by the D.M.I.

FIRST TECHNICAL VALIDATION OF THE PLATFORM IN THE LABORATORY

In order to validate the experimental platform technically, and to verify that what the assistance system gives to the operator conforms to the specified requests, a "first failure" situation has been established. This one is first described. An on-going experiment is then described and commented upon. This experiment aims at verifying the functioning of the whole platform.

A subject is asked to use the D.M.I. and to control the simulated process (see Fig. 8). Some failures were injected in the process according to a scenario. The scenario used for this experiment is described in Table 1. It consists in creating four failures. Each failure is activated for 3 rain. In the configuration case of the simulated process, the effects of each failure are described below. When all of the modules of the platform are activated, variables of the process are set to their nominal values, so that the functioning situation becomes optimal.

A moment later (3 min in this case study), the first failure is activated. Data scored in this experiment are: the gravity level of the process functioning situation, the kind of view displayed in the principal viewport, the kind of view displayed in the secondary viewport and the subject's actions.

The evolution of all the parameters scored is summarized in Fig. 9, which shows:

-the D.M.I.'s decisions, represented by the management of alarms and action plan, as well as by the content of the secondary viewport; -the answers given to the subject, represented by the content of the principal viewport; -the subject's activity; -the evolution of the process functioning gravity (evaluated by the D.M.I.).

The following paragraphs explain progressively the D.M.I.'s decisions without relating all of the inferences.

At the beginning of the scenario (between TO and T1), and after the detection of the first failure, the D.M.I. displays an alarm to the operator. This alarm is immediately detected by the operator. Furthermore, the D.M.I. proposes to the subject a set of possible causes, by automatically displaying surface justifications in the secondary viewport.

In this situation, the D.M.I. answered the questions "What", "When" and "How" in the following manner, see Table 2.

-"What": the D.M.I. deduced that the subject needed an action plan and surface justifications concerning this first failure; -"When": Since the situation was not serious, the D.M.I. deduced that an action plan should be displayed later, and that surface justifications should be displayed immediately; -"How": the D.M.I. deduced that surface justifications should be displayed as a fluency graph. In these conditions, the D.M.I. leads the subject in his search for possible failure causes, because the process situation severity is still low.

In the continuation of the scenario (between T1 and T2), the D.M.I. simultaneously displays both alarm and corresponding action plans. In this case, the process functioning severity is quite high (between 6 and 8) and the subject's aim is to restore the nominal functioning situation of the process quickly. As previously, the D.M.I. proposes to the subject, a set of possible causes, by automatically displaying surface justifications in the secondary viewport.

In this situation, the D.M.I. answered the questions "What", "When" and "How" in the following manner, see Table 3: -"What": the D.M.I. deduced that the subject needed an action plan and surface justifications concerning this first failure; -"When": Since the situation was quite serious, the D.M.I. deduced that both action plan and surface justifications should be displayed immediately; -"How": the D.M.I. deduced that an action plan should be displayed in a textual form, like alarms, and surface justifications in a fluency graph form. Note in Fig. 9 that when the second failure is activated, the subject changed his behaviour because the process functioning severity was quite high (about 8). He identified this situation by reading the action plan indicating that the failure had to be compensated with only a short delay.

Between T2 and T3, the process functioning severity increased suddenly. In this case, the D.M.I. answered the questions "What", "When" and "How" as shown in Table 4.

At the end of the scenario (after T3), the D.M.I. predicted that a severe situation was coming. In this case, it proposed to the subject an alarm, with the corresponding action plan, and it displayed all the justification details in the secondary viewport. The D.M.I. answered the questions "What", "When" and "How" as portrayed in Table 5.

After having analyzed all the scored data, it is possible to conclude that the functioning of the "Intelligent" Imagery manager is satisfactory, because it has correctly answered the three questions "What", "When" and "How" by displaying information in the secondary viewport automatically and in a coherent way. An example of a screen dump is presented in Fig. 10. It shows:

-an alarm and an action plan; -a set of possible failure causes in the secondary viewport; -a supervision view in the principal viewport.

Other experiments must be now done so as to complete this first technique validation of the platform.

CONCLUSION

This paper describes the authors' work contributing to the "intelligent" interface notion, in the field of complex process control. The focus here is on the way in which the "heart" of the interface is implemented with the help of artificial intelligence techniques. The management of the interface displays is condensed in the three questions What, When and How, to which the expert system has to give the appropriate answers.

The experimental platform is technically operational. It is now possible to undertake the next phase: the D.M.I. ergonomic evaluation. Its main objective is to verify that the complete assistance system answers a set of predefined criteria. These criteria will consider (i) system performance, in terms of differences between the objectives and the results obtained, and (ii) human factors related to man-machine interaction, assistance system utilization and human tasks in the different operational contexts (normal and abnormal) of the process. For instance, the evaluation will concern (i) the adequacy of the information to the real needs in the different human tasks, (ii) the access to the control displays and the interface functions, (iii) the chaining between the control displays corresponding with the cognitive steps for performing the tasks, (iv) the access time to information, (v) the human workload, and so on. At present, many operational methods exist for evaluating an assistance system. 23, [START_REF] Senach | Evaluation ergonomique des interfaces homme-machine : une revue de la littérature[END_REF] Most of them are commonly used in the authors' laboratory.

The D.M.I. ergonomic evaluation using the experimental platform will probably lead to the evolution of this "intelligent" interface approach.

(Fig. 2 .

 2 Fig. 2. The "What-When-How" concept. 7, 12, 13

Fig. 3 .

 3 Fig. 3. Examples of assistance to the operator according to the different situations of the system supervision.7

7

 7 Fig. 3. Examples of assistance to the operator according to the different situations of the system supervision.7

Fig. 4 .

 4 Fig. 4. Example of the automatic management of the aid messages according to the situation severity for a novice operator. 7

Fig. 5 .

 5 Fig. 5. The D.M.I. inference engine. 7, 18

Fig. 6 .

 6 Fig. 6. Method for constructing the knowledge data base. 7, 20

,

  AND Request = No_ Request, AND Situation = Abnormal, THEN What: = Action_ Plan, AND What: = Deep_and_Justified_Fluence_Graph IF Request = Help_To_Stop, AND What=Help_To_Stop, THEN When: = Now IF Operator_Class = 2, AND Previous_What =Variables, AND What= Deep_And_Justified_Fluence_Graph, THEN How: = Detailed_ Fluence_Graph

Fig. 7 .

 7 Fig. 7. Experimental platform architecture. 7, 13

Fig. 8 .

 8 Fig. 8. Localization and influence of variables in the simulated process. 7, 13, 22

Fig. 9 .

 9 Fig. 9. First experimental results.

Fig. 10 .

 10 Fig. 10. Example of a screen dump.

Table 1 .

 1 A failure scenario description[START_REF] Tendjaoui | Contribution à la conception d'interface "intelligente" pour le contrô1e de procédés industriels: application au Module Décisionnel d'Imagerie[END_REF]

Acknowledgement. The authors would like to thank Professor Patrick Millot for his contribution and helpful comments.

AUTHORS' BIOGRAPHIES