Search NASA⌕ Search

SEARCH · Search NASA

Results for “risk requirements architectures”

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

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

At least 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Advanced software integration: The case for ITV facilities

The array of technologies and methodologies involved in the development and integration of avionics software has moved almost as rapidly as computer technology itself. Future avionics systems involve major advances and risks in the following areas: (1) Complexity; (2) Connectivity; (3) Security; (4) Duration; and (5) Software engineering. From an architectural standpoint, the systems will be much more distributed, involve session-based user interfaces, and have the layered architectures typified in the layers of abstraction concepts popular in networking. Typified in the NASA Space Station Freedom will be the highly distributed nature of software development itself. Systems composed of independent components developed in parallel must be bound by rigid standards and interfaces, the clean requirements and specifications. Avionics software provides a challenge in that it can not be flight tested until the first time it literally flies. It is the binding of requirements for such an integration environment into the advances and risks of future avionics systems that form the basis of the presented concept and the basic Integration, Test, and Verification concept within the development and integration life cycle of Space Station Mission and Avionics systems.

Garman, John R.↗
NASA NTRS2008

Managing Large Scale Project Analysis Teams through a Web Accessible Database

Large scale space programs analyze thousands of requirements while mitigating safety, performance, schedule, and cost risks. These efforts involve a variety of roles with interdependent use cases and goals. For example, study managers and facilitators identify ground-rules and assumptions for a collection of studies required for a program or project milestone. Task leaders derive product requirements from the ground rules and assumptions and describe activities to produce needed analytical products. Disciplined specialists produce the specified products and load results into a file management system. Organizational and project managers provide the personnel and funds to conduct the tasks. Each role has responsibilities to establish information linkages and provide status reports to management. Projects conduct design and analysis cycles to refine designs to meet the requirements and implement risk mitigation plans. At the program level, integrated design and analysis cycles studies are conducted to eliminate every 'to-be-determined' and develop plans to mitigate every risk. At the agency level, strategic studies analyze different approaches to exploration architectures and campaigns. This paper describes a web-accessible database developed by NASA to coordinate and manage tasks at three organizational levels. Other topics in this paper cover integration technologies and techniques for process modeling and enterprise architectures.

O'Neil, Daniel A.↗
NASA NTRS2014

The Road to Realizing In-Space Manufacturing

Additive Manufacturing in space offers tremendous potential for dramatic paradigm shift in the development and manufacturing of space architectures. Additive Manufacturing in space offers the potential for mission safety risk reduction for low Earth orbit and deep space exploration; new paradigms for maintenance, repair, and logistics. Leverage ground-based technology developments, process characterization, and material properties databases. Investments are required primarily in the microgravity environment. We must do the foundational work. It's not sexy, but it is required.

Clinton, Raymond G.↗
NASA NTRSDate not supplied

NASA Development of Hardware for Life Support Systems in Cis Lunar and Surface Habitats

Sustained human presence requires the ability to survive with a minimal Earth supply chain and minimal communications from Earth. NASA is working on mission platforms to aggregate ECLS functions into a cis lunar and lunar surface architectures to demonstrate Mars forward capabilities and reduce the risk for human missions to Mars. This means the Environmental Control and Life Support (ECLS) technologies in the vehicle architecture will need to recover air and water from human and consumable waste products to support humans for short and long duration missions. NASA is developing ECLS technologies for Air Revitalization, Water Recovery and Management, Waste Management and Environmental Monitoring. Implementation of these technologies on microgravity and partial gravity platforms will collect component and system data on manned missions to increase the reliability needed for mission beyond Low Earth Orbit.

Imelda C. Stambaugh↗
NASA NTRS2002

Analysis of Parallel Burn Without Crossfeed TSTO RLV Architectures and Comparison to Parallel Burn With Crossfeed and Series Burn Architectures

