Vincent Rossignol
email: vincent.rossignol@ansys.com

Francois-Xavier Dormoy
email: francois-xavier.dormoy@ansys.com

A Deterministic Approach for Embedded Human-Machine Interfaces (HMI) Testing Automation

Keywords: Embedded, Software, HMI, Model, Tool, Verification, Testing, Automation, SCADE

Human-Machine Interfaces (HMI) have become a central piece of most embedded control systems in many industrial domains. New design techniques have aroused, speeding up the development phases, but the thorough testing of embedded HMIs today remains a largely human-based, time-consuming and error-prone task. During the last decade, many improvements in control software testing. have been made, but HMI testing is still an area where companies are looking for industrial solution helping them to reduce their cost thus securing their project. This paper presents an innovative embedded HMI testing approach, which aims at reducing the time spent on HMI verification phases, by automating test creation and test results comparison, while ensuring a very high level of determinism and reproducibility.

Introduction

Human-Machine Interfaces (HMI) have become a central piece of most embedded control systems in many industrial domains as illustrated in Figure 1 bellow.

From pure "displays", where the objective was to synthetize and display on screen information coming from the system(s) to the operator (pilot, driver, operator), they have also become more and more interactive, with additional means to send commands and orders to the system, via interactive media such as mice, trackballs, keyboards or tactile screens.

While new design techniques have arousedsuch as model-based HMI software designallowing to considerably speed up the development of embedded HMIs, the thorough testing of embedded HMIs, mandated This paper presents an innovative embedded HMI testing approach, which aims at reducing the time spent on HMI verification phases, by automating test creation and test results comparison, while ensuring a very high level of determinism and reproducibility. The innovation lies in the foundation of our approach relying on synchronous clock based approach ensuring determinism of the execution.

Current practices and State of the art

Current practices

HMI verification and validation (V&V) is the process of evaluating HMI software to verify whether they satisfy the requirements, and ensure that they are bug-free.

In the industry, still today most of the HMI V&V activities are done manually on the target platform as it is well described in a recent PHD Thesis [START_REF]Visual GUI Testing: Automating High-Level Software Testing in Industrial Practice : Emil Alegroth PhD Thesis for The Degree of Doctor of Philosophy[END_REF]. Testing is performed following test procedures with manual interaction with the HMI under test and checking with human eyes that behavior and rendering are correct according to requirements. These practices are very time consuming and not attractive for test people when the same test campaign needs to be done several times for each HMI intermediate release (or standard).

State of the art

There are several known GUI V&V techniques (e.g., model-based testing, static analysis) to ensure the quality and reliability of GUIs. They have been developed to find failures that affect GUIs or to measure the GUI code quality. The most used technique to measure the quality and reliability of GUIs is testing. Testing GUIs aims at validating whether a GUI has the expected behavior: Does the GUI conform to its requirements specification? Most of GUI testing approaches focus on automated GUI testing to provide an effective bugs detection [START_REF] Aho | Murphy Tools: Utilizing Extracted GUI Models for Industrial Software Testing[END_REF], [START_REF] Nguyen | GUITAR: an innovative tool for automated testing of GUI-driven software[END_REF], [START_REF] Mariani | AutoBlackTest: A tool for automatic black-box testing[END_REF] but as stated in [START_REF] Aho | Murphy Tools: Utilizing Extracted GUI Models for Industrial Software Testing[END_REF] "so far none of the academic approaches and tools has been adopted by the industry to test commercial software products"

The main reason is because model-based GUI testing solutions rely on surrogate HMI models of the real HMI to drive the test case generation. Crawler approaches or any other approaches may be used but then the reliability of the testing depends on the reliability of the test model. This Crawler approach is generally an issue, when extracting models at runtime (e.g. Murphy [START_REF] Aho | Murphy Tools: Utilizing Extracted GUI Models for Industrial Software Testing[END_REF] or Guitar [START_REF] Nguyen | GUITAR: an innovative tool for automated testing of gui-driven software[END_REF]) due to problems of the extraction.

