Robert Rönngren

Michael Liljenstam

Johan Montagnat

Rassul Ayani

Transparent Incremental State Saving in Time Warp Parallel Discrete Event Simulation

Many systems rely on the ability to rollback (or restore) parts of the system state to undo or recover from undesired or erroneous computations. Examples of such systems include fault tolerant systems with checkpointing, editors with undo capabilities, transaction and data base systems and optimistically synchronized parallel and distributed simulations. An essential part of such systems is the state saving mechanism. It should not only allow efficient state saving, but also support efficient state restoration in case of roll back. Furthermore, it is often a requirement that this mechanism is transparent to the user. In this paper we present a method to implement a transparent incremental state saving mechanism in an optimistically synchronized parallel discrete event simulation system based on the Time Warp mechanism. The usefulness of this approach is demonstrated by simulations of large, detailed, realistic FCA and a DCA-like cellular phone systems.

Introduction

Many systems rely on the ability to rollback (or restore) parts of the system state to undo or recover from undesired or erroneous computations. Examples of such systems include fault tolerant systems with checkpointing, editors with undo capabilities, transaction and data base systems and optimistically synchronized parallel and distributed simulations. An essential part of rollback based systems is the underlying state saving mechanism. This mechanism should not only allow efficient saving of states, but also support efficient state restoration in case of rollback. The implementation of the state saving and restoration mechanism is in many systems transparent to the user. The reason for this is obvious: the user should not have to bother with the intricate details of this mechanism such as whether complete states are saved or only a list of changes to the state. In this paper we examine some issues regarding state saving mechanisms in an optimistically synchronized parallel discrete event simulation (PDES) system [START_REF] Fujimoto | Parallel Discrete Event Simulation[END_REF] based on the Time Warp synchronization mechanism [START_REF] Jefferson | Virtual Time[END_REF].

The motivation for PDES is twofold: (i) to increase the execution speed; and/or (ii) to enable execution of larger simulation models compared to sequential DES. During the last decade, researchers have proved the efficiency of PDES methods in a number of application areas [START_REF] Cleary | Cost of State Saving & Rollback[END_REF][START_REF] Fujimoto | Parallel Discrete Event Simulation[END_REF][START_REF] Fujimoto | Parallel Discrete Event Simulation: Will the Field Survive?[END_REF]. Today, very challenging simulation problems are common in the industry and the neces-sary hardware for PDES is widely available, such as multi-processor workstations or reasonably efficient networks of workstations. Taking this into consideration one could expect PDES methods to be commonly used outside the PDES research community. This is however not yet the case [START_REF] Fujimoto | Parallel Discrete Event Simulation: Will the Field Survive?[END_REF]. One of the motivating factors for this is that very few, if any, PDES systems are sufficiently transparent. In most systems the user has to understand the underlying mechanisms and modify his (sequential) simulation code accordingly. This situation is by large a consequence of the quest for best possible performance. However, the execution of a simulation is only part of the simulation lifecycle [START_REF] Sargent | Verification and Validation of Simulation Models[END_REF]. Thus the performance gain from using a non-transparent PDES system is often outweighed by the additional time and effort that has to be spent in using the system.

In this paper we examine the possibilities to transparently implement incremental state saving in a PDES kernel based on Time Warp synchronization. The kernel is implemented in the C++ programming language. The rest of the paper is organized as follows. Section 2 describes several methods that have been proposed to reduce the state saving overhead in Time Warp. In Section 3 we describe the simulation kernel used in the experiments and in Section 4 a novel method to implement incremental state saving (ISS) in simulation kernels based on C++. This method has been implemented and tested in a cellular phone system simulator which is described in Section 5. Section 6 presents experimental results which show the impact on performance of the ISS method. Section 7 summarizes the contributions of the work presented in this paper.

State saving Issues in Time Warp

A PDES system can be expected to require significantly more memory than the corresponding sequential DES system to execute efficiently [START_REF] Preiss | Memory Management Techniques for Time Warp on a Distributed Memory Machine[END_REF]. In the case of Time Warp based PDES a naive implementation can use an arbitrarily large amount of memory compared to the corresponding sequential system [START_REF] Lubachevsky | Rollback sometimes works… if filtered[END_REF][START_REF] Lin | Optimal Memory Management for Time Warp Parallel Simulation[END_REF][START_REF] Lubachevsky | An Analysis of Rollback-Based Simulation[END_REF]. Since the motivation for PDES is to speed up the execution and/or enable the execution of larger simulation models it is essential to find mechanisms by which the state saving overhead can be reduced. We can distinguish between methods that: (i) reduce the amount of state information that is saved, thus reducing both execution time and memory consumption; and (ii) methods that can reclaim memory on demand, including memory of future objects (i.e. associated with events with timestamps greater than GVT [START_REF] Jefferson | Virtual Time[END_REF]), limiting the maximum memory needed [START_REF] Jefferson | Virtual Time II: Storage Management in Distributed Simulation[END_REF][START_REF] Lin | Optimal Memory Management for Time Warp Parallel Simulation[END_REF].

In the following we concentrate on the former category.

State Saving Techniques in Time Warp

The simplest method for state saving in Time Warp is to copy the entire state of a logical process (LP) each time it executes an event message. This is often referred to as copy state saving (CSS). However, we can expect rollbacks to be relatively infrequent compared to ordinary event executions in most Time Warp based simulations [START_REF] Fujimoto | Time Warp on a Shared Memory Multiprocessor[END_REF]. Furthermore, a state of an LP can be regenerated from an earlier state by re-execution of intermediate events. Accordingly, an LP does not need to save (or checkpoint) its state at each event execution but can choose to checkpoint only every th state [START_REF] Lin | Selecting the Checkpoint Interval in Time Warp Simulation[END_REF]. This is referred to as infrequent (or sparse or selective) checkpointing. Several methods have been proposed by which LPs adaptively can select their checkpoint intervals [START_REF] Rönngren | Adaptive Checkpointing in Time Warp[END_REF][START_REF] Fleischmann | Comparative Analysis of Periodic State Saving Techniques in Time Warp Simulators[END_REF]. These methods can easily be made transparent to the user.

Many challenging simulations, such as battle field simulations or simulations of large communication systems, are characterized by LPs with very large states where only a fraction of the state is updated in each event execution. In such applications it may be inefficient or even infeasible to save copies of the complete state which can be in the order of hundreds of kilobytes [START_REF] Cleary | Cost of State Saving & Rollback[END_REF]. In such applications it is often appropriate to use incremental state saving (ISS) [START_REF] Bauer | Reducing Rollback Overhead in Time-Warp Based Distributed Simulation with Optimized Incremental State Saving[END_REF][START_REF] Bruce | The Treatment of State in Optimistic Systems[END_REF][START_REF] Steinman | SPEEDES: A Multiple-Synchronization Environment for Parallel Discrete-Event Simulation[END_REF][START_REF] Steinman | Incremental State Saving in SPEEDES Using C++[END_REF][START_REF] Unger | An external state management system for optimistic parallel simulation[END_REF], in which only the updated parts of the state are saved. Thus the state saving mechanism builds a chain of state changes. In case of rollback the state is restored by undoing these changes.

