Selem Charfi
email: selem.charfi@univ-valenciennes.fr

Abdelwaheb Trabelsi
email: abdelwaheb.trabelsi@fss.rnu.tn

Houcine Ezzedine
email: houcine.ezzedine@univ-valenciennes.fr

Christophe Kolski
email: christophe.kolski@univ-valenciennes.fr

A User-Oriented Test environment based on User-Interface evaluation graphical controls

Keywords: User-Oriented Test (UOT), usability test, electronic informer, HCI evaluation

Several user-oriented techniques have been proposed for Graphical User Interface evaluation. In this paper, we focus on User-Oriented Test concepts, advantages and related problems. Among the User-Oriented Test techniques, the electronic informer is a powerful technique for interactive system testing. Thus, this research paper contributes in the improvement of existing tools for interactive system evaluation. This environment is achieved using (1) an electronic informer dedicated to the interactive system evaluation and (2) evaluation based graphical controls. The proposed evaluation environment is structured following client-server architecture. It aims to automate the interactive system evaluation process. Besides it takes the evaluation process into account since early interactive system design phases. This environment is validated by an experimental test.

INTRODUCTION

Interactive systems have become ubiquitous in all areas and sectors. Thus, obtaining usable systems has become a growing challenge to which software engineering community is often challenged to. Thus, interactive system usability is a real need in the interactive systems design. Indeed, usability testing is based on performance and user experience [START_REF] Stone | User interface design and evaluation[END_REF][START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF][START_REF] Sharp | Interaction Design: Beyond Human-Computer Interaction[END_REF]. To support interactive system usability, various evaluation techniques have been proposed for usability testing [START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF][START_REF] Stone | User interface design and evaluation[END_REF][START_REF] Sharp | Interaction Design: Beyond Human-Computer Interaction[END_REF]. Among them, we focus in this paper on User-Oriented Test techniques. These techniques can mainly be classified following two categories. The first one includes formal tests which are performed as a simulation of the real system running (they are computed under conditions similar to those used for the system use context). The second category contains less formal tests that consist generally in an iterative testing cycles. These cycles are designed in order to detect different failures related to usability [START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF].

In this paper, we will present an environment for useroriented testing. This environment is based on an electronic informer and evaluation based graphical controls. The evaluation through the proposed environment consists of comparing actions, performed by users, to planned ones by the evaluator. In this environment, the graphical controls are used to compose user interfaces. The evaluation process through the proposed environment aims to detect the user interface usability problems. The environment, proposed in this research, represents a contribution for the techniques of User Oriented Test. It intends to detect usability problems since software development cycle early stages.

USER-ORIENTED TEST (UOT)

The HCI domain is rich in evaluation techniques, concepts, approaches and tools [START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF][START_REF] Stone | User interface design and evaluation[END_REF]. Among the related techniques, we find the User-Oriented tests. According to Nielsen, the UOTs are the most effective for usability testing. They enable the direct interaction between users and the interactive system. The problems of usability can be identified in real terms. Generally, the UOT consists, at the first step, of creating a scenario (similar to those of the evaluated system use context). This scenario includes a set of tasks required for users to execute using the evaluated system. During the task execution, an observer records different interaction data either manually or automatically. The aim of such tests consists of investigating the user reaction together with the interactive system. This study enables the detection of the usability problems in the evaluated graphical user interface. Many UOT techniques exist such as "Think aloud protocol" (Kuusela and Pau, 2000), eye tracking [START_REF] Chynal | Remote usability testing using eyetracking[END_REF] and the electronic informer [START_REF] Trabelsi | Evaluation of an Information Assistance System based on an agent-based architecture in transportation domain: first results[END_REF]. Following the usability evaluation, the UOT evaluates interactive system efficiency, effectiveness and accessibility [START_REF] Sharp | Interaction Design: Beyond Human-Computer Interaction[END_REF]. In addition, they measure also user performance, productivity and satisfaction [START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF]. UOT offers the possibility to compare different prototypes alternatives and versions. It establishes benchmarks over a longer period of time to avoid user problems, to understand competitors, and to spark guidelines for feature, user interfaces and interaction design. The benchmarks can display different goals such as relevance, efficiency, learnability, attitude, and feature availability. Ivory and Hearst identifies UOT techniques as five categories (2001):

 Testing: consists in observing the users interacting with the interactive system to determine usability problems;  Inspection: consists in inspecting a set of criteria and aspects in order to identify the user interface (UI) usability problems;  Inquiry: enables gathering the user opinion and feedback essentially through questionnaires and interviews to identify the evaluated system use problems;  Analytical modeling: enables predicting usability problems via the user and the interface models' generation and,  Simulation: consists in simulating the interaction between the user and the interactive system to cover the evaluated system usability errors and problems. The UOT identifies usability problems and provides evaluation results. As the UOT are based on empirical data [START_REF] Rubin | Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests[END_REF]) and needs the system user in the evaluation process, the provided results are reliable. Despite the UOT advantages, we found some drawbacks. On one hand, although the UOTs are based on the system real use simulation and representation, generally the user test does not reproduce the identical interactive system usage scenario of the interactive systems use. On the other hand, the UOT offers to the evaluator important quantitative measures. Then, these data can be difficult to be processed and to be analyzed. They can require many resources: time, cost, operators, etc. In this paper, we are particularly interested in the electronic informer as a UOT technique. The electronic informer will be the object of the following section.

THE ELECTRONIC INFORMER AS A USER-ORIENTED TEST TECHNIQUE

What is an electronic informer?

An electronic informer is defined by [START_REF] Ezzedine | Integration of traffic management and traveler information systems: basic principles and case study in intermodal transport system management[END_REF] as a technique able to ensure the automatic collection, in a real situation, of users' actions and their repercussions on the system. The collection of information is achieved in a discreet and transparent way for the user. Users of evaluated system should not be disturbed by the presence of informers. This evaluation technique is structured following two closely dependent phases. The first phase consists on interaction data acquisition between the user and the interactive system. In the second one, the electronic informer classifies and analyzes the recovered data [START_REF] Ezzedine | Integration of traffic management and traveler information systems: basic principles and case study in intermodal transport system management[END_REF]. The electronic informer is a useful and a powerful technique for interactive system evaluation. It gathers automatically exhaustive interaction information. These data are processed to provide an empirical evaluation. The proposed evaluation is related to quantitative measures that ensure the evaluation process result reliability. In other word, the electronic informer tracks the interaction between the user and the interface in order to detect eventual usability problems in the evaluated user interface.

Electronic Informer vs usability tracking tools

Many tools for tracking user interaction are proposed for User-Oriented Tests. Such tools capture generally the interaction sequence as a video. They are mostly focused on the mouse target during the interaction session. For instance, we can cite "Simple Mouse Tracking" tool [START_REF] Pan | The Determinants of Web Page Viewing Behavior: An Eye Tracking Study[END_REF]. It stores the mouse target into a database. Thus, such tools provide the evaluator by an important amount of information as an evaluation result. These data are difficult to be processed in the evaluation process. Contrary to tracking tools, the electronic informer is based on different interaction devices information. It is not focused on the mouse target. In addition, it provides more detailed and exploitable information for the usability test. Furthermore, most of tracking tools are generally indented for Web user interface usability tests such as the case of "clicheat"1 .

Existing electronic informers

