\chapter{Background}
Over 30 years ago, Wiener and Curry \cite{Wiener1980} examined flight-deck automation and were questioning whether functions previously performed manually should be automated due to human factors issues. Even today this issue is current with the further progression of automation in the cockpit and the increasing number of tasks performed by the automation. In accordance to the concerns about pilots' problems understanding the automation expressed by the human factors community, Wiener \cite{wiener1989human} presented the result of a three-year study on the impact of new automation in a Boeing 757, at that time considered highly automated. The study revealed a flight crew that was surprised by the plane's automated system. Sarter and Woods \cite{Sarter1992, Sarter1994a} also evaluated the pilot-automation interaction in the cockpit and examined pilots' difficulties understanding the Flight Management System (FMS), especially problems with tracking its status. Subsequently, Sarter and colleagues \cite{Sarter1997c} summarized their extensive findings on pilot interaction with modern flight deck automation in a paper entitled ``Automation Surprise.'' They concluded that automation surprises are not simply the result of over-automation, but is one result of design failures driven by the assumption that new technology necessarily improves system performance. 

The lack of feedback from the automation system is one of the problems that was identified as leading to automation surprises. Sarter and colleagues \cite{Sarter1997b} examined the Airbus A320, a highly automated aircraft equipped with a glass cockpit, and its role in automation surprises. Their analysis showed that most pilots experienced automation surprises independent of their previous glass cockpit experience and are a prevelant issue when it comes to the progression in cockpit automation. The authors classified automation surprises into two categories: 1) the automation fails to do something the pilots expect, and 2) the automation does something the pilots did not expect. The pilots especially raised concern about the lack of feedback from flight controls in the new fly-by-wire A320, including the nonmoving throttles. The authors came to the conclusion that feedback systems are important for pilots to stay aware of what is going on in the cockpit, which remarks a major challenge for the development of highly automated cockpits. Palmer \cite{Palmer1995} came to the same conclusion in two case studies of Human-In-The-Loop (HITL) experiments. In the experiments the pilots were exposed to high workload which led to automation surprises. He concluded that pilots should monitor the Flight Mode Annunciator displays more vigilantly, since these were often the only indication of what the automation was doing. Furthermore, he suggested that autoflight designers should provide more salient displays. Finally, Leveson \cite{Leveson97:Glasgow} analyzed flight deck automation and proposes ways to mitigate ``Technology-Induced Human Error'' by making changes to the system while still in the conceptual phase. 

Automation surprises are based on the premise that the pilots' \textit{mental model} of the aircraft automation differs from the actual way the aircraft automation works. Norman \cite{norman1983some} has done fundamental work in the human-computer interaction domain of mental models, which is of interest in this work describing the interaction between pilots and aircraft (automation and autopilot). Through his observations he came to the conclusions that mental models are incomplete, unstable, unscientific and parsimonious. Doyle and Ford \cite{Doyle1998} have reviewed the literature for mental models, especially for the domain of mental models in dynamical systems, such as an aircraft. Their description of a mental model states that ``\textsl{a mental model of a dynamic system is a relatively enduring and accessible, but limited, internal conceptual representation of an external system whose structure is analogous to the perceived structure of that system}''. Doyle et al. \cite{doyle2008measuring} and Romera \cite{romera2000using} investigated how to measure these mental models. 
% in dynamical systems.  proposes another method for systematically comparing a user's mental model to the way the machine actually works. 


\section{Mental Models}
There are two types of mental models. One describes the mental model of the system dynamics and can be characterized as the ``long term mental model''. This mental model reflects the pilots' understanding of the airplane as a whole, including the cockpit system. It is the long term mental model that allows a pilot to know given the current state of the aircraft. Formation of this mental model about a particular aircraft starts the first time the pilot learns about the airplane in training. The information about a system contained in this mental model changes slowly and is stable (when, for instance, the pilot finds new or forgets functionalities of the aircraft). The mental model can be changed purposefully through training or implicitly through experience. The second type of mental model describes the current state of the environment, and is characterized as the ``belief'' of the pilot, and is of central interest in this work. It comprises all variables describing the current state of the aircraft, including speed, altitude and heading. Whenever the pilot takes a look at the flight instruments the belief is updated. Another part of this type of mental model is the expectation of the pilot about the future state of the aircraft. If the belief and the expectation do not match an automation surprise occurs as shown in Figure \ref{fig:WMC_AS}.