Few systems, if any, implement transparent ISS primarily due to problems associated with identifying which parts of the state that are updated and when. This could be accomplished by use of special purpose hardware [START_REF] Fujimoto | Design and Evaluation of the Rollback Chip: Special Purpose Hardware for Time Warp[END_REF] or by special purpose simulation languages with compiler support for ISS. However, due to cost issues, a majority of PDES systems are implemented on top of some general purpose programming language such as C or C++. Several of these systems implement ISS. The SPEEDES environment features several interesting and efficient techniques to implement ISS [START_REF] Steinman | SPEEDES: A Multiple-Synchronization Environment for Parallel Discrete-Event Simulation[END_REF][START_REF] Steinman | Incremental State Saving in SPEEDES Using C++[END_REF]. Good performance results with ISS in the context of VLSI simulations [START_REF] Bauer | Reducing Rollback Overhead in Time-Warp Based Distributed Simulation with Optimized Incremental State Saving[END_REF] and simulations of large telecom networks [START_REF] Cleary | Cost of State Saving & Rollback[END_REF] have been reported. ISS has also been implemented using persistent objects [START_REF] Bruce | The Treatment of State in Optimistic Systems[END_REF] in an interesting effort to achieve a transparent implementation of ISS. However, these implementations of ISS have the common denominator that they put the responsibility on the user of writing either special purpose code for the ISS or calling special functions when updating state variables or to explicitly save state variables that have been updated. If the user fails to supply the necessary code for ISS in these systems, the state restoration in case of rollback may be corrupted. This is likely to generate non-deterministic, erroneous, simulation results. Finding this type of programming errors is often hard, even for a user with a thorough understanding of the Time Warp mechanism. Hence, we conclude that it is essential that ISS can be implemented as transparently as possible to the user. The question is to which extent this is possible.

Parallel Simulation Kernel

The Parallel Simulation Kernel (PSK) used in this study is based on Time Warp synchronization and runs on shared memory multiprocessor workstations. It is written in C++ and uses static assignment of the LPs to the processors, aggressive cancellation of events (i.e. events are cancelled as soon as an antimessage is received), and the direct cancellation optimization for shared memory machines described in [START_REF] Fujimoto | Time Warp on a Shared Memory Multiprocessor[END_REF]. The basic synchronization primitives (such as locks, and barriers) are supplied by the p4 macro library [START_REF] Butler | Monitors, messages, and clusters: the p4 parallel programming system[END_REF] making the PSK portable to a variety of multiprocessors. One modification has been made to this library, however, the queuing locks supplied in the package have been replaced by spin-locks.

PSK Structure

The PSK provides an application independent basis on top of which discrete event simulations can be built. The system is object oriented. When creating application specific logical processes the user inherits from a virtual LP class, see Figure 1. Associated with an LP is a StateHandler object which implements the state saving and restoration method. Through the StateHandler the LP object is able to save its state and to rollback to a previously saved state. These mechanisms are transparent to the user.

Figure 1. The LP inside the PSK

Each LP is also associated to an Event Set containing both executed and un-executed events and a State Set containing copies of old states to be used for state restoration purposes in case of rollback, Figure 2. When an event is executed, it usually modifies the LP state. Thus before an event execution the StateHandler constructs a data structure containing the information necessary to restore the old state and links it to the event.

Figure 2. The events and the state set

In the case of incremental state saving, the data structure storing the state restoration information is a list of back ups of old values of state variables which have been modified in the execution of the event. In case of rollback, the StateHandler parses all executed events backward up to the rollback point. For each event in the rollback the StateHandler traverses the list of old state variable values in reverse order to restore the state.

Transparent Incremental State Saving

ISS can be implemented by identifying all updates to state variables at runtime and backing up the old values of the state variables before the state variable in itself is modified. In particular this could be implemented by changing the semantics of all side effect operators on state variables. In C++ it is possible to define data types and change the semantics of the operators on Thus, ISS can be implemented by creating special data types to encapsulate all state variables with overloaded operators that automatically perform the necessary ISS back up. Introducing special data types for state variables is not a severe limitation as many DES systems and most PDES systems require that the user declares his state variables so that they can be easily identified. Though this method may appear as straight-forward to implement there are several aspects of this approach which merit further attention.

Data Encapsulation

Only data which is part of the state of an LP should be backed up by the ISS mechanism. Hence, it is necessary to be able to distinguish between state variables and other variables. To solve this problem, a template class has been created to encapsulate any data type used to declare state variables, Figure 3. It is referred to as the State<> class.

template<class T> class State { public: .... // overloaded operators private:

T m_data; };

Figure 3. The State class declaration

The user is required to declare his state variables as State<> encapsulated data. The declaration of a state variable of type integer:

int m_int;
is thus written as:

State<int> m_int;
This will create m_int as an object for which the operators are overloaded to backup the data by transparently calling a backup method of the StateHandler object. The state variable data is stored in the type int m_data data member of the State<> object.

Overloading Operators

The backup method must be called each time a state variable is modified. Thus any side effect operator must be overloaded. In C++ this includes the =, ++, --, +=, -=, *=, /=, %=, ^=, &=, |=, >>= and <<= operators. But to achieve complete transparency, all other operators on the State <> objects must be overloaded. This is to allow the user to write expressions such as: m_int + 2 or 2 + m_int or m_int + m_int which perform calls to:

operator+<int>(State<int>&, int); operator+<int>(int, State<int>&); operator+<int>(State<int>&, State<int>&);
The proposed State<> template, its associated operators and copy constructor provide the user with a transparent ISS mechanism for all simple data types, such as integers, floats etc. However, arrays and other compound data objects deserve special attention.

Some operators, such as the subscript([]) operator, may be overloaded using different prototypes. That is, the user can define compound classes for which he can overload the subscript operator to return an object of any type of data member. Hence, one cannot make generic assumptions on the resulting type when applying subscript. Consequently, the State<> class cannot provide a generic subscript operator to ensure transparency. A simple solution is not to declare indexed state variables as State objects. Instead, each data member of indexed objects or classes should be State<> objects. This ensures that the state of the LP will be correctly backed up. An example illustrating this is found in Figure 4.

