Results for “Automating” — Page 6

NASA NTRS1993

The application of automated operations at the Institutional Processing Center

The JPL Institutional and Mission Computing Division, Communications, Computing and Network Services Section, with its mission contractor, OAO Corporation, have for some time been applying automation to the operation of JPL's Information Processing Center (IPC). Automation does not come in one easy to use package. Automation for a data processing center is made up of many different software and hardware products supported by trained personnel. The IPC automation effort formally began with console automation, and has since spiraled out to include production scheduling, data entry, report distribution, online reporting, failure reporting and resolution, documentation, library storage, and operator and user education, while requiring the interaction of multi-vendor and locally developed software. To begin the process, automation goals are determined. Then a team including operations personnel is formed to research and evaluate available options. By acquiring knowledge of current products and those in development, taking an active role in industry organizations, and learning of other data center's experiences, a forecast can be developed as to what direction technology is moving. With IPC management's approval, an implementation plan is developed and resources identified to test or implement new systems. As an example, IPC's new automated data entry system was researched by Data Entry, Production Control, and Advance Planning personnel. A proposal was then submitted to management for review. A determination to implement the new system was made and elements/personnel involved with the initial planning performed the implementation. The final steps of the implementation were educating data entry personnel in the areas effected and procedural changes necessary to the successful operation of the new system.

Barr, Thomas H.↗

NASA NTRS1994

Production and quality assurance automation in the Goddard Space Flight Center Flight Dynamics Facility

The Flight Dynamics Facility (FDF) at the NASA Goddard Space Flight Center (GSFC) generates numerous products for NASA-supported spacecraft, including the Tracking and Data Relay Satellites (TDRS's), the Hubble Space Telescope (HST), the Extreme Ultraviolet Explorer (EUVE), and the space shuttle. These products include orbit determination data, acquisition data, event scheduling data, and attitude data. In most cases, product generation involves repetitive execution of many programs. The increasing number of missions supported by the FDF has necessitated the use of automated systems to schedule, execute, and quality assure these products. This automation allows the delivery of accurate products in a timely and cost-efficient manner. To be effective, these systems must automate as many repetitive operations as possible and must be flexible enough to meet changing support requirements. The FDF Orbit Determination Task (ODT) has implemented several systems that automate product generation and quality assurance (QA). These systems include the Orbit Production Automation System (OPAS), the New Enhanced Operations Log (NEOLOG), and the Quality Assurance Automation Software (QA Tool). Implementation of these systems has resulted in a significant reduction in required manpower, elimination of shift work and most weekend support, and improved support quality, while incurring minimal development cost. This paper will present an overview of the concepts used and experiences gained from the implementation of these automation systems.

Chapman, K. B.↗

NASA NTRS2001

Psychophysiological Control of Acognitive Task Using Adaptive Automation

The major focus of the present proposal was to examine psychophysiological variables related to hazardous states of awareness induced by monitoring automated systems. With the increased use of automation in today's work environment, people's roles in the work place are being redefined from that of active participant to one of passive monitor. Although the introduction of automated systems has a number of benefits, there are also a number of disadvantages regarding worker performance. Byrne and Parasuraman have argued for the use of psychophysiological measures in the development and the implementation of adaptive automation. While both performance based and model based adaptive automation have been studied, the use of psychophysiological measures, especially EEG, offers the advantage of real time evaluation of the state of the subject. The current study used the closed-loop system, developed at NASA-Langley Research Center, to control the state of awareness of subjects while they performed a cognitive vigilance task. Previous research in our laboratory, supported by NASA, has demonstrated that, in an adaptive automation, closed-loop environment, subjects perform a tracking task better under a negative than a positive, feedback condition. In addition, this condition produces less subjective workload and larger P300 event related potentials to auditory stimuli presented in a concurrent oddball task. We have also recently shown that the closed-loop system used to control the level of automation in a tracking task can also be used to control the event rate of stimuli in a vigilance monitoring task. By changing the event rate based on the subject's index of arousal, we have been able to produce improved monitoring, relative to various control groups. We have demonstrated in our initial closed-loop experiments with the the vigilance paradigm that using a negative feedback contingency (i.e. increasing event rates when the EEG index is low and decreasing event rates when the EEG index is high) results in a marked decrease of the vigilance decrement over a 40 minute session. This effect is in direct contrast to performance of a positive feedback group, as well as a number of other control groups which demonstrated the typical vigilance decrement. Interestingly, however, the negative feedback group performed at virtually the same level as a yoked control group. The yoked control group received the same order of changes in event rate that were generated by the negative feedback subjects using the closed-loop system. Thus it would appear to be possible to optimize vigilance performance by controlling the stimuli which subjects are asked to process.

Freeman, Frederick↗

NASA NTRS1995

Line Pilots' Attitudes about and Experience with Flight Deck Automation: Results of an International Survey and Proposed Guidelines

A survey of line pilots' attitudes about flight deck automation was conducted by the Royal Air Force Institute of Aviation Medicine (RAF IAM, Farnborough, UK) under the sponsorship of the United Kingdom s Civil Aviation Authority and in cooperation with IATA (the International Air Transport Association). Survey freehand comments given by pilots operating 13 types of commercial transports across five manufacturers (Airbus, Boeing, British Aerospace, Lockheed, and McDonnell-Douglas) and 57 air carriers/organizations were analyzed by NASA. These data provide a "lessons learned" knowledge base which may be used for the definition of guidelines for flight deck automation and its associated crew interface within the High Speed Research Program. The aircraft chosen for analysis represented a progression of levels of automation sophistication and complexity, from "Basic" types (e.g., B727, DC9), through "Transition" types (e.g., A300, Concorde), to two levels of glass cockpits (e.g., Glass 1: e.g., A310; Glass 2: e.g., B747-400). This paper reports the results of analyses of comments from pilots flying commercial transport types having the highest level of automation sophistication (B757/B767, B747-400, and A320). Comments were decomposed into five categories relating to: (1) general observations with regard to flight deck automation; comments concerning the (2) design and (3) crew understanding of automation and the crew interface; (4) crew operations with automation; and (5) personal factors affecting crew/automation interaction. The goal of these analyses is to contribute to the definition of guidelines which may be used during design of future aircraft flight decks.

Rudisill, Marianne↗

NASA NTRS2006

Managing the Implementation of Mission Operations Automation

Reducing the cost of mission operations has necessitated a high level of automation both on spacecraft and ground systems. While automation on spacecraft is implemented during the design phase, ground system automation tends to be implemented during the prime mission operations phase. Experience has shown that this tendency for late automation development can be hindered by several factors: additional hardware and software resources may need to be procured; software must be developed and tested on a non-interference basis with primary operations with limited manpower; and established procedures may not be suited for automation requiring substantial rework. In this paper we will review the experience of successfully automating mission operations for seven on-orbit missions: the Compton Gamma Ray Observatory (CGRO), the Rossi X-Ray Timing Explorer (RXTE), the Advanced Composition Explorer (ACE), the Far Ultraviolet Spectroscopic Explorer (FUSE), Interplanetary Physics Laboratory (WIND), Polar Plasma Laboratory (POLAR), and the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE). We will provide lessons learned in areas such as: spacecraft recorder management, procedure development, lights out commanding from the ground system vs. stored command loads, spacecraft contingency response time, and ground station interfaces. Implementing automation strategies during the mission concept and spacecraft integration and test phase as the most efficient method will be discussed.

