A Flight Deck Decision Support Tool for Autonomous Airborne Operations

11 Pages·2002·1.1 MB·English

by  Ballin, Mark G.

A FLIGHT DECK DECISION SUPPORT TOOL FOR
AUTONOMOUS AIRBORNE OPERATIONS
Mark G. Ballin*, Vivek Sharma t, Robert A. Vivona t,
Edward J. Johnson', and Ermin Ramiscal ¶
NASA is developing a flight deck decision support tool to support research into
autonomous operations in a future distributed air/ground traffic management environ-
ment. This interactive real-time decision aid, referred to as the Autonomous Operations
Planner (AOP), will enable the flight crew to plan autonomously in the presence of dense
traffic and complex flight management constraints. In assisting the flight crew, the AOP
accounts for traffic flow management and airspace constraints, schedule requirements,
weather hazards, aircraft operational limits, and crew or airline flight-planning goals.
This paper describes the AOP and presents an overview of functional and implementa-
tion design considerations required for its development. Required AOP functionality is
described, its application in autonomous operations research is discussed, and a prototype
software architecture for the AOP is presented.
Introduction lenges of airborne separation assurance and, hence,
airborne conflict management (ACM). Most ACM con-
'.Nthe 199"f5r,eethefligRhTt"CAopaenradtioontahlers prealreaadsiegdm, conwcehpictsh froer- cepts identify the need to provide a cockpit display of
duces reliance on centralized air traffic management. traffic information (CDTI), and asystem of traffic con-
Free flight is defined as a safe and efficient flight oper- flict detection and resolution (CD&R) to participating
ating capability under instrument flight rules in which flight crewsf ,s Therefore, much effort has been ex-
operators have the freedom to select their path and pended on the development of CD&R algorithms and
speed in real time.lProponents of free flight believe on CDTI approaches. 9 12 While this research isuseful,
the concept will enable future growth of the National it alone cannot address concept feasibility, and it does
Airspace System (NAS) in a manner that scales di- not address the need for improved traffic management,
rectly with increases in air traffic, mitigates the need which must increase NAS throughput and accommo-
for costly expansions of ground-based infrastructure, date airspace user preferences in addition to assuring
and provides operational benefits to users of the sys- separation.
tem. In collaboration with industry and the international
While the general concept of autonomous aircraft R&D community, the National Aeronautics and Space
operations, under instrument flight rules, has been Administration (NASA) is maturing the Distributed
studied since 1965,2 no single concept of operations Air/Ground Traffic Management (DAG-TM) concept
has emerged as the best solution. Some concepts set as part of its Advanced Air Transportation Technolo-
aside specific airspace in which aircraft would be per- gies (AATT) Project. To support DAG-TM research,
mitted to manage their operations autonomously, a 5 NASA is developing an interactive flight deck decision
while other concepts propose a mixed environment of support tool, referred to as the Autonomous Opera-
autonomous and managed aircraft. 6 Further, much tions Planner (AOP). This paper describes the need
research and development remains to be performed to for the AOP, and presents an overview of functional
establish proof of feasibility and economic viability for and implementation design considerations required for
any of the proposed concepts. The complex issues of its development. AOP functionality is outlined, its
the transfer of authority and responsibility between application to autonomous operations research is dis-
centralized ground controllers and airborne partici- cussed, its software design is described, and a research
pants, the exchange of data between participants, and and development plan is presented for the AOP.
system stability and safety must be resolved. Ac-
tivities to date have focused primarily on the chal- Need for an Airborne Decision Support
Tool
*Associ&te Fellow, AIAA, NASA L&ngley Rese&rch Center,
H&mpton, VA Although CDTI and ACM concepts may alone pro-
tSenior Member, AIAA, Tit&n Systems Corpor&tion,
vide benefits, an increase in flight deck planning ca-
H&mpton, VA
pabilities may be necessary for concepts that signifi-
tSenior Member, AIAA, Tit&n Systems Corpor&tion,
Billeric&, MA cantly increase the airborne role in traffic management
_Senior Member, AIAA, NASA L&ngley Rese&rch Center, decision-making. While research suggests that a tac-
H&mpton, VA tical system meets the needs of safe separation assur-
¶Senior Member, AIAA, NASA L&ngley Rese&rch Center,
ance, 13other research results indicate these airborne
H&mpton, VA
capabilities should have a strategic planning compo-
1 OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
nent.X4 16 For concepts that involve airborne inte-
gration with ground-based air traffic service providers
E@ .............................................. ---- :-- :5-_,4L RTA
(ATSP) who manage traffic flow, look-ahead horizons
RTA requires ......... "';;"" at Fix
of more than 15 minutes may be beneficial, whereas 8min. delay ,,':::;;",""
tactical concepts may only involve horizons of five min- D_,_ ...... RTA #_e;__,_,-'"
requires B,'" A
utes or less. A flight-deck-based crew decision support RTA 1min. d#l_y RTA
research system is needed that supports the investiga- r6eqruaiirne.s delay .. requires
30 sec. ETA
tion of these and other issues in order to develop fea-
C_" RTA reduction
sible and economically viable concepts for distributed requires
air/ground traffic management, xz 4rain. delay
The following examples illustrate some potential
a) ATSP-provided RTAs require ETA adjustments.
benefits of using a flight crew decision aid that provides
increased sophistication in its planning assistance.
Figure 1 illustrates the potential advantages of a
planner that accounts for a global traffic situation. In at Fix
Figure l(a), there is no consideration of the traffic situ-
ation, either because of an insufficient look-ahead time
Path S_d_ /A_sspeed
or because of an unsophisticated ACM system. Air-
and Speed R_educt io_f/ Increase
craft A must absorb delay to meet a required time of
reduction
arrival (RTA) at the fix, and chooses to reduce speed.
C'¢'7 Path Stretch
By doing this, Aircraft A inadvertently causes a con-
flict with Aircraft B. This creates additional workload
b) Airborne decision aid determines appropriate strategy for
and a potential for controller intervention. In Figure each aircraft.
l(b), Aircraft A chooses a lateral path stretch as the Fig. 2 Airborne decision aid must choose appro-
best solution, thereby achieving efficient compliance priate strategy for meeting constraints.
with the ground-supplied restriction while minimally
impacting other aircraft and controllers. ment planning. A ground-based scheduler has resolved
In the second example, illustrated in Figure 2, Air- arrival capacity issues by assigning each aircraft an
craft A through E have estimated times of arrival RTA for crossing the fix (Figure 2(a)). Aircraft A
(ETA) at afix that are incompatible with flow manage- must increase speed so its ETA matches its assigned
RTA, while Aircraft B through E must absorb increas-
ing amounts of delay. For each aircraft, a flight deck
planning system identifies a conflict with the assigned
Absorb delay:
constraint, and determines the most appropriate strat-
Reduce speed by 10 kt %_...." egy (Figure 2(b)).
Figure 3 illustrates the possible benefits of a flight
@A .................... I'_----RT A
deck system that combines flight management plan-
ning with goals or preferences of the flight crew. The
"" at Fix
crew needs the earliest possible arrival over the des-
FEW'"
tination fix. In Figure 3(a), the flight plan accounts
for dynamic special use airspace (SUA), a region of
airspace that is temporarily inaccessible. In Figure
a) Constraints management without consideration of traffic. 3(b), the airborne planning aid has detected the re-
moval of the airspace constraint, and either through
direct crew input of its goals or through inference, has
Absorb delay: determined that an early arrival is the crew's goal. It
Lateral path stretch provides the new trajectory as an advismT to the crew,
who accept it.
A _RTA
These examples suggest that flight deck automation
to support crew planning may be useful. As currently
J at Fix
defined by the International Civil Aviation Organiza-
tion (ICAO), a conflict is "a predicted converging of
aircraft in space and time, which constitutes a viola-
b) Constraints management with consideration of traffic. tion of a given set of separation minima". 5 A crew
decision support system as described above expands
Fig. 1 Potential benefits of including situational
upon this definition: rather than being limited to traf-
planning in conflict and constraints management.
fic, the system identifies and resolves conflicts with
2 OF 11
AMERICAN INSTITUTE OF' AERONAUTICS AND ASTRONAUTICS
3. Tactical conflict resolution has been defined as a
maneuver that resolves a conflict, but does not
account for the own aircrafts flight plan in do-
ing so. Strategic resolutions have been defined
@ _ _1_ _ as those that, if executed, include recovery of the
Destination intended flight plan. zs Both types of resolution
have advantages and disadvantages. To continue
Fix research on the characteristics and desirability of
strategic and tactical ACM and the relationships
between them, a research decision support system
a) Crew needs earliest arrival possible; plan accounts for dy-
namic SUA. must provide independent strategic and tactical
ACM functions. It must also provide a flexible
and re-configurable alerting and advisory system
that integrates the two approaches in a way that
s _ _ conveys the appropriate information to the crew
; ' A
at the appropriate time. It may also be required
to provide advisories that include trajectory opti-
• -" Destination
• s mization or desired operational procedures, such
".-"" Fix
as flight-idle descents, since future commercial
systems, must ultimately be economically viable
for the airspace user.
b) Airborne decision aid detects removal of SUA and re-plans
for earliest arrival.
4. To support investigations of the safety aspects
Fig. 3 Airborne decision aid may require knowl- of system functions, operating independently or
edge of crew or company planning goals. in combination, the system must be designed to
maintain independence between these functions,
all hazards, aircraft performance limits, externally-
and it may need to provide redundancy.
imposed constraints, and crew or company preferences
and goals. Such a system is envisioned to contain sev- 5. The system must also support research that de-
eral characteristics: fines airborne and ground-based communication,
navigation, and surveillance (CNS) infrastructure
1. Because DAG-TM and most other distributed requirements. The system must therefore be de-
traffic management concepts are human-centered, signed to deal with a variety of data types, for-
the system must provide advisory information to mats, and data link characteristics. The system
the flight crew. It must be designed to enable the must be robust to missing data and account for
crew to execute a recommended action in a way redundant data provided from several sources. It
that minimally impacts crew workload. Because must be flexible enough to allow for exploration of
the crew will have final authority in all flight- varying data exchange content, update rates, and
management decisions, the system may need to availability requirements. Research may indicate
provide interactive tools to assist the crew in gen- a need to reconstruct missing information from a
erating alternative solutions. It may also need data linked source or infer the intent of proximate
input or derived information about mission goals traffic. Monitoring of an intruders conformance
to incorporate operator preferences in its advi- with its provided intent may also be needed.
sories.
6. Although it is designed for research, the system
must consider integration with existing flight deck
2. Distributed traffic management concepts may
systems and flight deck procedures to the extent
only be viable if they are capable of providing
possible. It should consider current guidelines and
benefits in dense and highly constrained traffic
standards that the aviation industry is developing
environments, zr Such environments are common
for the future, such as ARINC 660A. 19
today and are expected to remain common in the
future. Therefore, the cockpit decision aid must 7. The research system must be highly flexible so
be able to account for all known constraints while that currently proposed and future functional
determining the appropriate trajectory for the air- components may be incorporated, as they become
craft. Constraints include nearby traffic, special available. It must have a well-designed functional
use airspace, weather and other environmental architecture that utilizes stable and documented
hazards, and arrival time, speed, or altitude con- interfaces. This facilitates the investigation of
straints imposed by the ATSP for safety or to differing approaches to a given function without
expedite traffic flow. requiring extensive system modification. It must
3OF 11
AMERICAN INSTITUTE OF' AERONAUTICS AND ASTRONAUTICS
be capable of operation in several research en- 2. High-fidelity flight deck simulators that make up
vironments, from air traffic simulation to flight. the Langley Research Center Cockpit Motion Fa-
Finally, it must be capable of supporting sev- cility (CMF) will be used for investigations that
eral research approaches, from human-in-the-loop require a full crew simulation in a high-fidelity
investigations of system utility and usability to cockpit environment. These simulators utilize a
batch-mode verification and validation analysis. real-time simulation environment, so the AOP is
designed to accommodate normal simulation op-
The Autonomous Operations Planner erating modes, including initialize, trim, hold, op-
The AOP is a flight deck-based decision support re- erate, and reset.
search system that is currently under development to
3. The NASA Airborne Research Integrated Experi-
meet the above needs. It assists a flight crew in mis-
ments System (ARIES), a specially instrumented
sion planning and execution, as needed for future civil
Boeing 757, will be used to support in-flight vali-
operations under the DAG-TM paradigm. The crew
dation activities.
interacts with the AOP to perform trajectory plan-
ning that accounts for conflicts with (1) traffic hazards; The AOP is also designed to support both human-
(2) ownship aircraft performance limitations; (3) sys- in-the-loop (HITL) and batch modes of operation.
tem flow constraints that are imposed by the ATSP; HITL is defined as a mode in which subject pilots,
(4) airspace constraints, such as severe weather and subject controllers, and/or subject dispatchers inter-
dynamic SUA; and (5) operator flight goals, such as act with systems or simulators that will allow them
efficiency and schedule. to make flight- or traffic-management decisions, as
The AOP assists crew decision-making through they would in a deployed system. HITL will be used
for human factors research and AOP crew interface
(1) presentation of the most relevant information;
(2) the accommodation of crew planning preferences; development. Batch is a mode in which all system
(3) alerting advisories; and (4) automated negotiations operations are simulated with full repeatability using
with crews of other aircraft (if necessary) and ground- automated human operator models to represent hu-
based air traffic controllers. It analyzes surveillance mans in the simulated system. Batch mode will enable
and constraint data for potential airspace or traffic simulations with statistically significant sample sizes.
conflicts; it calculates conflict resolution options that
Functional Design
optimize parameters specified by the flight-crew; it
The AOP is designed around a set of core func-
provides tactical information for conflict-free maneu-
tions that are central to ACM applications: mission
vering; and it analyzes over-constrained problems for
planning, data management, interfacing with other on-
viable solutions. It will manage information received
board systems, and interacting with the flight crew.
by the flight deck from several sources that are ex-
The core AOP responsibilities are: (1) generating
pected to exist in future operational environments.
and managing ownship and traffic trajectories; (2) col-
These sources include the direct broadcast of position
lecting and maintaining data on area hazards that
and intent information from other aircraft in prox-
are comprised of hazardous weather, SUA, or other
imity, ground-based traffic information services, and
unusable air space; (3) probing the ownship trajecto-
ground-based flight information services. The AOP
ries for conflicts with the nearby traffic trajectories,
will fuse these data and manage any incomplete, re-
area hazards or constraints; (4) detecting and resolv-
dundant, or ambiguous information. Figure 4 is a
ing conflicts with hazards and constraints as well as
block diagram of AOP functionality expected at its
the strategic planning goals and preferences; (5) out-
completion.
putting data to be displayed to the crew, in the form of
Research Applications alerts, advisories, and flight management options; and
To facilitate autonomous flight management re- (6) responding to crew inputs. In order to achieve this
search, the AOP is designed for integration into three functionality, the AOP functional design must consider
specific research environments: the ownship aircraft, traffic and area-hazards in the
surrounding airspace, conflict detection and resolution
1. A concept-level distributed traffic simulation en-
mechanisms, output integration, and external inter-
vironment will be used for operational feasibility faces.
assessments, system-level requirements definition,
airborne and CNS technology requirements deter- Ownship
ruination, and human-centered design and assess- The AOP uses the ownship state and a representa-
ment. 2° A workstation-based aircraft simulation, tion of the ownship intent in order to create a set of
referred to as the Aircraft Simulation for Traf- trajectories. The AOP receives the ownship state in-
fic Operations Research (ASTOR), is designed to formation from the FMS, and the intent information
host the AOP, an enhanced-capability software from the flight plan buffers in the FMS and the cur-
FMS, and airborne CNS systems. rent mode control panel (MCP) settings. Once the
4OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
Ownship nav
&trajectory data
constraints _....'{ _ .............
• Ownship ] _l __ Crewpreferences
conforn'_nce
monitoring
• Ownship trajectory
processing • Conflict detection 1 • Strategic planning
• Ownship intent • Conflict Goalsand
inference prioritization preferences
• Conflict resolution accommodation
Automatic Trajectory
• Traffic data Manual optimization
processing (provisional)
Ambiguity t
resolution • Output integration
Confidence _i Alerting
assessment • Area hazard data ii Advising
Datafusion processing
• Traffic change Ambiguity
menitoring resolution
• Traffic intent Confidence
inference assessment
• Traffic trajectory Datafusion
generation • Area hazard change
monitoring
• Area hazard
dynamics prediction
_,,,_ Tinrfaofrfmicataionndhazards
Fig. 4 Autonomous Operations Planner functions upon completion.
ownship state and intent information is available, the The known intent may include information be-
AOP checks whether the ownship state is in confor- yond that currently used by the autoflight system
mance with its intent. for navigation, viz., crew preferences, airline op-
Based on the available information, i.e., ownship erational constraints, and ATSP crossing restric-
state, intent and conformance, the AOP creates fol- tions. If the aircraft is maneuvering tactically and
lowing trajectories. not following a known intent, the planning trajec-
tory represents the "most useful" trajectory for
1. The AOP creates a state-projection trajec-
strategic planning while the aircraft is flying tac-
tory by projecting the aircrafts current state pa-
tically. The primary purpose for this trajectory
rameters forward in time, along the linear velocity
is strategic conflict detection. There is always a
vector, ignoring turn rates. This trajectory is used
planning trajectory for the ownship aircraft.
for tactical conflict detection (e.g. blunder protec-
tion and tactical maneuvering). There is always 4, The AOP may create a provisional trajectory
one, and only one, state-projection trajectory for from either a non-active route or by modifying
the ownship aircraft. some element of the active route. Each provi-
sional trajectory represents a potential change to
2. The AOP creates a commanded trajectory the aircrafts current known intent that needs to
by evaluating all available command information be evaluated either by the crew or by the inter-
from the active FMS route, the MCP, and autopi- nal AOP automation. Provisional trajectories are
lot / autothrottle modes. This trajectory repre- used in conflict resolution, provisional planning,
sents what the aircraft will do if the crew makes self-spacing operations, and internal AOP func-
no changes to the automation settings in the cock- tions. Several provisional trajectories may exist.
pit. There is always a commanded trajectory for
the ownship aircraft when an autoflight system is 5, The AOP has a provision to create an inferred-
engaged. intent trajectory, if research determines that
intent-inferencing is necessary. This trajectory
3. The AOP creates a planning trajectory by uses known intent information and additional
evaluating all available "known intent" 21 infor- forms of potential intent information (e.g. a
mation from the AOP, the MCP, and the FMS. return to the planned route after traversing a
5 OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
weather-impacted region). This trajectory rep- namically activated special use airspace (SUA), and a
resents the AOPs "best guess" at ownship intent sector impacted by congestion. A model for this type
when the aircraft is not maneuvering consistently of area hazard includes, in addition to the static model,
with a "known intent". There is an inferred intent the activation schedule.
trajectory for the ownship aircraft only if the air- A dynamic area hazard is an area hazard whose
craft is not conforming to the known intent, and position (and potentially the shape) is variable with
if an intent inferencing function is available. respect to time. Examples include turbulence, thun-
derstorms, wind shear, heavy precipitation, hale, icing,
Traffic Hazards
volcanic ash, airborne hazardous materials, and fronts.
The AOP uses the traffic state and, if available,
A model for this type of area hazard could include, in
traffic intent information in order to create four-
addition to the static model, a velocity vector associ-
dimensional trajectories for the nearby aircraft. In ated with each vertex.
the current implementation, the AOP may receive
this information via either the Automatic Dependent Hazards Avoidance
Surveillance-Broadcast (ADS-B) or the Traffic Infor- The AOP independently uses both the state-based
mation Service (TIS) interface. The AOP fuses these and the intent-based algorithms for conflict detection
data and generates appropriate four-dimensional tra- and resolution with respect to the traffic and area haz-
jectories depending on the information broadcast by ards. In the event that the constraints need to be
the traffic aircraft. When only state information is relaxed to achieve a resolution, the AOP utilizes a haz-
available for a traffic aircraft, the AOP creates a state- ards prioritization function.
projection trajectory. When intent information, e.g.,
a set of trajectory change points (TCPs) and target State-based Conflict Detection and Resolution
state information, is received, the AOP creates ad- The AOP probes the ownship state-projection tra-
ditional intent-based traffic trajectories, namely the jectory for conflicts with the traffic state trajectories
TCP-based trajectory and/or the target-state tra- and the area hazard boundaries to determine state-
jectory. For every traffic aircraft, the AOP checks based conflicts. Currently, the AOP uses the National
whether the traffic state is in conformance with its Aerospace Laboratory of the Netherlands (NLR) strat-
broadcast intent. If the state for a traffic aircraft is egy to determine state-based conflicts, and to generate
not in conformance with its broadcast intent, the AOP conflict prevention bands that appear on the crews
creates an inferred-intent trajectory, representing the cockpit displays. 22 Conflict prevention bands indicate
inferred path of the traffic aircraft over adefined "look- no fly zones in terms of the aircraft heading, speed,
ahead" period. and vertical rate.
Area Hazards Intent-based Conflict Detection and Resolution
The AOP needs accurate data on the boundaries of
The AOP probes all available forms of the ownship
area hazards in space and time in order to determine if intent-trajectory for conflicts with the available traffic
any of the ownship trajectories conflict with the haz- intent information and the area hazard boundaries to
ard within a defined "look-ahead" period. The AOP determine intent-based conflicts. Currently, the AOP
can detect conflicts with different types of area hazard uses a protected zone conflict detection strategy and a
models. Expected area hazards to be detected include genetic algorithm approach for the conflict resolution
adverse weather, special use airspace, turbulence, vol- strategy.23, 24
canic ash, and terrain. The AOP design allows for
several levels of intensity and dynamics for area haz- Output Integration
ards as well as several methods of modeling, including The goals of the output integration function of the
N-sided polygon, grid-based, and centroid-vector ap- AOP are: (1) to integrate and format the ownship,
proaches. The three core types of models in the AOP hazards, and conflict data; (2) to determine the infor-
are static, time-variant static, and dynamic. mation to be sent to the crew-interface; (3) to associate
A static area hazard is an area hazard whose an alerting level to each resolution advisory for the de-
properties (such as position, geometry, and altitude tected conflicts; and (4) to determine appropriate time
bounds) are constant with respect to time. Static area to display and purge an advisory. The data available
hazards include terrain, low altitude man-made obsta- to the output integration function includes ownship
cles, and restricted airspace. A model for this type of trajectories, traffic trajectories, area hazard bound-
area hazard includes the number of vertices, the lati- aries, number and type of conflicts, conflict prevention
tude and longitude of each vertex, and the minimum bands, conflict resolution advisories, and other mission
and maximum altitudes of the area hazard. planning information. The current AOP design pro-
A time-variant static area hazard isa static area rides up to five internal alert-levels. A Level-0 alert
hazard whose requirement for avoidance varies with means that the conflict will not occur if the two aircraft
time. Two examples of such an area hazard are a dy- continue to follow their strategic plans, but the aircraft
6 OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
.........................._................................................... _ . . _z 4D trajectory
Crew alerting, _#_- Iterate untnl constraints are met: "_'_ to execute
planning assistance _ Conflict-Free Route that conforms with '_P"
_i_'_ ' : mission J__p_l_a__n___a_n_d_______m___p_o__sed constraints
lUtl¢l_l v_
_: __ Segment/waypoint constraints and best __
____ achievable trajectory based on aircraft _'_.__
_ performance/operational limits
l_,.__ _::__"
User Preferences
Route Constraints • Traffic Info Winds aloft
• Airspace Constraints
• Flow Management
Constraints
Fig. 5 Integration of the AOP with the FMS and flight deck systems.
are sufficiently close so that a tactical maneuver by the oll the navigation display (ND), and the primary flight
ownship or the traffic aircraft could cause a conflict. display (PFD). The AOP currently receives the crew
A Level-1 alert means that a conflict will occur if nei- inputs from a simulated multi-purpose control and
ther aircraft maneuver or change their strategic plans, display unit (MCDU). The AOP uses the flight plan
but the traffic aircraft is required to resolve that con- information in the FMS, and the settings on the MCP,
flict. The Level-0 and the Level-1 alerts are considered to build ownship intent.
"point out" alerts because they do not require any ac- The AOP interfaces with the aircraft FMS to obtain
tion of the ownship crew. A Level-2 alert differs from information specific to the equipped aircraft. Specif-
a Level-1 alert in that the ownship needs to resolve the ically, the AOP utilizes the trajectory integration ca-
conflict. A Level-2 alert becomes a Level-3 alert when pabilities of the FMS to generate ownship trajectories
the time to loss of separation has fallen below a spec- that are consistent with the FMS's aircraft perfor-
ified number of minutes. When separation is lost, a mance model, navigation database, crew preferences,
Level-4 alert appears. Researchers can combine AOP cost function data, and constraint data. These trajec-
alerts and/or specify the format and actions associated tories are probed against hazards, external constraints,
with alerts. and crew goals and preferences, to detect potential
conflicts. If the AOP detects conflicts, it uses the
External Interfaces
FMS again to generate four-dimensional trajectories
The AOP interfaces with a number of aircraft sys- during the iterative conflict resolution process until all
tems, or simulated aircraft systems, to receive input conflicts are resolved. After finding a solution, the
data from and to send output results to. All com- AOP uploads the conflict-free trajectory to one of the
munications between the AOP and the aircraft data FMS flight plan buffers for the crews evaluation. By
buses are based on modifications to existing aircraft taking advantage of the FMS's capability to predict ac-
standards. curate trajectories, based on ownship performance and
The AOP obtains the UTC time from the global company- or crew-specified constraints, the AOP gen-
positioning system (GPS) to synchronize its internal erates trajectmy change advisories that the aircraft is
clock with the aircraft clock. It uses the ADS-B traffic capable of flying. This approach also enables the AOP
data, and may use TIS data to determine state and to be designed as a generic system with applications
intent information about the other aircraft. The AOP to a wide range of aircraft types.
uses enhanced Flight Information Services (FIS)-like Figure 5 provides an overview of AOP integration
data to determine the position, shape and dynamics of with other flight deck systems, the FMS, and onboard
the area hazards. It sends its results to be displayed data links. In this figure, an advanced FMS is assumed
7OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
Se tSte
date are received prior to the processing trigger. In
this case, only one set of conflicts is released (equiv-
Intent State&Inte_
alent to the second set released in case (a)). In the
.......... _tfigger _ ......... asynchronous mode, Figure 6c, both of these real-time
cases are modeled the same way. All inputs that can
Intent o_i_s (1) cts(2)
be processed during this frame are identified and pro-
_nfli_s(2) cessed at the beginning of the frame, regardless of the
ReN-Time Real-Time As_c_onous actual computational time required. This removes the
(a) (b) (c) variability associated with the timing of inputs dur-
ing real-time modes, and provides repeatability for the
Fig. 6 Comparison of real-time and asynchronous
asynchronous mode. The results of the asynchronous
processing of ownship state and intent data.
mode match the results from case (b), proving validity.
that can support an iteration loop with the AOP to In the real-time mode, some calculations may take
generate potential ownship trajectories, in the back- longer than a single time frame. This is a function of
ground, while still performing normal FMS functions. the speed of the processor on which the AOP is exe-
cuting and the processor loading. Without accounting
Batch Mode Design Considerations for these factors, the AOP asynchronous mode could
To perform large numbers of non-human-in-the-loop potentially overestimate the real-time performance of
simulation runs, AOP has an asynchronous mode that the AOP. In batch mode, processing started within a
supports batch processing. The goal of asynchronous frame is finished within that frame. This causes the
mode is to create valid, repeatable system performance conflict resolution (CR) results, for example, to appar-
that can be used to create statistically significant re- ently be finished in 1 second of simulation time even
sults. A valid system performance means that the if it actually takes 4 seconds of wall-clock time. Batch
processing would produce results that could occur dur- processing mechanisms are being developed to account
ing real-time operations. Repeatability means that for for this situation. To simulate a computer requiring 4
the same inputs, AOP will produce the exact same re- seconds to complete CR calculations, the CR results
sults each time it is executed. How AOP accomplishes are "held" for three additional frames before being re-
validity and repeatability can be seen by a comparison leased. The magnitude of this "lag" is an adjustable
of real-time and asynchronous mode processing. parameter. This enables investigations into required
In Figure 6, the inputs to and outputs from AOPs processor performance, crew acceptability of system
conflict detection subsystem are presented for real- performance, and retrofit of AOP functionality into
time and asynchronous modes of operation. The time- existing flight deck computers.
line represents one cycle or frame of AOP processing
that starts at the top of the figure. Nominally, the AOP Software Design
AOP uses real-time or simulation-time frame lengths The AOP is implemented as a collection of sub-
of 1 second. During this frame, the AOP must com- systems that communicate with each other and with
plete a set of tasks that include execution of conflict the external systems through a common framework
detection algorithms. In the real-time mode, the AOP utilizing mutually agreed protocols. Each of the inde-
uses processing triggers for functions that are expected pendent AOP subsystems operates concurrently and
to complete within a frame. This ensures that pro- asynchronously with the other subsystems. A multi-
cessing begins with sufficient frame time remaining to threaded architecture is used so that subsystems may
complete the tasks during this frame. In the asyn- be assigned to individual execution threads.
chronous mode, processing triggers are not required. The AOP is an event-driven system, rather than a
The AOP will complete tasks assigned to this pro- periodic, schedule-driven system. It will, however, au-
cessing frame regardless of the actual processing time tomatically refresh trajectories if too much time has
required. In this mode, the simulation time is not ad- elapsed or trajectories have become invalid. These are
vanced until tasks are completed. both safety measures to ensure that the AOP main-
In Figure 6a, an ownship state is the only input data tains up-to-date trajectories and discards information
received by the conflict detection subsystem prior to a that is no longer relevant.
processing trigger. In this case, the state data are used A primary purpose of the AOP is to perform wide-
to determine new conflicts. In case (a), an ownship in- ranging research investigations in a simulation envi-
tent update is received after the first set of conflicts ronment. This requires the software to be extensible,
is output from the conflict detection subsystem. This flexible, and easily maintained. In order to provide
input event triggers a new conflict detection cycle that the researcher with maximum flexibility, the software
results in new conflicts (2) data being output during must be easily re-configurable at run-time. Since the
this AOP frame, thereby overwriting the old conflicts AOP is being designed to operate in three different en-
(1) data. In Figure 6b, both the state and intent up- vironments, all of which have different requirements,
8OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
shared-memmT architecture in the CMF and the
ARIES environments.
Figure 7shows the key components of the AOP soft-
OWnshiD ManaGer
ware. A central component is the AOP framework,
Ownship Processor
Plarn%inq Processor which integrates the subsystems providing the AOP
Command Processor with the input/output (I/O), the ownship, the haz-
Provisional Processor
ards, the conflict detection and resolution, and the
Inferred Intent Processor
output integration functions. Each subsystem has a
iiiiiiiiiiiii_iiiiiiiiiiiiiii
"manager", which is responsible for inter-subsystem
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
iiiiiiiiiiiii_iiiiiiiiiiiiii
communication, and one or more "processors", which
iiiiiiiiiiiiii_iiiiiiiiiiiiiii realize the functionality required of the subsystem.
The AOP Framework ensures a flexible, scalable,
iiii_iiiiiiiiiiiiiiiiiiiiiii and efficient framework for multi-threading asyn-
chronous communication among the AOP subsys-
tems, and reconfiguration during operation. The
iiiiiiiiiiiii_iiiiiiiiiiiiiii
AOP framework and subsystems employ a number
of software design patterns to achieve specific char-
AOP acteristics. _<_r Specifically, the AOP uses (1) a
Component-Configurator, (2) a Subject-Observer, (3)
an Acceptor-Connector, and (4) a Reactor design
Fig. 7" Key AOP software components. pattern to achieve efficiency and flexibility. The
Component-Configurator design pattern allows an ap-
the AOP must be able to interface with a variety of plication to link and unlink its components at run-time
external environments. In addition, the AOP must without having to modify, recompile, or statically re-
execute under Linux, Irix, and Win32. Thus, the soft- link the main application. This pattern supports the
ware must be platform-independent, to the maximum reconfiguration of components into the AOP without
extent possible. having to shutdown or re-start the main application.
The primary objectives of the AOP software design The Subject-Observer design pattern defines a one-to-
are (1) to instantiate the required AOP functionality many dependency between objects so that when one
described earlier, and (2) to meet the above software object changes state, all its dependents are notified
design constraints, in an efficient manner. This sec- and updated automatically. The AOP uses a vari-
tion describes the high-level software architecture of ation of this design pattern to include one or more
the AOP. Some of the salient software features are:
threads per object for asynchronous execution, to push
updates on message queues for protecting causal order-
Modular Design The AOP software is written in
ing, and to reference-count messages for efficient mem-
C++, using object-oriented design patterns. The ory usage. The Acceptor-Connector and the Reactor
object-oriented design provides extensibility, flex-
design patterns decouple a connections "management"
ibility, and re-usability of the AOP modules.
handling from its "service" handling. This allows a re-
searcher to easily develop a new "service" object to
Easy to Maintain The AOP software follows the
either handle data differently or get new data.
Langley Standard Real-Time Simulation in C++
(LaSRS++) guidelines developed for use in NASA Research and Development Plans
Langley Research Center facilities. _ These guide-
An early (pre-Build 1) prototype version of the AOP
lines help ensure the software will interoperate
is operational in the NASA Air Traffic Operations Lab-
with other NASA software systems, and that
oratory (ATOL). _s The prototype is being used to
the AOP software will be maintainable for many
support research studies and investigate new function-
years.
ality that may be required of the AOP. _9For example,
Platform Independence The AOP uses the Adap- RTCA concepts involving multiple protection zones
tive Communication Environment (ACE) as the surrounding the ownship will require new mechanisms
operating system abstraction layer to retain plat- both to detect conflicts and to properly inform the
crew of the conflict nature. _ Interoperability of the
form independence. ACE is a high-level C++
toolkit for writing sophisticated concurrent, par- AOP with airborne and ground-based systems is also
allel, and distributed applications. expected to be an area of active research. For exam-
pie, in a mixed equipage environment, some conflict
Flexible Interface The AOP supports data trans- resolution maneuvers may require compatibility with
mission using ARINC 429 characteristics over the Traffic Collision and Avoidance System (TCAS) ma-
TCP/IP in the ASTOR environment, and using neuvers, even if the ownship is not TCAS equipped.
9 OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS
Build 1 Build 2 Build 3
•Ownship Conformance •Coordination with ground- •Refinement of Build 2
Monitoring based traffic management capabilities
•Ownship Trajectory tools •Dynamic Area Hazards
Processing •Time Variant Static Area •Traffic Intent Inferencing
•Traffic Data Processing - Hazards •Port AOP functionality to
ADS-B •Multiple RTA 4-D high-fidelity simulators and
•Traffic Trajectory automatic resolution research aircraft
Generation •Fusion of hazards data
•Static Area Hazards - FIS- •Data Ambiguity resolution
B of hazards
•Area Hazard Modeling •Crew Alerting of
•Conflict Detection unpredictable traffic
•Conflict Resolution - 3D •Pairwise Separation
and single RTA 4-D Integration - Optimized
•ACM collision avoidance arrival spacing
zones •Flight Crew, AOC, ATSP
goals and preferences
accommodation
•Trajectory Optimization
Fig. 8 AOP phased development plan.
The AOP will also need to exchange data with, and actions with ground-based traffic management tools
operate cooperatively with, future ground-based air being developed by the NASA Ames Research Cen-
traffic management systems and airborne ASAS sys- ter. Additions to the airborne components of AOP
tems using advanced data link technologies. Future will include Time Variant Static Area Hazard conflict
CD&R algorithms, especially those that can be for- detection and resolution, capability for multiple RTA
really proven to result in safe resolution trajectories, 4-D resolutions, and conflict prioritization. Addition-
will be incorporated in the AOP as they become avail- ally, Traffic Data Management and Area Hazard Data
able. a° Management will give the AOP additional capability
A phased development of AOP capabilities is with ambiguity resolution, confidence assessment and
planned, as shown in Figure 8; other capabilities may data fusion from multiple data sources. The AOP
be added as research warrants. The initial build of will be integrated with pairwise-separation to aid the
the AOP incorporates both state-based, intent-based crew in sequencing and self-separation during arrivals.
conflict detection and resolution and optimized tra- If required, the trajectory between broadcast TCPs
jectories with traffic and static area hazards. Traf- will be constructed for conflict detection and resolu-
fic state-projection trajectories and traffic TCP based tion (e.g. determining the curved traffic trajectory to
trajectories are generated from traffic ADS-B data. Top of Climb and Bottom of Descent). Finally, op-
Area hazard models are generated from enhanced FIS- timized en route and arrival trajectories, assimilating
like data. In Build 1, to be completed in November flight crew, AOC and ATSP goals and preferences, will
2002, conflict resolution takes into account priority and also be introduced.
maneuver flight rules, user-specified resolution degrees Build 3will primarily add the traffic intent inferenc-
of freedom, and optimizes a a-D, or single RTA 4-D au- ing (if found to be necessary) and dynamic area hazard
tomatic resolution with the FMS. Conflict detection prediction to the AOP. Capabilities established in the
alerts, conflict resolutions and traffic are displayed to previous builds will be further refined. The AOP soft-
the crew through the aircrafts PED and ND. Flight ware will also be ported to CME and NASA aircraft
crew interaction, with the AOP, is through the MCP for research in high-fidelity simulation facilities and re-
and EMS CDU. Support for multiple types of protec- search aircraft.
tion zones surrounding the ownship will be added, and
a TCAS model will be incorporated in the ATOL en- Summary
vironment. In collaboration with industry and the interna-
Along with refining Build 1 capabilities, the ensu- tional R&D community, NASA is developing the Au-
ing build of the AOP will introduce automated inter- tonomous Operations Planner (AOP) flight deck de-
10 OF 11
AMERICAN INSTITUTE OF AERONAUTICS AND ASTRONAUTICS