Initialization of Incremental State Saving

A problem related to automatic incremental state saving is how to initialize the state saving. When the LPs are created, their data is initialized, i.e. modified. These initializations will cause calls to the backup method of the StateHandler. This is not desirable since the simulation has not yet started and the StateHandler objects may not yet exist. Consequently, the proposed mechanism must be able to distinguish an initialization from an assignment, though both may use the same methods in C++.

In our PSK this has been solved by performing a call to the backup method through a pointer. When a State<> object is created, the pointer is set to a dummy backup method which does nothing. Consequently, backup calls performed during the initialization are harmless. When required, each LP enables the backup ability of all its internal State<> objects by changing the backup method pointer of these objects. To enable this, the State<> objects link themselves into a list accessible to the LP when they are created. Currently, the backup capability of the State<> objects of an LP is only enabled on the completion of the initialization of the LP. Hence, the state of an LP cannot be augmented after the initialization unless special provisions are made to enable their backup capabilities as these parts otherwise would not be backed up. a temporary object of type A is created on the stack, this object is copied to m_a and immediately deallocated from the stack. This could interfere with the incremental state saving mechanism if the temporary object contains State<> objects, in which case the temporary object would backup itself. This should not occur since the temporary object is not part of the LP state. Furthermore, it could cause the StateHandler to try to restore the state of non-existing objects in the case of rollback. Two cases has to be taken into consideration. The temporary object could be created: (i) during the initialization phase; or (ii) after the initialization phase. In the first case the backup mechanism is not yet enabled but the temporary object will link itself to the LP list as described in Section 4.3. Since the temporary object will be deleted at the end of the LP creation, it should be unlinked from the linked list when its destructor is called.

If the temporary object is created during the execution it will not have its backup ability enabled. However, the State<> objects of the temporary object links and un-links to/from the list of State<> objects of the LP as described in Section 4.3. This could potentially be costly if the temporary object contains a large number of State<> objects. To prevent this a global variable is used as a flag which is set upon completion of the initialization. When created, a State<> object checks this flag to see if it should link to the list or not.

Pointers and Dynamic Memory Allocation

In a general case the state of an LP may contain pointers to data objects. These data objects could be dynamically allocated and deallocated. Our current implementation of ISS does not yet support these data types. In fact many PDES systems put the restriction that the state size of an LP has to be staticly defined. However, we will outline a possible solution to this problem which we intend to implement in a near future.

Integer arithmetic on pointers has to be supported. To guarantee transparency, operators acting both on State<> encapsulated pointers and integers should be overloaded in addition to the operators overloaded for non-pointer types. Since these operators do not exist for other objects than pointers, a template subclass of State<> will be declared, referred to as RefState<>. This will guarantee that pointers are correctly handled.

Transparent backup of dynamically allocated objects can be performed with the restriction that such objects only contain data members declared as State<> objects. To ensure that the backup capability of these objects are enabled, Section 4.3, the dynamically allocated object has to inherit from a base class where the constructor enables the backup capability. Furthermore, the method has to guarantee that a dynamically allocated object is not deallocated before it can be guaranteed that it will never be used in a rollback. For this purpose, the new and delete operators of the base class has to be overloaded. The base class contains a flag indicating if the user tried to delete the object or not. On a delete call, the memory block is not really deallocated, only the flag is set. The block can only be deleted in fossil collection and if it is tagged as deleted.

Memory Management Overhead

The proposed method for incremental state saving will cause the creation of backup objects each time a State<> variable is modified. Thus it is essential to have an efficient memory handler. We can expect that a majority of the data objects which will be backed up are small (such as 4-byte integers). Dynamically allocating and manipulating a large number of such objects in a list is not efficient. To alleviate this problem an improved memory manager for ISS has been introduced which treats backup objects containing less than 8-bytes of data (the size of a double i.e. the biggest C++ built-in type) in a special way. The memory manager implements linked lists of arrays of update structures. Each update structure can hold backup data of up to 8-bytes length. When an event is executed the StateHandler will request arrays of update structures to store backups of state variables less than 8 bytes in from the memory handler on demand. Thus the linked list operations for small backup objects are replaced by incrementing an index in an array. This scheme also alleviates the problem of deallocating the backup structures at fossil collection. With this method all small backup objects can be deallocated efficiently by returning the update structure arrays to the memory handler. Only backup objects larger than 8 bytes are dynamically allocated and stored in the linked list.

Level of Transparency Achieved

The proposed mechanism is not completely transparent. In particular, the user has to explicitly declare state variables as State<> or RefState<> objects. In addition, some minor problems remain. The compiler is sometimes able to automatically cast from a user defined type T to a given type X, but not from State<T> to X, though a cast operator from State<T> to T is provided in the State<> class. Thus, the user might have to explicitly make some casts which were not previously needed.

The user should also be cautious when redefining the copy constructor or the assignment operator of compound classes used for state variables. If the user defines his/hers own copy constructor and/or assignment operator for such classes, he/she should call the copy constructor or assignment operator of all contained State<> declared objects.

The proposed method differs from what can be achieved by compiler based methods in that there is no way of preventing the user from, intentionally or not, bypass the backup mechanism by modifying State<> data through pointers.

The Cellular Phone Simulator

In this study we have tested our ISS implementation on a simulator of a cellular communication system. Good performance for parallel simulation of similar systems has been reported in e.g. [START_REF] Carothers | A Case Study in Simulating PCS Networks Using Time Warp[END_REF]. Our simulator has previously been described in [START_REF] Liljenstam | A Model for Parallel Simulation of Mobile Telecommunication Systems[END_REF] and we will limit ourselves to describing some of its general properties.

The Cellular Phone Model

A cellular communication system is divided into a number of cells. To each cell a certain number of radio channels are allocated. Mobile Stations (MSs) residing in a cell can allocate any of the free radio channels allocated to the cell to send and receive phone calls. The same channel can be used in several cells that are sufficiently spaced apart since interference will be negligible.

When a mobile terminal moves from one cell to another it may become necessary to connect the MS to another base station, this is called a handover. If an attempt is made to make a call to or from a MS in a cell where there are no available channels, the call is blocked. If an ongoing call can not be handed over to a cell because there are no available channels it may be forced to terminate in which case the call is said to be dropped.

Radio channels can be allocated to cells staticly using Fixed Channel Assignment (FCA) or dynamically using some Dynamic Channel Assignment (DCA) scheme.

The simulation model consists of three submodels in a similar manner to the MaDRAS simulator [START_REF] Andersin | Distributed Radio Resource Allocation in Highway Microcellular Systems[END_REF]: the tele-traffic model, the mobility model, and the propagation model.