Anyway, all approaches requiring building the HMI model are complex [START_REF] Lelli | Classifying and qualifying gui defects[END_REF] and time consuming in operational usage. Furthermore, in industrial usage, maintaining the consistency between this surrogate model and the actual HMI under test is difficult or impossible during all project lifecycle.

Our Contribution: Deterministic HMI Testing Automation

To avoid the main drawback of crawler approaches (or any surrogate model usage), we propose in this paper to use the original model (the actual model used to produce HMI) for testing purpose.

The first pre-requisite for that approach is to rely on model-based development approach where the final HMI is automatically generated out of the model. When automatic code generation is complete (no line of code remains to be written to develop the HMI) and is qualifiable according to DO-178B/C, EN 50128, IEC 61508 and ISO 26262, we can then focus activity on the Model.

In addition to review and analysis, safety standards like DO-178C [9] require dynamic verification. Simulation (or model testing) can be used as a means for verifying compliance of models to their higher-level requirements and algorithm accuracy. We propose to use simulation to achieve HMI Testing.

Our approach is relying in three important steps which are explained in more detail in the next paragraphs:

1. Test execution on host (Model Simulation on development computer) (section 4) 2. Model Coverage (Dynamic analysis methods to check completeness, reachability of the model) (section 5) 3. Test execution on target (Testing of the executable object code on target hardware environment) (section 6)

During simulation, testing is about setting inputs of the HMI under test using traditional cyclic approach and observing HMI behavior and rendering to assess its correctness with regard to its requirements as described below in Figure 2.

When talking about inputs, not only the functional inputs need to be considered, but also all the data relative to user interaction. Indeed, the pointing device(s) data (pointer position, button, pressed/released, etc.) and keyboard device(s) data (keyboard key, pressed/released, etc.) must be considered as HMI SUT inputs.

In a similar way, for HMI systems, the outputs of the HMI SUT not only are the functional outputs. A key output of such HMI SUT is the "rendered image" itself, which is quite specific with respect to other systems. This indeed represents what the operator sees (with his eyes), and this output also must be considered for testing.

Atif M.Memon [START_REF] Atif | Automated testing of GUI applications: models, tools, and controlling flakiness[END_REF] stated that "Specialized tools are needed to generate and run test cases, models are needed to quantify behavioral coverage, and changes in the environment, such as the operating system, virtual machine or system load, as well as starting states of the executions, impact the repeatability of the outcome of tests making tests appear flaky" showing well the difficulties to have deterministic test case execution.

Because we are addressing safety critical GUI, test case execution determinism is not an option and furthermore it has to be consistent with target execution. So how can we build an approach where test execution will behave in the same way on all machine and for instance system load does not impact repeatability (determinism) of the outcome of tests? This is the condition to rely on the output of the test execution, when it says that the test is passed.

The deterministic testing approach described in this paper takes root in the SCADE® model-based design paradigm for HMIs, and its underlying formally defined language. We decided to bind our testing approach to the cycle-based execution model of SCADE to ensure functional determinism.

The cycle-based execution model of SCADE -SCADE Display combined with SCADE Suiteis a direct computer implementation of the ubiquitous sampling-actuating model of control engineering [START_REF]Testing and maintenance of graphical user interfaces: Valéria Lelli Leitão Dantas[END_REF]. It consists in performing a continuous loop as illustrated in Figure 3.

In this loop, there is a strict alternation between environment actions, including user interactions, and program actions. Once the input sensors (or interactions) are read, the cyclic function starts computing the cycle outputs, including the drawing of the rendered image. During that time, the cyclic SCADE function is blind to environment changes. When the outputs are ready, or at a given time determined by a clock, the output values are fed back to the environment, the computed image is rendered on screen, and the oracle checks can then be performed, then the program waits for the start of the next cycle.

An HMI designed as a SCADE model can be executed according to the cycle-based approach. It can thus be tested with the same approach:

HMI SUT

Functional inputs

Pointing and keyboard device(s) data

