Results for “Function Allocation” — Page 5

NASA NTRS2017

Exploring Concepts of Operations for On-Demand Passenger Air Transportation

In recent years, a surge of interest in "flying cars" for city commutes has led to rapid development of new technologies to help make them and similar on-demand mobility platforms a reality. To this end, this paper provides analyses of the stakeholders involved, their proposed operational concepts, and the hazards and regulations that must be addressed. Three system architectures emerged from the analyses, ranging from conventional air taxi to revolutionary fully autonomous aircraft operations, each with vehicle safety functions allocated differently between humans and machines. Advancements for enabling technologies such as distributed electric propulsion and artificial intelligence have had major investments and initial experimental success, but may be some years away from being deployed for on-demand passenger air transportation at scale.

Nneji, Victoria Chibuogu↗

NASA NTRS2017

Concept of Operations for RCO SPO

Reduced crew operations (RCO) refers to the reduction of crew members flying long-haul or military operations with more than one pilot onboard. Single pilot operations (SPO) refers to flying a commercial transport aircraft with only one pilot on board the aircraft, assisted by advanced onboard automation andor ground operators providing piloting support services. Properly implemented, RCO/SPO could provide operating cost savings while maintaining a level of safety no less than conventional two-pilot commercial operations. A concept of operations (ConOps) for any paradigm describes the characteristics of its various components and their integration in a multi-dimensional design space. This paper presents key options for humanautomation function allocation being considered by NASA in its ongoing development of RCO/SPO ConOps.

ConOps↗

NASA NTRSDate not supplied

TPSAS-NF1676L-11455-DND

Adaptive control is well suited for rapidly changing, highly uncertain, and potentially unpredictable, flight dynamics characteristic of upset or damage induced on transport as well as high-performance aircraft. Some of the recent flight experiences of pilot-in-the-loop with an adaptive controller have exhibited unpredicted interactions. In retrospect, this is not surprising once it is realized that there are now two adaptive controllers interacting, the traditional software adaptive control system and the pilot. In order to capture the interaction between the adaptive controller and the pilot, research is being conducted to characterize the pilot as an adaptive controller, to define the interaction between pilots and adaptive controllers, and to then specify the behavior of the controller and the function allocation between the pilot and the adaptive controller during adaptation. This presentation will explain the methodology employed in the current research involving the use of system identification techniques to help characterize pilots and to characterize the interaction of an adaptive controller with a pilot. In particular, system identification appears to be a viable technique for modeling a pilot. Also touched upon in this presentation are possible avenues of augmenting the Hess simplified pursuit model and planned research to further characterize a pilot’s interaction with an adaptive controller.

Anna Trujillo↗

NASA NTRS2019

Potential campaign architectures and mission design challenges for near-term international Mars Sample Return mission concepts

Mars Sample Return (MSR) continues to be a high priority in the planetary science community and a decades-long goal of international planetary exploration programs. Options for architectures and mission concepts are currently under study by NASA and ESA to find potential partnership opportunities to achieve MSR in the 2020s. The major elements of a potential MSR campaign have significant architectural flexibility and mission launch, arrival, and return options. The decision criteria often depend on mission design and functional allocations across many elements. This paper outlines the reference architecture and key trades among the campaign elements.

Olikara, Zubin↗

NASA NTRSDate not supplied

Collaborative Communications Between a Human and a Resilient Safety Support System

Successful introductory UAM integration into the NAS will be contingent on resilient safety systems that support reduced-crew flight operations. In this paper, we present a system that performs three functions: 1) monitors an operator’s physiological state; 2) assesses when the operator is experiencing anomalous states; and 3) mitigates risks by a combination of dynamic, context-based unilateral or collaborative dynamic function allocation of operational tasks. The monitoring process receives high data-rate sensor values from eye-tracking and electrocardiogram sensors. The assessment process takes these values and performs a classification that was developed using machine learning algorithms. The mitigation process invokes a collaboration protocol called DFACC to which, based on context, performs vehicle operations that the operator would otherwise routinely execute. This system has been demonstrated in a UAM flight simulator for an operator incapacitation scenario. The methods and initial results as well as relevant UAM and AAM scenarios will be described.

Advanced Air Mobility,↗

NASA NTRS2021

Collaborative Communications Between A Human and A Resilient Safety Support System

Successful introductory UAM integration into the NAS will be contingent on resilient safety systems that support reduced-crew flight operations. In this paper, we present a system that performs three functions: 1) monitors an operator’s physiological state; 2) assesses when the operator is experiencing anomalous states; and 3) mitigates risks by a combination of dynamic, context-based unilateral or collaborative dynamic function allocation of operational tasks. The monitoring process receives high data-rate sensor values from eye-tracking and electrocardiogram sensors. The assessment process takes these values and performs a classification that was developed using machine learning algorithms. The mitigation process invokes a collaboration protocol called DFACCto which, based on context, performs vehicle operations that the operator would otherwise routinely execute. This system has been demonstrated in a UAM flight simulator for an operator incapacitation scenario. The methods and initial results as well as relevant UAM and AAM scenarios will be described.