The teletraffic model describes the arrival process of new calls and their duration. The call arrivals form a Poisson process with a mean arrival rate , and exponential call duration with mean . The mobility model describes the movements of the mobile stations (MSs). The propagation model describes distance dependent propagation loss using a statistical model for correlated log-normal shadow fading. The path losses at a specific position are regarded as constant over time, so that at a position p the gain from a transmitting station s is G s,p forming a twodimensional matrix for each base station that describes the geography.

Each MS performs a "resource reallocation" procedure every 500 ms of simulated time. This procedure involves calculating the uplink and downlink Signal-to-Interference Ratio (SIR) and comparing it to a "least acceptable"-threshold to determine if the call should be dropped. Other BSs are also compared against the current connection and if another BS is found to be significantly better a handover is attempted. If a handover can not be completed due to lack of free channels the MS remains with the current connection.

Channel selection is done stochastically with equal probability among the available free channels on the BS. The uplink and downlink channels are changed at the same time and hence treated as one unit. Path losses are regarded as equal in both directions due to reciprocity. The radio channels are assumed to be orthogonal, so adjacent channel interference has been neglected.

The positions of the mobiles are updated every time there is new data to be read from the gain matrix, i.e. each mobile schedules a position update event for itself to occur when it has travelled the distance between two samples in the gain matrix. This event will cause the mobile to read the new radio gain from the matrix.

Each channel is a Logical Process (LP) in our model. There is also one generator LP that creates a mobile station when a new call arrives and sends it to the first channel assigned to it. Figure 5 shows an example of the communication patterns in the model. When a new call arrives to the system, a corresponding MS is created by the generator. After a BS has been selected, the new MS then proceeds to make its initial channel selection. A request is sent to all channels that are available on the selected BS to find out which channels are free at this time. One of the free channels is selected (if there is one, otherwise the call is blocked) and the MS object is sent to that channel. Similarly, when an MS decides to perform a handover to another BS a new set of requests are sent out to all channels available on the new BS and the selection is made. If no free channels are found and link quality is insufficient the call is eventually dropped. Requests made for the same channel from different MSs at the same simulation time is handled through an event priority scheme ordering the LPs so that one channel selection interaction is always completed before the next request message is processed. A channel holds information about all entities (base stations and mobiles) communicating on that channel.

Characteristics of the models relevant to state saving issues

With each model we have simulated two scenarios: (i) a system of 7 cells; and (ii) a system of 67 cells. These scenarios are referred to as the small and large area respectively, where the larger area is closer to a realistic system. Radio signal propagation is described by a read only matrix which is 0.3 Mb for the small area and 27Mb for the large area.

Each event will only modify one mobile station out of all the connections contained in the Channel object. The size of the Channel state for the FCA case is 1720 bytes and one BS-MS connection is only 156 bytes. Furthermore, most events are simple position updates in which case only part of the BS-MS connection is modified. Hence, on average only about 2% of the state is updated in an event which makes incremental state saving seem like a good candidate as suggested in [START_REF] Cleary | Cost of State Saving & Rollback[END_REF]. However, the state saving overhead is only a relatively small fraction of the total time to process an event due to the large event granularity. The mean event execution time is about 260 microseconds for the small area and 750 microseconds for the large area. The higher event execution time for the large area is primarily due to an increased cost for interference computations. The state size remains the same for both areas and the average time to save a state using copy state saving is about 140 microseconds. This means that for any improved state saving scheme (compared to pure copy state saving) we can at most cut the execution time by at about 45% for the small area and 15% for the large area by reducing the state saving overhead.

When using states sizes adjusted for a DCA model the situation becomes quite different. The mean event execution time increases slightly to about 430 microseconds for the small area and 830 microseconds for the large area, but the average state saving time increases to about 2200 microseconds for both models. This is due to a dramatic increase in state size for the Channel LP to 42776 bytes. The size of the BS-MS connection increases to 636 bytes. The most frequent events are still position updates. Consequently, the average fraction of the state updated in an event execution is even less for the DCA model than for the FCA model. In an average event execution less than 0.2% of the state free / busy "I want BS i, is channel free?" all available channels on BS i all available channels on BS j Initial channel selection handover is updated. The state saving overhead is quite severe when using copy state saving and in this case accounts for about 75 -85 % of the total time to process an event. Thus, we hypothesize that the DCA models will benefit even more from ISS than the FCA model.

Experimental Results

In this study we have compared the impact of four different state saving mechanisms on the cellular phone simulator for the FCA and DCA models:

• Copy State Saving (CSS). The state of the LP is saved at each event execution.

• Sparse State Saving (SSS) with fixed state saving interval. The best state saving intervals were experimentally determined to be 5 for the FCA model and 10 for DCA model respectively.

• Transparent Incremental State Saving (TISS) which is the method described in this report.

• User dependant Incremental State Saving (UISS). This is a more conventional ISS method in which the user is required to explicitly call a backup function. The cellular phone models are such that only a well defined part of the state is updated on each event execution. Consequently, only a few calls to the backup function are necessary on each event execution.

An important aspect of the transparency achieved by the TISS method is that the only changes that had to be made to the user code of the simulation models was to declare the state variables as State<> objects. By defining a macro for the State<> declarations exactly the same code could be used for CSS, SSS and TISS. This has several important implications: i) it is of great value when selecting the appropriate state saving method for a particular application also making it possible to support a wider variety of applications with a single user interface to the simulation system; (ii) it forms a basis for building a system which automatically selects the best state saving method for individual LPs.

The experiments were performed on a SUN Sparcstation 10 with 4 processors, 128 Mb primary memory and 1 Mb cache per processor. The average rollback length, in these experiments, varies between 3 and 4.

Speed-up

The performance results in Figures 6 through 9 are shown as the relative speed of the proposed state saving algorithms compared to copy state saving. Figures 6 and6 depicts the performance for the FCA model for small and large areas respectively. As predicted in Section 5.2 the improvement from reducing the state saving for this model would be limited to 15% for the large area and 45% for the small area. The performance results indicate that such improvements are possible with sparse state saving. To some extent the reduced memory consumption also results in improved performance of the memory system. Furthermore, the ISS methods are outperformed by the SSS method in these experiments. This is primarily due to the lower overhead in execution time for this method for the relatively small state sizes of this model. Figures 8 and9 show the performance of the state saving algorithms for the DCA model. The DCA model differs from the FCA model in that the states of the LPs are significantly larger in the DCA model. Consequently, these figures reveal that the ISS methods perform significantly better than CSS and SSS. Furthermore, we see that there is a significant cost for the transparency of the TISS method compared to the UISS. We do, however believe that this cost is justified in most cases as it alleviates the user from the burden of having to explicitly deal with the underlying state saving mechanism. The speed-up achieved by the ISS methods are higher than what could be attributed to the reduction of the state saving overhead alone. Examining Figure 13 we see that this phenomenon is not due to an increased efficiency. We 0.8 0.9 believe that the additional performance improvement mainly is caused by an improved locality which improves cache performance. This hypothesis is supported by the fact that the smaller model, for which the relative memory consumption reduction is larger, exhibits a larger improvement.

