Engineering topics

Wolter, Cynthia A.

Publications and source records attributed to Wolter, Cynthia A..

8 records

NASA NTRS2018

TCL2 National Campaign Human Factors Brief

The Technology Capability Level-2 National Campaign (TCL2nc) was conducted at six different test-sites located across the USA, during May and June of 2017. The campaign resulted in over 240 data collection flights using 24 different aircraft and involving 23 flight crews. Flights not only varied in duration, but also in the environments and terrains over which they flew. The TCL2nc highlighted beyond visual line of sight (BVLOS) and altitude-stratified operations, and saw five partners bring their own, independently built, UAS Service Supplier (USS) for use during the flight tests. This document presents data collected during the TCL2nc that informs the 'Operator' section of the 'Requirements/Best Practices' from the UTM Technical Capability Matrix and Guidelines to Operate (Rios, version as of March 2017). A review of the data collected indicated that although teams were well qualified on paper (in terms of both completing training and having experience with flying UAS vehicles), greater consideration should be given to the unique perspectives and backgrounds of future UAS operators. Overall, teams looked at a variety of sources for information, including USS client-displays, and participants became more mindful of the need to be aware of other vehicles, highlighting the value of reporting information. Observations found that flight crews' time to respond to a UTM issue depended heavily on the team structure, communication efficiency, and crew procedures. These points are discussed in more detail below.

unmanned vehicles↗

NASA NTRS2017

NASA's UTM Research

The Technology Capability Level-2 National Campaign (TCL2nc) was conducted at six different test sites located across the USA, during May and June of 2017. The campaign resulted in over 250 data collection flights using 26 different aircraft and involving 23 flight crews. Flights not only varied in duration, but also in the environments and terrains over which they flew. The TCL2nc highlighted beyond visual line of sight (BVLOS) and altitude-stratified operations, and saw five partners bring their own, independently built, UTM Service Supplier (USS) for use during the flight tests. This document presents data collected during the TCL2nc that informs the 'Operator' section of the 'Requirements/Best Practices' from the UTM Technical Capability Matrix and Guidelines to Operate (Rios, version as of March 2017). A review of the data collected indicated that although teams were well qualified on paper (in terms of both completing training and having experience with flying UAS vehicles), greater consideration should be given to the unique perspectives and backgrounds of future UAS operators. Overall, teams looked at a variety of sources for information, including USS client-displays, and participants became more aware of the need to be aware of other vehicles, highlighting the value of reporting information. Observations found that flight crews' time to respond to a UTM issue depended heavily on the team structure, communication efficiency, and crew procedures.

Mercer, Joey↗

NASA NTRS2015

A Validated Task Analysis of the Single Pilot Operations Concept

The current day flight deck operational environment consists of a two-person Captain/First Officer crew. A concept of operations (ConOps) to reduce the commercial cockpit to a single pilot from the current two pilot crew is termed Single Pilot Operations (SPO). This concept has been under study by researchers in the Flight Deck Display Research Laboratory (FDDRL) at the National Aeronautics and Space Administration's (NASA) Ames (Johnson, Comerford, Lachter, Battiste, Feary, and Mogford, 2012) and researchers from Langley Research Centers (Schutte et al., 2007). Transitioning from a two pilot crew to a single pilot crew will undoubtedly require changes in operational procedures, crew coordination, use of automation, and in how the roles and responsibilities of the flight deck and ATC are conceptualized in order to maintain the high levels of safety expected of the US National Airspace System. These modifications will affect the roles and the subsequent tasks that are required of the various operators in the NextGen environment. The current report outlines the process taken to identify and document the tasks required by the crew according to a number of operational scenarios studied by the FDDRL between the years 2012-2014. A baseline task decomposition has been refined to represent the tasks consistent with a new set of entities, tasks, roles, and responsibilities being explored by the FDDRL as the move is made towards SPO. Information from Subject Matter Expert interviews, participation in FDDRL experimental design meetings, and study observation was used to populate and refine task sets that were developed as part of the SPO task analyses. The task analysis is based upon the proposed ConOps for the third FDDRL SPO study. This experiment possessed nine different entities operating in six scenarios using a variety of SPO-related automation and procedural activities required to guide safe and efficient aircraft operations. The task analysis presents the roles and responsibilities in a manner that can facilitate testing future scenarios. Measures of task count and workload were defined and analyzed to assess the impact of transitioning to a SPO environment.

task analysis↗

NASA NTRS2014

A Task Analytic Process to Define Future Concepts in Aviation

A necessary step when developing next generation systems is to understand the tasks that operators will perform. One NextGen concept under evaluation termed Single Pilot Operations (SPO) is designed to improve the efficiency of airline operations. One SPO concept includes a Pilot on Board (PoB), a Ground Station Operator (GSO), and automation. A number of procedural changes are likely to result when such changes in roles and responsibilities are undertaken. Automation is expected to relieve the PoB and GSO of some tasks (e.g. radio frequency changes, loading expected arrival information). A major difference in the SPO environment is the shift to communication-cued crosschecks (verbal / automated) rather than movement-cued crosschecks that occur in a shared cockpit. The current article highlights a task analytic process of the roles and responsibilities between a PoB, an approach-phase GSO, and automation.

single pilot operations↗

NASA NTRS2014

Flight Deck Robustness/Conformance Testing with a Surface Management System: An Integrated Pilot-Controller Human-in-the-Loop Surface Operations Simulation