Sodano, R.↗

NASA NTRS2007

Experimental Evaluation of an Integrated Datalink and Automation-Based Strategic Trajectory Concept

This paper presents research on the interoperability of trajectory-based automation concepts and technologies with modern Flight Management Systems and datalink communication available on many of today s commercial aircraft. A tight integration of trajectory-based ground automation systems with the aircraft Flight Management System through datalink will enable mid-term and far-term benefits from trajectory-based automation methods. A two-way datalink connection between the trajectory-based automation resident in the Center/TRACON Automation System and the Future Air Navigation System-1 integrated FMS/datalink in NASA Ames B747-400 Level D simulator has been established and extensive simulation of the use of datalink messages to generate strategic trajectories completed. A strategic trajectory is defined as an aircraft deviation needed to solve a conflict or honor a route request and then merge the aircraft back to its nominal preferred trajectory using a single continuous trajectory clearance. Engineers on the ground side of the datalink generated lateral and vertical trajectory clearances and transmitted them to the Flight Management System of the 747; the airborne automation then flew the new trajectory without human intervention, requiring the flight crew only to review and to accept the trajectory. This simulation established the protocols needed for a significant majority of the trajectory change types required to solve a traffic conflict or deviate around weather. This demonstration provides a basis for understanding the requirements for integration of trajectory-based automation with current Flight Management Systems and datalink to support future National Airspace System operations.

Mueller, Eric↗

NASA NTRS2010

Effects of Secondary Task Modality and Processing Code on Automation Trust and Utilization During Simulated Airline Luggage Screening