Memory Consumption

Figure 10 and 11 show the memory consumption for the FCA and DCA models respectively for the large area. The memory consumption was recorded during long runs (5000 seconds of simulated time) for which the memory used by the simulator stabilized. In both models, the simulator first allocates a 27 Mb data structure to store the area simulated. Hence, only memory above 27 Mb is significant as far as state saving is concerned. These figures clearly show that both sparse and incremental state saving can reduce the memory consumption significantly. UISS performs slightly better than TISS which is explained by the fact that while TISS saves several small pieces of the state UISS can save the same information as a single or a few larger pieces reducing the overhead.

Efficiency

Changes to one of the mechanisms in a Time Warp system can sometimes affect the optimistic synchronization substantially. This effect has been demonstrated for event list management [START_REF] Rönngren | Efficient Implementation of Event Sets in Time Warp[END_REF] and other types of memory management policies [START_REF] Das | A Performance Study of the Cancelback Protocol for Time Warp Parallel Simulation[END_REF]. Figures 12 and13 show the impact of the state saving mechanism on the efficiency, defined as the ratio of committed events to executed events (committed events and events that are rolled back). These figures show that the state saving methods had little impact on the efficiency for these benchmarks.

Conclusions

Transparency of the state saving mechanism is essential for the acceptance of PDES methods by a wider audience as it relieves the user from the burden of having to understand and interact with an often intricate mechanism. In this paper we have discussed a method to implement incremental state saving in a Time Warp simulation system built on top of the C++ programming language. The method is based on the ability to overload operators in C++. The most prominent characteristics of this approach is that it achieves a high degree of transparency with acceptable overhead compared to a non-transparent implementation of ISS.

In the proposed method the only changes required to the users application code is to use special type declarations of the state variables. In particular, this allows the same user application code to be used regardless of whether the underlying state saving mechanism used is copy state saving, sparse state saving or incremental state saving.

The usefulness of the proposed method has been demonstrated by simulations of large realistic simulation models of cellular phone systems. The experimental results show that incremental state saving is important to achieve good performance in cases where the state vectors are large and only a small fraction of the state is updated on average. In some cases the execution time was reduced by more than an order of magnitude compared to conventional copy state saving.

In future systems we believe that the system should be able to select the best state saving method for individual LPs at run time. This will be facilitated if the state saving mechanism can be made transparent.

Figure 4 .

 4 Figure 4. An example of correct data encapsulation in the proposed incremental state saving scheme 4.4. Temporary Objects C++ compilers can sometimes create temporary objects automatically. Consider the example in Figure 4. If the user writes a statement like: m_a = A();

  A& operator[](int index);

Figure 5 .

 5 Figure 5. Basic communication pattern in the simulation model.

Figure 6 .

 6 Figure 6. FCA model, small area simulated on 2 and 4 processors.

Figure 7 .

 7 Figure 7. FCA model, big area simulated on 2 and 4 processors.

Figure 8 .

 8 Figure 8. DCA model, small area simulated on 2 and 4 processors.

Figure 9 .

 9 Figure 9. DCA model, big area simulated on 2 and 4 processors.

Figure 10 .Figure 11 .

 1011 Figure 10. Memory consumption for the FCA model

Figure 12 .Figure 13 .

 1213 Figure 12. Efficiency of the state saving algorithms in the FCA model


Denis Besnard
email: denis.besnard@ncl.ac.uk

David Greathead
email: david.greathead@ncl.ac.uk

Gordon Baxter
email: g.baxter@psych.york.ac.uk

When mental models go wrong. Co-occurrences in dynamic, critical systems

Keywords: Mental models, human error, cognitive psychology, critical systems. 1

This paper highlights a psychological phenomenon affecting the accuracy of mental models. It occurs when two consecutive events happen as expected by an operator. Typically, such a situation reinforces the confidence in one's mental model. However, consecutive events can happen as a random co-occurrence, for reasons that actually differ from the ones believed by the operator. Nonetheless, because of the consistency between the environmental data and the operator's expectations, one event can be taken to be the cause of the other. When this false belief happens, the mental model is erroneously assumed to be valid. We discuss this phenomenon and its potential disastrous consequences using the example of a real commercial air crash. We finally address some implications for systems' design and support tools.

INTRODUCTION

During a presentation, one of the authors' colleagues using his laptop for displaying slides got interrupted when his computer's screen went blank. He hit the track pad of his laptop in case the latter had gone into sleep mode but the video signal did not come back. As he was using an adapter for the VGA display cable, he suspected the connection had come loose. After some seconds during which he tightened more firmly the adapter and the display cable together, the video came back on. The problem was solved and, hopefully, the adapter would now behave normally. Some minutes later, the same scenario happened again and our colleague performed the same actions as before. He hit the track pad but this triggered no signal. He then modified the position of the display adapter so that the weight of the cable would not pull on it. A couple of seconds later, the video was back on again. The third time the scenario happened, it became obvious, at least to everyone except the person using the laptop, that the manipulation of the display adapter and the video coming back on was pure coincidence. We discovered that the machine was going into sleep mode and needed about 6 to 8 seconds to exit it. It is likely that any action carried out just before the video signal came back would be considered as the solution.

Through this simple -yet real-example, we wish to highlight an interesting cognitive feature that is common across domains. Humans tend to consider that their vision of the world is correct whenever events happen in accordance with their expectations. However, two sequential events can happen as expected without their cause being captured. When this is the case, humans tend to treat the available evidence as exhaustively reflecting the world, erroneously believing that they have understood the problem at hand. These co-occurring events can seriously disrupt situation awareness when humans are using mental models that are highly discrepant to reality but nonetheless trusted.

In the next section, we consider how the mechanisms leading to the aforementioned error can be explained using the concept of mental models. We then assess the role of this error in dynamic, critical applications using the example of a commercial air crash (section 3). We finally discuss some ways for improving the design of critical systems to avoid such problems (section 4).

MENTAL MODELS