\begin{figure}[!h]
\centering
		\includegraphics[scale=0.8]{images/WMC_AS.png}
	\caption{This figure shows the way automation surprises occur.}
	\label{fig:WMC_AS}
\end{figure}

Javaux \cite{Javaux1998, Javaux1999} did work on the first type of mental model that describe the system dynamics. He used state models to explain Sarter and Woods' work on automation surprises, placing special emphasis on mode confusion. He came to the conclusion that mode confusion appears because pilots are not aware of all of the preconditions that have to be fulfilled for a given mode change, and that the reason humans are not fully aware is caused by (1) frequential and (2) interferential simplification. Javaux's work explained how pilots simplify or reduce the number of preconditions that trigger a certain mode change to the preconditions that are most salient. Preconditions for intended mode changes that are not salient, but are almost always satisfied, are forgotten. Circumstances in which the forgotten precondition is not satisfied, often leads to mode confusion. 

Work on \textit{``short-term '' mental models}, in this case the beliefs, about the system state in human agents has been done extensively by Corker and colleagues \cite{Corker1993} in their human performance model MIDAS (Man-Machine Integration Design and Analysis System). They simulated the pilot's belief through a construct called Updateable World Representation (UWR). The UWR is a subset of the state of the world, which is instantiated with the current state of the world. Subsequently, when the simulation runs, the UWR may begin to deviate depending on the percepts the human agent is capturing and the state of the memory. The UWR accounts for the fact that humans have an internal representation of the external world that usually differs from the actual state of the world. Their belief of the state of the aircraft may not correspond to the real state, which takes part in explaining automation surprises in the cockpit. Depending on how inaccurate the data in the mental model is that the agent acts upon, this may lead to undesired results. For instance, if the pilot acts on the airplane thinking one particular flight mode is engaged, while the flight mode has been changed by the automation, this may lead to aircraft maneuvers that were not desired by the pilot. Furthermore, memory does not store everything that is perceived for an infinite amount of time. Memory decays in the UWR, which is modeled by an exponential function that leads to forgetting of information stored in the UWR over time. The MIDAS UWR does not capture how the mental model would evolve over time to simplify its explanation of the way the system operates, as Javaux did. Instead it only relies on the state of the world and the update of the copy of this state in the UWR depending on the percepts captured. 

Corker and colleagues' \cite{Corker1993} human performance model MIDAS was integrated in an accident risk assessment methodology called TOPAZ \cite{blom2001, stroeve2003} (Traffic Organization and Perturbation Analyzer) by Blom and Corker and colleagues \cite{blom2005}. Their work demonstrated the feasibility of such an integration. In their paper, they describe how to do this integration to describe the risk of collision between two aircraft. 

In 1998, Butler et al. recognized \cite{butler1998formal} the power and benefit of \textit{model checking} in assisting human factors through ``a deeper scrutiny of the internals of the automation'' and at describing and avoiding mode confusion. Rushby and colleagues continued on this path and described system behavior and mental models as finite state transition systems to make them viable for model checking. In particular they examined automation surprises involving the Airbus A320 \cite{Crow2000}, Boeing 737 \cite{Rushby00:fm-elsewhere} and MD-88 \cite{Rushby:RESS02}. Rushby's \cite{Bass2011} instantiation of a mental model for use in his model checker SAL (Symbolic Analysis Laboratory) is simpler than the UWR. A mental model for inclusion in SAL only represents the pilot's expectation about the state of the aircraft: descending, leveled or climbing. This expectation is updated upon the pilots performing actions that lead to the change of this state. Rushby's work on the automation surprise in \cite{Crow2000} is described in detail in section \ref{sec:modelcheck381}.


\section{Model Checking} \label{sec:modelchecking}
Model Checking originates from computer science and is still used particularly in this domain for property checking of system models. A model is checked for a specified property by an exhaustive state space exploration (see Figure \ref{fig:sal_model}). 