There are many electronic informers for interactive system evaluation. In this paper we follow an illustrative way rather than the exhaustive one. The most recent electronic informer can be illustrated as the following:  MESIA [START_REF] Trabelsi | Evaluation of an Information Assistance System based on an agent-based architecture in transportation domain: first results[END_REF]: is an electronic informer dedicated for the agent based interactive system evaluation. The strong idea behind this electronic informer is its architecture coupled with the system to evaluate. MESIA is structured by several informer agents resulting from the evaluated system architecture (and more particularly from the presentation layer agents). MESIA is based on the Petri nets (PN) for the interaction modeling between the user and the system to evaluate. It simulates the PN related to the interaction. It also ensures PN confrontation and specification. This electronic informer is specific to a transportation supervision system. MESIA supports only interaction abstract levels. This can lead to important data number. These data are costly to be analyzed (in terms of time and resources).  MultiDevice RemUsine (Paterno et al., 2007): is based on CTT2 task modelling to analyze interaction captured data. It is intended for mobiles interactive system's Remote evaluation. MultiDevice RemUsine considers the external environment different elements (the noise, the lighting, etc.). The CTT task model enables detecting the divergences between the actions performed by the user and those planned by the interactive system designer. MultiDevice RemUsine proposes, at the end the evaluation process end, a graphical report that presenting the collected information.

 EISEval (Environment for Interactive System Evaluation) [START_REF] Tran | EISEval, a Generic Reconfigurable Environment for Evaluating Agent-based Interactive Systems[END_REF]: is a generic and configurable electronic informer. It is used especially for agent based interactive systems. It captures Human-Computer interaction. Like MESIA, it models the interaction sequences using the PN. Using its confrontation module, it analyzes the various captured interaction information. The major disadvantage of this informer is the proposed PN as an evaluation result. They are difficult to be explored for user interface evaluation. Moreover, the configuration process requires injecting a code into the evaluated interactive system code source.

ISUTE: INTERACTIVE SYSTEM USER-TEST ENVIRONMENT

ISUTE is an Interactive System User-Test Environment. It is indented to detect usability problems in the evaluated user interface. It is structured following client-server architecture.

The client is the evaluation based graphical user interface control. On the server part, we find an electronic informer dedicated for the evaluation of interactive systems. This environment supports the UOT at early system design phases: it supports interactive system early evaluation. The early evaluation consists on an explicit coupling between design and test phases (Nielsen, 1994;[START_REF] Tarby | Prevision of evaluation by traces during the software design of interactive systems: two approaches compared In Ahmed Seffah[END_REF]. Such evaluations reduce test cost (time and resources). Indeed, according to Nielsen, correcting final system usability problems is 100 times more costly than correcting these design errors at first design phases (Nielsen, 1994). ISUTE operates as follows: the graphical controls are endowed with mechanisms supporting interaction information sending through sockets via the TCP/IP network protocol to the informer. Using the CTT, the informer enables the confrontation between the executed action sequence ("the observed task model") and the planned action sequence ("the referential model"). This confrontation aims at detecting user interface usability problems. The evaluation process requires users, designers and an evaluator. In order to model user tasks, we opt for the CTT (Paterno, 2000). In deep, this modeling notation structures well the interaction between the user and the interactive system. It models interaction into tasks and sub-tasks. Besides, CTT proposes some operators as the one offering the choice between different action sequences (Paterno, 2000). The evaluation process is illustrated below with the BPMN3 notations [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF], Fig. 1. During the preevaluation phase, a programmer team implements the evaluation based controls. The proposed controls (client part in the proposed evaluation environment) are similar to those proposed by development environments. Indeed, they ensure the same features and are exposed to the toolbar in the integrated development environments operating with the "Drag and Drop" principle, Fig. 2. There is not any specificity of usability test that is visible to the designer. The specificity of graphical component for evaluation consists on informing the electronic informer (the server part in the evaluation environment) via the executed elementary task messages. These controls allow graphical user interface composition through the "WYSIWYG"4 environments. Once the interface is elaborated, the designer executes the possible tasks with the graphical user interface. During the interaction session, the controls send information to the informer. The evaluator establishes tasks and sub-tasks diagram using CTT notations.

The evaluator exploits the electronic informer to associate the various elementary actions (executed by the designer) with sub-tasks using "drag and drop". Once this association is established, the electronic informer generates the user task referential model. Then, the user executes the various tasks.

The evaluation based controls informs the electronic informer of the executed actions. The graphical control sends to the electronic informer:  The execution time of elementary actions;  The type of the executed actions (button click, checklist select, etc.);  The associated form (the screen interface to which the graphical control is added);  The text content of the graphical control;  The graphical control name;  The type of the graphical control (button, textbox, label, combo-box, etc.) and,  The IP address of the used machine. At the user task execution end, the confrontation module compares between the action sequence specified by the designer (the referential model) and the executed action sequence by the user (the observed task model). This confrontation generates the UOT results. This result articulates essentially around the usability problems in the evaluated interface. More details are given later (in Result and analyzes section).

Graphical Evaluation Based Custom Control

ISUTE proposes a set of graphical controls for the design and the test of user interfaces. These controls are inherited from graphical controls proposed by "MS Visual Studio 2010". These controls are integrated into the toolbox so the designer can use these controls to compose the interactive system user interface. The proposed controls are: combo-box, radio-button, label, button, tab control, textbox, list-box, check-box and checkbox list. These controls are encapsulated into a DLL file to ensure their integration into the toolbox, Fig. 2.

Electronic Informer

The proposed electronic informer has a modular architecture.

It is articulated around four modules.

Referential Model Generator Module

This module sets up the referential model. This model contains the instructions and elementary action sequences. These sequences are determined by the interactive system designer. The reference model is established by associating the executed elementary tasks and task modeling, Fig. 3.

Observed Task Model Generator Module

The observed task model generator module captures of the elementary actions executed by the user. This capture is done via the reception of information from the evaluation based controls. Once the user ends the executed of the tasks, this module piles the elementary action sequences into an XML file. The interaction sequence is realized separately for each task. Besides, the electronic informer supports the same task execution by several users. This module provided result will be exploited by the confrontation module.

Confrontation Module

The confrontation module is the electronic informer central module. It establishes the confrontation between the referential and the observed task models. This confrontation aims to detect the repetitive, useless and erroneous user actions. Furthermore, this module detects the usability various problems. The confrontation is based on Finite State Automaton 5 (FSA). We opt for the FSA because they model the sub-tasks' various alternatives (often we have more than one possibility to execute a task). The CTT model is converted into a finished automaton. Then, the confrontation module inspects the sequence of elementary actions (the observed task model) to detect inconsistencies. This inspection aims to compare the observed task model to the referential one.

Statistics Generator Module

The statistics generator module provides the evaluation process result. In order to simplify the UOT process and to minimize the evaluator analysis and interpretation workload, this module proposes statistics to the evaluator. These statistics concern the user that succeeded the execution of the required tasks, the tasks and sub-tasks execution average and the comparison between the observed task and referential models in a graphic way with a colored legend, Fig. 6 and Fig. 9.

APPLICATION TO A NETWORK TRANSPORTATION SYSTEM

ISUTE proposed electronic informer collects the interactions between the user and the evaluated interactive system. The captured data are very important as far as they reconstituting referential model and compare it to user models. The tests process participants are familiarized with the interactive system during five minutes before beginning the experimental tests. The evaluator has to specify the task to be realized by the users. To validate the proposed environment, we apply the proposed graphical component for evaluation to design and then evaluate a network supervision system user interface: The IAS.

The IAS (Information Assistant System)

The IAS is a system proposed within the project "SART". It indents to assist regulators in supervision rooms for the management and the supervision of urban transport networks. It aims to ensure that regulators do their jobs optimally during normal or abnormal transport network situations [START_REF] Ezzedine | Integration of traffic management and traveler information systems: basic principles and case study in intermodal transport system management[END_REF]. Thus, it aims to minimize the waiting time of passengers and their continuity of displacements in multimodal networks (Tran et al., 2008). The IAS presents the different network information to passengers and regulators. It basically consists of informing supervisors among the different network vehicles position in the transportation network. In addition, it also enables the supervisor to communicate with vehicles drivers and passengers via sending messages. Note that the IAS architecture is an agent based one.

Interested readers can consult [START_REF] Ezzedine | Integration of traffic management and traveler information systems: basic principles and case study in intermodal transport system management[END_REF]Trabelsi et al., 2009;Tran et al., 2008).

