Search NASA⌕ Search

SEARCH · Search NASA

Results for “Level of Automation”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 91 records · Page 5

The Virtual Mission Operations Center

Spacecraft management is becoming more human intensive as spacecraft become more complex and as operations costs are growing accordingly. Several automation approaches have been proposed to lower these costs. However, most of these approaches are not flexible enough in the operations processes and levels of automation that they support. This paper presents a concept called the Virtual Mission Operations Center (VMOC) that provides highly flexible support for dynamic spacecraft management processes and automation. In a VMOC, operations personnel can be shared among missions, the operations team can change personnel and their locations, and automation can be added and removed as appropriate. The VMOC employs a form of on-demand supervisory control called management by exception to free operators from having to actively monitor their system. The VMOC extends management by exception, however, so that distributed, dynamic teams can work together. The VMOC uses work-group computing concepts and groupware tools to provide a team infrastructure, and it employs user agents to allow operators to define and control system automation.

Moore, Mike↗

Operator Performance Evaluation of Fault Management Interfaces for Next-Generation Spacecraft

In the cockpit of the NASA's next generation of spacecraft, most of vehicle commanding will be carried out via electronic interfaces instead of hard cockpit switches. Checklists will be also displayed and completed on electronic procedure viewers rather than from paper. Transitioning to electronic cockpit interfaces opens up opportunities for more automated assistance, including automated root-cause diagnosis capability. The paper reports an empirical study evaluating two potential concepts for fault management interfaces incorporating two different levels of automation. The operator performance benefits produced by automation were assessed. Also, some design recommendations for spacecraft fault management interfaces are discussed.

Hayashi, Miwa↗

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-loop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of"pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS. The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (1) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multi-sensor series of trajectories.

Brewster, L.↗

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Lab

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success ofthe Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-Ioop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of "pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS.' The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (l) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multisensor series oftrajectories

Brewster, Linda L.↗

Ground-based Automated Scheduling for Operations of the Mars 2020 Rover Mission

The National Aeronautics and Space Administration’s (NASA) Mars 2020 Rover, named Perseverance, landed on the surface of Mars in Jezero Crater on February 18, 2021. Since the landing, the rover’s activities have been planned with the aid of a ground-based automated scheduling system called Copilot. Automated scheduling is very rare for planetary rover missions. Historically humans have created a schedule manually and ensured that the schedule satisfied all constraints. Higher levels of automation in the system allows science planners to produce schedules for the rover more quickly. In addition to scheduling user-provided activities, Copilot generates and schedules two types of support activities: sleep activities and heating activities. Some activities require the CPU to be on as they execute, so Copilot schedules wakeups and shutdowns of the CPU at the appropriate times. Some activities require areas of the rover to be heated before they can execute, and that heating must be maintained throughout the duration of the activity. Copilot schedules the preheat and maintenance heating activities for the user-provided activities that require them. To facilitate Copilot usage, the Crosscheck tool shows the science planners how Copilot constructed a schedule. For activities that fail to be scheduled, Crosscheck gives information on the constraints that the activity would have violated. This gives the users insight into how to change the input activities and constraints in order to achieve a schedule that satisfies their goals.

Towey, Shannon↗

Automation effects in a multiloop manual control system

An experimental and analytical study was undertaken to investigate human interaction with a simple multiloop manual control system in which the human's activity was systematically varied by changing the level of automation. The system simulated was the longitudinal dynamics of a hovering helicopter. The automation-systems-stabilized vehicle responses from attitude to velocity to position and also provided for display automation in the form of a flight director. The control-loop structure resulting from the task definition can be considered a simple stereotype of a hierarchical control system. The experimental study was complemented by an analytical modeling effort which utilized simple crossover models of the human operator. It was shown that such models can be extended to the description of multiloop tasks involving preview and precognitive human operator behavior. The existence of time optimal manual control behavior was established for these tasks and the role which internal models may play in establishing human-machine performance was discussed.

Hess, R. A.↗

Landsat Data Continuity Mission (LDCM) Flight Dynamics System (FDS)

The Landsat Data Continuity Mission (LDCM) will be launched in January 2013 to continue the legacy of Landsat land imagery collection that has been on-going for the past 40 years. While the overall mission and science goals are designed to produce the SAME data over the years, the ground systems designed to support the mission objectives have evolved immensely. The LDCM Flight Dynamics System (FDS) currently being tested and deployed for operations is highly automated and well integrated with the other ground system elements. The FDS encompasses the full suite of flight dynamics functional areas, including orbit and attitude determination and prediction, orbit and attitude maneuver planning and execution, and planning product generation. The integration of the orbit, attitude, maneuver, and products functions allows a very smooth flow for daily operations support with minimal input needed from the operator. The system also provides a valuable real-time component that monitors the on-board orbit and attitude during every ground contact and will autonomously alert the Flight Operations Team (FOT) personnel when any violations are found. This paper provides an overview of the LDCM Flight Dynamics System and a detailed description of how it is used to support space operations. For the first time on a Goddard Space Flight Center (GSFC)-managed mission, the ground attitude and orbits systems are fully integrated into a cohesive package. The executive engine of the FDS permits three levels of automation: low, medium, and high. The high-level, which will be the standard mode for LDCM, represents nearly lights-out operations. The paper provides an in-depth look at these processes within the FDS in support of LDCM in all mission phases.