There are currently three dominant TSTO class architectures. These are Series Burn (SB), Parallel Burn with crossfeed (PBw/cf), and Parallel Burn without crossfeed (PBncf). The goal of this study was to determine what factors uniquely affect PBncf architectures, how each of these factors interact, and to determine from a performance perspective whether a PBncf vehicle could be competitive with a PBw/cf or SB vehicle using equivalent technology and assumptions. In all cases, performance was evaluated on a relative basis for a fixed payload and mission by comparing gross and dry vehicle masses of a closed vehicle. Propellant combinations studied were LOX: LH2 propelled orbiter and booster (HH) and LOX: Kerosene booster with LOX: LH2 orbiter (KH). The study conclusions were: 1) a PBncf orbiter should be throttled as deeply as possible after launch until the staging point. 2) a detailed structural model is essential to accurate architecture analysis and evaluation. 3) a PBncf TSTO architecture is feasible for systems that stage at mach 7. 3a) HH architectures can achieve a mass growth relative to PBw/cf of < 20%. 3b) KH architectures can achieve a mass growth relative to Series Burn of < 20%. 4) center of gravity (CG) control will be a major issue for a PBncf vehicle, due to the low orbiter specific thrust to weight ratio and to the position of the orbiter required to align the nozzle heights at liftoff. 5 ) thrust to weight ratios of 1.3 at liftoff and between 1.0 and 0.9 when staging at mach 7 appear to be close to ideal for PBncf vehicles. 6) performance for all vehicles studied is better when staged at mach 7 instead of mach 5. The study showed that a Series Burn architecture has the lowest gross mass for HH cases, and has the lowest dry mass for KH cases. The potential disadvantages of SB are the required use of an air-start for the orbiter engines and potential CG control issues. A Parallel Burn with crossfeed architecture solves both these problems, but the mechanics of a large bipropellant crossfeed system pose significant technical difficulties. Parallel Burn without crossfeed vehicles start both booster and orbiter engines on the ground and thus avoid both the risk of orbiter air-start and the complexity of a crossfeed system. The drawback is that the orbiter must use 20% to 35% of its propellant before reaching the staging point. This induces a weight penalty in the orbiter in order to carry additional propellant, which causes a further weight penalty in the booster to achieve the same staging point. One way to reduce the orbiter propellant consumption during the first stage is to throttle down the orbiter engines as much as possible. Another possibility is to use smaller or fewer engines. Throttling the orbiter engines soon after liftoff minimizes CG control problems due to a low orbiter liftoff thrust, but may result in an unnecessarily high orbiter thrust after staging. Reducing the number or size of engines size may cause CG control problems and drift at launch. The study suggested possible methods to maximize performance of PBncf vehicle architectures in order to meet mission design requirements.

Smith, Garrett↗
NASA NTRS1992

Microwave vs optical crosslink study