Limitations in memory and processing capabilities mean that humans cannot handle the totality of the information displayed in their environment. Instead, they build representations that are meant to support behaviour [START_REF] Rabardel | Les hommes et les technologies[END_REF]. These mental models can take various forms (see [START_REF] Moray | A taxonomy and theory of mental models[END_REF] for a taxonomy of the different types). Since we are describing cognitive activities in situ, we take mental models to be scarce, goal-driven images of the world that are built to understand the current and future states of a situation. What characterises best mental models is their incompleteness. Their content is only a partial representation of the environment and their scope is limited [START_REF] Sanderson | Knowledge acquisition and fault diagnosis: experiments with PLAULT[END_REF][START_REF] Sanderson | Predicting fault diagnosis performance: why are some bugs hard to find ?[END_REF]. They are essentially built from a) the knowledge needed for pursuing a given goal and b) some data extracted from the environment. The resulting image of the world is one in which the essential features of a problem are overemphasized whereas the peripheral data can be overlooked [START_REF] Ochanine | Le rôle des images opératives dans la régulation des activités de travail[END_REF]. In this respect, mental models are described as homomorphic representations of the world [START_REF] Moray | Intelligent aids, mental models, and the theory of machines[END_REF]. They are simplified, cognitively acceptable versions of a too complex reality. In dynamic processes, it may be the case that mental models are correct at early stages of the interaction. Over time, with the evolution of this interaction and possible degradation of the situation (due to an emergency, for instance), the model gets simplified and becomes more based on correlation between system elements, such that only the best predictors of the system's states are taken into account [START_REF] Baxter | Towards a classification of state misinterpretation[END_REF].

Although building and maintaining mental models are core activities in the control of dynamic complex systems, human operators also have to perform several other critical tasks that affect system performance. They have to plan actions, control movements, exchange information with collaborators and so on. This complex combination of tasks has to be executed with a limited amount of cognitive resources. For this reason, operators tend to save resources whenever it is possible using mechanisms such as selective memory and heuristic, shortcut-based reasoning [START_REF] Rasmussen | Information processing and human-machine interaction[END_REF]. In the case of mental models, saving resources causes them to be built on the basis of partial pieces of evidence. However, this has to be seen as the consequence of cognitive limitations where problems are solved according to an intuitive cost-benefit trade-off. Since [START_REF] Simon | Models of man[END_REF] concept of bounded rationality, it is accepted that cheap adequate solutions are often preferred to costly perfect ones. In other words, people tend to satisfice rather than optimise, settling on a solution that is deemed good enough even though it may be sub-optimal.

The consequences of flawed mental models can be disastrous when operators are interacting with dynamic critical systems, e.g. commercial airplanes. Operators of these systems (i.e. pilots) are sometimes faced with unexpected problems which they have to diagnose and resolve. This local troubleshooting activity, which is inserted in the more global objective of piloting the aircraft, involves the construction of an explanation in real-time. Factors such as limited cognitive resources, confirmation bias [START_REF] Klayman | Hypothesis testing in rule discovery: Strategy, structure and content[END_REF] and time pressure can mean that pilots construct an erroneous explanation of such incidents. Flaws in mental models are detected when the interaction with the world reveals unexpected events. However, these inaccurate mental models do not always lead to accidents. Very often, they are recovered from. In this respect, error detection and compensation are significant features in human information processing. The weakness of mental models lies in their poor requirements in terms of validity: If the environmental stream of data is consistent with the operator's expectations, that is enough for the operator to continue regarding the mental model as valid. The understanding of the mechanisms generating the data is not a necessary condition.

We are not concerned here with how operators could build exhaustive mental models, as their incompleteness reflects a strong need for information selection. Rather, the issue of interest is to understand the conditions in which operators believe they have a good picture of the situation whereas the underlying causal mechanisms have not been captured. One of these conditions is the co-occurrence of events. The types of problem that can arise from this phenomenon are illustrated in the next section.

THE KEGWORTH ACCIDENT

The Kegworth air crash (Air Accidents Investigation Branch, 1989) was chosen to illustrate the problems that can be caused by co-occurring events, for two reasons. First, it is a well-known accident, allowing us to ground our discussions in a case that is now well-understood. Second and most importantly, this crash offers a very good -although tragic-instance of the mechanism we wish to discuss in this paper. Although the Kegworth accident report was issued several years ago, the co-occurrence angle has not been studied to date. For these two reasons, we believe further progress can be made in understanding the psychological mechanisms that were causally involved in the crash. There is also some value in achieving this understanding since this mechanism is believed to be domain independent. Therefore, the Kegworth accident may provide data from which we can gain useful knowledge that can be generalised to humanmachine interaction in the large.

On the 8th of January 1989, a British Midland Airways Boeing 737-400 aircraft crashed into the embankment of the M1 motorway near Kegworth (Leicestershire, UK), resulting in the loss of 47 lives. The crash resulted from the flight crew's management of a mechanical incident in the left (#1) engine. A fan blade detached from the engine, resulting in vibration (severe enough to be felt by the crew) and the production of smoke and fumes that were drawn into the aircraft through the air conditioning system. The flight crew mistakenly identified the faulty engine as the right (#2) engine. The cockpit voice recorder showed that there was some hesitation in making the identification. When the captain asked which engine was faulty, the first officer replied 'It's the le… it's the right one', at which point the right engine was throttled back and eventually shut down. This action coincided with a drop in vibration and the cessation of smoke and fumes from the left (faulty) engine. On the basis on these symptoms, the flight crew deduced that the correct decision had been taken, and sought to make an emergency landing at East Midlands airport. The left engine continued to show an abnormal level of vibration for some minutes, although this seems to have passed unnoticed by the pilots. Soon afterwards, the crew reduced power to this engine to begin descent, whereupon the vibration in the engine dropped to a point a little above normal. Approximately ten minutes later, power to the left engine was increased to maintain altitude during the final stages of descent. This resulted in greatly increased vibration, the loss of power in that engine and the generation of an associated fire warning. The crew attempted at this point to restart the right engine but this was not achieved in the time before impact, which occurred 0.5 nautical miles from the runway.

In addition to the crew's mistakes, several other factors contributed to the accident. When later interviewed, both pilots indicated that neither of them remembered seeing any indications of high vibration on the Engine Instrument System (EIS; see Figure 1). The captain stated that he rarely scanned the vibration gauges because, in his experience, he had found them to be unreliable in other aircraft. It is also worth noting that the aircraft was using a new EIS which used digital displays rather than mechanical pointers. In a survey carried out in June 1989 (summarised in the accident report), 64% of British Midland Airways pilots indicated that the new EIS was not effective in drawing their attention to rapid changes in engine parameters and 74% preferred the old EIS. The secondary EIS, on which the vibration indicator was located followed standard design practice and hence did not include any audio or additional visual warning to indicate excessive readings. As another contributing factor, the crew workload increased out of control. Some time after the #2 (working) engine had been erroneously shut down, the captain tried without success to stay in phase with the evolution of the incident. He was heard on the cockpit voice recorder saying:

'Now what indications did we actually get (it) just rapid vibrations in the aeroplane -smoke…'. At this point, the crew were interrupted with a radio communication from air traffic control. Later, the flight service manager entered the flight deck and reported that the passengers were very panicky. This further distracted the flight crew and the captain had to broadcast a message of reassurance to the passengers. Both the captain and first officer were also required to make further radio communications and perform other duties in preparation for the landing. All of these actions affected the degree of control of the emergency. Finally, it is worth noting that while both the captain and the first officer were experienced (over 13,000 hours and over 3,200 hours flying time respectively), they had only 76 hours experience in the Boeing 737-400 series between them.

DISCUSSION

In this section, we briefly address some general issues about mental models in complex dynamic systems (for a definition of these systems, see [START_REF] Brehmer | Man as a stabilizer of systems. From static snapshots of judgement processes to dynamic decision making[END_REF][START_REF] Cellier | Expertise in dynamic systems[END_REF].

Based on our analysis of the Kegworth accident data, we then make some general suggestions for improving the dependability of systems that are deployed in complex dynamic domains. We conclude the discussion by outlining some limits that need to be made explicit when studying human error.

EIS

There are some similarities between the particular flaws in mental models that we have identified using the Kegworth accident data, and some existing types of human error. Nevertheless, our approach can be distinguished from mode confusion [START_REF] Crow | Models of mechanised methods that integrate human factors into automation design[END_REF]Leveson et al., 1997;[START_REF] Rushby | Modelling the human in human factors[END_REF][START_REF] Rushby | An automated method to detect potential mode confusions[END_REF] in that the automation behaves as expected in our case. It can also be distinguished from fixation errors [START_REF] De Keyser | Fixation errors: Failures to revise situation assessment in dynamic and risky systems[END_REF]) in that we are concerned with the processes involved in the construction of mental models rather than their persistence.

Mental models in a dynamic world