Good, Susan M.↗

Preliminary system design of a Three Arm Capture Mechanism (TACM) flight demonstration article

The overall objective of the Three Arm Capture Mechanism (TACM) is to serve as a demonstration of capability for capture of objects in space. These objects could be satellites, expended boosters, pieces of debris, etc.; anything of significant size. With this capability we can significantly diminish the danger of major collisions of debris with valuable space assets and with each other, which would otherwise produce many smaller, high velocity pieces of debris which also become concerns. The captured objects would be jettisoned into the atmosphere, relocated in 'parking' orbits, or recovered for disposition or refurbishment. The dollar value of satellites launched into space continues to grow along with the cost of insurance; having a capture capability takes a positive step towards diminishing this added cost. The effort covered is a planning step towards a flight demonstration of the satellite capture capability. Based on the requirement to capture a communication class satellite, its associated booster, or both, a preliminary system definition of a retrieval kit is defined. The objective of the flight demonstration is to demonstrate the techniques proposed to perform the mission and to obtain data on technical issues requiring an in situ space environment. The former especially includes issues such as automated image recognition techniques and control strategies that enable an unmanned vehicle to rendezvous and capture a satellite, contact dynamics between the two bodies, and the flight segment level of automation required to support the mission. A development plan for the operational retrieval capability includes analysis work, computer and ground test simulations, and finally a flight demonstration. A concept to perform a selected mission capturing a precessing communications satellite is described. Further development efforts using analytical tools and laboratory facilities are required prior to reaching the point at which a full commitment to the flight demonstration design can be made.

Schaefer, Otto↗

Display and Automation Considerations for the Airborne Collision Avoidance System Xu

In this paper we examine several display and automation considerations of a collision avoidance system that is currently under development: the Airborne Collision Avoidance System (ACAS) Xu. This study builds on previous work conducted as part of NASA’s Unmanned Aircraft Systems (UAS) Integration into the National Airspace System (NAS) project. ACAS Xu represents the next-generation successor to the Traffic Alert and Collision Avoidance System (TCAS II), wherein the Xu variant is intended for UAS applications. Whereas TCAS II exclusively issues RAs in the vertical dimension, a major distinction between ACAS Xu and previous collision avoidance (CA) systems is the introduction of horizontal and “blended” RAs (i.e., RAs with both horizontal and vertical components). This present work was conducted as an engineering analysis involving two parts. In Part 1, a two-by-two, within-subjects study was performed that manipulated how RAs were presented to a pilot situated at a UAS ground control station. Five participants experienced four experimental trials in which text and aural alerting characteristics were manipulated. In Part 2, another five participants experienced four trials in which the levels of automation were manipulated with regard to the CA and return-to-course (RTC) tasks. The results for Part 1 found no effect of display or alerting configuration on pilot performance. However, it was discovered that pilot response time to RAs greatly depended on the RA type. In particular, pilots were quicker to respond to vertical RAs (M = 4.52 seconds) than horizontal (M = 7.42 seconds) and blended (M = 9.68 seconds) RAs in which both dimensions were issued simultaneously. For Part 2 of the study, pilots found both auto-CA and auto-RTC functions equally useful. Most pilots were comfortable with the automation, however responses were mixed. Three of five participants indicated high levels of comfort with the auto-CA function, while two rated their comfort as low. Pilots’ comfort for the auto-RTC functionality was slightly higher: four out of five pilots gave high ratings, while one pilot gave a low rating. Overall, pilots ordinally ranked their preference for automated functions as auto-CA together with auto-RTC (when an aural alert announces a change between CA and RTC states), auto-CA, and auto-CA and RTC (without the aural state-change announcement). Recommendations for improving the display of automation are also discussed.

collision avoidance↗

Display and Automation Considerations for the Airborne Collision Avoidance System Xu