The purpose of this research was to examine the impact of environmental distractions on human trust and utilization of automation during the process of visual search. Participants performed a computer-simulated airline luggage screening task with the assistance of a 70% reliable automated decision aid (called DETECTOR) both with and without environmental distractions. The distraction was implemented as a secondary task in either a competing modality (visual) or non-competing modality (auditory). The secondary task processing code either competed with the luggage screening task (spatial code) or with the automation's textual directives (verbal code). We measured participants' system trust, perceived reliability of the system (when a target weapon was present and absent), compliance, reliance, and confidence when agreeing and disagreeing with the system under both distracted and undistracted conditions. Results revealed that system trust was lower in the visual-spatial and auditory-verbal conditions than in the visual-verbal and auditory-spatial conditions. Perceived reliability of the system (when the target was present) was significantly higher when the secondary task was visual rather than auditory. Compliance with the aid increased in all conditions except for the auditory-verbal condition, where it decreased. Similar to the pattern for trust, reliance on the automation was lower in the visual-spatial and auditory-verbal conditions than in the visual-verbal and auditory-spatial conditions. Confidence when agreeing with the system decreased with the addition of any kind of distraction; however, confidence when disagreeing increased with the addition of an auditory secondary task but decreased with the addition of a visual task. A model was developed to represent the research findings and demonstrate the relationship between secondary task modality, processing code, and automation use. Results suggest that the nature of environmental distractions influence interaction with automation via significant effects on trust and system utilization. These findings have implications for both automation design and operator training.

Phillips, Rachel↗

NASA NTRS2014

Level of Automation and Failure Frequency Effects on Simulated Lunar Lander Performance

A human-in-the-loop experiment was conducted at the NASA Ames Research Center Vertical Motion Simulator, where instrument-rated pilots completed a simulated terminal descent phase of a lunar landing. Ten pilots participated in a 2 x 2 mixed design experiment, with level of automation as the within-subjects factor and failure frequency as the between subjects factor. The two evaluated levels of automation were high (fully automated landing) and low (manual controlled landing). During test trials, participants were exposed to either a high number of failures (75% failure frequency) or low number of failures (25% failure frequency). In order to investigate the pilots' sensitivity to changes in levels of automation and failure frequency, the dependent measure selected for this experiment was accuracy of failure diagnosis, from which D Prime and Decision Criterion were derived. For each of the dependent measures, no significant difference was found for level of automation and no significant interaction was detected between level of automation and failure frequency. A significant effect was identified for failure frequency suggesting failure frequency has a significant effect on pilots' sensitivity to failure detection and diagnosis. Participants were more likely to correctly identify and diagnose failures if they experienced the higher levels of failures, regardless of level of automation

performance↗

NASA NTRS2017

Lighting Automation - Flying an Earthlike Habitat

Currently, spacecraft lighting systems are not demonstrating innovations in automation due to perceived costs in designing circuitry for the communication and automation of lights. The majority of spacecraft lighting systems employ lamps or zone specific manual switches and dimmers. This type of 'hardwired' solution does not easily convert to automation. With advances in solid state lighting, the potential to enhance a spacecraft habitat is lost if the communication and automation problem is not tackled. If we are to build long duration environments, which provide earth-like habitats, minimize crew time, and optimize spacecraft power reserves, innovation in lighting automation is a must. This project researched the use of the DMX512 communication protocol originally developed for high channel count lighting systems. DMX512 is an internationally governed, industry-accepted, lighting communication protocol with wide industry support. The lighting industry markets a wealth of hardware and software that utilizes DMX512, and there may be incentive to space certify the system. Our goal in this research is to enable the development of automated spacecraft habitats for long duration missions. To transform how spacecraft lighting environments are automated, our project conducted a variety of tests to determine a potential scope of capability. We investigated utilization and application of an industry accepted lighting control protocol, DMX512 by showcasing how the lighting system could help conserve power, assist with lighting countermeasures, and utilize spatial body tracking. We hope evaluation and the demonstrations we built will inspire other NASA engineers, architects and researchers to consider employing DMX512 "smart lighting" capabilities into their system architecture. By using DMX512 we will prove the 'wheel' does not need to be reinvented in terms of smart lighting and future spacecraft can use a standard lighting protocol to produce an effective, optimized and potentially earthlike habitat.

Clark, Tori A.↗

NASA NTRS2017

Lighting Automation Flying an Earthlike Habitat