Advanced air mobility↗

NASA NTRS2022

PAAV Concept Document

The Pathfinding for Airspace with Autonomous Vehicles (PAAV) Concept Document, version 1.0, lays out the key challenges and potential solutions for the use of uncrewed aircraft (UA) technology for future regional air cargo operations. The challenges and solutions described in this document were informed by communications with the UA industry community (e.g., RTCA, the Federal Aviation Administration, and regional air cargo business operators), as well as the PAAV team’s research activities during the last two years including four tabletop exercises, a human-in-the-loop simulation study, a numerical simulation study, a functional allocation study, and flight data analysis (Appendix A). This document first describes the expected operational context of PAAV (Section 2), such as the flight mission, baseline UAS components, nominal operations, m:N operations (i.e., "m" remote pilots per "N" aircraft), and off-nominal operations. This context sets the scope for the PAAV concept development work. PAAV concept development assumes that UA operations will be increasingly autonomous. Thus, near- and far-term assumptions are defined (Section 3). PAAV identified seven key challenges for UA operations (Section 4): - Flight route planning - Separation and flow management - Traffic pattern integration - Contingency management - Taxi, takeoff, and landing - m:N operations - Communications operations The following 13 potential solutions to these challenges are then described (Section 5): - Scalable communications architecture - Data link - Designated UAS corridors - Crew planning for m:N operations - Flight route optimization - Traffic load-level control - Trajectory solutions with data link - Automated hazard avoidance for m:N operations - Traffic pattern integration (TPI) tool - Standard lost command and control (C2) link (LC2L) procedures - Automated hazard avoidance under LC2L - Auto-taxi, auto-takeoff, and auto-land - Ground control station (GCS) user interface for m:N operations The document attempts to link each of these solutions to one or more of the challenge areas. Novel solutions involving numerous automation technologies are needed to mitigate traffic and airspace management challenges, especially for realizing m:N operations and ensuring safety under LC2L conditions. The purpose of this document is to help understand alternatives and tradeoffs among potential solutions and provide a foundation for a cohesive PAAV concept that will be described and refined in subsequent concept versions.

Unmanned aircraft, uncrewed aircraft, regional air↗

NASA NTRS2023

Airspace Automation Flight Tabletop Exercise

Interconnections of new systems are needed for airspace automation capabilities required in Urban Air Mobility (UAM). FAA Concept of Operations (CONOPS) V1.0 shows Provider of Services for UAM (PSU) at the center of the notional architecture; however, the functional role of the PSU in data exchange and the path to get there is unclear. In partnership with Wisk Aero, Avision, ANRA, Collins Aerospace, OneSky, SkyGrid, and AURA, the NASA National Campaign held discussions and tabletop exercises to test the functional allocations and work flows between an aircraft operator, airspace providers, Command and Control Communication Service Providers (C2CSP), and FAA air traffic in a real-world scenario. The exercise included preplanning and execution of a passenger mission with nominal, contingency, and conflict management scenarios for initial UAM operations. This working paper describes initial conditions for the flight tabletop exercise, exercise summaries, lessons learned, and recommendations for future work.

National Campaign↗

NASA NTRSDate not supplied

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

NASA NTRSDate not supplied

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

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

How the Allocation of Lander Functions Impacts Human Lunar Exploration Architecture Propellant Demands

As NASA looks to the moon as a proving ground for the technologies required to conduct the first human exploration campaign of Mars, this study assesses the potential propellant demands that a sustained human lunar presence would require. In particular, this study evaluates how the allocation and distribution of vehicle functions to a different number of vehicles can impact the propellant required to conduct a human lunar exploration mission. Four different transportation architectures for human lunar exploration and three different refueling assumptions were defined. The impact on the propellant required for a mission was assessed for all architectures and refueling assumptions for ranges of crew payload mass, vehicle inert mass fraction, and a sensitivity to the mission maneuver velocity magnitudes. The results of this analysis show that aggregating vehicle functions to a single-stage lander vehicle can have a positive impact on the architecture's level of vehicle reusability and that an increase in the number of refueling opportunities reduces the mass of the vehicles and of the propellant required per mission.

Matteo A. Clark↗

NASA NTRSDate not supplied

How the Allocation of Lander Functions Impacts the Cost Breakeven for Lunar In-Situ Propellant Production

This study proposes to leverage the evaluation of the cost breakeven for using lunar-derived propellants as compared to those delivered from Earth, in support of an extended human exploration campaign as defined in a companion paper, to explore this architectural question: how do choices in the number and function of different vehicles performing lunar descent and ascent impact the cost breakeven of using in-situ propellant production relative to propellant delivery from Earth for a combination of human lunar and Mars missions?

