A Generic Approach for Assessing Compatibility Between Task Descriptions and Interactive Systems: Application to the Effectiveness of a Flight Control Unit

2.1 Generation of Application From a Task Model

From the seminal work of ADEPT (Wilson et al. 1993) and its design process based on tasks and domain models, many authors have followed and refined that approach as, for instance, in the CAMELEON framework (Calvary et al. 2003). The basic assumptions for these approaches is that task models are the preliminary source of information and that it is possible to generate an interactive application from such information (while adding other ingredients such as UI guidelines for instance). The main claim is that with such an approach it is possible to generate user interfaces for different platforms thus reducing the development costs. The main drawbacks are that it is difficult to integrate design and craft knowledge in such processes ending up with stereotyped user interfaces far away (in terms of design and interaction techniques) from leading edge applications.

2.2 Correspondence at Models Level

Another approach promoted was to perform integration with a (possibly formal) model of the interactive system. Such an approach has been firstly introduced in (Palanque, Bastide and Sengès 1995). However, such an approach requires a description technique able to encompass all the elements of the interactive application including input device information, interaction techniques as well as the non-interactive part (functional core) of the application. Another drawback is the high development costs for the construction of the application and interaction models limiting usually its use to safety critical applications. Besides, such approaches are very different from current processes in interactive application development where Rapid Application Developments toolkits (RAD) are common practice. Lastly, task models and system models must be consistent. It is another cumbersome task to perform as presented in (Navarre et al. 2001) where such compatibility was assessed through scenarios extracted from the task models and executed on the system model.

2.3 Issue of Having the Task Model at Run Time

An orthogonal issue with respect to the two approaches presented above, lies in the fact that some of the advantages (such as contextual help) can only be available if the task models are embedded during the use of the application. Embedding task models at run time while executing the models of an interactive application was proposed in (Barboni et al. 2010) where the benefits were made available but again at the costs of building an interactive application via the construction of system models. This capability has also been used to modify the system behavior at run time. In (Blumendorf, Lehmann and Albayrak 2010), the current state of execution of task models are used to modify user interfaces distribution over several devices. At last, automated testing of GUIs has been proposed in (Nguyen et al. 2014) but is based on test cases (sequences of low level GUI events) and not on task models.

3.1 Proposed Process

The process takes as input an existing interactive system and its software interactive applications. This process, illustrated in Figure 1, starts with 2 phases that can be lead concurrently: task modelling and instrumentation of the interactive application. The task analysis and modelling phase consists in understanding user’s tasks with the interactive system and in describing them in task models. The particularity of this phase is that task models of the low-level interactions with the applications have to be produced, as these descriptions of the interactive tasks will be put in correspondence with the interactive application. The amount of tasks to be performed can be very important and thus there can be several models which describe tasks at various abstraction level. All these models have to be linked between each other and these phase is depicted as the “integration of task models” phase in Figure 1. In this phase the models are simulated in order to check their completeness and consistency with regards to operational scenarios.

Figure 1

Process for validating the effectiveness of an interactive application.

On the interactive application side, the software is instrumented to enable the connection with task models. Then, a synergistic module automatically extracts widgets from the interactive application and interactive tasks from the task models. Interactive tasks are then put in correspondence with the widgets and their associated events (phase “Editing correspondences between tasks and widgets” in Figure 1). When trying to link interactive tasks to widgets and events, if tasks are not matching widgets or events, incompleteness is detected and the task models have to be mend (return loop in Figure 1). Once the task models are complete, the instrumented interactive application can be co-executed with the task models. During this co-execution, inconsistencies can be detected between task models and interactive application, for example if a widget is described to be used instead of another which should really be used. In this case, the task models have to be corrected (return loop from “testing via co-execution” box in Figure 1).

The required framework to support such correspondence edition and to support co-execution of the interactive application with task models is discussed in the next section.

Once the task models are complete and consistent with the instrumented interactive application, the co-execution framework can be exploited in order to provide support for training programs (Martinie, Palanque, Navarre et al. 2011), contextual help (Palanque and Martinie 2011) and user centered redesign. In the illustrative example, we describe how this co-execution framework provides support for assessing effectiveness of interactive applications, which can be exploited for the re-design of an interactive application.