To proceed to the evaluation of the IAS, we propose a prototype designed with the proposed evaluation controls, Fig. 3. The used controls are: button, label, picture box, text box and Combo-Box.

The evaluation process

The evaluation consists on an interaction session. During this session, the user is required to execute three tasks with the evaluated user interface. For every task, a referential model is defined. It is modeled through the CTT task modeling notation.

As mentioned previously, the comparison consists on comparing between referential and observed task model. Then, we proceed to interaction session to define the observed task model to proceed to the evaluation.

Interaction session

The interaction session consists on enquiring the user to manage the perturbations occurring on the network using the IAS. As mentioned previously, the proposed environment has client-server architecture, Figure 4.

Fig. 4. Interaction session devices

In the proposed evaluation process, the evaluator interacts with the electronic informer and the user with the user interface designed with the proposed evaluation based controls. These controls communicate with the informer through the sockets to send the different user interaction information. The tasks to execute by the user are, Fig. 5:  Send a message to the driver of the vehicle "Tramway 5" due to an advance of four minutes;  Send a message to the driver or the vehicle "Tramway 1" due to a delay of three minutes and,  Send a message to the driver of the vehicle "Tramway 8" due to a delay of five minutes.

Fig. 5. Interaction session tasks to be executed by the user Each task is decomposed of four sub-tasks, Fig. 7. The first sub-task consists on click the icon for the delay. This icon is a picture box control. This click will display an interface entitled "Agent_message", Fig. 6. It enables user to enter the message to be sent. Then, the second sub-task consists on specifying the user who will receive the message (a vehicle driver, waiting passengers or vehicle's passengers; in our case the message receiver is a vehicle driver). The message receiver selection is done through a selection using a combo box. Then, the third sub-task consists of entering the message to send in a textbox. The fourth sub-task is the validation of the message to be sent via the button ("Send").

Fig. 6. A screen shot of the message sending user interface Fig. 7. The "handling of the perturbation" task modelling through CTT notations

Choice of users for interaction session

For this experimentation, we are based on the works of (Hwang and Salvendy, 2008;[START_REF] Whiting | Creating realistic, scenario-based synthetic data for test and evaluation of information analytics software[END_REF]. We choose twelve users. These users are classified into two categories. The first one is constituted by six computer science student (experimented users). The second category includes the other six sport science students (novice users). Before proceeding with the interaction session, the evaluator explains to the users the experimentation context as well as to tasks that they have to execute with the interactive system.

Result and analyses

At the experimental test end, the electronic informer proposes to the evaluator a list of performed tasks by the user. The tasks are colored according to the task execution success (green: totally executed, red: unfilled, pink: delay in the execution and yellow: incomplete), Fig. 8. Furthermore, the executed task sequence is proposed to the evaluator. They contain essentially the task execution success rate.

In our experimentation, the users did not find any problems to execute the three required tasks. Indeed, the electronic informer shows 100 % success result. One of major advantages of the proposed environment is that it offers to the evaluator the erroneous manipulation and/or its locations in the action sequence.

Fig. 8. A view of experimentation results

First, the evaluation showed the ease of the proposed graphical controls for the evaluation of user interface.

Remember that the purpose of this evaluation is not to evaluate the IAS user interface but to test the functionality of the proposed evaluation controls. The evaluation process does not detect any usability problem when using the evaluated IAS. The users were able to easily perform the required three tasks. As an evaluation result, the electronic informer provides the evaluator by the success rate of the tasks performed by the different users and the performed actions' sequences. An evaluation of the IAS was elaborated by Tran et al. (2008). The provided evaluation by ISUTE are simpler to be exploited than those provided by EISEval.

One of the limits of the proposed electronic informer consists of the fact that the evaluator is not able to save actions performed by the user. In addition to that, it does not provide evaluation results under a form that can be exploitable for further studies and analysis. The informer cannot precisely specify the location of usability problems and provide improvement suggestion to the evaluator to get better user interface. In addition, the proposed statistics are poorly developed and require to be worked more.

RELATED WORK

The proposed environment identifies the problems of usability at user interfaces. It informs mainly about usability problems frequency, impact and persistence. The detected problems are related to the following usability problem categories: minor, major and catastrophic usability problems (in the sense of usability problem rating scale of Nielsen (1994)).

Most usability evaluation tools and techniques do not consider the evaluation since the first interactive system lifecycles. Thus, evaluation is elaborated at the last stage: the test phase in the sense of the waterfall life-cycle (e.g. MESIA (Trabelsi et al., 2009), EISEval (Tran et al., 2008)). In fact, the evaluation process is more complex. One major advantage of the proposed environment is the fact that the evaluation has been considered since early stage. In fact it, the designer uses evaluation dedicated controls to compose graphically the user interface. Indeed, he/she has not to integrate code lines into the source code to capture interaction by the electronic informer or to implement specific mechanisms for the evaluation process.

In addition, most existing tools provide to the evaluator a huge amount of information. Then, it requires an important amount of time and effort to process it (Charfi et al., 2011a).

In fact, the most difficult task to process while evaluating interactive system is to analyze the captured data in order to provide critics as an evaluation report to the evaluator. This difficulty is due to the lack of conformity of the information to be processed. Then, it will be hard to be exploited in the UOT process. The usability problems detection process, through ISUTE, is rather effective and easy to set up; the electronic informer proceeds of an exhaustive information collection for the evaluation process. Indeed, ISUTE covers a wide information spectre. Furthermore, the interaction data capture is made in a discreet way that does not influence the user-test context. However, ISUTE does not interpreter automatically the detected usability problems. Thus, the interpretation is done manually by the evaluator. Then, ISUTE does not propose any solution for the detected usability problems. ISUTE detects only automatically the interactive system usability problems.

In addition, the evaluators are often faced with a difficulty for evaluating an interactive system. It consists of setting up mechanism for information capture. The existing informers need to integrate code lines into the evaluated system code source to ensure data capture. Furthermore, the electronic informer setting up is generally a complex process (especially for building and configuring). For instance for MESIA, some instructions need to be injected into the interactive system source code that the electronic informer can detect the interaction information). Thus, the pre-evaluation process is complex to establish. However, ISUTE does not require code integration into the evaluated system source. It does not affect the interactive system source to evaluate.

CONCLUSION

This article presented an environment proposition for the interactive system User-Oriented tests. This Environment is composed of two parts. The first one is interested in the evaluation based graphical controls. The second part is an electronic informer. The proposed UOT process is automated during the information capture, and analysis. Furthermore, it considers the HCI usability test since early interactive system design phase. In this article we present this environment, entitled ISUTE. It evaluates the user interfaces basing on the interaction sequence comparison. The interaction is modeled through CTT notations. The main advantage of this environment is the fact that it does not require specific mechanism to integrate in the evaluated system source code.

Comparing this finding to the existing environment, ISUTE has the specificity to incorporate the graphical user interface control to the evaluation process. The proposed environment was applied for the evaluation of a system for transport network supervision.

As research perspectives, we propose to combine these graphical controls with those proposed in (Charfi et al., 2011b). Indeed, we suggest integrating the ergonomic quality inspection in the proposed evaluation based controls to cover the maximum of the interactive system usability problems.

On the other hand, we suggest improving the informer so that it can capture the elementary actions of various users simultaneously. Besides, we suggest using the task planning automatic concept [START_REF] Gabillon | Automated planning for user interface composition[END_REF]. In the proposed UOT environment, the number of the proposed graphical controls for evaluation is limited to only ten graphical controls. Besides, the current Environment evaluates only the WIMP (Windows, Icons, Menu, and Pointing device) interfaces; it is not possible to evaluate WUI (Web User Interfaces). On the other hand, the provided evaluation results are not well normalized and formalized.

Fig. 1 .

 1 Fig. 1. The User-Oriented Test process through ISUTE (expressed through the BPMN notations).

Fig. 2 .

 2 Fig. 2. The custom evaluation based controls integrated into the integrated development environment Toolbox.

Fig. 3 .

 3 Fig. 3. A prototype of the IAS user interface

http://www.labsmedia.com/clickheat/index.html

Concur Task Trees is a notation for user task modelling. Its major advantage is its task hierarchic structure and the provided graphical syntax. It focuses on activities that users intend to perform. It is rich of temporal operators(Paterno, 2000).

Business Process Model and Notation.

Notation for « What You See Is What You Get ». It designs programming environments that compose visually the GUI.

Automatons are constituted by states and tasks. They model process, cycles and protocols. The automatons are frequently used at formal language and compilation level.

ACKNOWLEDGMENTS

The present research work is partially supported by the International Campus on Safety and Inter-modality in Transportation (CISIT), the Nord-Pas-de-Calais Region, the European Community, the Regional Delegation for Research and Technology, the Ministry of Higher Education and Research, and the CNRS.


Jean-René Ruault
email: jean-rene.ruault@dga.defense.gouv.fr

* Frédéric Vanderhaegen

Christophe Kolski

Sociotechnical systems resilience: a dissonance engineering point of view

Keywords: Socio-technical system, Safety, Resilience, Dissonance management, Railway. 

Resilience deals with the capacity to adjust itself face disturbing events, to cope with unforeseeable conditions. Resilience is based upon the dynamic process of "visual piloting". The gap between the specified task and the done activity generates dissonance between beliefs and representations. In many cases, such as silent migration or normalization of deviance, management of dissonance is hazardous. The proposition of this article deals with a resilient management of dissonance. The case study expresses the management of dissonance in the context of railway accident.

INTRODUCTION

A sociotechnical system is designed to run inside its specified design and safety margins [START_REF] Dod | Department of Defense Standard Practice, System safety[END_REF]. Factors of context as well as the system's environment evolve and vary, affecting sociotechnical system's performance. In this case, the sociotechnical system runs outside its specified design and its safety margins. The gap between the specified task and the real activity generates dissonance between beliefs and representations. The article differentiates, on one side, the hazardous management of dissonance, such as silent migration or normalization of deviance, and, on the other side, the resilient management of dissonance. The article proposes two solutions for a resilient management of dissonance. The case study expresses these two types of management of dissonance in the context of a railway accident.

STATE OF THE ART: SOCIOTECHNICAL SYSTEMS RESILIENCE

What does resilience mean?

Luzeaux [START_REF] Luzeaux | Engineering Large-scale Complex Systems[END_REF] characterizes resilience as a "management at the border of the domain of application. The challenges linked to resilience include the management of that which is uncertain or unplanned, accidents, the transition between more or less catastrophic circumstances while avoiding a true catastrophe, and the return to a more normal operational status". Here, the term of resilience relates to the sociotechnical systems including the traditionally three levels: the technical system level, the human level and the organizational level (a crew, for example). [START_REF] Luzeaux | Engineering Large-scale Complex Systems[END_REF] differentiates four main resilience functions: 1) avoidance (capacity for anticipation); 2) resistance (capacity for absorption); 3) adaptation (capacity for reconfiguration), and 4) recovery (capacity for restoration).