The intersatellite links (ISL's) at geostationary orbit is currently a missing link in commercial satellite services. Prior studies have found that potential application of ISL's to domestic, regional, and global satellites will provide more cost-effective services than the non-ISL's systems (i.e., multiple-hop systems). In addition, ISL's can improve and expand the existing satellite services in several aspects. For example, ISL's can conserve the scarce spectrum allocated for fixed satellite services (FSS) by avoiding multiple hopping of the relay stations. ISL's can also conserve prime orbit slot by effectively expanding the geostationary arc. As a result of the coverage extension by using ISL's more users will have direct access to the satellite network, thus providing reduced signal propagation delay and improved signal quality. Given the potential benefits of ISL's system, it is of interest to determine the appropriate implementations for some potential ISL architectures. Summary of the selected ISL network architecture as supplied by NASA are listed. The projected high data rate requirements (greater than 400 Mbps) suggest that high frequency RF or optical implementations are natural approaches. Both RF and optical systems have their own merits and weaknesses which make the choice between them dependent on the specific application. Due to its relatively mature technology base, the implementation risk associated with RF (at least 32 GHz) is lower than that of the optical ISL's. However, the relatively large antenna size required by RF ISL's payload may cause real-estate problems on the host spacecraft. In addition, because of the frequency sharing (for duplex multiple channels communications) within the limited bandwidth allocated, RF ISL's are more susceptible to inter-system and inter-channel interferences. On the other hand, optical ISL's can offer interference-free transmission and compact sized payload. However, the extremely narrow beam widths (on the order of 10 micro-rad) associated with optical ISL's impose very stringent pointing, acquisition, and tracking requirements on the system. Even if the RF and optical systems are considered separately, questions still remain as to selection of RF frequency, direct versus coherent optical detection, etc. in implementing an ISL for a particular network architecture. These and other issues are studied.

Kwong, Paulman W.↗
NASA NTRSDate not supplied

NASA's Implementation of Cloud Services for Human Space Flight

Cloud is a tried-and-true technology used throughout United States government agencies, including the National Aeronautics and Space Administration (NASA). With reliable results and infrequent downtimes, cloud allows for secure remote access, customizability, and streamlined monitoring options, creating an environment for better data integrity and availability. As NASA increasingly migrates functions to the cloud, the Space Communications and Navigation Program (SCaN) program has been investigating how this capability can be leveraged to provide communication services to its users and customers. Currently, missions such as NASA-ISRO Synthetic Aperture Radar (NISAR), Plankton, Aerosol, Cloud, ocean Ecosystem (PACE), and Roman Space Telescope (RST) are planned to incorporate cloud into their data delivery architecture. However, SCaN is looking to expand further. This conversion to using cloud services allows for greater availability of mission data for both robotic and human space flight (HSF)missions. The SCaN program and the Near Space Network (NSN) are working to consolidate resources and create a cloud environment suitable for the entirety of the SCaN program network architecture. SCaN is in the process of finalizing its cloud architecture and soon will be implementing cloud services. The new services used will adhere to federal regulations including Federal Risk and Authorization Management Program (FedRAMP), which is built upon National Institute of Standards and Technology (NIST)documentation. While keeping in mind these security requirements, an auxiliary objective of the cloud integration is to ensure the most cost-efficient solution; providing a scalable, robust and resilient system. Using cloud services, NASA will gain access to better centralized monitoring and management features, along with customizable services on a pay-per-use plan. With the ever-growing NASA mission data volume needs, maintaining ample storage space is another major constraint. Processing and storing such large amounts of data, on the order of terabytes a day, requires dynamic processing capability which is inherently a strength of cloud computing. By routing this data from ground stations through the cloud, there will be greater ease of access for both SCaN and the user community. Artificial intelligence and other built-in cloud functions can also enhance efficiency, improving data processing time. Thereby also allowing for better data availability. As we look to the future of cloud services, NASA will continue to leverage capabilities that will benefit NASA’s ability to provide cost-effective communication services. This paper further outlines the evolution of cloud use by SCaN in the context of Human Space Flight.

cloud storage↗
NASA NTRS2018

A Plasma Aerocapture and Entry System for Manned Missions and Planetary Deep Space Orbiters

A rapid mission to Mars requires a large change in vehicle velocity upon arrival to establish a stable orbit. This demand is even greater for a Neptune science, requiring many kilometers per second of V. It is clear from past mission studies that a manned Mars mission and deep space planetary orbiters require aerobraking and aerocapture which use aerodynamic drag forces to slow the spacecraft. Aerocapture would enable long term studies of the outer planets and moons that would not be possible with existing braking methodologies. While the ability to utilize these atmospheres to slow down and capture spacecraft would dramatically reduce the cost, launch mass, and travel time, currently planned approaches require significant additional spacecraft mass and risk as the spacecraft must descend deep into the planetary atmosphere in order to produce significant drag on a relatively small aeroshell. The plasma based Magnetoshell being developed in this program holds the potential to perform the desired braking with significantly increased drag and control while dramatically reducing mass. Most importantly, this technology significantly lowers the risk involved with aerocapture thereby making manned planetary missions possible. The fundamental physics of the Magnetoshell is based on demonstrated experimental results. Successful implementation will dramatically decrease radiation exposures, mission risk, launch cost, and launch mass. Implementation of aerobraking by employing a solid deflector or aeroshell as a method for orbit insertion and circularization has been successfully demonstrated in the past, resulting in launch mass savings greater than 50%. In order to reduce the effect of frictional heating and dynamic pressure on the typically fragile aeroshell, or worse solar panels, the braking must be distributed over many orbital passes at a high altitude in the less dense regions of the atmosphere. It can thus take several months for a meter-scale, 1000 kg, aeroshell to execute the many elliptic orbital passes through the atmosphere to achieve the required V. This rather slow method of braking not only reduces frictional heating and dynamic forces, but also avoids unpredictable dynamic behavior due to turbulence, as well as unknown and seasonally variable atmospheric composition and temperature which has led to dangerous, mission-critical events. For exploration class missions such as DRA 5.0 aerocapture and Thermal Protection Systems (TPS) are proposed for breaking at Mars for cargo missions. Traditional aerocapture is considered too risky for manned missions. Even with the enormous mass savings that aerocapture allows, it still requires 80 tons of aeroshell and significantly increased launch mass and propellant. As will be shown, by using Magnetoshells for aerobraking, the DRA 5.0 mission will save 224 metric tons (MT) and greater than $2 B in launch costs. Beyond the dramatic savings for existing mission architectures, a low-mass, risk-free aerocapture system would allow much more rapid missions to Mars and deep space orbiters by allowing direct, faster trajectories. As will be shown, the plasma Magnetoshell Aerobraking, Aerocapture, and Entry System (AAES) not only reduces mass and cost while enabling significant new mission architectures, but also significantly reduces radiation exposures by decreasing trip times.

Manned Missions↗
NASA NTRS2017

Prospective Architectures for Onboard vs Cloud-Based Decision Making for Unmanned Aerial Systems

This paper investigates propsective architectures for decision-making in unmanned aerial systems. When these unmanned vehicles operate in urban environments, there are several sources of uncertainty that affect their behavior, and decision-making algorithms need to be robust to account for these different sources of uncertainty. It is important to account for several risk-factors that affect the flight of these unmanned systems, and facilitate decision-making by taking into consideration these various risk-factors. In addition, there are several technical challenges related to autonomous flight of unmanned aerial systems; these challenges include sensing, obstacle detection, path planning and navigation, trajectory generation and selection, etc. Many of these activities require significant computational power and in many situations, all of these activities need to be performed in real-time. In order to efficiently integrate these activities, it is important to develop a systematic architecture that can facilitate real-time decision-making. Four prospective architectures are discussed in this paper; on one end of the spectrum, the first architecture considers all activities/computations being performed onboard the vehicle whereas on the other end of the spectrum, the fourth and final architecture considers all activities/computations being performed in the cloud, using a new service known as Prognostics as a Service that is being developed at NASA Ames Research Center. The four different architectures are compared, their advantages and disadvantages are explained and conclusions are presented.

Software engineering↗
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 and ubiquitous autonomy 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 for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, concepts of operations, and interface control documents, 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 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) standalone 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.