3.2 Approaches for Co-Execution of Interactive Application and Task Models

Co-execution of system models and task models can be used to provide support for the development of single user applications (Barboni et al. 2010) and collaborative applications (Martinie et al. 2014). In this paper we propose a framework that enables the co-execution of an interactive application with its associated task models. For this purpose, a synergistic module, which consists of a correspondence editor and a co-execution controller (or simulation controller), has been built in order to be able to interface task models with an interactive application programmed with a textual programming language. Following the work proposed in (Barboni et al. 2010) and (Martinie et al. 2014), connecting task models and system models in a software development environment requires the following steps to be performed:

1. On task modelling side:

   1. A set of interactive tasks (both input and output) must be extracted from the tasks specification (as they represent actions performed by the user and feedback the system provides the user with).

   2. The task models simulation environment notifies to the synergistic module the evolution of the scenario under construction using a dedicated API (sending data from the simulator).

2. On system modelling side:

   1. The activation and rendering functions have to be extracted as they represent the system inputs and outputs. They contain information about the widgets, the list of related events (relevant for correspondence), the activation rendering methods for each couple of widget and event (i. e. how enabled / disabled widget statuses are rendered) and lastly the rendering methods (graphical representation of data within widgets).

   2. The system modelling execution environment executes the models and notifies to a synergistic module about any change that happens using a dedicated API.

In the proposed approach, these mechanisms remain the same on the task models side, but on the system side, working without models requires to build a co-execution framework with equivalent mechanisms, i. e.:

1. For editing correspondences, the synergistic module of the framework needs to acquire what is provided by both activation and rendering functions: a list of widgets, the list of related events, the activation rendering methods and the rendering methods.

2. For co-execution of the interactive application and associated task models, the synergistic module of the framework requires to be notified about any change: activation status of the widget (enabled / disabled), rendering changes. The synergistic module also has to be capable of raising events (for example, to force widgets to trigger a particular event).

Providing such features depends on how the application has been built, i. e. whether or not it has been setup for co-execution.

3.3 Instrumentation of an Existing Interactive Application

When preparing the setup for co-execution, the effort required by the developer depends on the choice of technology or architecture made:

1. A first possibility would be to ask developers to provide the activation and rendering functions as explained in the previous section, implementing a dedicated API. This solution requires knowledge about the synergistic module and modifies the structure of the interactive application.

2. Another possibility is to ask developers to instrument the code of the existing application with means to allow the access of pertinent widgets of the application for both user inputs and system graphical outputs. Such a solution requires less effort from developers but implies to precisely define how required features would be exposed (widgets, events, rendering methods…). With Java^1[1] for instance (since jdk 1.5), “annotations” are special software code elements that can be used both at compilation and at run time in order to point out objects, attributes or methods, and providing access to them.

The option which consists in providing the developers with a library of widgets already prepared for the correspondence editing is particular. Such a solution introduces a bias as it requires the developer to work with this predefined set of widgets, and prevent them from using new widgets. If this last case occurs, the developer will have to provide extra code to use these new widgets within the framework (which corresponds to the first two possibilities presented).

Table 1 provides an overview of the possibilities that the application developer will have to face to be able to connect an interactive application to task models.

3.4 Design and Development of the Synergistic Module

If the application is not instrumented for co-execution with task models, the effort will have to be assumed by developers of the correspondence module. The complexity of such approach thus depends on the technology used to develop the application:

1. The used technology may provide mechanisms (at design time or at runtime) to discover interactive widgets and their features. This could be resource files providing the widgets and their layout (such as in Microsoft Visual Studio, or with Java FX fxml files, Qt qml files…) or mechanism provided by the runtime environment such as with Java Swing application (at runtime it is possible to explore the widget tree of any Java Swing application).

Another possibility could be to modify the runtime environment and to enhance widgets with dedicated mechanisms (as described in previous section). A good example of such possibility is the architecture of Java Swing, where it is possible to change the Look&Feel manager at runtime of any application even if it has not been set up for (for each Swing component, the Look&Feel manager defines both the rendering and how user events are handled). But for these two aforementioned possibilities, there are two important limitations:

1. Widgets that are not predefined within the framework but are used for the application cannot be easily used for the correspondence editing as they would be difficult to detect and difficult to analyze (to provide list of produced events for instance). Fixing this point thus depends on the used technology.

2. Widgets that appear at run time cannot be detected at boot strap.

In any case (except when a dedicated API for connection has been implemented in the application), a set of functionalities have to be developed in the synergistic module in order to be able to adapt what is provided by the interactive application and to connect it to task models. Table 2 provides an overview of the work that has to be done by the synergistic module developer depending on the way the interactive application has been prepared for correspondence and co-execution. In this article, we present a solution based on the code instrumentation as it: a) provides full support for connecting an interactive application with its associated task models; b) provides support for modularity of the framework; c) does not modify the architecture of the interactive application; d) is the more accurate with regards to recent advances in software engineering.

4.1 Task Modeling With HAMSTERS

Task models support gathering and structuring data from the analysis of users’ activities, and recording, refining and analyzing information about users’ activities. Several notations are available to describe tasks with varying expressiveness levels depending on targeted analysis. HAMSTERS (Human – centered Assessment and Modeling to Support Task Engineering for Resilient Systems) is a tool-supported graphical task modeling notation for representing human activities in a hierarchical and ordered way. At the higher abstraction level, goals can be decomposed into sub-goals, which can in turn be decomposed into activities. Output of this decomposition is a graphical tree of nodes. Nodes can be tasks or temporal operators.

Tasks can be of several types (Figure 2) and contain information such as a name, information details, and criticality level. Only the single user high-level task types are presented here but they are further refined. For instance the cognitive tasks can be refined in Analysis and Decision tasks (Martinie, Palanque, Barboni et al. 2011) and collaborative activities can be refined in several task types (Martinie et al. 2014).

Figure 2

High-level Task Types in HAMSTERS.

Temporal operators (presented in Table 3) are used to represent temporal relationships between sub-goals and between activities. Tasks can also be tagged by temporal properties to indicate whether or not they are iterative, optional or both.

HAMSTERS’ notation and tool provide support for task-system integration at the tool level (Martinie, Palanque, Navarre et al. 2011) by:

1. Structuring a large number and complex set of tasks introducing the mechanism of subroutines (Martinie, Palanque and Winckler 2011) and generic components (Forbrig et al. 2014). These structuring mechanisms enables the breakdown of a task model in several ones. Subroutines are similar to functions or procedures. Generic components offer a set of properties and a set of functions and can be instantiated several times in several task models.

2. Describing data that is required and manipulated (Martinie et al. 2013) in order to accomplish tasks. Figure 3 recapitulates the notation elements to represent data. Information (“I:” followed by a text box) may be required for execution of a system task, but it also may be required by the user to accomplish a task. The notation element “Physical Object” (“Phy O:” followed by a text box) supports describing whether a user or a system task requires a particular physical object to be accomplished. The notation element “Object” (“O:” followed by a text box) is dedicated to the description of a software data object that is required by the system in order to accomplish a task. The notation element “Software Application” (“Sw A:” followed by a text box) provides support for the description of a software application that is required in order to accomplish a task.

Figure 3

Representation of Objects, Information and Knowledge with HAMSTERS Notation.

4.2 Interactive Application Instrumentation and Annotations Processing

As stated above, we present an approach where developers of the interactive application instrument their code with annotations so that the interactive application can be integrated within the synergistic framework. Our framework and the interactive application presented in the case study are fully implemented using the Java technology. In particular, we propose a solution based on the Java type annotation mechanism (since JSE 1.8). Annotation in Java is a form of metadata (prefixed with a ‘@’), providing data about a program that is not part of the program itself. Annotations have no direct effect on the code instructions that they annotate but they are used by the compiler to detect errors. At compilation time, they provide information to generate the code. At run time they provide support for examining the annotated code. We use this last possibility in our framework. There are a lot of possible usage of such annotations:

1. For instance, the following annotation may be used at run time to periodically schedule a method call.

   @Schedule(dayOfWeek="Fri", hour="23")public void doPeriodicCleanup() { ... }

2. The following one is used at compilation time to detect a possible assignment to a null value (and raise an compilation error if so)

   @NonNull String str;

The approach proposed is based on such annotations to point out within the code widgets that may be used to build the correspondence. There are two kind of annotations: one for widgets related to user inputs and the other one for graphical outputs from the system, any widget being possibly of the two kinds:

1. Example of a simple button

   @EventSource(name="Validate", event="actionPerformed")private JButton btn1;

2. Example of a label

   @Renderer(name="Display", property="text")private JLabel lbl1;

3. Example of a text field

   @EventSource(name="Name", event="actionPerformed")@Renderer(name="Name", property="text")private JTextField txt1;

Both types of annotation may be enhanced with extra data to provide information for the correspondence editing. In the two cases it provides a readable name for the correspondence (independent from the attribute name) and another information (the name of the related event or the name of the widget property that may change while using the application). Table 4 summarizes the different annotations used in this approach and the corresponding interactive tasks.

Table 4

Annotations used and corresponding interactive tasks

Interactive application	Corresponding task	Annotation declaration	Annotation definition
Activation Event produced by user action on a widget	Input Task	@SynergyEventSource	Defined by an event source name and an event name Ex: @SynergyEventSource(name=“buttonl“, event=“a661EvtSelection“)
Rendering Change in the rendering of a widget	Output Task	@SynergyRenderer	Defined by a Tenderer name and a widget property name Ex: @SynergyRenderer(name=“labell“, property-‘labelString“)SynergyRenderer(name=“labell“, property-‘labelString“)

When editing the correspondence between the interactive application and task models, the synergistic framework uses the introspection mechanism of Java to find any annotated widget, building a list of widgets available for editing.

4.3 Architecture of the Framework for Coupling Task Models and Instrumented Interactive Application

The architecture of the synergistic software environment that supports both correspondence editing and co-execution is presented in Figure 4.

Figure 4

Architecture of the synergistic environment

This architecture is composed of: two modules for task edition and simulation (on the left side), the interactive application (on the right side) and of modules for connecting and co-executing task models with interactive application (grey shaded in the center in Figure 4). The colors of the architecture elements make explicit in light grey elements that have been either added or deeply redesigned to extend co-execution to applications not designed following a model-based approach (Barboni et al. 2010). The module in charge of interfacing the interactive application with the correspondence editor and simulation controller is called the “Annotation processor module”. This module is responsible of processing the annotations and of providing information about widgets, events, rendering to the correspondence editor and notifications to the simulation controller (as described in section “Approaches for co-execution of interactive application and task models”). The main differences with the architecture presented in (Barboni et al. 2010) are that: the architecture presented here is not exclusively model-based; the information about widgets and events is provided by the annotation processor module instead of the PetShop CASE tool.

5.1 Presentation of the FCU Backup

In interactive cockpits, the Flight Control Unit (FCU) is a hardware panel composed of several electronic devices (such as buttons, knobs, displays…). It allows crew members to interact with the Auto-Pilot and to configure flying and navigation displays. The FCU Backup is an interactive application designed for the recovering of all FCU functions in case of FCU failure and is used in exclusion with the FCU. It is composed of two interactive pages:

1. EFIS_CP: Electronic Flight Information System Control Panel for configuring piloting and navigation displays.

2. AFS_CP: Auto Flight System Control Panel for the setting of the autopilot state and parameters.

For example, this application is displayed on two of the eight cockpit LCD screens (in the Airbus A380), one for the Captain and the other for the First Officer. The crew members can interact with the application via the Keyboard and Cursor Control Units which gathers in a single hardware component a keyboard and a trackball.

In this paper, we will focus on the EFIS_CP page depicted in Figure 5. The left panel is dedicated to the configuration of the Primary Flight Display while the two right panels are dedicated to the configuration of the Navigation Display (illustrated in Figure 6). The top right panel of the EFIS page enables the display of several navigation information while the bottom panel of the EFIS page enables to choose the display mode and scale.

Figure 5

