SEARCH · Search NASA

Results for “ConOps”

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.

SourceResearch connectionFrom yearThrough year

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

At least 109 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

An Approach for Defining IASMS Services, Functions, and Capabilities

Assuring safety in the NAS with the inclusion of new entrants, such as Advanced Air Mobility (AAM), will require overcoming unique safety challenges that result from combining innovative technologies with novel airspace concepts for moving people and cargo using autonomous vehicles. The focus of the In-time Aviation Safety Management System (IASMS) is to overcome AAM’s safety assurance challenges. The IASMS Concept of Operations (ConOps) describes an interconnected set of services, functions, and capabilities (SFCs) designed to manage operational risks, identify unknown risks, and inform system designs. This paper describes an approach for defining SFCs based on technology trends in research, assessment of known and unknown risks in voluntary safety reports, and causal and contributing factors in aviation accidents and incidents. This approach would identify potential SFCs that further expand the Monitor, Assess, and Mitigate (M-A-M) functionality that represents the enabling framework of the IASMS. Safety implications that will result from integration of AAM in the transformation of the National Airspace System (NAS) were addressed in National Academies committees reports on AAM and IASMS. Development of a ConOps for IASMS was a top recommendation and can be represented as a reframing of safety assurance that builds on real-time alerting such as the Traffic Alert and Collision Avoidance System, and adds the more encompassing in-time temporal parameter in recognition of the different timelines for collecting and assessing safety data for risk mitigations. For example, mining for safety trends from data sources such as the Aviation Safety Information Analysis and Sharing system occurs over a longer time period. Research on AAM operations poses that SFCs can be designed to monitor the safety margin appropriate for AAM including with regards to the distance between current flight parameters and nominal ideal conditions. These in-time comparisons will become more complex as the density of operations increases at least in certain areas and can include planned and actual 4D trajectory, and in-time comparisons having implications on conflict modeling and prediction including expected and actual departure time, fix/waypoint crossing times, and arrival time. These comparisons would be integrated as part of SFCs that redefine and inform new safety margin. An increased safety margin improves management of operational risks while reducing the potential for anomalies. An increased safety margin also has implications for operator confidence in the certainty of its operations and trust in automation. Technology trends in research could be used to refine existing SFCs and define needs for additional SFCs that provide safety improvements to the design and operation of vehicles, airspace design, and operator performance requirements. NASA is developing innovative approaches to safeguard against major accidents and incidents that have occurred in the NAS and those anticipated with the inclusion of envisioned AAM operations. The innovations use operational performance data to monitor, detect, and predict flight variations exceeding safe nominal patterns, such as would be caused by navigational error, severe weather complications, or hijacking of UAS controls. These innovative approaches have high potential to prevent accidents and incidents in the new AAM era. It is anticipated that elements of the innovations will evolve into SFCs for the IASMS. Voluntary safety reports can be monitored to identify anomalies related to design or operational performance risks. Reports could be periodically monitored and assessed for specific topics. Reports might serve as weak signals or precursors indicative of emergent risk such as when combined with other safety information. The architecture could include SFCs that are based on voluntary safety reports recognizing the periodic temporal nature of data analysis. As previously mentioned, aviation accidents with their causal and contributing precursors can inform the need for SFCs in the IASMS. Accidents and incidents at San Francisco International Airport such as Asiana 214 and Air Canada 759 illustrate how combinations of different factors lead to increased risk. These types of precursors and different factors have implications on the types of SFCs that could be needed to monitor and manage different sources and types of design and operational risk. Continuing to assure the safety of AAM as designs and operations gain in complexity can be accompanied by defining SFCs that also increase in complexity. These SFCs can leverage information from findings and recommendations synthesized across on-going research, voluntary safety reports, and accident and incident reports. These SFCs can serve to refine accuracy of algorithms and resolve limitations with current practices. The IASMS architecture represents the framework for the SFCs and their critical role in safety assurance.

In-Time Aviation Safety Management System↗