Autonomous Systems↗
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 NTRS2008

A Testbed for Evaluating Lunar Habitat Autonomy Architectures

A lunar outpost will involve a habitat with an integrated set of hardware and software that will maintain a safe environment for human activities. There is a desire for a paradigm shift whereby crew will be the primary mission operators, not ground controllers. There will also be significant periods when the outpost is uncrewed. This will require that significant automation software be resident in the habitat to maintain all system functions and respond to faults. JSC is developing a testbed to allow for early testing and evaluation of different autonomy architectures. This will allow evaluation of different software configurations in order to: 1) understand different operational concepts; 2) assess the impact of failures and perturbations on the system; and 3) mitigate software and hardware integration risks. The testbed will provide an environment in which habitat hardware simulations can interact with autonomous control software. Faults can be injected into the simulations and different mission scenarios can be scripted. The testbed allows for logging, replaying and re-initializing mission scenarios. An initial testbed configuration has been developed by combining an existing life support simulation and an existing simulation of the space station power distribution system. Results from this initial configuration will be presented along with suggested requirements and designs for the incremental development of a more sophisticated lunar habitat testbed.

Lawler, Dennis G.↗
NASA NTRS2010

Human System Drivers for Exploration Missions

Evaluation of DRM4 in terms of the human system includes the ability to meet NASA standards, the inclusion of the human system in the design trade space, preparation for future missions and consideration of a robotic precursor mission. Ensuring both the safety and the performance capability of the human system depends upon satisfying NASA Space Flight Human System Standards.1 These standards in turn drive the development of program-specific requirements for Near-earth Object (NEO) missions. In evaluating DRM4 in terms of these human system standards, the currently existing risk models, technologies and biological countermeasures were used. A summary of this evaluation is provided below in a structure that supports a mission architecture planning activities. 1. Unacceptable Level of Risk The duration of the DRM4 mission leads to an unacceptable level of risk for two aspects of human system health: A. The permissible exposure limit for space flight radiation exposure (a human system standard) would be exceeded by DRM4. B. The risk of visual alterations and abnormally high intracranial pressure would be too high. 1