Attempting to save cognitive resources causes mental models to be biased in such a way that partial confirmation is easily accepted. Instead of looking for contradictory evidence, people tend to wait for consistent data. This phenomenon, called confirmation bias [START_REF] Klayman | Hypothesis testing in rule discovery: Strategy, structure and content[END_REF], has already been studied in human-machine interaction (e.g. [START_REF] Yoon | Deep-reasoning fault diagnosis: an aid and a model[END_REF]. The corollary of confirmation bias is that people overlook contradictory data. This is one explanation for the reinforcement of flawed mental models. In the case of the Kegworth accident, an erroneous decision coincided with a reduction in the level of the symptoms which lasted for some twenty minutes. When it is compatible with the operator's expectations, this type of cooccurrence probably works against rejection of the existing mental model. It also makes it harder to integrate any contradictory evidence that may subsequently become available.

Operators are more likely to reject any information that is not consistent with their expectations, rather than update their mental model. The latter has a cost that operators cannot always afford in time-critical situations. In the end, data can be abusively reinterpreted to fit the model that operators have of a situation [START_REF] Moray | Intelligent aids, mental models, and the theory of machines[END_REF]. This confirmation bias is probably the outcome of an economy-driven reasoning: following a line of least effort [START_REF] Rasmussen | Information processing and human-machine interaction[END_REF], operators can treat random data as meaningful if it matches their vision of the world.

Operators can erroneously maintain as valid, representations that have already departed from a reasonable picture of the reality. In dynamic situations, one reason is that operators try to avoid the cost of revising their mental model as long as it allows them to stay more or less in control.

In other words, they satisfice. Because mental models are constantly matched against the feedback from the process they control, they are fed with a constant stream of data. However, there exist situations where the feedback is discrepant from the operator's expectations. When this discrepancy provokes such a loss of control that required tasks cannot be run anymore, some costly revision of the mental model as well as diagnostic actions are needed [START_REF] Rasmussen | Diagnostic reasoning in action[END_REF]. This is a non-trivial task in dynamic situations such as piloting an aircraft in that some control is already lost and the crew is required to run, coordinate and share two processes at the same time. One is a rule-based control of the flight parameters: the plane must continue to fly. The other process is information gathering and integration. The potential work overload caused by this dual activity may explain why outdated (flawed) mental models are maintained even after the detection of some mismatches. Provided they can keep the system within safe boundaries, operators in critical situations sometimes opt to lose some situation awareness rather than spend time gathering data at the cost of a total loss of control [START_REF] Amalberti | La conduite de systèmes à risques[END_REF]. Critical situations can be caused by the combination of an emergency followed by some loss of control. When this happens, there is little room for recovery. The Kegworth accident probably falls into this category. When the flight crew got around to thinking about checking the engine data, they were distracted by other more urgent tasks. The emergency nature of the situation and the emerging workload delayed the revision of the mental model which ultimately was not resumed.

Implications for the design of dependable systems

The Kegworth crash highlights that the control of automation is a real dialogue between operators and machines. When this dialogue fails because information flow does not help situation awareness, events are likely to be processed in a sub-optimal manner. The following discussion will not focus explicitly on co-occurrences as they are a fine-grained mechanism as compared to the complexity and diversity of cognitive activities involved in the control of dynamic processes. Instead, we think a wider discussion is needed to assess more precisely the stakes of a more reliable interaction between operators and machines. We believe that humanmachine interaction could be improved in two complementary ways.

Training operators

Operators must be made more aware of human factors through training and education. Some psychological mechanisms can then become more obvious to the operators themselves and positively influence the perception that they have of their own performance. In aviation, for example, human factors have been an integrated part of pilot training for many years (e.g. [START_REF] Green | Human factors for pilots[END_REF]. Nowadays, these training schemes include explicit consideration of cognitive psychology, decision making and human error. Within the cockpit, these contents contribute to better communication, more efficient distributed decision making and improved stress management. Looking at the broad picture, human factors must be regarded as one of the many elements that keep the commercial accident rate constant despite the increase in traffic. In the near future, it will be the case that more and more pilots, who will have been educated in human factors from the early stages, will contribute to an even higher degree to critical systems' dependability.

Embedded agents

The automation must be designed to be aware of the operators by having some embedded knowledge of human reasoning as well as some screening functions (e.g. [START_REF] Boy | Operator assistant systems[END_REF][START_REF] Rasmussen | Technologie de l'information et analyse de l'activité cognitive[END_REF]. This would allow machines to anticipate operator's decisions, provide more appropriate context-sensitive alarms and support for critical decisions. Expected benefits include the provision of some assistance in emergency situations before matters become too critical. Operators need more help in those situations for which they have not been trained, than on nominal settings. It implies that systems at large have to be designed in such a way that unexpected events can be recognised and appropriately handled by support tools. [START_REF] Wageman | Analyse des représentations initiales liées aux interactions hommeautomatique (IHA) en situation de contrôle simulée[END_REF] argues that interfaces can typically flood operators with extra data at a time of the process (e.g. emergencies) where few resources are still available. From our point of view, we think it is precisely because operators' intentions are not captured by automated systems that over-information occurs. This issue has been developed by [START_REF] Hollnagel | Information and reasoning in intelligent decision support systems[END_REF] who proposed the concept of intelligent decision support systems, and further addressed by [START_REF] Filgueiras | Human performance reliability in the design-for-usability life cycle for safety human computer interfaces[END_REF]. One way forward may be to design support tools that incorporate models of the system they are a part of. This would permit the automation to predict the future states it is going to enter given the inputs coming from the environment and the operator. Without this kind of assistance, operators will have to continue looking for data during critical phases of process control. The use of embedded agents to support decision making has already started in the aviation domain. The most notable example is probably Hazard Monitor (e.g. [START_REF] Bass | Knowledge requirements and architecture for an intelligent monitoring aid that facilitate incremental knowledge base development[END_REF]. This system tracks user interactions and tries to match these against stored expectation networks of normative behaviour as a way of doing plan recognition. On the basis of what it detects, Hazard Monitor can then make suggestions about what the user should consider to do next. These suggestions are prioritised, and initially start as gentle reminders about something that needs to be done. The second level is a stronger reminder that it is getting more critical that a particular action be performed. Finally, as a last resort, Hazard Monitor can directly intervene to take the action. Even though Hazard Monitor is a sophisticated system, it still only deals with routine interaction. In other words, it is largely restricted to dealing with plans that would be used in normal circumstances. In the particular case of co-occurring events, it would not be able to offer any assistance to avoid the potential problems. Nonetheless, Hazard Monitor is a concrete example of a decision support agent that highlights a tangible research stream in critical systems' design (see [START_REF] Jennings | Applications of intelligent agents[END_REF], for a more complete list of applications of intelligent agents).

We believe that research in intelligent agents can enhance the reliability of human-machine systems by improving the human-machine interaction in general. Agents need a) to provide support to help operators make the right decisions and take the appropriate actions, and b) to act as barriers when they try to perform erroneous actions. However, we are aware of some limitations. For instance, the notion of correctness itself is difficult to capture since it is highly context-dependent. Moreover, some totally unexpected failures, such as the one causing the crash-landing of a DC-10 in Sioux-City (NTSB, 1990), can make agents useless, if not undesirable. It could also be argued that agents based on inductive methods of reconstructing pilots' intentions can have flaws in data selection. Although the latter is a distinct possibility, these flaws may be caused by our current state of knowledge rather than by the principle of inferring mental models from interaction data. As suggested by [START_REF] Hollnagel | Cognitive systems engineering: new wine in new bottles[END_REF], more research is needed in cognitive ergonomics and embedded agents design. In the field of human-machine interaction, this would facilitate the integration of such mechanisms as construction, revision and decay of mental models. New research in neuroergonomics (e.g., [START_REF] Hancock | The future of neuroergonomics[END_REF][START_REF] Parasuraman | Neuroergonomics: research and practice[END_REF] may help to provide more detailed information about how these processes occur.

Supporting operators towards aviation safety

Generally speaking, we see our recommendations as local measures belonging to a broader context where the operator still retains the overall responsibility as the final decision maker. But for operators' decisions to be accurate in emergency situations, for example, a fast and clear understanding of the situation is needed. We feel that dedicating some computing power to information gathering, analysis and prediction will feed operators' mental models with more useful data as well as supporting a better interaction between human agents and complex dynamic critical systems. This matters for critical operations such as aircraft piloting (see [START_REF] Dehais | GHOST: experimenting conflicts countermeasures in the pilot's activity[END_REF]. The constant increase in commercial aviation traffic has not been followed by an increase in accident rate. Contributions to this rather positive state of facts are the steady technical improvement of modern aircrafts as well as the genuine cognitive flexibility of flight crews when handling exceptions [START_REF] Besnard | A cognitive approach to safe violations[END_REF]. Nevertheless, as reported by [START_REF] Amalberti | La conduite de systèmes à risques[END_REF], a flat accident rate has persisted since the 1970s. This is why we think more efforts have to be invested in the reliability of the dialogue between operators and automation. We think, following Amalberti, that the limit to modern aviation safety now lies in the extent to which we can improve cooperation in the dialogue between automated systems and operators. This assertion undoubtedly extends beyond aircraft piloting and hits any critical system where humans have to take decisions.

Limits

We wish to emphasise that mental models can also fail for several reasons other than cooccurrence, such as complexity, lack of knowledge, and workload. We want to give cooccurrences the attention they deserve. They can lead to catastrophes but only account for a small portion of the failures of mental models. Although we have focussed on the weaknesses of mental models, we also have to emphasise that human errors are not cognitive dysfunctions. Often, errors must be seen as marginal events caused by the same mechanisms that generate correct actions most of the time [START_REF] Rasmussen | Information processing and human-machine interaction[END_REF]. As a consequence, errors have to be considered in this paper as the side-effects of a cost/benefit driven reasoning process aimed at getting an optimal performance for the lowest mental cost [START_REF] Amalberti | Modèles de raisonnement en ergonomie cognitive[END_REF]1996).

CONCLUSION

Human performance is fallible. Paradoxically it remains one of the ironies of automation that operators are still required to intervene and fix the problem when the automation fails (Bainbridge, 1987). It is the inherent human traits of flexibility and adaptability that allow them to be able to do this. What we have started to argue here is that monitoring and control in human-machine systems needs to be considered more as a joint concept.

Our level of understanding of the ways and situations in which human performance can go awry continues to improve. In particular, in this paper we have shown how co-occurring events can lead to problems. The next step is to capture the details of this phenomenon in such a manner that they can be incorporated into the design of systems, using embedded intelligent agents, for example, as a way of increasing the dependability of the overall system in the face of increasing complexity.

6.

Figure 1 :

 1 Figure 1: A Boeing 737-400 cockpit. The EIS is located in the centre (© Pedro Becken. All rights reserved). The secondary EIS is magnified on the right-hand side of the picture. The vibration indicators are circled in white (photo from Air Accident Investigation Branch accident report).

Visit DIRC at www.dirc.org.uk

ACKNOWLEDGEMENTS

The funding for this study was provided as part of the Dependability Interdisciplinary Research Collaboration (DIRC) 1 which is funded by the EPSRC grant number GR/N13999. The authors wish to thank anonymous reviewers for useful comments.

7.