A classical example for model checking is a fault tolerance algorithm examining the error robustness of a signal transmission system. A source sends out a signal to one or several receivers that is passed through relays. The specification to be checked is how many faulty relays the system can handle before a wrong signal is passed to the receivers. Figure \ref{fig:faulttolerance} shows such a system comprising a source, three relays and two receivers. One specification to check in this system can be: is the correct signal going to reach the receivers if one relay is faulty. Obviously, when three relays are faulty there is no possibility for the correct signal to reach the receivers.

\begin{figure}[!h]
\centering
		\includegraphics[scale=1]{images/FaultTolerance.png}
	\caption{Example of a fault tolerance algorithm model.}
	\label{fig:faulttolerance}
\end{figure}

A model comprises \textit{an initial state}, \textit{state transitions} and a \textit{specification} that is checked. Rushby describes in \cite{rushby2003needham} and \cite{rushby2004sal} how to create a model with SAL (Symbolic Analysis Laboratory), the model checker described in this work. All variables of the model are set to an initial value which describes the initial state from which the model checker begins the state exploration. \textit{State transitions} describe changes to variables that occur in between states. Transitions can require a precondition to be true to occur or may occur without fulfilling preconditions. In state transitions, one or more variables are set to a new value. Last, the \textit{specification} to be checked is defined, which is characterized by a state in which the specification no longer holds. For instance, a specification can be that a variable can never take a certain value, no matter which state transitions occur. 