EFIS control panel (w / o WPT button activated).

Figure 6

Navigation display (w / o waypoints displayed).

More particularly, we will focus on two different activities that can be performed using the EFIS_CP page: the activities that have to be performed in order to insert waypoints in the current route and the activities that are related to the configuration of the barometer settings.

5.2 Task Analysis and Modelling

5.2.1 Inserting a Waypoint in the Current Route

During the flight, crew members may ask permission or be asked to modify the current route of the aircraft. If the air traffic controller agrees, a clearance is ordered to the pilot to insert a waypoint.

Figure 7 details the tasks that have to be performed to reach this goal. First, thanks to the VHF radio device, the crew member receives a clearance from the air traffic controller indicating which waypoint has to be added in the current route (interactive output task “Receive a clearance from ATM for inserting a waypoint in flight plan” and perceptive task “Perceive waypoint insertion request” in Figure 7). Then, s / he decides to check the waypoints (cognitive decision task “Decide to check waypoints”) and has to perform a set of activities to display waypoints on the navigation display (abstract task “Display waypoints on ND” in Figure 7). In order to display waypoints on the navigation display, the crew member has to display the EFIS page and to configure the display options. The subroutine “Configure ND display options” describes the tasks that have to be performed to configure the navigation display options. The part of this subroutine task model which is relevant to our illustrative example is depicted in Figure 8. It shows that the crew member can iteratively configure the display of navigation information (iterative abstract task “Configure display of navigation information”) until (temporal ordering operator “disable”) s / he decides that the ND is setup correctly (cognitive task “Decide that ND setup if ok”). To configure the display of navigation information, the crew member has the choice between several actions to perform.

Figure 7

Task models for Handle waypoint insertion.

Figure 8

Subpart of “Configure ND display options” subroutine task model.

In order to configure the display of waypoints, s / he will press the WPT button widget.

Figure 9 details the component “Press button widget to configure the display of [information, button]”. This component is a generic task model that details what have to be performed by the pilot to configure the display of an information by pressing the corresponding button widget. First the crew member has to locate the corresponding button widget (user task “Locate <button> in Figure 9), then to perceive the current state of this button (perceptive task “Perceive current status of <button>” in Figure 9). Then, s / he decides that the current status of the button is the right one or not according to the targeted status (temporal ordering operator “choice”). If the crew member analyses that the current status of the button does not match the target status, s / he clicks on it (interactive input task “Click on <button>” in Figure 9). The new status of the button is displayed (interactive output task “Display <button> status” in Figure 9). The crew member then can perceive the new status of the button and decide that it is the right one (user tasks “Perceive current status of <button>” and “Decide that status of <button> is OK for targeted display configuration of <information>”). Figure 10 details the component “Press button widget to configure the display of [information, button]” instantiated for the information “waypoints” and the corresponding button “WPT button”.

Figure 9

Task model for component “Press button widget to configure display of [information, button]”.

Figure 10

Task models for Press button widget to configure display of waypoints.

5.2.2 Configure Barometer Settings

Before landing, crew members may be asked to configure the barometric pressure according to the one reported by the airport. The barometric pressure is used by the altimeter as an atmospheric pressure reference in order to process correctly the plane altitude. Figure 11 details the tasks that have to be performed by the pilot in order to configure the barometric settings. In order to change the barometric pressure (abstract task “Change atmospheric reference”), the pilot has first to select the QNH mode (component “Select checkbutton in radiobox for configuration of [atmospheric reference, QNH checkbutton, atmospheric reference radiobox]”). S / He can then configure the pressure unit by choosing to display it in hPa (component “Press button widget to configure the display of [pressure unit, InHg to hPa button]”) or in InHg (component “Press button widget to configure the display of [pressure unit, hPa to InHg button]”). Then, the pilot can set the atmospheric reference in InHg (component “Set value in editboxnumeric [InHg pressure, InHg editboxnumeric]”) or in hPa (component “Set value in editboxnumeric [hPa pressure, hPa editboxnumeric]”). Figure 12 details the component “Set value in editboxnumeric [information, editboxnumeric]” instantiated for the information “InHg pressure” and the editboxnumeric “InHg editboxnumeric”. First the pilot has to locate the corresponding edtiboxnumeric widget (user task “Look at <InHg editboxnumeric>”), then to perceive the current displayed value (perceptive task “Perceive value of <InHg pressure> in <InHg editboxnumeric>”).