In short, resilience relates to the sociotechnical system's capacity to adjust faced with disturbing events, to adapt and learn, when the disturbances are apart from the specified perimeter of the system adaptation mechanisms, i.e. irregular threats and threats without precedent. Moreover, resilience includes the detection that the adaptive capacity limits are reached [START_REF] Luzeaux | Engineering Large-scale Complex Systems[END_REF]. Such adjustment capability has to maintain safety and avoid accident. This adjustment capability is based upon the dynamic process of "visual piloting". The system must have a great capacity to estimate its position with regard to the danger zone [START_REF] Luzeaux | Engineering Large-scale Complex Systems[END_REF]. The system must be designed to cope with uncertainty. It is necessary to specify the envelope of required, desirable, even acceptable, execution and to require that the system recognizes the situations where it is likely to leave this envelope. "Resilience is obtained via the system capability to monitor conditions at the edges of the performance envelope, determining their value and the usual distance from the edge and the ability to adapt the operational behaviour of the system to potential developments in the envelope…" [START_REF] Luzeaux | Engineering Large-scale Complex Systems[END_REF]. This capacity is based upon architecture flexibility and tolerance. The objective is to qualify and quantify the drift of the system towards the state of failure before a major breakdown occurs.

In many cases, the system has been designed to be safe under specified conditions, but there are no means to monitor the system when it operates under unspecified conditions, and to reassess actual risk. Safety under this situation is neither monitored nor controlled. This is like visual piloting without visibility. We describe three kinds of unspecified conditions: barriers removal, silent migration, normalization of deviance. They may be modelled as functional resonance. [START_REF] Vanderhaegen | Analyse et contrôle de l'erreur humaine[END_REF] explains how human operators deviate and bypass barriers (functional, physical, procedural…) which were designed and built by safety engineers. Pressure to increase performance, as well as negative impacts of barriers (increase operator workload), cause barriers removal or bypassing. In the context of Benefit/Cost/Deficit (BCD) analysis, the operators neglect the safety and dangerous consequences of barriers bypassing. It is partly due to cognitive biases that highlight performance benefits while veiling and hiding hazards. The BCD analysis can be a way to define resilience indicators and criteria in order to assess the impact of behavioural alternatives facing perturbations such as barrier removals [START_REF] Zieba | Resilience of a human-robot system using adjustable autonomy and human-robot collaborative control[END_REF][START_REF] Zieba | Principles of adjustable autonomy: a framework for resilient human machine cooperation[END_REF], Zieba et al., 2011).

On the one hand, since the barriers have been removed, the system moves silently, migrates, outside its safety specified conditions. [START_REF] Amalberti | Violations et migrations ordinaires dans les interactions avec les systèmes automatisés[END_REF] makes it clear that safety devices, by reducing system performance, generate deviating behaviours from operators in order to maintain the specified performance level. In the case of an automatic drug dispensing system, the migration phenomenon can begin very quickly as far as the deployment step. [START_REF] Amalberti | Violations et migrations ordinaires dans les interactions avec les systèmes automatisés[END_REF] explains that "the nurses, with the complicity of the doctors, created false patients to remake wild drug stocks for all marginal cases" which are the cases where "the patient is not yet recorded in the database", or "situations of losses of pill in geriatrics". The perverse effect of the research of safety is induced by the reduction of adaptive capability, which becomes more powerful within the specified perimeter, but more rigid and extremely fragile outside this perimeter, in case of sharp context variation. This migration phenomenon is excluded from the experience feedback process; it is dumb, in some extent an omerta situation (code of silence).

On the other hand, barriers removal and running outside safety specified conditions become normal. [START_REF] Vaughan | The Challenger Launch Decision. Risky Technology, Culture, and Deviance at NASA[END_REF] defines normalization of deviance as gradual process and incremental deviations where unacceptable practices or standards become "acceptable risk", allowing risk to increase over time. As management recurrently observes the problem with no consequence, one gets to the point that the problem is normal and acceptable. This behaviour becomes the normal way of doing business. Those who try to challenge the behaviour are ignored or stigmatized. The lack of casualty provides evidence proving the success of this deviant behaviour.

These situations may be modelled as functional resonance. The Functional Resonance Analysis Method (FRAM) [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF] expresses the interaction between performance variability of the output (O) of functions. It is induced by the variability of the functions' input (I), time (T), control (C), resources (R) and preconditions (P) (fig. 1).