In this presentation we examine several display and automation considerations of a collision avoidance system that is currently under development: the Airborne Collision Avoidance System (ACAS) Xu. This study builds on previous work conducted as part of NASA’s Unmanned Aircraft Systems (UAS) Integration into the National Airspace System (NAS) project. ACAS Xu represents the next-generation successor to the Traffic Alert and Collision Avoidance System (TCAS II), wherein the Xu variant is intended for UAS applications. Whereas TCAS II exclusively issues RAs in the vertical dimension, a major distinction between ACAS Xu and previous collision avoidance (CA) systems is the introduction of horizontal and “blended” RAs (i.e., RAs with both horizontal and vertical components). This present work was conducted as an engineering analysis involving two parts. In Part 1, a two-by-two, within-subjects study was performed that manipulated how RAs were presented to a pilot situated at a UAS ground control station. Five participants experienced four experimental trials in which text and aural alerting characteristics were manipulated. In Part 2, another five participants experienced four trials in which the levels of automation were manipulated with regard to the CA and return-to-course (RTC) tasks. The results for Part 1 found no effect of display or alerting configuration on pilot performance. However, it was discovered that pilot response time to RAs greatly depended on the RA type. In particular, pilots were quicker to respond to vertical RAs (M = 4.52 seconds) than horizontal (M = 7.42 seconds) and blended (M = 9.68 seconds) RAs in which both dimensions were issued simultaneously. For Part 2 of the study, pilots found both auto-CA and auto-RTC functions equally useful. Most pilots were comfortable with the automation, however responses were mixed. Three of five participants indicated high levels of comfort with the auto-CA function, while two rated their comfort as low. Pilots’ comfort for the auto-RTC functionality was slightly higher: four out of five pilots gave high ratings, while one pilot gave a low rating. Overall, pilots ordinally ranked their preference for automated functions as auto-CA together with auto-RTC (when an aural alert announces a change between CA and RTC states), auto-CA, and auto-CA and RTC (without the aural state-change announcement). Recommendations for improving the display of automation are also discussed.

collision avoidance↗

Configuring the Orion Guidance, Navigation, and Control Flight Software for Automated Sequencing

The Orion Crew Exploration Vehicle is being designed with greater automation capabilities than any other crewed spacecraft in NASA s history. The Guidance, Navigation, and Control (GN&C) flight software architecture is designed to provide a flexible and evolvable framework that accommodates increasing levels of automation over time. Within the GN&C flight software, a data-driven approach is used to configure software. This approach allows data reconfiguration and updates to automated sequences without requiring recompilation of the software. Because of the great dependency of the automation and the flight software on the configuration data, the data management is a vital component of the processes for software certification, mission design, and flight operations. To enable the automated sequencing and data configuration of the GN&C subsystem on Orion, a desktop database configuration tool has been developed. The database tool allows the specification of the GN&C activity sequences, the automated transitions in the software, and the corresponding parameter reconfigurations. These aspects of the GN&C automation on Orion are all coordinated via data management, and the database tool provides the ability to test the automation capabilities during the development of the GN&C software. In addition to providing the infrastructure to manage the GN&C automation, the database tool has been designed with capabilities to import and export artifacts for simulation analysis and documentation purposes. Furthermore, the database configuration tool, currently used to manage simulation data, is envisioned to evolve into a mission planning tool for generating and testing GN&C software sequences and configurations. A key enabler of the GN&C automation design, the database tool allows both the creation and maintenance of the data artifacts, as well as serving the critical role of helping to manage, visualize, and understand the data-driven parameters both during software development and throughout the life of the Orion project.

Odegard, Ryan G.↗

Automated Attitude Sensor Calibration: Progress and Plans

This paper describes ongoing work a NASA/Goddard Space Flight Center to improve the quality of spacecraft attitude sensor calibration and reduce costs by automating parts of the calibration process. The new calibration software can autonomously preview data quality over a given time span, select a subset of the data for processing, perform the requested calibration, and output a report. This level of automation is currently being implemented for two specific applications: inertial reference unit (IRU) calibration and sensor alignment calibration. The IRU calibration utility makes use of a sequential version of the Davenport algorithm. This utility has been successfully tested with simulated and actual flight data. The alignment calibration is still in the early testing stage. Both utilities will be incorporated into the institutional attitude ground support system.

Sedlak, Joseph↗

Demonstration of an automated CFD system for three-dimensional flow simulations

In this paper the capabilities of an automated CFD system which is currently available at NLR are demonstrated. Transonic flow around the AS28G wing/body configuration and hypersonic flow through a generic three-dimensional mixed-compression airbreathing inlet are simulated. An assessment of the level of automation of the current CFD-system is made. The problem-turnaround time lies within the order of a week for both applications.

Vanderburg, J. W.↗

Automation of the ICME Workflow Incorporating Material Digital Twins at Different Length Scales Within a Robust Information Management System