Figure 11

Task models for Configure baro settings.

Figure 12

Instantiation of “set value in editboxnumeric” component task model for InHg pressure.

Figure 13

Simplified task model for Configure flight instruments

Figure 14

Excerpt from the FCU Backup widget declarations

Then, s / he decides that the current value is the right one or not according to the targeted value. If s / he decides that the value has to be changed, s / he clicks on the corresponding editboxnumeric (interactive input task “Click in <InHg editboxnumeric>”) and edit the value (interactive input tasks “Type <InHg pressure> value in <InHg editboxnumeric>” and “Type on Enter key”). The new value is then displayed on the editboxnumeric (interactive output task “Display final value of <InHg pressure> in <InHg editboxnumeric>”). The pilot then can perceive the new value and decide that it is the right one.

5.3 Interactive Application Instrumentation

As presented in previous section, the approach proposed is based on the Java type annotation mechanism and proposes two kind of annotations: @SynergyEventSource used as an activation annotation and @SynergyRenderer used as a rendering annotation. Considering the two activities we are focusing on in this case study, we are interested in seven different widgets. Figure 14 presents the declarations of these widgets: one picturepushbutton to configure the display of waypoints (ppbWPT), two checkbuttons to configure pressure mode (chk_QNH and chk_STD), two editboxnumerics to edit the pressure reference (ebnHPA and ebnINHG) and two picturepushbuttons to choose the pressure unit (ppbHPA and ppbINHG).

Figure 15 presents the same widget declarations with the corresponding annotations. For each widget, the annotations (that are highlighted in bold in this Figure) are added before its declaration. For example, the annotations for the picturepushbutton ppbWPT notify that this widget (named wpt) is likely to send one event (named a661EvtSelection) and to change its display upon the change of the picture property.

Figure 16

Illustration of the editing of correspondences between tasks and widgets.

5.4 Editing of Correspondences Between Tasks and Widgets

Once the tasks models are defined and once the application is instrumented, the synergistic environment extracts automatically widgets from the interactive application (following the annotations) and interactive tasks from the task model. To illustrate the correspondence edition, we uses the task model presented in Figure 13 and the FCU Backup application annotated as presented in Figure 15. The synergistic environment extracts from the task model seven interactive input task and three interactive input tasks. It extracts from the FCU Backup application seven widgets events and three rendering actions. To edit the correspondences between tasks and widgets, the developer uses the correspondence editor as illustrated in Figure 16. This tool may be divided into three parts:

1. The left bottom part presents two tabs. The first one, displayed in Figure 16, enables the developer to choose among the available task models the one that s / he will use in the correspondence edition. The second tab (that is not displayed in Figure 16) enables the developer to choose, among the available ones, the application that will be used in the correspondence edition.

2. The top part presents two correspondence tables. The top one defines the input correspondences. It enables the developer to put in correspondence interactive input tasks and widget event handlers. The bottom correspondence table defines the output correspondences. It enables the developer to put in correspondence interactive output tasks and rendering actions. For both interactive input and output tasks, event handler and rendering actions the correspondence editor offers to the developer a drop-down list with all the available ones (as illustrated in Figure 16 for the event handler of the last line of the input correspondences table).

3. The right bottom part is divided into two panels. The top one presents the correspondence coverage, pointing out the number of unused interactive input and output tasks, event handler and rendering actions. This enables the developer to check the completeness of the correspondence edition. As an example, the illustration in Figure 16 presents a correspondence coverage of 55%. This is due to the fact that only 5 of the 7 interactive input tasks and 4 of the 7 event handlers are currently used. Finally, the bottom panel enables the developer to set the co-execution properties (main task model and main application for the co-execution) and to launch the co-execution.

Figure 17

Illustration of a co-execution step between task models and FCU Backup application.

5.5 Co-Execution between Task Models and FCU Backup Application