Functional outputs

Rendered image Feed the inputs (including user interaction)

Scope of SCADE

2.

Execute the display computation cycle

3.

Observe/check the outputs (including the rendered image)

This cycle-based approach for SCADE generated HMI execution is not only key to ensure determinism of the interactive HMI application itself, but also to set up a deterministic and reproducible testing strategy. Unlike most other HMI design frameworks and tools which rely on surrogate models, the same test scenarios will always lead to the same execution sequence and obtained results (both functional outputs and rendered images), whichever the operating system and target platform, given the same HMI model.

Following this approach, we have defined a testing language with the following characteristics:

• Modularity: allowing dedicated initialization or preamble sequences as well as re-useable test scenarios in test procedures

HMI Host Testing and graphical oracles

Test execution on host is the first step of our proposed approach. The main benefit is early testing in the left side of the V model [START_REF]Combining Model-Based Testing and Stepwise Formal Development Qaisar Ahmad Malik SBN[END_REF]. The objective of this step is to verify that the HMI model complies with its requirements.

Figure 4: Example of Test Scenario

To achieve this goal, our HMI testing methodology needs to provide a way to check that the GUI application is working as expected. In the proposed approach, both the "rendered images" and the SCADE model "functional outputs" / graphical properties constitute the expected results of the HMI tests. Because HMI test needs to be requirements based, choice between functional outputs or bitmaps are driven by requirements. When requirements are about interactive functional behavior functional outputs are checked. When requirements are about graphical rendering of an image or part of the image, bitmap checking is done.

For rendering Oracles we propose to focus on some parts of the image relative to the requirements under test as depicted in Figure 5.

Figure 5: Illustration of identified part of image comparison

For this purpose, image filtering capabilites have been integrated into our testing environment in order define areas where image comparison must be done according to the requirements.

This allows to check parts of the HMI images by defining mask images with exclusion and inclusion areas. The mask image has the same dimensions as the original HMI image and uses the following color coding: inclusion areas are drawn in white color and represent zones in the HMI image that have to be checked by image check instruction. In contrast, exclusion areas represent zones in the image that have to be ignored by image check instruction and are drawn in any other color but white.

Image Oracle production

We assume that a "reference" image is given in the requirements but in general images in requirements are far from the actual image rendering. In industrial projects, we noticed that a first version of the GUI application is often used to produce "reference" images. Of course, these captured images are reviewed against requirements but then constitute a well-defined reference image. This is the reason why SCADE Test provide a way for a Tester to record a test scenario while he is executing a test procedure. During this test recording he can pause and add any Oracle (Value comparison or filtered image).

Any graphical property of any graphical object within the SCADE Display model can be checked. When a requirement relates to the appearance of a graphical element on the screen (e.g. the color of a LED), the V&V engineer is able to check, at any cycle of the test scenario, an expected value for the "color" property of the circle representing the LED.

This approach is supported by extending current capabilities of the SCADE Test Environment tool to HMI intensive applications. The SCADE Test Environment is an integrated environment for V&V engineers to automate both the creation and management of test cases, run the test cases created from the High-Level Requirements (HLR), and automate the generation of conformance reports as illustrated below in Figure 6. With our approach, we propose to define HMI test scenarios (our tooling is helping in the area) using a simple language we have defined and automate execution on host ensuring execution and results determinism. A conformance (Passed/Failed) report is then automatically produced at the end of execution. In Result column, a Ratio of differences is provided. 0.00 means no differences. In the first line with Failed Red rectangle 0.032 is the ratio of error between Expected and Actual image.

Image Comparison Algorithm

The ratio computed for image comparison results is based on a specific algorithm that computes the average distance (in terms of color) for each pixel of the image. The resulting ratio ranges from 100 (all colors different) to 0 (no color differences).

Let 'n' be the number of pixels of an image and 'i' the index of those pixels. Let r1i, g1i, b1i (red, green, blue) be the colors of each pixels for the image to compare and r2i, g2i, b2i the ones for the reference image. The following expression is used to compute the difference between two images in percent:

