Results for “Function Allocation” — Page 5

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.↗

NASA NTRS2014

Autonomous Mission Operations Roadmap

As light time delays increase, the number of such situations in which crew autonomy is the best way to conduct the mission is expected to increase. However, there are significant open questions regarding which functions to allocate to ground and crew as the time delays increase. In situations where the ideal solution is to allocate responsibility to the crew and the vehicle, a second question arises: should the activity be the responsibility of the crew or an automated vehicle function? More specifically, we must answer the following questions: What aspects of mission operation responsibilities (Plan, Train, Fly) should be allocated to ground based or vehicle based planning, monitoring, and control in the presence of significant light-time delay between the vehicle and the Earth?How should the allocated ground based planning, monitoring, and control be distributed across the flight control team and ground system automation? How should the allocated vehicle based planning, monitoring, and control be distributed between the flight crew and onboard system automation?When during the mission should responsibility shift from flight control team to crew or from crew to vehicle, and what should the process of shifting responsibility be as the mission progresses? NASA is developing a roadmap of capabilities for Autonomous Mission Operations for human spaceflight. This presentation will describe the current state of development of this roadmap, with specific attention to in-space inspection tasks that crews might perform with minimum assistance from the ground.

Mission Operations↗

NASA NTRS2002

A Ground Systems Architecture Transition for A Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the ISS payloads program, and the resulting functional breakdown of the products that support that architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗

NASA NTRS2003

A Ground Systems Architecture Transition for a Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the International Space Station (ISS) payloads program, and the resulting functional breakdown of the products that support this architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗

NASA NTRS2012

XHAB 2012 Final Report Habitat Demonstration Unit Lite

The University of Maryland Space Systems Laboratory (SSL) was awarded a NASA X-Hab 2012 grant for the design and construction of a new Earth analogue habitat for habitability research. This work builds on the past ECLIPSE and X-Hab projects at the SSL, by combining these elements with a new habitat module in order to create a single research platform for habitability studies. The “Crew Habitat Evaluator for Long-duration Orbital, Near-earth, and Interplanetary Applications” (CHELONIA) will deliver a much more flexible architecture than the previously developed mock-ups, allowing facilitating faster modification of the interior layouts and available total volume. This will enable the investigators to evaluate crew assessments and task performance as a function of the interior layout, functional area allocation and total available volume. This paper documents the design of this new infrastructure, and includes the details of the manufacturing of a new habitat mock-up module and modifications to the existing elements. The paper also includes a brief discussion of possible future research goals. Initial layouts are implemented using foam-core volumetric mock-ups for internal equipment and outfitting. These low fidelity mock-ups constitute a “library” that will allow a very rapid evaluation of a multitude of layouts. CHELONIA is also suitable for higher fidelity functional mock-ups, as well as short to medium-duration mission simulations. This new facility will enable the examination of habitat layouts for both partial gravity and microgravity environments. While partial gravity systems will be easily evaluated with the habitat currently in development, microgravity subsystems will be studied by utilizing low fidelity volumetric neutral buoyancy mock-ups in order to determine if commonality in the design for these two environments is appropriate. Finally, this new facility is being integrated into the SSL Moonyard planetary surface simulation center. The Moonyard simulates a planetary surface by means of a large sandbox, and is used primarily for rover field trials and suit systems evaluation. This new facility will be a prime element in future Earth analog simulations at the University of Maryland in support of NASA exploration objectives.

Kevin Davis↗