If UAVs can be flown via ground based command and control, can the co-pilot role be moved to a ground based pilot terminal? The design alternative will communicate with flight hardware to give a “virtual” representation of flight dynamics to the ground co-pilot. The avionics are extended from the aircraft to the ground through a command downlink (CDL) with a ground based command uplink (CUL) to the aircraft. The design assumes the ground terminal can be assigned to multiple flights. Just like an air traffic controller or flight dispatcher tracks and hands off flights, the ground based terminal will have the ability to be net-centric and handoff flight control.
The system will have to augment procedures to account for queuing of multiple flights. The procedure simulation and business model will determine what the thresholds are in terms of performance and cost. Other factors maybe added into the simulation through scenarios such as CDL link loss or complete ground failure. In any alternative, the ability for a pilot to perform with automation failure should be addressed within the scope of the simulation and its assumptions.
6.0 Simulation Methodology
The design alternatives provide a mechanism to augment the pilot role being replaced for the single pilot cockpit system. Two important factors are analyzed: how the procedures change relative to the baseline two pilot case, and how does each alternative impact airline operating expense. The single pilot cockpit is driven by market forces in both the commercial aviation industry, and the commercial pilot labor market. A design alternative that can improve the outlook in both areas will be evaluated.
6.1 Procedure Model
Procedure models offer insight into how users operate a system. In a cockpit scenario, procedure models can help isolate pilot performance bottlenecks and sources of error . Analysis of flight crew operating procedures is done to create a baseline two-pilot performance for comparing design alternative’s performance. Procedure performance is assumed to be directly related to safety and reliability for the purpose of determining design feasibility.
The procedure model represents the standard operating procedure for flying a sophisticated jet aircraft. The procedures are derived from an RJ-100 Flight Crew Operators Manual (FCOM) and modeled to capture the actions required to complete a procedure which is decomposed by tasks and actions. We first extract each procedure specification sections from the manual into an Excel spreadsheet to identify the responsible entities to execute a task. An example snapshot of the spreadsheet is in Figure .
Figure : Snapshot of tasks from the RJ100 FCOM.
The tasks are composed of functions that require specific physical and/or mental actions to be performed by one or both pilots. Responsible entities are identified as: Pilot Flying (PF), Pilot Not Flying (PNF), Co-Pilot (COPI), Pilot Occupying the Left Seat (PIC), and Both Pilots (B/P). Each task has one or more identified actions associated with its execution. Actions are described in Table . The use of actions to describe the task is driven by the need to assign a performance measure to the overall structure. Figure shows the frequency of actions relative to each entity. These frequencies are derived from the initial Excel spreadsheet data. The XML procedure model is expected to grow the number of actions as more fidelity is added to each subtask in the hierarchy model. The ability to design a full human factors experiment with live pilots as experimental subjects is outside the scope of this systems design and analysis. Simplifications are made to facilitate a high level representation of psychomotor and cognitive performance. The procedure simulation section will discuss limitations in greater detail, to include experimental design and input modeling.
Physical Instrument Manipulation
Classifies tasks that require an entity interact physically with avionics or controls
Pushing Throttle Forward
Verbal Cockpit Callout
Tasks that require specific verbal messages to be broadcasted for all crew to hear
Observing the outside of the airplane (flight environment)
Look Out for Runway on Approach
Verbal External Communication
Extended periods of conversation requiring specific focus
Table : Table lists the basic physical and mental actions that are required for each task.
The procedure model is decomposed further into a custom XML schema so that it can later be easily parsed into the simulation program. The base schema is shown in Figure . Tasks are decomposed based on the entity responsible and their responsible subtasks. Each subtask is decomposed further into a set of steps and actions that characterize the parent subtask. For the task model, we assume that the tree is executed sequentially and any cross dependency will be captured by hierarchical arrangements.
Figure : Task completion physical and mental actions.
The procedure model is assumed to be authoritative when instantiated for specific flight scenarios, that is, behavior (if any) outside the scope of the FCOM will not be considered. An individual procedure model is created for each design alternative before being input into the simulation program. The procedure model abstracts the capabilities of each technology in the form of functional performance. The functionality manipulates which component tasks and actions can be handled by a new system replacing a pilot. The remaining pilot in each procedure model will have changes to their procedure based on hypothetical interaction with each design alternative.
Figure : XML schema used to parse Excel sheet.
6.1.1 Procedure Simulation
The procedure simulation is used to analyze the performance of system designs under a series of testing scenarios. These scenarios are created to gather evidence for operational feasibility, reliability, and safety. The simulation parses the procedure model and executes tasks based on a designed scenario. These scenarios may describe a particular stage of flight, e.g. takeoff, approach, cruising, etc. The simulation outputs the results of execution times for each task and entity to produce an overall procedure execution time for each alternative’s procedure model. Over several replications, data will be collected to gather inferential statistics.
The simulation is coded in Java with several additional libraries to provide enhanced statistical and math functionality. The program begins by loading the task model and parsing the XML structure into different classes. The task structure is preserved through the class structure. In this way, several task models can be loaded and ran in the same replication. Tasks are executed through the iteration of each task, subtask, and step in a sequential fashion. Statistics are gathered for each replication of the task model.
The complex nature of flying operations leads the simulation to operate based on several assumptions. The following is the lists of assumptions used in the simulation.
The time for a pilot to perform physical or mental actions is modeled by a lognormal distribution for each categorical action.
Cognitive and physical actions are approximated by parameters from keystroke level human computer interaction studies.
Lower level human factors out of scope.
RJ100 FCOM used to model procedures are representative for other two pilot jet airliners.
Procedure model is a complete representation of flight
Ignore company specific tasks outside of FCOM.
Based on the assumptions above, distributions must be used to generate random variates within the simulation. These variates describe the time it takes to perform a physical and/or mental action within the task execution process. Table shows the notional representation of the stochastic action times. The parameters of the distributions are approximated using keystroke level model functions. For example, mental actions take 1.2s, button pushes take 0.1s with a sequence of 2 mental actions and 4 button pushes taking 2.8s. The total time to complete the task based on the actions required will be treated as the estimator for the mean and variance of the distribution.
The random variables at the action level of the procedural model represent the bottom most structure of the overall tree. The procedure model is decomposed by tasks and component actions. Each alternative will manipulate the number of tasks and actions in a procedure. The simulation iterates through the tree and replicates the simulation results in a Monte Carlo simulation fashion governed by the equations in Figure .
Physical Instrument Manipulation
Verbal Cockpit Callout
Physical Flight Computer Interaction
Visual Instrument Inspection
Visual Environment Inspection
Verbal External Communication
Table : Distribution table for physical and mental performance times
The alternative processing time is an expected value generated from several replications of the simulation for a target confidence interval. The processing time is the weighted summation of the procedures as defined by each alternative’s unique procedure model. Statistical tests are used to determine if there is a significant difference in the expected alternative processing time relative to the two pilot cockpit baseline system design. The design of experiment in 6.1.2 Procedure Simulation Design of Experiment details the inputs and outputs of the simulation. Because system dynamics are out of scope of the research, the simulation makes simplifications for the processing time of each alternative in the form of a uniform and triangular distribution.
The business model aims to determine the cost feasibility of each design alternative. Based on a set of input assumptions, how do the operating costs of major air carriers respond to the decrease of pilot labor? To answer this question, a business case is developed to evaluate each design alternative against. If the expected lifecycle cost is less than the two pilot baseline case, then the design may be evaluated as a suitable system depending on factors such as significance and sensitivity to change.
The lifecycle model is based on the operating cost of the most popular commercial jet airliner – the Boeing 737-300 . Random variables are used for each of the costs and are derived from triangular distributions based on historical BTS data as shown in the design of experiment Table . A Monte Carlo simulation is used to produce the expected lifecycle cost based on several thousand replications for a target confidence interval.
The above equation is used to generate the lifecycle cost for a period of years where will be the average fleet age of the Boeing 737-300’s reported through Form 41 fillings to the US DOT. The cost for each alternative is estimated using a triangular distribution which picks a best, worst, and most likely case. The parameters are unknown due to the undeveloped state of most of the alternatives, but historical avionics systems will be used where appropriate to estimate the unit cost of the alternative.