Figure 17 presents one step of co-execution of the tool suite presented in this paper. The left part (resp. the right part) corresponds to the execution of the models and application before clicking the WPT button to display waypoints (resp. after clicking) using a task driven co-execution.

Figure 18

Illustration of a co-execution step between task models and FCU Backup application.

A particular focus on the left part of the figure allows the understanding of the tool suite (which is a set of modules of the NetBeans IDE.^2[2] This tool may be divided into four parts:

1. The top part is a set of classical IDE menu bars and tool bars buttons.

2. The left part provides means to navigate amongst the project files (java sources, HAMSTERS and correspondence models).

3. The right part shows properties of the sources or models (bottom part) and tools to modify the currently selected model (on the top part a specific toolbox appears depending on the kind models).

4. The center part allows the editing and execution control of both the sources and models. The layout of this part is fully reconfigurable as illustrated by the layout difference of the left and right part of the figure.

5. To illustrate the synergistic exploitation of both task models and the FCU backup application, we use the model presented in the previous sections (cf. Figure 13), focusing on the task driven simulation.

Following the five numbered steps presented on the figure, the behaviour of the task driven simulation is as follows:

1. A set of available tasks is provided by the HAMSTERS environment that is selectable within the associated list box.

2. The selected task is connected to a widget event (the click on WPT button) by the correspondence editing.

3. Perform the task thus acts as if the user clicks on the corresponding button.

4. As if the button were clicked, a rendering may occur and this rendering may be related to an output HAMSTERS task, using the output correspondence edition (in our example, the button status changes to engaged and this property change is related to the task display <WPT button> status).

5. When an output task is selected, a dedicated panel appears at the bottom of the tool, showing whether a rendering occurs and if it corresponds to an output correspondence (panel “feedback on task performance). In this panel it is possible to indicate if the rendering was effectively correct and perceive (for log purpose).

5.5.1 Testing Task Models Consistency Using Co-Execution

Figure 18 presents another step of this co-execution. In this configuration, the user has already clicked on the QNH checkbutton and must now choose the pressure unit by performing interactive input task “Click on InHg to hPa button” or interactive input task “Click on hPa to InHg button” (Figure 18-1 and Figure 18-2). However, as shown by the orange colour highlighting it on Figure 18-1 and the fact that it is not highlighted in green in Figure 18-2, the interactive input task “Click on hPa to InHg button” is not accessible for the user. This is due to the fact that only the “InHg to hPa” button is displayed on the FCU Backup (cf. Figure 18-3). Therefore, the “hPa to InHg” button is not accessible for the user, neither is the corresponding task.

This inconsistency brings our attention on the fact that the task model is faulty and must be corrected to correspond to the application use (step “Mending of task models” in the process). The corrected task model is presented in Figure 19. In this case, the pilot must click on the “InHg to hPa” button before editing the pressure in hPa. If s / he prefers to edit the pressure in InHg, s / he can then click on the “hPa to InHg” button.

Figure 19

Corrected simplified task model for Configure baro settings.

5.6 Analysis of the Effectiveness of the FCU Backup Application With Regards to Crew Members’ Tasks

Thanks to the correspondence and co-execution, we have verified that the task models of the “Handle waypoint insertion request” activities are complete and fully consistent with regards to the FCU Backup interactive application. From the task models, we can analyse that the crew member has to move from one application to another in order to be able to modify the flight plan. S / he has to display the EFIS page to be able to configure the ND display options (“FCU Backup EFIS page” software application object in Figure 7 and “FCU Backup FMS page” software application object in Figure 7).

Thus, we have numbered 10 articulatory tasks that are only dealing with moving from one page to another (5 subtasks in the “Display EFIS_CP page” subroutine and 5 tasks in the “Display FMS page subroutine” in Figure 7).

Furthermore, this articulatory task load will also have to be added to the crew member’s activities as far as s / he will have to switch to another application in order to come back to her / his current activity. This analysis shows that the interactive application, as currently designed, reduces the crew members’ efficiency. One potential solution for re-design could be to integrate the Navigation Display panel with the FMS panel in one single interactive application.