Recent successes in Integrated Computational Materials Engineering (ICME) have demonstrated the potential in designing fit-for-purpose materials for a given application in a cost and time efficient manner. However, the material design process must contain a level of automation in the material decision process, implementing some optimization algorithms, to truly enable the full benefits of ICME, particularly when considering materials at multiple length/time scales. In this work, we will demonstrate how the GRC ICME schema and Python framework automates a workflow that captures, analyzes, maintains, and disseminates the digital footprint in the context of tailoring resin material at the nanoscale of a woven composite Y-joint at the macroscale for an Aurora D8 double bubble fuselage. This digital footprint incorporates the interaction of both structural digital twins and material twins at various length scales.

Brandon L. Hearley↗

Command and Control Concepts for an Lift Plus Cruise Electric Vertical Takeoff and Landing Vehicle

Electric Vertical Takeoff and Landing (eVTOL) vehicles have the potential to enable cost effective Urban Air Mobility (UAM) applications. Many of these vehicle concepts will takeoff vertically like a helicopter, transition to fly like an airplane, and then transition back to land vertically like a helicopter. However, these concepts may also pose several challenging handling and control problems, which must be addressed prior to safe and reliable urban operations. This study investigates some of these challenges by evaluating different command and control concepts for a conceptual Lift Plus Cruise vehicle designed by NASA’s Revolutionary Vertical Lift Technology (RVLT) project. Four different command concepts with increasing levels of automation are developed. The command and control architecture for these concepts is presented along with findings from the evaluation of these concepts in a series of three piloted studies in the Vertical Motion Simulator at NASA Ames Research Center, where pilots flew operationally relevant flight test maneuvers specifically designed to expose potential deficiencies. The higher-level control systems and the associated pilot interfaces were shown to improve performance and handling in many cases, especially for higher precision and lower to moderate aggression maneuvers. The benefits were limited for higher aggression tasks in environmentally stressing conditions, due to the slower response of the automation and inherent limitations of the vehicle design, which highlights the potential need for tradeoffs between concept of operations and vehicle capabilities

Thomas Lombaerts↗

Automated, Parametric Geometry Modeling and Grid Generation for Turbomachinery Applications

The objective of this Phase I project is to develop a highly automated software system for rapid geometry modeling and grid generation for turbomachinery applications. The proposed system features a graphical user interface for interactive control, a direct interface to commercial CAD/PDM systems, support for IGES geometry output, and a scripting capability for obtaining a high level of automation and end-user customization of the tool. The developed system is fully parametric and highly automated, and, therefore, significantly reduces the turnaround time for 3D geometry modeling, grid generation and model setup. This facilitates design environments in which a large number of cases need to be generated, such as for parametric analysis and design optimization of turbomachinery equipment. In Phase I we have successfully demonstrated the feasibility of the approach. The system has been tested on a wide variety of turbomachinery geometries, including several impellers and a multi stage rotor-stator combination. In Phase II, we plan to integrate the developed system with turbomachinery design software and with commercial CAD/PDM software.

Harrand, Vincent J.↗

Platform Management System (PMS) evolution

In fiscal year 1988 a study was begun to define the platform management system (PMS) functions required for the mature platform operations era. The objectives of the task include: (1) defining how to increase the operational productivity of the platform by providing enhanced capability for responding to changing events, (2) influencing the initial PMS design by identifying required 'hooks and scars', and (3) evaluation potential automation techniques that are appropriate given predicted onboard computing resources. Initial platform operations scenarios were defined. The focus was on PMS-related functions where operations enhancements are likely to occur. Operations productivity was defined in terms of scientific productivity of the platform as well as the level of automation of the ground system. The Platform Operations Productivity Enhancement Report was completed earlier this year documenting system enhancements to increase science productivity and ground system automation. Using the baseline PMS defined in the PMS Definition Document as a starting point, the resulting PMS-specific enhancements were molded into a sequence of progressively more sophisticated operations management capabilities. This sequence of upgrades to the PMS has been documented in a PMS Evolution Plan. The plan includes enhancements in the areas of resources scheduling, resource modeling, system and payload anomaly management, and transaction sequence interpretation. A plan for migration of functions from the ground portion of the PMS to the flight portion is also included. The impacts of this plan on the platform are now being documented to ensure that the required 'hooks and scars' are included in the baseline system. Future plans include a prototype of some of the PMS enhancements to address the feasibility of and techniques for implementing these enhancements in the onboard computing environment.

Tilley, Mike↗

Final-Approach-Spacing Subsystem For Air Traffic

Automation subsystem of computers, computer workstations, communication equipment, and radar helps air-traffic controllers in terminal radar approach-control (TRACON) facility manage sequence and spacing of arriving aircraft for both efficiency and safety. Called FAST (Final Approach Spacing Tool), subsystem enables controllers to choose among various levels of automation.

Davis, Thomas J.↗