Unwanted outcomes are due to interaction among individual functions, unusual variability out of the range of everyday variability [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF]. For each of these elements, variability is described in terms of speed (too fast / too slow), distance (too far / too short), sequence (reversal / repetition / commission / intrusion), object (wrong action, wrong object), force (too much / too little), duration (too long /too short), direction (wrong direction) and timing (too early / too late / omission). Sources of variability are external or internal of the system, such as working environment, ambient operating conditions, organizational culture, as well as maintenance quality or equipment reliability and availability. [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF].

Activity / function

Dissonance engineering

Dissonance engineering applies the cognitive dissonance concept and denotes the discomfort, the conflict, when simultaneously holding two or more conflicting representations, beliefs, or values. The dissonance generates misunderstanding, frustration, anger. People reduce dissonance by altering existing cognitions, avoiding situations or information sources that disconfirm ones' beliefs, rejecting different knowledge, or adding new ones to create a consistent belief system [START_REF] Festinger | A theory of cognitive dissonance[END_REF]. Dissonance theory explains human behaviour by positing that people have a bias to seek consonance between their expectations and reality. People engage in a process termed "dissonance reduction", which can be achieved in one of three ways: lowering the importance of one of the discordant factors, adding consonant elements, or changing one of the dissonant factors [START_REF] Festinger | A theory of cognitive dissonance[END_REF].

Dissonance engineering applies this notion in order to explain, on the one hand, the conflict of representations between groups, and, on the other hand, conflict between behaviours and representations. Such conflicts can arise from BCD analysis.

Dissonance engineering consists of exhibiting these differences and conflicts between sets of representations and beliefs, in order to reduce these conflicts, to change beliefs, to restore a clear and relevant situation awareness, to enhance hazard avoidance, to limit compensation phenomena, and to improve adaptation capability.

The dissonance management aims at returning to a new level of knowledge stability, the reduction of the dissonance. Trialand-error, and wait-and-see are strategies to manage dissonance [START_REF] Vanderhaegen | A dissonance management model for risk analysis, invited session "Risk Management in Life Critical Systems[END_REF].

PROPOSITION: DISSONANCE MANAGEMENT FOR RESILIENT SYSTEMS DESIGN

There is always a difference between the real behaviour and the specified behaviour of the system. This variation is seldom expressed. More still, the work of engineers, in term of reliability, of risk prevention, is based primarily on the specified behaviour, never on the real behaviour.

Hardy (2010) expresses that "plans that do not reflect reality may create the impression that effective organization is in place and that risks have been reduced, when in fact large risks could exist".

This difference may grow from the beginning of the operation of the system, from step to step. This gap generates difference between, on the one hand, the beliefs of the designers and the managers (high level and middle management), on the other hand, the beliefs of the operators. Two different cultures, two different sets of representations, and beliefs, are formed in an insidious way then, in opposition one of the other. There is, on the one hand, the set of representations and beliefs that the managers, the engineers, the quality managers and the quality auditors forge themselves; the specified path, the system as-designed, the task as-prescribed. The designers and the managers believe that the system is operated compliantly with the specified procedures, regarding the safety regulations. On the other hand, there is the set of representations and beliefs which the operators work out, the actual path, the system as-used and the activity as-done [START_REF] Leplat | Erreur humaine, fiabilité humaine dans le travail[END_REF]. For instance, operators tend toward more barriers removals. Since the difference between the real behaviour, the task, and the specified behaviour, the activity, of the system grows, the dissonance grows accordingly.

These two sets of representations, of beliefs, are dissonant. They give different meanings to the events, with the situations of the environment, the actual states of the system, insofar as these two sets of representations are based on two different reference marks. This dissonance refers to inconsistency or conflict from holding two or more incompatible beliefs or representations simultaneously.

The figure 2 expresses this difference between these two behaviours. The specified path deals with the specified task [START_REF] Leplat | Erreur humaine, fiabilité humaine dans le travail[END_REF], or the work-as-imagined, in the context of FRAM [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF], taking place along the time. It contains specified local variability included within tolerance margins, that is everyday, or 'normal' variability [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF] as defined a priori.

The actual path, among other possible ones, denotes the actual activity [START_REF] Leplat | Erreur humaine, fiabilité humaine dans le travail[END_REF], or the work-as-done [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF], of the sociotechnical systems, function of met contingencies. This actual path contains actual local variability, since these contingencies are not stable and linear.

The gap between these two paths is due to unusual conditions, 'out-of-range' variability [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF], that is not an isolated case, but a huge trend. These unusual conditions may be new and unforeseeable working environments conditions. Coming from A, this actual path crosses the barrier at 1 (figure 2) and moves to B, then to C. The actual path from A to C via B expresses a deviation that may be far away from the specified path. This deviation may be due to performance variability outside the specified range, including evolution of the environmental situations. It may be based upon BCD analysis. The difference between the specified behaviour and the real behaviour is compensated by the operators by various means, like withdrawal of barriers, new unwritten procedures, or quite simply the standardisation of the deviance. The exceptional practices, which comprise risks or which are to be implemented in only exceptional situations, become current, regular, routine, and their risked character, is hidden by the banality of the practices, the routines. Mostly, this deviation phenomenon deals with silent migration. No one can assess the distance, the gap, between the specified and the actual paths; there is no situation awareness, no capability to assess the risk induced by the situation point B.

It is a visual piloting, but without visibility.

One can differentiate two kinds of dissonance management: the hazardous one and the resilient one.

The hazardous or pathogenic management of the dissonance deals with processes or procedures change that may be made without understanding of the increase of risks [START_REF] Hardy | The system safety skeptic[END_REF]. These changes can produce uncontrolled new hazards.

The hazardous or pathogenic management of the dissonance lays on:

• The silent migration which is invisible and uncontrolled.

It is a denial of the gap between the specified path and the actual one.

• The normalization of deviance, which reinterprets the gap as consistent with the regulations and uses the exceptional procedures of the regulations as usual ones.

• The search of the scapegoat, in order to avoid a deeper analysis of the situation.

In a state of dissonance, managers will avoid information and situations that might increase the dissonance. So they may restore consonance through misperception, rejection or refutation of the information that is incompatible with their beliefs and representations. In this context, this variation, product of variability, is denied in the representations of the managers and the engineers, since these representations interpret this variation like a failure or an error which one should hasten to correct. Moreover, support is sought from others who share the same beliefs, and attempts are made to persuade others, in order to restore consonance. These means allow management to reaffirm already held beliefs and representations rather than reference material that contradicts them.

On the other hand, the resilient management of dissonance consists of exhibiting these two sets of representations, expressing incompatibilities between them, suggesting means to change beliefs, and to restore a common clear and relevant shared understanding of the situation from the two communities (managers and operators). The aim is that all stakeholders, operators as well as managers and designers share the actual states of the system, and how far the actual states of the system are from the specified ones, in order to explain hazardous situation and to reduce the dissonance.

The resilient management of the dissonance is based upon:

• A clear, relevant and shared situation awareness, among all the communities, operators as well as management and regulation, which implies to assess the gap between the specified path and the actual one as usual fluctuations or, on the opposite, the trend of a forecast latent deviation.

• The simulation of possible or incredible accident scenarios, function of the context, and the actual states of the system produced from, on the one hand, an accident cases base, and, on the other hand, field data provided by relevant sensors.

• The consideration of assessed evolutions in order to update the design of the system, comprising safety design (barriers, procedures …) and to restore safety, including the evolutions of the system's environment [START_REF] Bachatène | Adaptability of software intensive systems, facing new threats and opponents new tactics[END_REF].

In this context, we develop two solutions in this article, the first on expressing migration against risk, the second on training to avoid and to cope with unpredictable accidents. Then, we propose to use FRAM to model the variability.

Mistake-proving device for resilient management of dissonance