In addition, the image comparison builds the image showing differences based on the differences of each color pixel using the following expressions:

Introduction to HMI Model Coverage

Once you've run your test cases and checked that all have passed on Host, meaning that the software behaves correctly with regard to requirement you generally have to answer this question: Have I have made enough test cases and caught all existing errors? Model-level coverage is the known way to measure whether the set of test cases you created covers the whole model according to a defined criterion.

Model coverage analysis should not be confounded with structural [code] coverage analysis. Model coverage analysis concerns the low-level requirements expressed by a model, and is at a higher level of abstraction than structural coverage analysis. Model coverage analysis concerns the functional aspects of the model regardless of the code that implements this model, which structure is highly dependent on the coding technique. Also, the code coverage criteria that are required by standards and supported by tools are limited to control structures and Boolean expressions: they do not address very important functional aspects such as the Definition and Use of data.

As we did for SCADE Suite (Control Software) we are currently defining criteria for HMI model coverage. HMI model coverage measures the activity of a model in terms of graphical object drawing and the following criteria apply:

• All graphical object must be drawn

Target Testing

Target testing is the final and most important goal for testing activity. Because HMI software can run in a wide variety of target environments, the test execution infrastructure must adapt to a range of hardware targets.

The objective is to run all the test cases that were previously written and executed on the host (see Section 4) on the target hardware environment.

This approach is deployed since many years for control software (SCADE Suite) but innovative for HMI. The difficulty is not in target execution but more on target image rendering checks. Several possibilities exist:

-Target test harness may perform the whole bitmap comparison but then some sizing limits may be reached -Image comparison is made on host thanks to communication between host and target implemented in TDP (Target Deployment Port)

This last part represents an ongoing work we are currently partnering with tool providers experts in target testing environment. Details of this work cannot be disclosed for now.

Conclusion and Future Work

The extension of the SCADE Test Environment for SCADE generated HMIs combines a cycle-based HMI testing approach enabling a deterministic testing execution framework with the automation of a large part of the testing process itself: automatic bitmap production, automatic replay of test scenarios, automatic conformance results generation from both image comparison and functional results checks. This shall result in significant time and cost savings over manual verification strategies for embedded HMI applications.

Future areas of interest for SCADE-based HMI testing automation include: extensive reuse of HMI test scenarios on the target platform, model coverage analysis from the same set of test scenarios, and extension of the test environment to the ARINC 661 HMI design paradigm, for which dedicated SCADE Solutions for ARINC 661 are particularly fitted.

Figure 1

 1 Figure 1 Airbus A 380 Cockpit

Figure 2 :Figure 3 :

 23 Figure 2: The HMI System Under Test

Figure 4

 4 Figure 4 illustrates an exemplary test scenario which is written in the testing language: SSM::set Altitude 0.0 SSM::set AltitudeValid 0 SSM::set DisplayMode 3 SSM::cycle 1 SSM::cycle 1 SSM::set Altitude 20.9449462890625 SSM::cycle 1 SSM::set Altitude 10.47003173828125

Figure 6 :

 6 Figure 6: Illustration of conformance (Pass/failed) report

Figure 7 :

 7 Figure 7: Calculation of image comparison result.

Figure 8 :

 8 Figure 8: Calculation of Image Differences

  • Readability: offering both tabular and textual formats, which eases test reviews • Observability: allowing to define expected-results checking including invariant checking and accuracy tolerance customization (per data or data types) • Implementation naming free: ensuring independence from the SCADE model implementation with alias mechanism for associating requirements names to implementation names; then, reducing expensive rework for interface changes and facilitates test data maintenance. Root element of the test language is a test procedure. A test procedure identifies the HMI SUT and a list of records containing a list of test cases. A so called Test Case Record contains a list of test scenarios together with the corresponding test instructions. All test scenarios in a Test Case Record are executed in sequence. This sequence may start with initialisation section or preamble section.

Test scenario is then a sequence of:

• Input setting (can be device pointer for interactive Display) using [SSM::set] instruction • Check request (check of expected values is done after cyclic execution) using [SSM::check] instruction] • Cycle execution (1 or n) using [SSM::cycle] instruction

  • Activation of priorities (call to the top-level drawing function) • Activation of objects (enable/visible/maskActivity) • Activation of children of conditional container (switch-case) • Activation of parametrized part of objects: outline, fill, texture • Activation of parametrized appearance states: halo, modulate, polygon smooth, Once the test cases are created and executed on the host, the objective of the SCADE Test Model Coverage is to provide the capability to measure the model coverage of all test cases.Model-level coverage analysis can show how thoroughly the HMI model has been tested by software requirements-based tests. The analysis pinpoints each test case's role in covering the SCADE model, especially valuable in efficiently correcting errors in the software design. Resolution enables correction or justification for all uncovered parts, pinpointing any shortcomings in requirements-based test procedures, software requirements inadequacies, dead software parts and "deactivated" software parts.

Glossary

GUI:

Graphical User Interface


Philippe Blache
email: blache@lpl-aix.fr

Dialogue Management in Task-Oriented Dialogue Systems

Keywords: Human-centered computing → Natural language interfaces; Task-oriented dialogue, Common Ground, Inference, Dialogue management

This paper presents a new framework for implementing a dialogue manager, making it possible to infer new information in the course of the interaction as well as generating responses from the virtual agent. The approach relies on a specific organization of knowledge bases, including the creation of a common ground and a belief base. Moreover, the same type of rules implement both inference and control of the dialogue. This approach is implemented within a dialogue system for training doctors to break bad news (ACORFORMed).

the entire knowledge, including the information to be delivered as well as the way the doctor is supposed to deliver it. Moreover, at the difference with an actual conversation, the agent only reacts occasionally with specific types of productions: backchannels, emotions, clarification questions and answers to doctor's questions. The role of the dialogue manager is then to identify what type of production to trigger as well as generating its contents.

KNOWLEDGE ORGANIZATION

The management of task-oriented dialogue systems relies on different sources of knowledge: the description of the context, the evolution of the information instantiated during the interaction as well as the respective beliefs of the stakeholders of the dialogue. We present in this section the characteristics of these knowledge bases.

The Universe of Interpretation

From the perspective of the doctor, the information has to be delivered according to certain requirements and recommendations [START_REF] Schnebelen | Annonce d'un dommage associé aux soins[END_REF], and is organized around three different phases: greetings, damage description, remediation. The doctor has a complete knowledge of the context, the degree of severity, the risk, etc. The agent also has access to the same knowledge. Figure 2 presents a subpart of the knowledge base describing an intestinal perforation that occurred during a surgery for polyp resection. All different events are represented as an attribute-value pair.

In the case of a human-human conversation, information updating consists in building a shared knowledge, called "common ground" [START_REF] Allan | What is common ground?[END_REF][START_REF] Clark | Using language[END_REF][START_REF] Stalnaker | Common ground[END_REF], made of what is supposed to be known by all stakeholders. The task consists in adding new information (the increment) in relation to an item of the common ground (the anchor). In this common knowledge base, many information is also presupposed or can be inferred incrementally. What is specific to the common ground is that all participants suppose the others also have access to the same knowledge. In the case of a training dialogue environment, the context, the scenario and the recommendations are already known by the system (i.e. the virtual agent) before the interaction (this fact is hidden to the trainee). The evolution of information transfer from the doctor to the patient, instead of an updating mechanism, simply comes to specify in the knowledge base what has been transferred. As a consequence, the system knows at any time what has been updated and what remains to be instantiated. We distinguish the three types of information that constitute the knowledge base:

• The universe of discourse: what is actually known by the system and the trainee. We propose in the following to precise our knowledge organisation taking into account these specificities.

Different Point of Views, Different Bases

The particular situation of a training environment necessitates to distinguish and precise different types of information concerning knowledge and beliefs from the doctor and the patient.