NASA NTRSDate not supplied

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy that is ubiquitous throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and Concepts of Operations (ConOps) for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, ConOps, and interface control documents (ICDs), in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module (i.e. ECLSS). A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM) to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design – GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1) to implement autonomy at the VSM, MSM, and SM levels; (2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with the VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1) Orion as visiting vehicle registers with VSM; (2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Fernando Figueroa↗

NASA NTRSDate not supplied

Validation of Fitness for Duty Standards Using Pre- and Post-Flight Capsule Egress and Suited Functional Performance Tasks in Simulated Reduced Gravity (Pilot Egress Fitness)

As NASA prepares for exploration missions, it will be critical to understand and build upon known crew capabilities. Specifically, we need to know the functional capacities of crew at different stages of a mission and characterize these profiles so that the appropriate vehicle requirements and mission concepts of operations (ConOps) can be developed. One of the most complex phases of any missions is when there is a transition between gravity environments. For instance, both physiological adaptation to microgravity and subsequent re-entry into a gravity environment result in reduced functional capacity, even with rigorous adherence to inflight countermeasures. Quantification of the astronauts’ post-landing functional performance is necessary to design ConOps for exploration missions. Specifically, these two high-risk tasks may have to be performed soon after gravity transitions: •Unassisted capsule egress task after return to Earth •Planetary extravehicular activity (EVA) soon after landing on Mars or the Moon This study has been broken down into two phases. A pilot phase to assess the overall feasibility and demonstrate the capability to do these tasks shortly after landing and the full Egress Fitness study, which will be part of the CIPHER complement. This study uses a functional task approach to characterize performance of these high-risk tasks in long-duration ISS crewmembers before flight and shortly after return to Earth. Prior to any testing, each astronaut subject completes a suit fit check to ensure adequate sizing and mobility to be able to complete the EVA tasks. Pilot Egress Fitness pre-flight and post-flight testing includes an Earth based emergency egress out of a functional capsule mockup, and a short Mars gravity EVA simulation including suit donning, hatch egress, ladder descent, task board cable operations, baggage transfer over sand/rocky regolith, alignment with a rear entry port, and suit egress. Pre-flight testing can occur almost anytime pre-flight, but post-flight scheduling is much more critical with the capsule egress test occurring 1-4 hours after landing and the planetary EVA approximately 18-36 hours after landing. Data collected for both tasks includes task completion time, photo, and video. The EVA portion also includes collection of metabolic and heart rate. Pilot Egress Fitness study has completed baseline pre-flight testing on 3 astronaut subjects. Post-flight testing of the first two subjects will be completed in November 2021 and the final subject around March 2022. Results and lessons learned from this pilot study will inform the full Egress Fitness study, which will incorporate additional pre-flight sessions, longer EVA tasks, and post-flight testing on R+1, 4, and 7 to characterize the timeframe of recovery

J R Norcross↗

NASA NTRS2021

Concept of Operations for OSIRIS-REx Optical Navigation Image Planning

Optical navigation (OpNav) is a critical subsystem of the OSIRIS-REx asteroid sample return mission, which operated in the vicinity of near-Earth asteroid (101955) Bennu from August 2018 through April 2021. A substantial amount of mission resources across multiple subsystems and institutions is required to ensure that the OpNav data are successfully acquired. The KinetX OpNav team, part of the Flight Dynamics System (FDS), is responsible for performing required analysis to develop the OpNav operations plans; requesting, reviewing and verifying the plans; and ultimately using the image data for critical navigation operations. The FDS team, responsible for the mission navigation, is operated by KinetX Aerospace with management and operations support from NASA’s Goddard Space Flight Center. The Science Processing and Operations Center (SPOC), located at the University of Arizona’s Lunar and Planetary Laboratory, is responsible for generating the planning products for all science and most OpNav data. These plans are integrated into the spacecraft sequences, tested, and commanded by the Mission Support Area (MSA) at Lockheed Martin Space. To ensure mission-critical navigation image data are successfully acquired, the plan is developed through a waterfall of planning cycles over the course of 3 months prior to onboard plan execution. During the initial strategic planning for a mission phase, detailed analysis is performed by the OpNav team to conceptualize the concept of operations (ConOps) for image data collection. This phase OpNav Narrative is included along with other strategic planning documents for the key ground segment stakeholders to review and provide feedback. The detailed OpNav plans get defined in the tactical planning cycle, which spans 8 to 3 weeks before the week-long integrated sequence is executed on-board the spacecraft. During the tactical cycle, the initial OpNav Request is submitted along with the science requests, kicking off development of the science and OpNav plans. Once the initial plan is drafted, interfaces are exercised so that the plan can be reviewed and iterated, if necessary. A rigorous schedule is followed by the planning teams during the implementation cycle, spanning the last 18 days before uplink, to ensure all the necessary integration, testing, and reviewing can occur on time. The development of the OpNav planning ConOps, including responsibilities, interfaces, timelines, and procedures, took extensive collaboration across mission elements and institutions. The process was robust throughout the 137 weeks of continuous Optical Navigation Operations at Bennu, which concluded on April 9th, 2021.

Coralie D. Adam↗

NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗

NASA NTRSDate not supplied

The In-time Aviation Safety Management System Concept for Part 135 Operators

Transformations of the National Airspace System, such as envisioned with Advanced Air Mobility, will enable improvements for managing and assuring safety for Part 135 transportation of passengers and cargo. The purpose of this paper is to describe the In-time Aviation Safety Management System (IASMS) Concept of Operations (ConOps) and how its innovations such as using predictive analytics could benefit operators for risk management and safety assurance. The National Academies recommended development of an IASMS ConOps to secure a safe future NAS. Part 135 operators are currently not required to have a formal safety management system.

Kyle K. Ellis↗

NASA NTRSDate not supplied

Lessons Learned from Medical System Foundation Development for Long-Duration Lunar Orbit and Lunar Surface Missions

The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has been tasked with the development of Medical System Foundations for Level of Care IV for both short-duration lunar orbital missions and, subsequently, long-duration lunar orbital and surface operations missions. These Medical System Foundations serve as a framework to aid in early medical system design and mission planning. The content of both Foundation models is similar, consisting of a concept of operations, functional decomposition, clinical content (medical conditions, capabilities, and resources), technical requirements (interface, non-functional, and functional), and traces between these components and to the NASA standards documents and parent-level (Program- and Vehicle habitat system-level) requirements. Additionally, the development of both Foundations employed systems engineering principles and a model-based systems engineering (MBSE) approach. Throughout the development of these Foundations, ExMC has strived to improve the efficiency and robustness of its processes and to be more responsive to change (i.e., in design reference mission parameters and assumptions) and to stakeholders’ feedback. The most significant improvements made between the short- and long-duration Foundation models during this transformation process are the following: • Replacement of the traditional document-based ConOps with a model-based ConOps according to MBSE principles, which facilitated more efficient understanding of the material and the consolidation of all relevant information into a centralized location. • Utilization of an agile approach with tasks organized into sprints. This approach enabled solicitation of more frequent usability feedback from stakeholders, incorporation of more human factors reviews into the sprints, and more efficient tasking of team members. This presentation will discuss the journey of developing both Foundation models, as well as the lessons learned and resulting improvements made between the Short- and Long-Duration models.

M Kaetzer↗

NASA NTRSDate not supplied

Long Duration Medical System Foundation for Lunar Orbital and Lunar Surface Exploration Missions

For long-duration lunar orbital and lunar surface (LDLOS) exploration missions, the NASA Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a medical system foundation through which clinical considerations may be represented via a systems engineering-based model. Components of the Long Duration Medical System Foundation model include a concept of operations (ConOps), functional decomposition, medical conditions to be addressed, clinical capabilities and resources, technical requirements, and traces of requirements to NASA standards documents and parent-level (Program- and Vehicle habitat system-level) requirements. The Foundation model offers the means to present information in a readily accessible format that is understandable across all clinical, engineering, scientific, and managerial disciplines. Collectively, these components constitute a foundation that serves future programs with similar long duration mission profiles as a starting point for medical system design. The Foundation was developed by a multidisciplinary team of systems engineers, scientists, and clinicians across NASA. The process started with ConOps development, subsequently decomposed into the functionalities needed to diagnose, treat, and prevent medical conditions. The clinical team identified medical conditions most likely needed to be diagnosed and treated during a long-duration lunar exploration mission. Through these approaches, requirements were codified for the LDLOS medical system. These requirements were then traced to NASA standards, medical conditions, medical capabilities, and medical resources, facilitating stakeholders’ use of the Foundation model to analyze traces and to identify medical system interfaces with other vehicle systems or subsystems. In addition, the Foundation may be used as a basis for performing risk trades on medical system mass and volume allocation. This discussion will focus on the processes through which the LDLOS Medical System Foundation was developed, how the Foundation builds a bridge between the medical and engineering domains, and how these processes may be applied more broadly to a crew health and performance system and other system domains.

Jay Lemery↗

NASA NTRS2023

Orion Cabin Lighting System: Filter Workaround for Maintaining Crew Circadian Entrainment

Introduction: Suboptimal crew circadian entrainment (CCE) is common and results in cumulative fatigue and reduced cognitive function. This may promote use of psychostimulants and hypnotics. The Orion Cabin Lighting System (OCLS) consists of 15 dimmable lamps circuited to several zones. The OCLS monochromatic white lamp design is insufficient for maintaining CCE. While blue light (480-nm) elicits peak wake-cycle response, it is a powerful disruptor of CCE. We propose OCLS lamp filters (OLFs) as a workaround for maintaining CCE. Methods: Preliminary OLFs testing utilized a tunable-white LED to serve as a baseline lamp in the NASA Lighting Lab’s controlled environment (prototype OCLS lamps were unavailable). Illuminance and spectral irradiances were measured with the NASA Lighting Lab’s spectroradiometer. ConOps is proposed for OLFs. Results: OLFs markedly attenuated 480-nm light and illumination with minimal mass/volume requirements. ConOps includes in-flight deployment of OLFs and reducing OCLS lamp intensity prior to bedtime. Pros: minimal mass/volume, no added power, and a simplistic design. Cons: manual twice-daily articulation of OLFs, undetermined frangibility/flammability/off-gassing and effects on thermal regulation, and untested task illumination or color fidelity in the Orion cabin. Discussion: While OLFs aptly attenuate 480-nm light from our tunable LED lamp in the Lighting Lab’s controlled environment, they remain untested within the Orion cabin on OCLS lamps. Future tests include Orion cabin illumination optimization for appropriate Lux delivery and ensuring task/color fidelity with OLFs deployed. Adequate OCLS cooling should be similarly assessed. Other safety testing includes OLF frangibility/flammability/off-gassing in an enriched-O 2 /hypobaric environment. Together, these data will demonstrate OLFs provide a viable workaround for maintaining CCE further ensuring mission safety and success.

Carlos Rene Dostal↗

NASA NTRS2022

National Campaign (NC)-1 Strategic Conflict Management Simulation (X4) Final Report

Urban Air Mobility (UAM) enables highly automated, cooperative, passenger or cargo-carrying air transportation services in and around urban areas. UAM is a subset of the Advanced Air Mobility (AAM) concept under development by the National Aeronautics and Space Administration (NASA), the Federal Aviation Administration (FAA), and industry. The Strategic Conflict Management (SCM) Simulation, dubbed “X4”, was conducted between July 2021 and June 2022 by NASA with the FAA and industry to evolve the Provider of Services for UAM (PSU) that will be needed to ensure initial UAM operations can scale in the National Airspace System (NAS). The FAA UAM Concept of Operations (ConOps) v1 [1] served as an initial guiding document for the X4 airspace management system design to ensure the architecture supports testing of services provided by third-party service providers. To that end, the X4 architecture leveraged concepts and technologies developed for Unmanned Aircraft System (UAS) Traffic Management (UTM) while also developing and testing new capabilities and services needed for UAM. The architecture included an initial prototype of the FAA-Industry Exchange Protocol (FIDXP), third-party services such as the PSUs, and Discovery and Synchronization Service (DSS), and other new services such as Demand-Capacity Balancing (DCB) to facilitate UAM strategic conflict management. During X4, NASA led discussions and collaborated with seven industry airspace partners to develop initial airspace management concepts for UAM that drove what would be tested and evaluated during the simulations. The initial capabilities defined for PSU leveraged UTM UAS Service Supplier (USS) as a starting point and evolved to meet UAM requirements. These discussions were also an opportunity for NASA to collaborate with industry to develop a set of initial Community-Based Rules (CBRs). These CBRs enabled how UAM traffic would be cooperatively managed among UAM operators. The collaborative, iterative process of developing CBRs with industry during X4 provided insight into the challenges involved and identified the need for a suitable and effective forum for future CBR development. In parallel with these discussions, NASA conducted a series of seven software sprints and two collaborative simulations with the airspace partners that built up in complexity. Over the course of the year, all seven partners successfully completed all the sprints by demonstrating the required capabilities. They also participated in the two collaborative simulations to demonstrate how multiple PSUs could work together in a collaborative, more complex environment with higher traffic density. The X4 simulation accomplished NASA's objectives and helped advance the development of the seven participating PSUs. The lessons learned provided insight into key elements of the UAM Notional Architecture from the FAA ConOps v1 [1] and UTM technologies when applied to UAM: - Having a Concept of Use (ConUse) defined prior to the activity would accelerate the time and effort from concept development to testing. - While the UAM Notional Architecture provided a starting point for a federated architecture that support services provided by third-party providers, the USS and PSU differed in their capability definitions for operational intent submission and sharing, conformance monitoring, airspace authorization, strategic conflict management, airspace constraints and dynamic replanning. - While existing DSS developed for UTM provided a way for PSU and other UAM services (such as DCB) to discover relevant operations from each other, additional complexity and challenges were found during X4 testing and illuminated the need for a more suitable solution for UAM. Industry can leverage the results of this demonstration to accelerate UAM requirements, CBRs, and standards development. The FAA and other government municipalities and agencies will be able to leverage results to inform future policies and identify additional gaps that require further analysis, moving toward operationalization of UAM.

Urban Air Mobility↗

NASA NTRSDate not supplied

Design and Technology Maturation of the Stratospheric Projectile Experiment of Entry Dynamics

The supersonic and transonic dynamic stability of blunt-body reentry vehicles currently poses large risks in all of NASA’s ongoing entry missions (MSR SRL, MSR EES, and Dragonfly). These projects have allocated millions of dollars to testing and modeling efforts to buy down risk by using the current state-of-the-art (SoA) facilities at NASA’s disposal. While these facilities have heritage in supplying dynamics data to reentry missions, their availability is severely limited – particularly with the high number of concur-rent projects requesting simultaneous testing– and are costly when considering the science density per dollar. None of the current SoA facility methodologies allow the test model to have the dynamics fully develop through a flight relevant free-stream profile and as such require extrapolations with resultant high uncertainties in order to relate the test dynamics to flight expectations. SPEED is a NASA Ames Center Innovation Fund (CIF) project that is developing a highly tailorable and cost-effective test methodology to better assess the dynamic stability of blunt-body reentry vehicles via a stratospheric balloon flight. This is accomplished by dropping a suite of instrumented capsules from a stratospheric balloon to gain a statistically relevant dataset of scaled reentry vehicles in mission relevant free-flight conditions. This presentation will walk through how the test methodology is being implemented specifically for the Mars Sample Return (MSR) Earth Entry System (EES) geometry in an awarded Flight Opportunities Program (FOP) test flight in early CY24. SPEED Application to MSR: SPEED consists of three main mechanical systems: the Drop Platform, the Projectile, and the test Capsule. SPEED is being developed as a set of guidelines and recommendations for how to test with the proposed Concept of Operations (Conops) since the specific design parameters will vary depending on the specific project’s reference trajectory and entry vehicle design. As such, this presentation will walk through the development time-line as shown in Fig. 2. This is meant to serve as a blueprint for further missions as desired. Mechanical and Avionics Design. The SPEED test platform designed for the MSR-EES capsule geometry with nominal entry parameters has the ability to carry 10 Capsules to altitude instrumented with: 1. 3-Axis Accelerometer 2. IMU 3. Gyroscope 4. Magnetometer 5. Pressure Transducer cruciform 6. Uplook and Horizon Cameras To package the avionics/instrumentation suite, the capsule is approximately 1’ in diameter with the Outer Mold Line (OML) centroid-scaled from the full EES design. The internal volume is gutted and custom-shaped to fit the desired instrumentation suite, as well as to allow for the positioning of ballast mass such that the Center of Gravity is analogous to the flight vehicle. All structural components in the Capsule and Projectile are 3D printed, which significantly reduces the cost of each flight unit to around $1500 including all instrumentation, avionics, and structural components. Flight Conops. The test Capsule is accelerated to the desired altitude and Mach number while stowed in the Projectile, a missile-like vehicle consisting of steel ballast in the nose, a low-drag OML, and an Ejection Mechanism to reliably release the Capsule into the free-flow supersonic conditions. For the MSR-EES design, the capsule employs ~3kg of ballast mass at the nose to accelerate the 1.25kg test Capsule to ~Mach 1.7 at 23km altitude. This requires an initial release altitude of 40km, the quoted limit of a 80kg payload by the FOP-contracted balloon provider. Once the Ejection Mechanism avionics detect the proper conditions, the spring-loaded Ejection Mechanism will release and – guided by the sabot – expose the test Capsule to the desired test conditions for ~5 seconds of free-flight in the supersonic/transonic regimes. Dynamics in the subsonic regime will also be captured with the instrumentation suite with post-flight recovery operations aimed at recovering the high-G-load capable SD cards after the planned hard impact landings. Testing and Development: In the few months the SPEED project has worked the development of MSR-EES flight test, the team has performed lab and drone based testing which this presentation will overview. After the first design phase, the team fabricated Engineering Demonstration Units (EDUs) of all subsystems to perform validation testing shown in Fig. 5. After validation was completed on the subsystem level, a drone-drop test was performed at the recreational flight ceiling of 400ft altitude to assess the SPEED systems in a flight environment. Parameters such as in-flight stability, hard impact landing performance, and avionics performance were quantified and qualified. The FY23 CIF will culminate in a helicopter drop test aboard an Air National Guard Blackhawk. This will prepare the team for the CY24 FOP stratospheric balloon flight that should provide the final verification to begin offering the test platform for mission support. Focus of Presentation: This presentation will outline the technology maturation path of the SPEED implementation to the MSR-EES capsule baseline as well as the details regarding the mechanical system, avionics and instrumentation, and flight operations. Note that a complementary presentation is being submitted for a methodology overview of the SPEED test platform, introducing the testing technique and benefits as well as the full application space of the technology.

pitch damping coefficient↗

NASA NTRSDate not supplied

Optimizing Urban Air Mobility Research Through Bi-Directional Integration Processes for Effective Verification and Validation

Urban Air Mobility (UAM), a subset of Advanced Air Mobility (AAM), aims to revolutionize metropolitan transportation. This paper explores an engineering process framework within National Aeronautics and Space Administration (NASA)’s Air Mobility Pathfinders (AMP) project, which is focused on the safe scaling and seamless integration of UAM operations within the National Airspace System (NAS). Progressing through three phases — Initial, Midterm, and Mature — the Federal Aviation Administration (FAA)’s UAM Concept of Operations (ConOps) describes a proposed path for the evolution of UAM operations, presenting multifaceted challenges in technology, regulation, and stakeholder engagement. With this ConOps as a basis, the AMP project is executing research, development, test, and evaluation activities aimed at delivering validated reference architectures for the Midterm phase. This paper illuminates the pivotal role of the systems engineering process in managing these technical efforts. Robust verification and validation methods, along with systematic bi-directional integration process, enhance the ability to conduct research into the design and evolution of safe, efficient, and reliable UAM systems. In this paper a systematic framework will be presented and shown to facilitate interactions between UAM stakeholders and to effectively manage the complex architecture of UAM operations in the NAS.

National Airspace System↗

NASA NTRSDate not supplied

ETM: Upper Class E Traffic Management

The FAA, along with input from the National Aeronautics and Space Administration (NASA) and industry partners, published an initial Concept of Operations (ConOps) for Upper Class E Traffic Management (ETM). To support the next iteration of the ConOps, NASA Ames Research Center has been investigating several technologies and operating principles that will help enable industry in the system development of a cooperative operating environment. Following in the footsteps of the established Unmanned Aircraft Systems Traffic Management (UTM) concept, ETM will utilize some of the basic system architecture and the community-based theories of cooperation and coordination. The main considerations for ETM as compared to UTM, are the diversity of the vehicle types with varying speed and maneuverability capabilities, the severe stratospheric atmosphere conditions, the potential longevity of the missions, and the assorted operating modes (e.g., transit, loitering, or hovering). TM oriented technologies and proposed operating principles are being tested and assessed in a collaborative evaluation of an initial ETM system in spring of 2024. These slides will be presented to a group of stratospheric operators, informing them on some past work and the next steps in the ETM research.

Upper Class-E Traffic Management (ETM)↗

NASA NTRSDate not supplied

A Science-Focused Artificial Intelligence (AI) Responding in Real-Time to New Information: Capability Demonstration for Ocean World Missions

Introduction: Artificial intelligence (AI) has long been considered a potential mechanism to explore increasingly challenging environments, including those with extreme temperatures and pressures, limited communication capabilities, or those with demanding terrain. We posit that missions in extreme environments could deploy an onboard AI focused on science observations and goals in order to augment a traditional concept(s) of operations (ConOps). An onboard AI capability could perform functions such as data analysis in order to make high-level decisions, including prioritized data transmission for analysis by ground-based teams or autonomously-guided follow-on analyses that maximize science return. Such a capability would empower missions to respond to scientific data of interest in real-time; a mission could make observations and perform a preliminary analysis to alert ground-based scientists to an observation of interest, enabling an informed, rapid response from Earth-based teams. Enceladus Case Study for Onboard AI: We are developing an onboard AI capability for real-time telemetry response that formulates and carries-out informed decisions in service to established mission goals, enabling increased science return of a mission. We focus our AI development for use on a constellation of SmallSats orbiting Enceladus. Our Enceladus case study tests autonomous decision-making capabilities in scenarios with complex orbital dynamics, plume ejecta, extreme cold environments, power restrictions, and a requirement to maximize science return for a potential positive detection of life, while critically evaluating the potential for false positives. Telemetry includes simulated scientific data, spacecraft onboard operational data (e.g., position, velocity, and rotation), and engineering hardware performance data. Enceladus SmallSat Constellation. Our constellation includes eight SmallSat spacecraft in an 8:35 resonant orbit-based formation, leveraging Saturn’s gravitational forces to maintain stable orbits with global coverage around Enceladus. To our knowledge, we simulate the first stable configuration of multiple spacecraft in closed orbits around Enceladus, using a full ephemeris force model (Russell and Lara, 2009). Each spacecraft’s orbit will precess, causing an eastward ground track shift (from an orbiter’s perspective) of each spacecraft for each orbit. However, all spacecraft return to their original positions relative to Enceladus after eight Enceladus revolutions around Saturn. We model communication pathways between SmallSats to understand how information would need to be transmitted across the constellation to enable AI-driven decision-making and resource allocation across the fleet. Capability Demonstration. Our simulated capability demonstration inputs position, velocity, and rotation telemetry from our Enceladus-focused constellation simulations, and mass spectrometry data collected from abiotic and biotic laboratory-analog ocean world experiments (Theiling et al., 2018; Theiling, 2021; Da Poian et al., 2023). Data from these experiments are used to simulate MS measurements and different scenarios of science observations for onboard analysis performed on each of the eight spacecraft. For these demonstrations, we integrate 24 machine learning (ML) algorithms into an onboard intelligence as a ‘knowledge base’, including algorithms evaluating data quality and those predicting (with % confidence) gas composition, ocean aqueous chemistry, and whether the sample was influenced by microbial life. The onboard AI capability is designed to use the knowledge base to come to a consensus-based decision in the interpretation of the observed data in order to request additional action outside of a pre-defined ConOps. Requested actions could include e.g., prioritized downlink to Earth (for analysis by ground-based teams) or follow-on analyses performed across the constellation. The spacecraft’s intelligent onboard planner must then determine whether sufficient resources (e.g., time, power, etc.) are available and weigh the request with mission priorities. In our simulation, the constellation is able to identify potential biosignatures using onboard ML algorithms, evaluate the confidence of that prediction, and perform follow-on analyses across the fleet to confirm the detection, in order to best prepare a transmission of these data to Earth-based teams.

astrobiology↗

NASA NTRSDate not supplied

Overview of an Exploratory, Real-Time, Multi-Pilot Simulation Study of Early eVTOL Operations at Non-Towered Vertiports

This paper provides a report out on an exploratory, multi-aircraft/multi-pilot, real-time simulation study conducted by NASA of early commercial powered-lift, Urban Air Mobility (UAM) operations at a non-towered vertiport. As used in this paper, vertiport refers to the primary ground and airspace elements facilitating the takeoff and landing of electric vertical takeoff and landing (eVTOL) aircraft with central emphasis on a vertipad, i.e. the physical touch-down and lift-off area and surrounding approach , departure, local pattern procedures. The study, known as the Piloted UML-2 ConOps Study (PUCS), had two high-level goals. The first goal was providing preliminary insights and observations relevant to the piloting and flight operations of early, commercial UAM operations aligned with the initial stage of the FAA’s Advanced Air Mobility (AAM) Implementation Plan and the second level NASA’s UAM Maturity Level (UML) scale. The second goal was evaluating a novel, medium-fidelity, extensible, many-pilot, real-time simulation capability known as the UAM Flyers developed by NASA. The Flyers are intended to allow rapid development, screening, evaluation, and demonstrations of potential Concepts of Operation (ConOps) for UAM flight operations and airspace management in a modular and low-cost, real-time, human-in-the-loop rapid simulation prototyping environment. For this study, ten Flyer cockpits were configured to evaluate flight operations through a non-towered vertiport with pilot interfaces and displays (external and in-cockpit) appropriate for operations under visual flight rules (VFR) and employing flight and communication procedures representative of current operations at non-towered airports. The presented results include an achieved operational tempo; durations of individual flight tasks for approaches and departures; off-nominal events and triggers; and pilot comments regarding potential procedural and technology improvements.

Urban Air Mobility↗

NASA NTRSDate not supplied

Overview of an Exploratory, Multi-Pilot Simulation Study of Early eVTOL Operations at Non-Towered Vertiports

Urban Air Mobility↗

NASA NTRSDate not supplied

Cislunar Trajectory Design and Maneuver Autonomy for NASA's Moon to Mars Architecture

NASA’s Moon to Mars architecture is an ambitious roadmap of manned cislunar and deep space exploration. The extensive amount of orbital assets required will place a significant burden on ground-based resources, such as communication networks and operations facilities. Spacecraft autonomy is essential for maintaining a vast number of complex missions beyond Earth orbit. To achieve full autonomy, spacecraft must be able to employ methods of robust maneuver design without an explicit dependence on commands sent from the ground. This level of autonomy is needed not only for stationkeeping, but also for outbound transfers. To address the need of spacecraft maneuver design autonomy, this work investigates the use of neural networks (NNs) in a supervised learning environment. A supervised learning approach for NNs allows for a curated training data set, consisting exclusively of perturbations applied to a desired mission concept of operations (ConOps). The proposed approach allows humans on the ground to design a specific mission ConOps before flight, then employ NNs to fly the mission robustly and autonomously. This investigation numerically tests maneuver autonomy in four highly sensitive regions of flight: orbit raising, translunar injection burns, powered lunar flybys, and invariant manifold insertion burns. These straining cases are contextualized by testing them in a demonstration mission, targeting an Earth-Moon L3 orbit. The study first establishes feasibility by automating impulsive burn maneuvers. However, some guidance algorithms will need more intensive commands, such as inertial pointing and angular rates. To validate this method, NN maneuver autonomy is applied to a finite burn model of the demonstration mission. The use of sequential, mission specific maneuvers provide an appropriate testbed to demonstrate the robustness of a NN trained on feasible perturbed states. Moreover, these scenarios provide preliminary proof-of-concept for fully autonomous missions that execute maneuvers without dependence upon explicit command uplinks. As a result, the technological advancement proposed in this work may significantly ease the strain on ground-based mission operations. This would enable complex and autonomous mission execution in cislunar and deep space regimes, filling a technology gap required to support future manned missions.

NASA↗

NASA NTRSDate not supplied

Evaluating Lunar Water Processing System Model Configurations for Small Scale Oxygen and Hydrogen Production Within JAXA'S ISRU Technology

Introduction: In-Situ Resource Utilization (ISRU) refers to novel methods of extracting and processing local resources for use in life support and propulsion systems, reducing or eliminating the required consumables to be transferred from Earth. Current estimates of water-ice availability embedded in regolith within the Moon’s permanently shadowed regions (PSR’s) range between 1-5% by weight. However, the composition and characteristics of the “wet” regolith is unknown. Alternate ISRU excavation techniques and Concept of Operations (ConOps) must be explored to optimize surface system operations based on these factors. To assess the feasibility of different ISRU subsystem technologies and compare system architecture configurations, an interchangeable system model was generated to incorporate technologies spanning excavation of raw materials to storage of products and determine optimal arrangement of total system processing needs. Total Mass, Volume, and Power (M/V/P) requirements were computed for 168 design iterations of this water processing plant. System Model: In FY24, the System Engineering and Integration (SE&I) ISRU Modeling and Analysis (SIMA) team developed a lunar water processing system model using the Mission Analysis and Integration Tool (MAIT) to estimate the M/V/P for ISRU subsystems operating under a wide range of Hydrogen (H2) and Oxygen (O2) production targets for the Space Technology Mission Directorate (STMD) [1]. Based on Japan Aerospace Exploration Agency’s (JAXA) surface operational requirements, this system architecture was modified to include the ability to excavate consolidated icy regolith (versus granular ice excavation using Kennedy Space Center’s (KSC) ISRU Pilot Excavator, IPEx) and explore the feasibility of processing the lunar water both inside and outside of the PSR. For the consolidated icy regolith case study, excavation was performed via a mobility transport chassis outfitted with The Regolith Ice Drill for Exploring New Terrain (TRIDENT) for drilling [2] and the Cold Operable Lunar Deployable Arm (COLDArm) [3] for regolith transfer. The system model determines the required rover and payload. M/V/P to handle the required regolith processing rates. The regolith is then sorted and heated to sublimate the ice (via an auger dryer). The exiting high temperature, low pressure vapor is cleaned of volatiles (via cold trap) and electrolyzed to produce H2 and O2. These products are then dried, liquified with 20 K and 90 K cryocoolers (for H2 and O2, respectively), and stored in cylindrical tanks. Study Goals: Due to the different ConOps options of regolith transport to the ridge for processing versus processing it directly inside the PSR, as well as the unknown regolith/water-ice composition, new excavation techniques and their power configurations are being evaluated within a ISRU system architecture for production targets less than NASA’s pilot plant (1 mT). This analysis investigates the feasibility of numerous excavation techniques, power architectures, and logistical operations and determines an optimal system configuration with regards to M/V/P. It aims to investigate which parameters, both locally and globally, have the greatest effect on each subsystem within the plant. This can be used to identify the most critical components of the plant, and guide future decisions on allocating funding for research and development. The results from this study may provide subsystem developers with appropriate interfaces with excavation subsystems and downstream processes, and assessing the overall feasibility of each excavation technique, power architecture, and logistical timeframe. References: [1] Carlson, A. et. al. (2024) ICES. [2] Zacny, K., et. al. (2024) “ASCE Earth and Space”. [3] McCormick, R., et. Al. (2024) IEEE Xplore.

ISRU↗