Kundrot, Craig E.↗
NASA NTRS2019

Recommendation for a Medical System Concept of Operations for Gateway Missions

NASA’s exploration missions to cis-lunar space will establish a permanent gateway to future transport missions to Mars. These missions mandate a significant paradigm change for mission planning, spacecraft design, human systems integration, and in-flight medical care due to constraints on mass, volume, power, resupply, and medical evacuation capability. These constraints require medical system development to be tightly integrated with mission and habitat design to provide a sufficient medical infrastructure and enable mission success. This concept of operations provides a vision of medical care needs that will be used to guide the development of a medical system for the cis-lunar Gateway Habitat. This medical system will serve as the precursor to what is implemented in future exploration missions to Mars. This concept of operations documents an overview of the stakeholder needs and system goals of a medical system and provides examples of the types of activities for which the system will be used during the mission. This concept of operations informs the ExMC systems engineering effort to define the Gateway Habitat Medical System by documenting the medical activities and capabilities relevant to Gateway missions, as identified by the ExMC clinician community. In addition, this concept of operations will inform the subsequent systems engineering process of developing technical requirements, system architectures, interfaces, and verification and validation approaches for the medical system. This document supports the closure of ExMC Gap Med01: We do not have a concept of operations for medical care during exploration missions, corresponding to the ExMC-managed human system risk: Risk of Adverse Health Outcomes & Decrements in Performance due to Inflight Medical Conditions.

Rubin, David↗
NASA NTRS2019

Medical System Concept of Operations for Mars Exploration Mission-11: Exploration Medical Capability (ExMC) Element - Human Research Program

NASA’s exploration missions to Mars will have durations of 2-3 years and will take humans farther away from Earth than ever before. This will result in a paradigm shift for mission planning, spacecraft design, human systems integration, and in-flight medical care. Constraints on real-time communication, resupply, and medical evacuation are major architectural drivers. These constraints require medical system development to be tightly integrated with mission and vehicle design to provide crew autonomy and enable mission success. This concept of operations provides a common vision of medical care for developing a medical system for Mars exploration missions. It documents an overview of the stakeholder needs and goals of a medical system and provides examples of the types of activities the system will be used for during the mission. Development of the concept of operations considers mission variables such as distance from Earth, duration of mission, time to definitive medical care, communication protocols between crewmembers and ground support, personnel capabilities and skill sets, medical hardware and software, and medical data management. The information provided in this document informs the ExMC Systems Engineering effort to define the functions to be provided by the medical system. In addition, this concept of operations will inform the subsequent systems engineering process of developing technical requirements, system architectures, interfaces, and verification and validation approaches for the medical system. This document supports the closure of ExMC Gap Med01: We do not have a concept of operations for medical care during exploration missions, corresponding to the ExMC-managed human system risk: Risk of Adverse Health Outcomes & Decrements in Performance due to Inflight Medical Conditions. This document is applicable to the ExMC Element Systems Engineering process and may be used for collaboration within the Human Research Program.

Urbina, Michelle↗
NASA NTRSDate not supplied

Space ROS TOFU: Flying Space ROS with Containerized Hybrid Trust