First, at the difference with natural interactions, the discourse universe is a closed word in the logical sense: it is fully specified and all information that does not belong to the universe is considered to be false. This renders possible not only to reduce ambiguity and uncertainty, but also to control drastically the possible inferences. Concretely, a complete knowledge base is created, containing the general medical knowledge, the scenario of the specific damage to be announced and the way the damage has to be announced (the different phases and their contents). This constitutes the complete universe of interpretation and control of the dialogue. As mentioned above, the particularity here is that the trainee and the virtual agent have both access to what we call here the knowledge base.

Besides this global knowledge, it is necessary to create and update a base of what the trained doctor thinks the patient knows or believes. This type of knowledge is overt for both stakeholders, human and virtual and corresponds to what is usually considered as the common ground. In this application, the common ground is a subpart of the knowledge base, representing in fact what the doctor believes the patient knows.

Finally, from the patient (i.e. the virtual agent) point of view, it is also necessary to create and update, besides the common ground, a specific belief base consisting in inferences from the information that is delivered. This base makes it possible to verify soundness and coherence of doctor's discourse.

To sum up, three different bases are maintained in our training dialogue environment:

• Knowledge base: complete knowledge of the dialogue context and goals, accessible by both the trainee and the virtual agent. • Common ground: the initial overt knowledge (that the patient is supposed to have) plus the information instantiated during the dialogue. • Belief base: contains the common ground plus the knowledge that can be inferred by the patient from doctor's discourse.

We present in the following how to take advantage of such organization for the supervision of the dialogue system.

KNOWLEDGE REPRESENTATION

The different bases contain facts and beliefs that constitute events, in the sense of [START_REF] Mcrae | People use their knowledge of common events to understand language, and do so as quickly as possible[END_REF]. We propose in this section to detail the organization of such events first by proposing a global representation in terms of attribute/value structures, and then by specifying some particular features.

Feature Structure Representation

Events are typed feature structures, their values can be atomic or complex and correspond to different types: strings, boolean, composites, etc. Events are then associated to definition domains, that can be lists, rendering possible for a feature to be associated to an exhaustive list of values. Among them, it is often the case that one can be chosen as a default value.

Moreover, we have seen the importance of tracking knowledge base updating: knowing whether the value of an event has been inferred or instantiated during the discourse is necessary. Finally, another important information is whether the feature belongs or not to the common ground or, in other words, whether the trainee doctor thinks the agent knows the event (i.e. has the event instantiated in the base).

In our system, all three bases of knowledge are gathered into a single one, which corresponds to the global knowledge base in which the status of each information (whether it also belongs to the common ground and/or the belief base) is specified. These different information are represented explicitly as shown in figure 3.a. Moreover, we integrate to this representation two features dependent-values and reqirement that will be described in the following sections.

The example given in 3.b illustrates a diagnosis event for intestinal surgery: the possible values are listed, among which the default is polyp2 . During its discourse, the doctor has instantiated the value colorectal-polyp which is more specific than the possible values (but not incompatible as we will explain later). Finally, this

                      event possible-values list default-value item instantiated-value item inferred-value item common-ground boolean dependent-values list reqirement boolean                       a. Event features                  diagnosis possible-values polyp, colitis, cancer, ... default-value polyp instantiated-value colorectal-polyp inferred-value i common-ground true                  b. Example of an event

Dependent Values

Information is not only structured, it is also organized temporally: the occurrence of an event is often conditioned by the realization of another one. For example, the prescription of a surgery can only be done after establishing the diagnosis. In the same way, the diagnosis of a disease is usually done after the apparition of some symptoms.

In our knowledge organization, this constraint can be encoded directly within the representation of the event thanks to a specific feature. The figure 4 presents the example of the surgery event, that can be described on the basis of a diagnosis, relying on the analysis of symptoms.