Model checkers take the initial system state and exhaustively search the state space associated with the prescribed transitions looking for violations in the specification. If the specification is fulfilled, then the model checker notifies the user that the undesired state (in Figure \ref{fig:sal_model} the state with the `State NOT OK' sign) is not reachable. If the specification is not fulfilled the model checker demonstrates how the undesired state can be reached by showing the state transitions that lead from the initial state to the undesired state (see Figure \ref{fig:property}).    %This is called a counter example since 

\begin{figure}[!h]
	\centering
		\includegraphics[scale=0.6]{images/sal_model.png}
	\caption{Example of the exploration of the state space.}
	\label{fig:sal_model}
\end{figure}

\begin{figure}[!h]
\centering
		\includegraphics[scale=1]{images/property.png}
	\caption{Architecture of a model checker.}
	\label{fig:property}
\end{figure}

In model checking time is not explicitly modeled but implicitly represented by state transitions. A state is characterized by properties and the transitions are characterized by the change of these properties. A state transition that leads the model from one state to the next can change one or several state variables at the same time. The change of state variables can be either very large or small depending on how the state transition is characterized. The time such a state transition represents in reality can therefore be large or small, depending on how long such a state transition would take in reality. For example if a state transition can change the altitude of the aircraft by 500 feet, then such a transition would take several seconds in reality, depending on the pitch, altitude and speed of the aircraft. 
% The model checker starts at a defined initial state.

Due to the exhaustive nature of model checking, depending on how complex the model is, the number of potential states may be prohibitive. To reduce the number of states that need to be explored, it is reduced using algorithms. For instance, SAL (Symbolic Analysis Laboratory) uses a symbolic algorithm to reduce the number of states. Nevertheless, a poor definition of the model can lead to a state space explosion that a model checker cannot examine in an appropriate time frame anymore. For instance, a state explosion occurs when representing continuous variables as each having an infinitely large number of discrete values. Therefore, all variables have to be discrete or discretized into a bounded set of values. Unfortunately, such an architecture makes it impossible to fully model aircraft dynamics. 
%Same applies to state transitions (actions), too many state transitions lead to a state explosion. 

%Synchronous, asynchronous, deadlocks


CounterExample-Guided Abstraction Refinement (CEGAR) \cite{clarke2000} is a method in model checking in which a simple model is constructed, which then is iteratively refined. The model is checked for the desired specification; if a counterexample is found that does not appear realistic, the model is refined implementing new state transitions or refining unrealistic state transitions. This process is continued until a counterexample is found which appears feasible. 




% FROM JOHN
% It's CEGAR: CounterExample-Guided Abstraction Refinement.  It's a standard term in CS so just Google it.  The idea in NextGenAA is to use a crude abstraction and model check it in SAL; if you get a counterexample, concretize it (i.e., add the necessary realistic details) and try to reproduce it in WMC; if you succeed, good, that's a real problem; if not, study the difference between the abstract SAL counterexample and the concrete WMC example and use that to refine the SAL abstraction (i.e., remove the excessive abstraction that is generating a counterexample that isn't there in the realistic model).

% FROM WIKI
%Counterexample guided abstraction refinement (CEGAR) begins checking with a coarse (imprecise) abstraction and iteratively refines it. When a violation (counterexample) is found, the tool analyzes it for feasibility (i.e., is the violation genuine or the result of an incomplete abstraction?). If the violation is feasible, it is reported to the user; if it is not, the proof of infeasibility is used to refine the abstraction and checking begins again.


\section{Simulation} \label{sec:simulation}
Simulations aim to reproduce real world behavior at a useful level of fidelity. Flight simulations have to comprise flight dynamics of the aircraft to be simulated and imitate a real world flight leading to a high level of fidelity. Ideally, behavior observed in simulations can be reproduced in reality and vice versa. The benefit of simulations is that they are less cost intensive than performing hardware or human-in-the-loop (HITL) tests and allow a broader spectrum of tests than real world agents or systems would allow. 

In the context of this work, the degree of fidelity models continuous aircraft flight dynamics in contrast to highly abstracted flight dynamics given in model checking, namely in the SAL model provided by Rushby and colleagues \cite{Bass2011}. Furthermore, simulations, such as in this work, explicitly model time. Every aircraft state and action is linked to a specific time at which it occurs. Model checkers do not provide time explicitly, instead rely only on the sequence of actions, which also lacks the description of the full aircraft state. In the simulation model given in this work, the actions of the involved agents: pilot, air traffic controllers and automation are decomposed into the manipulation of levers and buttons. For instance actions for the pilots include deploying flaps, dial and push heading selector. Decomposing further into human agent body movements is not necessary, nor helpful. 

WMC, the \textit{simulation} platform that was used for the simulations in this work, was developed to predict human-automation interaction in operational contexts \cite{Pritchett2011, Pritchett2011a}. WMC comprises agent models that are generic and autonomous from any description of work. The knowledge of work is encapsulated outside the agent models. Work particular to a system, such as the cockpit system including the pilots and the automation in the cockpit or the controllers working in Air Traffic Control are such a system. These models describing the work of a particular sub-system situated in the simulation are called workmodels. Each workmodel is built hierarchically similar to an Abstraction Hierarchy (AH) \cite{vicente1992} at which bottom the functions are decomposed of actions that are passed to the agent models that execute the actions. 

In WMC, there are different types of agents. Perfect agents that execute each action exactly as is without having any internal representation of a task structure. This kind of agent is used for any machine, such as the flight deck automation. The other type is a human agent model that has a limit of tasks it can execute at a time (usually 3, 7 or 50, which corresponds to an unlimited amount). If the human agent is completely occupied, meaning executing the maximum number of actions, new actions with same or lower priority are delayed and new actions with higher priority interrupt active actions. To keep track of these tasks the human agent model has a list for active, delayed and interrupted actions. If an action is delayed or interrupted for too long, the pilot may forget them altogether. 

Each action that is part of a workmodel contains information about what resource variables it manipulates (gets information from or sets to a new value) and how frequently it has to be executed. Resources describe the state of the environment and the aircraft and are the only possibility for an agent to perform changes in the environment within an action. Each action has to specify which resources it is allowed to retrieve (``get'') and which it is allowed to change (``set'').  

Actions are executed in the order they are specified by the agent they are assigned to. A simulation clock keeps track of which action is scheduled next and after an action is executed it is either scheduled for another time in the future or to the a very long time later, which is a time that is practically never reached by the simulation. When an action is set for a very long time away and another action needs to schedule this action, its next scheduled time is updated to a closer time. For more information regarding WMC, see \cite{Pritchett2011} and \cite{Pritchett2011a}.  