Currently, spacecraft lighting systems are not demonstrating innovations in automation due to perceived costs in designing circuitry for the communication and automation of lights. The majority of spacecraft lighting systems employ lamps or zone specific manual switches and dimmers. This type of 'hardwired' solution does not easily convert to automation. With advances in solid state lighting, the potential to enhance a spacecraft habitat is lost if the communication and automation problem is not tackled. If we are to build long duration environments, which provide earth-like habitats, minimize crew time, and optimize spacecraft power reserves, innovation in lighting automation is a must. This project researched the use of the DMX512 communication protocol originally developed for high channel count lighting systems. DMX512 is an internationally governed, industry-accepted, lighting communication protocol with wide industry support. The lighting industry markets a wealth of hardware and software that utilizes DMX512, and there may be incentive to space certify the system. Our goal in this research is to enable the development of automated spacecraft habitats for long duration missions. To transform how spacecraft lighting environments are automated, our project conducted a variety of tests to determine a potential scope of capability. We investigated utilization and application of an industry accepted lighting control protocol, DMX512 by showcasing how the lighting system could help conserve power, assist with lighting countermeasures, and utilize spatial body tracking. We hope evaluation and the demonstrations we built will inspire other NASA engineers, architects and researchers to consider employing DMX512 "smart lighting" capabilities into their system architecture. By using DMX512 we will prove the 'wheel' does not need to be reinvented in terms of smart lighting and future spacecraft can use a standard lighting protocol to produce an effective, optimized and potentially earthlike habitat.

Clark, Toni A.↗

NASA NTRS2018

Human-Automation Allocations for Current Robotic Space Operations

Within the Human Research Program, one risk delineates the uncertainty surrounding crew working with automation and robotics in spaceflight. The Risk of Inadequate Design of Human and Automation/Robotic Integration (HARI) is concerned with the detrimental effects on crew performance due to ineffective user interfaces, system designs and/or functional task allocation, potentially compromising mission success and safety. Risk arises because we have limited experience with complex automation and robotics. One key gap within HARI, is the gap related to functional allocation. The gap states: We need to evaluate, develop, and validate methods and guidelines for identifying human-automation/robot task information needs, function allocation, and team composition for future long duration, long distance space missions. Allocations determine the human-system performance as it identifies the functions and performance levels required by the automation/robotic system, and in turn, what work the crew is expected to perform and the necessary human performance requirements. Allocations must take into account each of the human, automation, and robotic systems capabilities and limitations. Some functions may be intuitively assigned to the human versus the robot, but to optimize efficiency and effectiveness, purposeful role assignments will be required. The role of automation and robotics will significantly change in future exploration missions, particularly as crew becomes more autonomous from ground controllers. Thus, we must understand the suitability of existing function allocation methods within NASA as well as the existing allocations established by the few robotic systems that are operational in spaceflight. In order to evaluate future methods of robotic allocations, we must first benchmark the allocations and allocation methods that have been used. We will present 1) documentation of human-automation-robotic allocations in existing, operational spaceflight systems; and 2) To gather existing lessons learned and best practices in these role assignments, from spaceflight operational experience of crew and ground teams that may be used to guide development for future systems. NASA and other space agencies have operational spaceflight experience with two key Human-Automation-Robotic (HAR) systems: heavy lift robotic arms and planetary robotic explorers. Additionally, NASA has invested in high-fidelity rover systems that can carry crew, building beyond Apollo's lunar rover. The heavy lift robotic arms reviewed are: Space Station Remote Manipulator System (SSRMS), Japanese Remote Manipulator System (JEMRMS), and the European Robotic Arm (ERA, designed but not deployed in space). The robotic rover systems reviewed are: Mars Exploration Rovers, Mars Science Laboratory rover, and the high-fidelity K10 rovers. Much of the design and operational feedback for these systems have been communicated to flight controllers and robotic design teams. As part of the mitigating the HARI risk for future human spaceflight operations, we must document function allocations between robots and humans that have worked well in practice.

robotic allocation↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Initial Design Guidelines for Onboard Automation of Flight Path Management

Achieving the National Academy of Science’s vision of advanced aerial mobility will depend on significant developments in automation to achieve safe and efficient operations. Flight path management (FPM), a major category of automation functionality needed to achieve this vision, will provide dynamic management of an aircraft’s flight path, ensuring that it remains feasible to fly to mission completion, deconflicted from hazards, coordinated with other traffic, flexible to accommodate future disturbances, and optimized to meet business objectives. While efforts are underway to advance FPM technology for the Urban Air Mobility application, initial design guidelines are presented for FPM automation capabilities to achieve each of these objectives based on 15+ years of prior FPM automation research and development. Methods to efficiently account for uncertainty in the prediction of trajectories are described, as are additional considerations for prioritizing safety in the design of FPM automation capabilities and interactions between aircraft. Recommendations are supported by extensive experience gained via previous work with the FPM reference automation system, Autonomous Operations Planner, developed by NASA. By employing capable FPM automation supported by cooperative operational flight rules and information sharing, future aircraft operators will benefit from an increased ability to plan and execute safe and efficient flights and to achieve mission success in a dynamic airspace.