surgery-ev ⇒                             symptoms 1       possible-values pain, inflammation, digestion, ... default-value pain       diagnosis 2           possible-values polyp, colitis, ... default-value polyp dependent-values 1           surgery-type           possible-values surgery, coelioscopy, ... default-value coelioscopy dependent-values 2                                      

Figure 4: Dependency between events within a structure

As it is usually the case with feature structures, elements can be indexed and referred to within a same structure. This mechanism is the basis of structure sharing for example in HPSG. It stipulates the fact that the coindexed feature structures refer to the same element. In this example, the diagnosis and surgery-type events have a dependent value (respectively symptoms and diagnosis events).

Weighting Events

In the description of an event, some features can be more important than others. It is possible to encode such information with continuous values, representing the weights and making it possible to rank the events thanks to their importance. This information can be of some interest when evaluating the coherence or the completeness of a structure. In our approach, we reduce the possible weights to two values, representing the fact that some events has to be instantiated obligatorily, whereas some others can be left free or underspecified. This constraint is encoded by the requirement feature that can take two values: hard and soft.

surgery-ev ⇒                                   diagnosis 1          possible-values polyp, cancer, ... default-value polyp reqirement hard          surgery-type 2             possible-values surgery, coelioscopy, ... default-value coelioscopy dependent-values 1 reqirement hard             duration           possible-values long, medium, short dependent-values 2 reqirement soft                                            

Figure 5: Relative weights

The example in figure 5 represents the fact that the instantiation of diagnosis and surgery-type sub-events is mandatory for the event diagnosis to be complete. Their reqirement value is then set to hard, whereas the duration of the surgery can be left underspecified.

INFERENCE AND RULES

Knowledge management requires an inference relation making it possible to generate new knowledge starting from the one which is instantiated during the discourse. We present in this section how rules can implement this relation. A first section proposes a brief sketch of the inference rule language we use. The two last sections describes how rules can implement both feature inference and dialogue actions: inference rules constitute a single framework for knowledge management and dialogue supervision.

A Language for Representing Inference Rules

Many different representations of inference rules exist from artificial intelligence [START_REF] Colmerauer | Theoretical model of prolog ii[END_REF][START_REF] Frühwirth | Constraint Handling Rules[END_REF], knowledge management [START_REF] Horrocks | A semantic web rule language combining owl and ruleml[END_REF][START_REF] Motik | Web ontology language: Direct semantics[END_REF], etc. We present here an adapted version of the agent programming language AgentSpeak/Jason [START_REF] Bordini | Programming Multi-Agent Systems in AgentSpeak using Jason[END_REF][START_REF] Miller | Logics of common ground[END_REF][START_REF] Pfau | Modelling and using common ground in human-agent collaboration during spacecraft operations[END_REF]. In our representation, rules distinguish three components:

• The specification of the context, events, features that are involved in the inference relation. • The conditions that trigger the inference.

• The consequent of the inference. These three parts are represented in rules as follows 3 :

context : conditions -> consequent
The definition of the context and the access to feature values relies on the identification of the elements (events, features) to be involved in the rule and unification. The first operation consists in labelling an object with a type, following the syntax of the casting operation. For example, the operation (feature)f1 consists in creating an object of type feature with the label f1. Unification is represented by the symbol "=" and makes it possible to specifies values in the identification of the triggering objects. For example, the context (event.surgery)s1 ∧ [s1.duration = d1] indicates an event s1 of type surgery which has a feature duration of label d1.

Rules for Inferring New Knowledge

The instantiation of new values during the discourse opens the possibility to infer new knowledge. For example, the doctor may announces an urgency for the remediation surgery, which means that the problem is serious. This commonsense knowledge can be instantiated in the base as inferred-value (simplified to infer) of the corresponding feature thanks to the following rule: R1: (event.surgery)s1 ∧ [s1.urgency = u1] : u1 == high -> s1.severity.infer = high;

Note that this new knowledge is inferred which means, according to our definitions, that the patient believes now this information. In some cases, the inferred knowledge may not be necessarily true, but only believed by the patient. For example, if the doctor announces the necessity of a long operation, the patient may think that the problem is serious, the risk high and the complexity of the surgery important (which may or may not be true).