Space ROS is a distribution of Robot Operating System 2 (ROS2) targeting the specific requirements of flight software and spaceborne robotics while maintaining the flexibility that has made ROS indispensible for robotics research and industrial system integration. With Space ROS, a project can leverage the existing ROS2 ecosystem to reduce redundant development while tackling increasingly complex demands for on-device intelligence; however, there is no substitute for flight heritage to combat the risk-aversion common to spaceflight projects, and Space ROS has yet to fly. To break the collective-action standoff and gain valuable flight experience, the Distributed Spacecraft Autonomy (DSA) team at NASA Ames Research Center developed Opportunistic Software Experiments for Spacecraft Autonomy Testbeds (OSE-SAT) architecture, utilizing containerization to execute lower-trust software under traditionally verified heritage flight software for demonstration on-orbit. OSE-SAT leverages a hybrid-trust model where flexible, complex components like Space ROS can run without risk to the host spacecraft while providing validated feedback to a highly scrutinized, trusted core. We leverage this testbed to demonstrate Space ROS in flight, building heritage, and experience for projects with "Trust On First Use" (TOFU) requirements for flight heritage. We present a Space ROS component for OSE-SAT, lessons learned integrating Space ROS into a flight software stack, and the results of the first known use of Space ROS in orbit.

small satellites↗
NASA NTRS2012

Digital Calibration of TR Modules for Real-Tme Digital Beamforming SweepSAR Architectures

Real-time digital beamforming, combined with lightweight, large aperture reflectors, enable a new architecture, which is the baseline for the proposed DESDynI [Deformation, Ecosystem Structure, and Dynamics of Ice] SAR [Synthetic Aperture Radar] Instrument (or DSI). This new instrument concept requires new methods for calibrating multiple simultaneous channels. The calibration of current state-of-the-art Electronically Steered Arrays typically involves pre-flight TR (Transmit/Receive) module characterization over temperature, and in-flight correction based on measured temperatures. This method ignores the effects of element aging and any drifts unrelated to temperature. We are developing new digital calibration of digital beamforming arrays, which helps to reduce development time, risk and cost. Precision calibrated TR modules enable real-time beamforming architectures by accurately tracking modules' characteristics through closed-loop digital calibration, which tracks systematic changes regardless of temperature. The benefit of this effort is that it would enable a new, lightweight radar architecture, with on-board digital beamforming. This provides significantly larger swath coverage than conventional SAR architectures

Hoffman, James Patrick↗
NASA NTRS2021

FRESCO: A Framework for Spacecraft Systems Autonomy

Achieving the science exploration and defense goals of the following decades will require flight systems capable of operations with limited operator contact, system mode changes and retasking based on sensor data, and complex robotic operations. To support these capabilities, increasingly autonomous flight systems are required that can perform dedicated mission functions, e.g. payload targeting and communications, and system-level functions, e.g. planning and goal monitoring. Architecting an autonomous system requires a well-reasoned, self-consistent framework to avoid \textit{ad hoc} design choices that will introduce complexity and risk. The Framework for Robust Execution and Scheduling of Commands On-Board, FRESCO, is the result of lessons learned in developing a software architecture to enable autonomous solar system exploration. FRESCO generalizes this work to offer a modular, software-agnostic approach to developing verifiable architecture for autonomous space systems. FRESCO specifies guiding principles, functions, interfaces, and interactions from which mission-specific autonomous control architectures can be derived. FRESCO is a principled framework relying on explicit, state-based goal definitions, centralized management of state knowledge, clearly separated control boundaries, and hierarchical reasoning. Using components from FRESCO reference architecture, an autonomous decision-making architecture can be designed for spacecraft which can then be mapped to flight software architecture. FRESCO is flexibly defined to enable autonomous control of flight systems built using extensive software and hardware heritage. Finally, FRESCO-derived architectures support a spectrum of operator/spacecraft interactions, ranging from traditional commanding to goal-driven commanding with the ability to change mission goals autonomously. FRESCO has been used in defining the autonomy architectures for the ASTERIA mission and have been demonstrated in laboratory and software simulation for small body rendezvous and in-space servicing missions.

Kolcio, Ksenia↗