The first solution is based mostly upon mistake-proving devices, such as one which assesses and expresses to the operators and the managers the gap between both paths, and persuasive technology devices [START_REF] Fogg | Creating Persuasive Technologies: An Eight-Step Design Process[END_REF].

For each most important risk, an HCI panel expresses the risk assessment matrix (table 1), and the actual risk assessment. Since barriers removal, as well as silent migration or normalization of deviance modify the behaviour of the system, actual risk is different from the specified risk. We propose to enlighten this difference and exhibit it to stakeholders. We propose that the panel expresses the migration of the actual risk on the matrix. For instance, barriers removal impacts risk that passes from medium to high. In this context, the first step consists in enhancing the vigilance in order to avoid risk. Then, as a second step, a new risk mitigation has to be done in order to reduce the risk.

Severity

This panel has to be deployed upon operators' workstations as well as upon managers' ones. This solution allows all stakeholders to share a relevant representation of actual risks.

Foreseeable possible or incredible accident based upon simulation

The second solution consists in presenting possible or incredible accidental scenarios to operators and managers (figure 3). The simulation expresses scenarios of possible or incredible accident that may happen, function of the actual path of the system. The simulation enhances the shared situation awareness and gives the opportunity to foresee potential accident.

Accident cases base

Actual field data, including trend drift These scenarios are elaborated from actual field data on the one hand, and the accident cases base on the other hand.

Modelling variability and the gap between specified task and actual activity with FRAM

Both these solutions express the gap between specified task and actual activity, that is quite a huge variability. FRAM [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF] models this variability, and interaction between functions that finish as an accident.

The figure 4 expresses the 'normal' variability [START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF] of the function F3's output, depending on variability of its input (F1) and control (F2). The variability of the function F3's output impacts function F4 since it is one of its inputs.

The main issue is to detect and model the drift from normal variability to 'out-of-range', hazardous, variability that induces accident. The lying "S" expresses resonance or variation within a function that affects its output and, then, the downstream functions.

CASE STUDY: RAILWAY ACCIDENTS ANALYSIS

The application deals with the dissonance management in the railway context. It is based upon the analysis of the Zoufftgen accident report (BEATT, 2009). On October 11 th , 2006, two trains collided head on near of Zoufftgen. Six people died, one was seriously injured and fifteen others had minor injuries.

The report expresses many direct and indirect causes or causal factors of the accident, that are (BEATT, 2009):

• the human error: the Traffic Controller of the Bettembourg Central Control Post (CCP) mistakenly issued the driver of the Regional Express Train an order to pass through the "danger" signal protecting the section of track on which the freight train was travelling;

• the mistake issuing the pass-through order, and which concerns the CCP: the incorrect staff handover procedure just before the accident, the high frequency of signal faults, the poor ergonomics of the available documentation, and the ergonomics of the Visual Control Panel which could be improved;

• the failure of attempts to rectify the situation: incorrectly pressing the radio warning button, delay in implementing the traction power cut-off procedure, failure to transmit the warning to the Thionville Control Post, and the limited capacity of the telephone system at the Bettembourg CCP;

• underlying causes regarding staff skills: insufficient knowledge by the CCP staff of the procedures to be followed, particularly for issuing pass-through orders or for handling emergency situations, and the absence of practical training in emergency procedures;

• the Safety Management System and the regulatory framework of Luxembourg Railways (CFL): unrealistic division of tasks between the Bettembourg CCP staff, lack of encouragement to gain experience and laissezfaire approach to monitoring staff and implementing management control. The Area Manager and his Assistant said that they were surprised at the extent of non-compliant behaviour at shift handovers.

Hazardous management of dissonance contributing to the accident

In many instances, this case study shows that hazardous management of dissonance is implemented.

The report shows normalization of deviant behaviours:

• The Traffic Controller did not carry out all the prescribed preliminary checks before issuing a pass-through order. This omission seemed to occur fairly often at the Bettembourg CCP since the wrong-track working fixed equipment display is not in the Traffic Controller's visual field when he is looking at the check lights for the tracks towards France (BEATT, 2009).

• Written orders to pass through a main fixed signal, a "danger" signal. At Bettembourg, 107 written orders to pass through a Main Fixed Signal were issued over the three-month period, before the accident. The cause was unknown in most orders (BEATT, 2009).

The report shows silent migration, too:

• Violation of staff handover procedure, due to poor procedure usability. At 11h30, the Morning Traffic Controller wanted to leave but the Evening Traffic Controller had not yet arrived. This quite common practice is contrary to the regulations. In addition to the oral handover, the Morning Traffic Controller gave a sheet of "scrap paper" to the Evening Train Announcer (BEATT, 2009).

• Lack of separation between traffic management activities and ordering food activities, in order to prepare lunch. It is a hidden dual-task consuming attention resources to the detriment of the traffic control activity (BEATT, 2009).

The report shows impacts of factors of context:

• Poor usability of the visual control panel. There are two different meanings expressing track availability (BEATT, 2009).

• Poor usability of regulation books. The book prescribing handover procedure exhibits a poor usability, staff members didn't read the procedure and developed their own one (BEATT, 2009).

• High frequency of signal faults. It is not unusual that the main fixed signal fails to set at "proceed" when a route command is made (BEATT, 2009).

• Low reliability of the devices attempting to rectify the situation. The radio warning signal failed, due to a hidden fault on the device (BEATT, 2009).

• Lack of knowledge about the traction power. "The CCP staff did not know that the button to cut off traction power only operates on the marshalling yard track and has no effect on the main tracks" (BEATT, 2009).

• Lack of efficient communication at the staff handover (quality of the communications between operators) (BEATT, 2009).

Modelling interaction of the variability generating the accident with FRAM

These elements are modelled using functional resonance method. The figure 5 expresses the interaction of the variability, using the functional resonance analysis method. The pass-through order, which is the output (O) of the traffic control activity, is induced by many elements, the violation of staff procedure (C: control), the lateness of the evening traffic controller (T: time), the insufficient check (P: precondition), and, mostly resources (R: resources) difficulties, dual task reducing attention resources, high frequency of signal faults, poor usability of procedure(s) and HCI.

The managers and the operators didn't share a common situation awareness of the activities as done, at Bettembourg, generating dissonance between representations and beliefs of these two communities. The managers didn't know the extent of non-compliant behaviour at shift handovers (BEATT, 2009). Normalization of deviance as well as silent migration were the usual hazardous management of dissonance at CSF. No one was able to detect that the adaptive capacity limits were reached, nor to estimate the system position with regard to the danger zone. There were neither safety margin nor tolerance capability.

In this context, both the avoidance (issuing a pass-through order) and the resistance (attempting to rectify the situation) functions of the resilience failed.

On the opposite, the resilient management of dissonance would satisfy the functions of the resilience, mostly avoidance and resistance in order to estimate the actual position with regard to the danger zone.

Mistake-proofing device restoring the capability to visual piloting for resilient management of dissonance