This commonsense knowledge can be instantiated in the base the inferred-value (simplified to infer) of the corresponding features describing the surgery: R2: (event.surgery)s1 ∧ [s1.duration = d1] : d1 == long -> s1.severity.infer = high; s1.risk.infer = high; s1.complexity.infer = high;

From Knowledge Inference to Action Inference

Besides instantiating inferred values, the same type of rules can be used directly to manage dialogue processing. In most of the cases, the virtual patient speaks in reaction to the doctor's discourse by answering a question, expressing emotion or asking for precisions. The two last situations can be controlled by inference rules. For example, if the doctor delivers an unexpected or incoherent information, this can be identified by the fact that the corresponding instantiated value is different than the default value of the same feature. This is implemented thanks to the following rule:

R3: (feature)f1 ∧ [f1.instantiated = i1] ∧ [f1.default = d1]
: i1 != d1 -> ask-question(default-mismatch, i1, d1);

We do not describe here the module of language generation in the dialogue system. Simply note that the ask-question action passes as parameters the type of the question (here default-mismatch) and the values concerned by the question. The generating module will elaborate then the corresponding message to be produced by the virtual agent.

This mismatch situation can be refined to the cases where the term used by the doctor is similar but not exactly the same as that expected. This is not a mismatch in the sense of the previous rule, but rather a similarity gap between the terms. Such discrepancy can be taken into account by introducing distributional information in the feature values: instead of being terms such as polyp, cancer, surgeon, etc. feature values can be represented by the corresponding distributional vectors ----→ polyp, -----→ cancer, ------→ surдeon, etc. (extracted from existing corpora of transcribed training sessions). In this case, the mismatch problem comes from a similarity value (calculated with classical measures derived from cosine, for example) that is lower than a certain threshold, as implemented by the following rule:

R4: (feature)f1 ∧ [f1.instantiated = i1] ∧ [f1.default = d1]
: sim(i1, d1) < threshold -> ask-question(default-similarity, i1, d1);

Note that the ask-question action takes the adequate type value as for the generation of the answer.

The last situation we illustrate as for the use of rules is dialogue management. We have introduced in the knowledge representation the notion of dependent values, implementing the synchronization of feature instantiation: some features have to be instantiated before others. This type of mismatch is identified by the fact that the feature has a dependent value which value is not already instantiated or inferred. This rule can be applied for controlling the synchronization of the different phases of a dialogue (greetings, damage description, etc.): each phase corresponds to an event that may have as dependent value another one. Typically, the event damage description has the vent greetings as dependent value.

CONCLUSION

We have presented in this paper an approach implementing a dialogue supervision system relying on the management of a knowledge base, a common ground and a belief base. Inference rules exploit this information in order to generate new knowledge as well as controlling the coherence and the progress of the dialogue. This approach has been developed in the framework of a specific human-machine dialogue task: training the human agent to deliver information in a specific context.

Figure 1 :

 1 Figure 1: The ACORFORMed environment

Figure 2 :

 2 Figure 2: Example of Universe of Discourse

•

  The increment: what is instantiated by the trainee during the session. • The beliefs: what the trainee supposes the virtual agent knows.

Figure 3 :

 3 Figure 3: Feature structure organisation

  R5: (feature)f1 ∧ [f1.dependent = d1] ∧ [d1.instantiated = null] ∧ [d1.infer = null] -> ask-question(default-synchro, i1, i2);

The two last features dependent-values and reqirement will be illustrated later.

At the difference with Jason, the left-hand side of the rule, made of the context and the conditions, represents the antecedent, the right-hand side the consequent.

ACKNOWLEDGMENTS

This work, carried out within the Labex BLRI (ANR-11-LABX-0036)and the Institut Convergence ILCB (ANR-16-CONV-0002), has benefited from support from the French government, managed by the French National Agency for Research (ANR) and the Excellence Initiative of Aix-Marseille University (A*MIDEX).