Christopher A. Jones↗

NASA NTRSDate not supplied

How the Allocation of Lander Functions Impacts Human Lunar Exploration Architecture Propellant Demands

Explore the source record for details and available documents.

Matteo A Clark↗

NASA NTRS2018

Human-Automation Allocations for Current Robotic Space Operations: Space Station Remote Manipulator System

NASA’s Human Research Program’s Risk of Inadequate Design of Human and Automation/Robotic Integration (HARI) delineates the uncertainty surrounding crew work with automation and robotics in spaceflight. HARI is concerned with detrimental effects of ineffective user interfaces, system designs and/or functional task allocation on crew performance, potentially compromising mission success and safety. This risk arises because of limited experience with complex automation and robotics in spaceflight. One key knowledge gap within the HARI risk is related to function allocation.

Chang, Mai Lee↗

NASA NTRS2020

Robotic Specialization in Autonomous Robotic Structural Assembly

Robotic in-space assembly of large space structures is a long-term NASA goal to reduce launch costs and enable larger scale missions. Recently, researchers have proposed using discrete lattice building blocks and co-designed robots to build high-performance, scalable primary structure for various on-orbit and surface applications. These robots would locomote on the lattice and work in teams to build and reconfigure building-blocks into functional structure. However, the most reliable and efficient robotic system architecture, characterized by the number of different robotic 'species' and the allocation of functionality between species, is an open question. To address this problem, we decompose the robotic building-block assembly task into functional primitives and, in simulation, study the performance of the the variety of possible resulting architectures. For a set consisting of five process types (move self, move block, move friend, align bock, fasten block), we describe a method of feature space exploration and ranking based on energy and reliability cost functions. The solution space is enumerated, filtered for unique solutions, and evaluated against energy and reliability cost functions for various simulated build sizes. We find that a 2 species system, dividing the five mentioned process types between one unit cell transport robot and one fastening robot, results in the lowest energy cost system, at some cost to reliability. This system enables fastening functionality to occupy the build front while reducing the need for that functional mass to travel back and forth from a feed station. Because the details of a robot design affect the weighting and final allocation of functionality, a sensitivity analysis was conducted to evaluate the effect of changing mass allocations on architecture performance. Future systems with additional functionalities such as repair, inspection, and others may use this process to analyze and determine alternative robot architectures.

Bernus, Borbala↗

NASA NTRS2007

Development of the Functional Flow Block Diagram for the J-2X Rocket Engine System

The J-2X program calls for the upgrade of the Apollo-era Rocketdyne J-2 engine to higher power levels, using new materials and manufacturing techniques, and with more restrictive safety and reliability requirements than prior human-rated engines in NASA history. Such requirements demand a comprehensive systems engineering effort to ensure success. Pratt & Whitney Rocketdyne system engineers performed a functional analysis of the engine to establish the functional architecture. J-2X functions were captured in six major operational blocks. Each block was divided into sub-blocks or states. In each sub-block, functions necessary to perform each state were determined. A functional engine schematic consistent with the fidelity of the system model was defined for this analysis. The blocks, sub-blocks, and functions were sequentially numbered to differentiate the states in which the function were performed and to indicate the sequence of events. The Engine System was functionally partitioned, to provide separate and unique functional operators. Establishing unique functional operators as work output of the System Architecture process is novel in Liquid Propulsion Engine design. Each functional operator was described such that its unique functionality was identified. The decomposed functions were then allocated to the functional operators both of which were the inputs to the subsystem or component performance specifications. PWR also used a novel approach to identify and map the engine functional requirements to customer-specified functions. The final result was a comprehensive Functional Flow Block Diagram (FFBD) for the J-2X Engine System, decomposed to the component level and mapped to all functional requirements. This FFBD greatly facilitates component specification development, providing a well-defined trade space for functional trades at the subsystem and component level. It also provides a framework for function-based failure modes and effects analysis (FMEA), and a rigorous baseline for the functional architecture.

White, Thomas↗

NASA NTRS1992

The application of Open System Architecture to planetary surface systems

The issues that future planet surface activities must confront are explored, the basic concepts that provide the basis for establishing an Open System Architecture (OSA) are defined, the appropriate features of such an architecture are identified, and examples of OSAs are discussed. OSAs are designed to provide flexibility and evolutionary growth of planet surface systems to support the users needs. An OSA is based on two fundamental principles: precise definition of component functionality and the establishment of standards. An OAS must be functionally decomposed, top down, to identify all functions, subfunctions, subsubfunctions, etc., that are required to be performed by the system. There is an allocation of function, or process, to components. The functional packaging within a component becomes the user's primary perception of the system. The standards of an OSA enable the user to attain the full functional capabilities inherent in the system.

Petri, D. A.↗