Flight Path Management, FPM, AOP, UAM, deconflicti↗

NASA NTRSDate not supplied

Initial Design Guidelines for Onboard Automation of Flight Path Management

Achieving the National Academy of Science’s vision of advanced aerial mobility will depend on significant developments in automation to achieve safe and efficient operations. Flight path management (FPM), a major category of automation functionality needed to achieve this vision, will provide dynamic management of an aircraft’s flight path, ensuring that it remains feasible to fly to mission completion, deconflicted from hazards, coordinated with other traffic, flexible to accommodate future disturbances, and optimized to meet business objectives. While efforts are underway to advance FPM technology for the Urban Air Mobility application, initial design guidelines are presented for FPM automation capabilities to achieve each of these objectives based on 15+ years of prior FPM automation research and development. Methods to efficiently account for uncertainty in the prediction of trajectories are described, as are additional considerations for prioritizing safety in the design of FPM automation capabilities and interactions between aircraft. Recommendations are supported by extensive experience gained via previous work with the FPM reference automation system, Autonomous Operations Planner, developed by NASA. By employing capable FPM automation supported by cooperative operational flight rules and information sharing, future aircraft operators will benefit from an increased ability to plan and execute safe and efficient flights and to achieve mission success in a dynamic airspace.

Flight Path Management↗

NASA NTRSDate not supplied

Physiological and Subjective Responses of Pilots During Advanced Air Mobility Flight Testing With Automated Systems

Aviation is constantly evolving, mostly due to the integration of automated systems into the National Airspace System. This presents a host of challenges and opportunities. NASA's Advanced Air Mobility (AAM) project has taken a significant leap forward with a research flight test led by the Integration of Automated Systems (IAS) sub-project. This effort focused on assessing automated flight deck algorithms essential for supporting high-density Urban Air Mobility (UAM) operations. Carrying out a two-ship flight test in UAM Maturity Level 4 scenarios, the team evaluated state-of-the-art algorithms, including Hazard Perception and Avoidance (HPA) and flight path management (FPM) systems. This presentation focuses on results of pilots' physiological and subjective responses during the flight scenarios conducted. In collaboration with Lockheed Martin Advanced Technology Laboratories (ATL), we collected and analyzed live-flight biometric data using eye tracking, mobile brain imaging, and heart rate sensors. The data provides insights into pilots' workload and cognitive engagement while navigating automated tools, leveraging both biometric data and post-encounter subjective assessments. The research highlights the interaction between human operators and automated systems, contributing valuable lessons learned about gathering human data in live-flight environments. The knowledge acquired from this endeavor enhances our understanding of human factors in automated flight and informs future studies attempting to undertake similar feats.

air mobility↗

DOE OSTI2025

Microreactor Automated Control System - Digital Twin Models and Advanced Control Systems Updates

Automation of control systems is expected to be important in the economic and safe operation of microreactors. Therefore, there is a need to develop and demonstrate automated control for microreactors, along with the development of testbeds for this purpose. This report provides updates on the status of a nonnuclear microreactor automated control system (MACS)—a real-time, hardware-in-the-loop testbed for non-nuclear testing of microreactor control system automation. A real-time hardware-in-the-loop testbed incorporates the realistic dynamics of physical systems into control system development and testing. The collaborative effort between Oak Ridge National Laboratory (ORNL) and Idaho National Laboratory (INL) resulted in the development of a prototypic microreactor plant-level digital twin that includes the reactor and a balance of plant system. Advanced control strategies were incorporated to demonstrate testing of control automation solutions. The gRPC communication protocol, which was implemented in the hardware-in-the-loop testbed by INL, was coupled to a digital twin model developed using the TRANsient Simulation Framework of Reconfigurable Models (TRANSFORM) library in Modelica. This digital twin simulation was tested with the ViBRANT hardware for realistic feedback and visual representation of control action in real time. A modular Python client structure was developed to manage functional mock-up unit-based simulation and real-time gRPC communication. Hardware-in-the-loop testing indicated that the modeled reactor—a natural-convection, molten-salt coolant loop configuration—responds well to control of drum positioning for modulation of reactor core power, as well as system-level control and downstream demand changes. Ongoing research is focused on integrating additional control algorithms that utilize data from newly included sensors within the MACS hardware testbed, as well as demonstrating and assessing the performance of the different automated control algorithms on multiple additional operational scenarios.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