The avoidance function consists of restoring the capability to visual piloting, rather than piloting without visibility (silent migration and normalization of deviance). It consists in detecting the trend and expressing the gap between the specified task and the real activity. A clear and relevant situation awareness must be shared among all the actors of CSF, operators as well as managers and regulation (Ruault et al., 2012a[START_REF] Ruault | Persona pour la conception de systèmes complexes résilients[END_REF]. This clear shared situation awareness is based upon feedback from field, expressing the gap between specified procedure and done activity. This shared situation awareness lays on the presentation of the actual risk face to the specified risk. This normalization of deviance may be expressed using risk assessment matrix. Written orders are exceptional barriers removal that have to be used in situations where an accident is improbable. Such trends, as issuing written orders have to be detected, expressed to all stakeholders in order to be fixed. From step to step (table 2), few written orders were used in situations where an accident is remote (1), then more written orders were used, reaching occasional likelihood (2), then more and more written orders, around 100 written orders per month, reaching probable likelihood (3), passing from medium risk to serious risk, then high risk. The visual display expresses explicitly this migration.

Expressing foreseeable possible or incredible accident to operators

The avoidance function is based upon a simulation that expresses to operators the accident that should happen within the actual context. This simulation complements the visual display expressing explicitly the current migration. It is based upon field data and accident cases base. It matches the field data, such as written orders, with the accident cases and expresses incredible and unpredictable accident to operators.

The resistance function consists of maintaining the capability to rectify the situation. It relies on secure equipment reliability, such as radio. It is based upon relevant and well known skills to cut off traction power, knowing the perimeter and the limits of the button (marshalling yard track), to phone to the operators who are able to cut off the traction power.

The resistance function has to be efficient along track between Bettembourg and Thionville, whatever the location of the train.

CONCLUSIONS

To adjust to disturbing events, to cope with unforeseeable conditions, resilience capacity is based upon the dynamic process of "visual piloting". There is always a difference between the specified task and the done activity. This gap generates dissonance between beliefs and representations. In many cases, such as silent migration or normalization of deviance, management of dissonance is hazardous and does not avoid accident. The proposition of this article deals with a resilient management of dissonance that allows expressing this gap and enhancing shared situation awareness in order to restore visual piloting capacity. The case study illustrates the management of dissonance in the context of railway accident. The case study addresses silent migration and normalization of deviance contributing to an accident.

FRAM differentiates 'normal' variability and 'out-of-range' variability, but does not model the trend, the drift, nor these two kinds of variability. It will be a key issue to enhance FRAM in order to model trend and express these two kinds of variability.

This first step, enhancing visual piloting, has to be completed with a second step in which the gap has to be taken into account. That means upgrading the system function of the new environment conditions and the identified trend, modifying the safety device, both physical, functional as procedural, and evolving training, in order to implement a culture of safety.

This after-the-fact approach is the first step in order to prepare an open-ended experiment. We will compare the dissonance engineering approach with other ones in order to highlight its relevance in a resilient perspective.

Fig. 1 .

 1 Fig.1. Functional representation with FRAM[START_REF] Hollnagel | FRAM: The Functional Resonance Analysis Method[END_REF].

  Fig. 2. Specified and actual paths of a sociotechnical system.

Fig. 3

 3 Fig. 3 Foreseeable possible or incredible accident.

Fig. 4 .

 4 Fig. 4. Generic example of functional resonance analysis method.

Fig. 5 .

 5 Fig. 5. Functional resonance model of the accident.

ACKNOWLEDGEMENTS

The present research work has been supported by CISIT (International Campus on Safety and Intermodality in Transportation), the Nord-Pas-de-Calais region, the European Regional Development Fund (FEDER), and the GDR E Hamasyt (European Research Group on HumAn-MAchine SYstems in Transportation). The authors gratefully acknowledge the support of these institutions.


Arnaud Brossard
email: arnaud.brossard@univ-valenciennes.fr

Mourad Abed
email: mourad.abed@univ-valenciennes.fr

Christophe Kolski
email: christophe.kolski@univ-valenciennes.fr

Context Awareness and Model Driven Engineering: A Multi-Level Approach for the Development of Interactive Applications in Public Transportation

Keywords: Context Awareness, Model Driven Engineering, Public Transportation

Model Driven Engineering (MDE) is becoming today the new paradigm in applications development. Concurrently to that, with the generalization of mobile computing, the notion of context awareness needs to be taken into account in more and more applications. The problem is that integrating context awareness in a MDE approach is not strait forward. In this paper, we will show our solution to integrate them by using a multilevel approach for the notion of context awareness and an adaptation of the classic Model Driven Architecture (MDA) through the use of multilevel frameworks.

Introduction

Today, and in particular in the field of public transportation, interactive applications should be multiform by being able to adapt themselves to different platforms but also to their context of use [START_REF] Schilit | Context Aware Computing Applications[END_REF]. This involves an increasing technical complexity which seek to manage the Model Driven Engineering (MDE) approaches [START_REF] Favre | L'ingénierie dirigée par les modèles[END_REF] [START_REF] Schmidt | [END_REF]. And if today, there are numerous researches in context awareness and MDE fields, very few establish explicit links between them. In this paper, we will show that, in a MDE approach, the context should not be taken into account only at the conceptual level but at all levels of the architecture.

Model Driven Engineering (MDE) and Context Awareness

2.1

Model Driven Engineering The purpose of Model Driven Engineering [START_REF] Schmidt | [END_REF] is to allow the automatic generation of applications by defining conceptual models and more specifically by assembling conceptual models. For doing that, MDE is based on a three levels MDA 1 1 MDA: Model Driven Architecture architecture (OMG, 2001) which allow to convert the conceptual models to the final application throw a succession of models transformations (cf. figure 1).

Figure 1. The Model Driven Architecture

In this paper, and by referring us to [START_REF] Brossard | Modélisation conceptuelle des IHM : Une approche globale s'appuyant sur les processus métier[END_REF], we will use, by extension, the term of business process to characterize the conceptual models of the CIM level of the MDA architecture.

Context Awareness

The concept of context, in the field of interactive applications, was defined by [START_REF] Dey | Towards a Better Understanding of Context and Context-Awareness[END_REF] as following: "Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves." Using similar definitions, some other works have tried to characterize the context [START_REF] Schilit | Context Aware Computing Applications[END_REF] [START_REF] Gross | Awareness in Context-Aware Information Systems[END_REF]. For this paper, we have retained those of [START_REF] Thevenin | Plasticity of User Interfaces: Framework and Research Agenda[END_REF] which propose a vision of the context using three dimensions: user, environment and platform.

Context adaptation and MDE: a multi-level approach

3.1

The characterization of the three dimensions of context When developing interactive applications, each dimension of the context can be characterized by several elements. Thus, the user could be characterized by:

-Explicit properties (name, address, job, …).

-Interests and preferences which are used to specify his/her tastes and goals (for instance: "I rather would use the bus than the subway", …). -Information about his/her mind state, emotional states (traveler in a hurry, sleeping traveler, …). -… The environment could be characterized by:

-Time (for instance: morning, evening, public holiday, …) -Geographical space (for instance: the type of space like a station or a store, …).

-Others stimulus linked to the physical environment (luminosity, noise, …).

-… The technical platform could be characterized by:

-Specific technical elements (all the interaction possibilities, screen size, …).

-A platform level type, which allow to aggregate different platforms inside units having a certain number of characteristics in common from the interactions point of view. -… This multiform characterization of the three dimensions, which is far from being exhaustive and this paper, involves a very significant number of possibilities of different contextual adaptations; quite apart from the fact that the various elements characterizing each dimension could interact with each other. It is all this complexity and all the possibilities that need to be managed inside a MDA type architecture, which is the foundation of any MDE approach.

3.2

Context and MDA architecture In a classical MDE approach, the whole application must be defined at the conceptual level and each contextual adaptation should be defined there. However, this is not always coherent. Thus, if one takes the automatic adaptation of the platform to the luminosity, this one is dependent on the technical possibilities of the platform like its capacities to collect the external luminosity and to regulate the luminosity by programming. That is why it is not relevant to define this kind of adaptation in the conceptual level, all the more it will be necessary to take into account this adaptation in all the applications. In fact, it will be more efficient to let the platform do this adaptation automatically and thus to integrate it to the PSM level. In table 1, we present our vision of the management of context elements in a MDA architecture. 4 Case study: Contextual adaptation of a traveler's information system in public transportation

General introduction to our approach:

To be able to use the multilevel approach of context awareness as shown in 3.2, we propose to use an adaptation of the classic MDA architecture as presented in the figure 2. It is important to point out that our architecture is, for the moment, only able to manage classical interactive applications of WIMP (Window, Icon, Menu, Pointing device) type.

Figure 2. Our proposal for the MDA approach adaptation

In our proposal, which is described in details in [START_REF] Brossard | Modélisation conceptuelle des IHM : Une approche globale s'appuyant sur les processus métier[END_REF], the conceptual models are defined using different specific models, which allow to modelize the application and its environment. In these models, the main model is the Business Process Model, which uses the other models to define, from the business point of view, the processes associated to the application. These conceptual models are designed relying on a whole set of functional services defined at the CIM level which will be presented in details in 4.2. These services are developed within a parameterized framework using rules to allow a quick adaptation of the behavior of each service. The transformation from the level PIM to the level PSM uses a two levels framework. The first one allow to take into account all the specificities common to all the platforms from a specific family like the Personal Digital Assistant (PDA) family. The second one, specific to the final platform, such as for example a PDA color under Palm OS, allow to adapt the application to the specificities of each final platform. The PSM frameworks are used to translate the PIM services to PSM services and to transform the conceptual interactive elements into concrete interactive elements. Thus, while passing by PIM framework, an element of the conceptual type text field, for example, could be translated into a dropdown list or a field text according to the rules associated with each framework at the PSM level. It is also at the PSM level that we introduce information relating to the physical positioning of the various graphical elements and to their presentation (color, form, an so on). As for the PIM level, the rules defined at the PSM level are used to allow a quick adaptation of the PSM framework.

4.2

First example: Context awareness at the CIM level In this example, we will show how the context of use of a business process could be taken into account in our approach. For defining the business processes, we use a specific notation directly derived from the Business Process Modeling Notation [START_REF] Bpmi | Business Process Modeling Notation version 1[END_REF]. The business process used in this example is quite simple: it is the process associated to the purchase of a train ticket (cf. figure 3). This main process contains three sub-process: the first one allows the user to search for and select a trip, the second one is associated to the payment validation and the third one is linked to the payment confirmation.

Figure 3. The Business Process associated to train ticket buying

In our example, the main process is the same for all users whatever the place where the user is (at home, at the station, in the train, …). As the user still need a concrete ticket to take the train, he always needs to print is ticket in a Self Service Terminal at the railway station but the payment confirmation sub-process is not the same depending on the context of use of the process. Thus, if the user buys his train ticket directly at the Self Service Terminal at the railway station, he/she receives the payment confirmation on a small ticket otherwise he receives an email (cf. figure 5) and should go to a Self Service Terminal to pick up is ticket. For being able to do that, the payment confirmation subprocess should be able to take into account the context of use and more specifically it should be able to know if the user uses it on a Self Service Terminal or on another place. For doing that we should define into the sub-process a selection step which allows us to evaluate the context (cf. figure 4). This is done by the evaluation of a specific rule "UseSelfServiceTerminal" which could return only two values: "Yes" if the process is used on a Self Service Terminal and "No" otherwise. If the result is "Yes", the Self Service Terminal prints the ticket and a payment receipt. If the result is "No", an email is sent to the user.

4.3

Second example: Context awareness at the PIM level At the PIM level, the notion of context awareness is taken into account through the PIM Framework witch contains all the technical and functional services that could be used explicitly or implicitly at the CIM level. An implicit service is a service used by the application which is not taken into account in the business processes defined at the CIM level. For example, the session management is an implicit service: all applications use it to manage the user session and it does not have to be defined explicitly at the CIM level to be used. An explicit service is a service which could be used in a CIM model but does not have to be defined at the CIM level. For example, the personalization of information returned by user requests has not to be defined as the CIM level. The only thing which it is important to defined at the CIM level is the kind of personalization (by country, by user preferences, …) and not the personalization process itself. As at the PIM level all the services are defined through the PIM framework, the notion of context awareness could be taken into account at two places. At first, inside the framework and more exactly inside the service itself where we could use context information to define different behaviors for a same service. Or, through the definition of rules where we could define the use of different sub-services depending of the context of use. In our example, we will show this second option through the definition of two different music request services regarding the user localization: inside a vehicle or outside a vehicle. If the user is outside a vehicle, each request will go directly to the application server (cf. figure 6) and the user will use a service called "DirectMusicRequest". If the user is inside the vehicle, the request will go the embedded server and if anything is found, the request will be transmitted to the application server (cf. figure 7) and the application will use a service called "EmbeddedMusicRequest".

4.4

Third example: Context awareness at the PSM level Today some mobile devices contain sensors, which allow them to catch some information about their environment (sound, luminosity, geographical localization through GPS). Some contextual adaptations could be done automatically by the platform like, for example, the automatic adaptation to the external luminosity on the notebook "MacBook Pro" from Apple Inc. Otherwise, the information given by the sensors could be used in the PSM framework to do some automatic adaptation. For example, if the user uses an application which guide him/her to his/her next connection inside a railway station, we could define, if we have a speed rate sensor on the user platform, inside the PSM framework that the font style used for the current location will not be the same if the user is moving slowly or if he/she is moving fast or even running (cf. figure 8). In this example, the choice made of managing the context at the PSM level is relevant if the information about the user speed could be only available for one or two platforms and if this information will not be used as a criteria at the CIM level. In fact, for each contextual information, an analysis have to be done to define the level where the information about the context will be managed. As the results of these analysis are linked to the business domain and more explicitly to the company for whom the application is programmed, there is no good and bad choice as far as the contextual information is not managed concurrently at two different levels. It is probably one of the key points of our approach but one of its drawback as it will not be easy to manage the evolution in time of each contextual information: management at the PSM level and then, after a while, at the CIM level. One of the solutions to avoid this drawback could be to manage all the contextual information at the CIM level but it will introduce more complexity in the models and less flexibility without allowing to manage some technical adaptations like those presented in 4.3. In fact, the choice of the management level is a balance between all this constraints and limitations and, for us, it is itself a very interesting research area.

Figure 4 .

 4 Figure 4. The contextual adaptation of the payment confirmation process

Figure 6 .

 6 Figure 6. The standard technical architecture (service DirectMusicRequest)

  Figure 8. Adaptation to the user moving speed: slowly moving (a) or fast moving (b)

Table 1 .

 1 Management of context elements in a MDA architecture MDA

Level Examples of Context Elements CIM

		-Use of local information to automatically adapt the application to the
		context of use without calling a specific business process (Examples:
		automatic choice of a screen presentation type like Windows XP style or
		Mac OS style, automatic adaptation of the platform to the luminosity, …).
	PSM	-Definition and characterization of the sensors and the actuators
		associated with the contextual adaptation: What can the sensor measure?
		How? Which are the different valid values? And, if one can not make a
		measure how is the context element taken into account (default value,
		users choice, specific process associated to the platform, …) ?

-Conceptual characterization of the context elements (for instance: definition of geographical spaces like stations or cities, definition of the platforms levels, …) -Use of the characterization in the business processes (Example: a buying business process of transport document differentiated according to whether the user is in a railway station or in a subway station) PIM -Choice of different generic technical solutions according to the context (Example: technical solution of purchase validation different in a station than in a train)

Conclusion

The future of interactive applications, in particular in the field of public transportation, will need, most probably, a closer integration between MDE approaches and contextual adaptations. As we have seen in this paper, this integration should not be made only for conceptual models but for all the levels of the MDA architecture. In fact, it imposes an adaptation of the architecture through an enrichment of the PIM and PSM levels. But, it implies also a new grid for the analysis of contextual elements in order to split up their adaptation in the three MDA levels. It is certainly the most important point to succeed, in the future, the perfect integration between MDE approaches and contextual adaptation.

Aknowledgment

The present research work has been partially supported by the "Ministère de l'Education Nationale, de la Recherche et de la Technologie", the "Région Nord Pas-de-Calais" and the FEDER (projects MIAOU, EUCUE, SART), the ANR ADEME (Viactic.Mobilité). The authors gratefully acknowledge the support of these institutions.