An integrated flight deck and controller human-in-the-loopsimulation was conducted with a total of 120 Dallas-Ft.Worth (DFW) taxi-out operations. In this first integratedPilot-Controller Spot and Runway Departure Advisor(SARDA) simulation, ATC Ground and Local Controllersused the SARDA decision support tool to plan and issuespot release clearances and departure clearances. TheAirport and Terminal Area Simulator (ATAS), a simulatedB737NG piloted, in turn, by 10 commercial transportparticipant pilots, was integrated into the realisticsimulation traffic environment. In the simulation,controllers used SARDA advisories to issue spot release,taxi route, and runway/departure radio voice clearances toall aircraft on the airport surface. Simulation resultsindicated that under a variety of observed pilot/aircraftperformance variations, SARDA yielded controlleradvisories that were: Supportive of current-day time-basedoperations; Compatible with controllers’ expectations;Predictive of actual take-off times; and, Adaptable to offnominalevents. An Information Sharing Display, thatpresented SARDA sequence and timing information on theflight deck, was considered useful for both NextGenoperations and current-day time-based Traffic ManagementInitiative (TMI) operations.

Foyle, David C.↗

NASA NTRS2013

NextGen Flight Deck Surface Trajectory-Based Operations (STBO): Contingency Holds

The purpose of this pilot-in-the-loop taxi simulation was to investigate a NextGen Surface Trajectory-Based Operations (STBO) concept called "contingency holds." The contingency-hold concept parses a taxi route into segments, allowing an air traffic control (ATC) surface traffic management (STM) system to hold an aircraft when necessary for safety. Under nominal conditions, if the intersection or active runway crossing is clear, the hold is removed, allowing the aircraft to continue taxiing without slowing, thus improving taxi efficiency, while minimizing the excessive brake use, fuel burn, and emissions associated with stop-and-go taxi. However, when a potential traffic conflict exists, the hold remains in place as a fail-safe mechanism. In this departure operations simulation, the taxi clearance included a required time of arrival (RTA) to a specified intersection. The flight deck was equipped with speed-guidance avionics to aid the pilot in safely meeting the RTA. On two trials, the contingency hold was not released, and pilots were required to stop. On two trials the contingency hold was released 15 sec prior to the RTA, and on two trials the contingency hold was released 30 sec prior to the RTA. When the hold remained in place, all pilots complied with the hold. Results also showed that when the hold was released at 15-sec or 30-sec prior to the RTA, the 30-sec release allowed pilots to maintain nominal taxi speed, thus supporting continuous traffic flow; whereas, the 15-sec release did not. The contingency-hold concept, with at least a 30-sec release, allows pilots to improve taxiing efficiency by reducing braking, slowing, and stopping, but still maintains safety in that no pilots "busted" the clearance holds. Overall, the evidence suggests that the contingency-hold concept is a viable concept for optimizing efficiency while maintaining safety.

NextGen↗

NASA NTRS2012

DataComm in Flight Deck Surface Trajectory-Based Operations

The purpose of this pilot-in-the-loop aircraft taxi simulation was to evaluate a NextGen concept for surface trajectory-based operations (STBO) in which air traffic control (ATC) issued taxi clearances with a required time of arrival (RTA) by Data Communications (DataComm). Flight deck avionics, driven by an error-nulling algorithm, displayed the speed needed to meet the RTA. To ensure robustness of the algorithm, the ability of 10 two-pilot crews to meet the RTA was tested in nine experimental trials representing a range of realistic conditions including a taxi route change, an RTA change, a departure clearance change, and a crossing traffic hold scenario. In some trials, these DataComm taxi clearances or clearance modifications were accompanied by preview information, in which the airport map display showed a preview of the proposed route changes, including the necessary speed to meet the RTA. Overall, the results of this study show that with the aid of the RTA speed algorithm, pilots were able to meet their RTAs with very little time error in all of the robustness-testing scenarios. Results indicated that when taxi clearance changes were issued by DataComm only, pilots required longer notification distances than with voice communication. However, when the DataComm was accompanied by graphical preview, the notification distance required by pilots was equivalent to that for voice.

Bakowski, Deborah L.↗

NASA NTRS2012

DataComm in Flight Deck Surface Trajectory-Based Operations

The purpose of this pilot-in-the-loop aircraft taxi simulation was to evaluate a NextGen concept for surface trajectory-based operations (STBO) in which air traffic control (ATC) issued taxi clearances with a required time of arrival (RTA) by Data Communications (DataComm). Flight deck avionics, driven by an error-nulling algorithm, displayed the speed needed to meet the RTA. To ensure robustness of the algorithm, the ability of 10 two-pilot crews to meet the RTA was tested in nine experimental trials representing a range of realistic conditions including a taxi route change, an RTA change, a departure clearance change, and a crossing traffic hold scenario. In some trials, these DataComm taxi clearances or clearance modifications were accompanied by 'preview' information, in which the airport map display showed a preview of the proposed route changes, including the necessary speed to meet the RTA. Overall, the results of this study show that with the aid of the RTA speed algorithm, pilots were able to meet their RTAs with very little time error in all of the robustness-testing scenarios. Results indicated that when taxi clearance changes were issued by DataComm only, pilots required longer notification distances than with voice communication. However, when the DataComm was accompanied by graphical preview, the notification distance required by pilots was equivalent to that for voice.

NextGen↗