Search NASA⌕ Search

SEARCH · Search NASA

Results for “software architecture design subsystem”

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.

124 records · Page 7

Advanced techniques in reliability model representation and solution

The current tendency of flight control system designs is towards increased integration of applications and increased distribution of computational elements. The reliability analysis of such systems is difficult because subsystem interactions are increasingly interdependent. Researchers at NASA Langley Research Center have been working for several years to extend the capability of Markov modeling techniques to address these problems. This effort has been focused in the areas of increased model abstraction and increased computational capability. The reliability model generator (RMG) is a software tool that uses as input a graphical object-oriented block diagram of the system. RMG uses a failure-effects algorithm to produce the reliability model from the graphical description. The ASSURE software tool is a parallel processing program that uses the semi-Markov unreliability range evaluator (SURE) solution technique and the abstract semi-Markov specification interface to the SURE tool (ASSIST) modeling language. A failure modes-effects simulation is used by ASSURE. These tools were used to analyze a significant portion of a complex flight control system. The successful combination of the power of graphical representation, automated model generation, and parallel computation leads to the conclusion that distributed fault-tolerant system architectures can now be analyzed.

Palumbo, Daniel L.↗

Enabling Reliable, Fault-Tolerant Autonomous Lunar Habitats with High-Performance Spaceflight Computing

The lunar surface presents unfavorable constraints and harsh living conditions. To address these challenges, autonomous habitats will require complex integrated systems that combine advanced software, high-performance hardware, and cutting-edge sensors to ensure sustainability, safety, and operational efficiency. Consequently, maintaining a sustainable presence on the Moon requires reliable infrastructure and efficient development, precise monitoring, and utilization of resources within a lunar installation. These elements are essential not only to ensure that lunar settlement can be long-term, self-sustaining, and resource-efficient, but also to serve as a foundation for future missions and eventual human habitation on Mars. Humans are not native to the Moon; therefore, our survival and ability to thrive will depend on autonomous systems that can foster safety and resilience through high-availability architectures, graceful degradation, and highly fault-tolerant spaceflight hardware capable of continuing operation during failures. This requires advanced human-rated distributed systems architectures with specialized electronics, scalable capabilities, and an integrated design approach. Unlike current practices focused on short-term missions and regularly maintained components, permanent lunar compute systems must be designed for extended operations beyond mission durations. This paper explores the necessity of transitioning toward fault- tolerant, highly autonomous hardware systems designed for multi-year missions. It also identifies critical subsystems that require high levels of autonomy, supported by radiation-hardened processors and extreme thermal loads, which are essential to mitigate long-term degradation and ensure sustainable lunar habitation. Finally, the paper aligns with NASA’s identified Civil Space Shortfalls, particularly in high-performance onboard computing, advanced data acquisition, extreme-environment avionics, radiation monitoring and countermeasures, and autonomous health management. It proposes NASA’s new High-Performance Spaceflight Computing (HPSC) processor as a turnkey solution, delivering 100 times the performance-per-watt of legacy rad-hard CPUs and enabling onboard AI, edge computing, and fault-tolerant features essential for sustained lunar autonomy and beyond.

Sarkis S Mikaelian↗

Surface Habitat Systems

The Surface Habitat Systems (SHS) Focused Investment Group (FIG) is part of the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) effort to provide a focused direction and funding to the various projects that are working on human surface habitat designs and technologies for the planetary exploration missions. The overall SHS-FIG effort focuses on directing and guiding those projects that: 1) develop and demonstrate new surface habitat system concepts, innovations, and technologies to support human exploration missions, 2) improve environmental systems that interact with human habitats, 3) handle and emplace human surface habitats, and 4) focus on supporting humans living and working in habitats on planetary surfaces. The activity areas of the SHS FIG described herein are focused on the surface habitat project near-term objectives as described in this document. The SHS-FIG effort focuses on mitigating surface habitat risks (as identified by the Lunar Surface Systems Project Office (LSSPO) Surface Habitat Element Team; and concentrates on developing surface habitat technologies as identified in the FY08 gap analysis. The surface habitat gap assessment will be updated annually as the surface architecture and surface habitat definition continues to mature. These technologies are mapped to the SHS-FIG Strategic Development Roadmap. The Roadmap will bring to light the areas where additional innovative efforts are needed to support the development of habitat concepts and designs and the development of new technologies to support of the LSSPO Habitation Element development plan. Three specific areas of development that address Lunar Architecture Team (LAT)-2 and Constellation Architecture Team (CxAT) Lunar habitat design issues or risks will be focused on by the SHS-FIG. The SHS-FIG will establish four areas of development that will help the projects prepare in their planning for surface habitat systems development. Those development areas are the 1) surface habitat concept definition, 2) inflatable surface habitat development, and 3) autonomous habitat operations, and 4) cross-cutting / systems engineering. In subsequent years, the SHS-FIG will solicit a call for innovations and technologies that will support the development of these four development areas. The other development areas will be assessed yearly and identified on the SHS-FIG s Strategic Development Roadmap. Initial investment projects that are funded by the Constellation Program Office (CxPO), LSSPO, or the Exploration Technology Development Projects (ETDP) will also be included on the Roadmap. For example, in one or two years from now, the autonomous habitat operations and testbed would collaborations with the Integrated Systems Health Management (ISHM) and Automation for Operations ETDP projects, which will give the surface habitat projects an integrated habitat autonomy testbed to test software and systems. The SHS-FIG scope is to provide focused direction for multiple innovations, technologies and subsystems that are needed to support humans at a remote planetary surface habitat during the concept development, design definition, and integration phases of that project. Subsystems include: habitability, lightweight structures, power management, communications, autonomy, deployment, outfitting, life support, wireless connectivity, lighting, thermal and more.

Kennedy, Kriss J.↗

Preliminary Sizing Completed for Single- Stage-To-Orbit Launch Vehicles Powered By Rocket-Based Combined Cycle Technology

Single-stage-to-orbit (SSTO) propulsion remains an elusive goal for launch vehicles. The physics of the problem is leading developers to a search for higher propulsion performance than is available with all-rocket power. Rocket-based combined cycle (RBCC) technology provides additional propulsion performance that may enable SSTO flight. Structural efficiency is also a major driving force in enabling SSTO flight. Increases in performance with RBCC propulsion are offset with the added size of the propulsion system. Geometrical considerations must be exploited to minimize the weight. Integration of the propulsion system with the vehicle must be carefully planned such that aeroperformance is not degraded and the air-breathing performance is enhanced. Consequently, the vehicle's structural architecture becomes one with the propulsion system architecture. Geometrical considerations applied to the integrated vehicle lead to low drag and high structural and volumetric efficiency. Sizing of the SSTO launch vehicle (GTX) is itself an elusive task. The weight of the vehicle depends strongly on the propellant required to meet the mission requirements. Changes in propellant requirements result in changes in the size of the vehicle, which in turn, affect the weight of the vehicle and change the propellant requirements. An iterative approach is necessary to size the vehicle to meet the flight requirements. GTX Sizer was developed to do exactly this. The governing geometry was built into a spreadsheet model along with scaling relationships. The scaling laws attempt to maintain structural integrity as the vehicle size is changed. Key aerodynamic relationships are maintained as the vehicle size is changed. The closed weight and center of gravity are displayed graphically on a plot of the synthesized vehicle. In addition, comprehensive tabular data of the subsystem weights and centers of gravity are generated. The model has been verified for accuracy with finite element analysis. The final trajectory was rerun using OTIS (Boeing Corporation's trajectory optimization software package), and the sizing output was incorporated into a solid model of the vehicle using PRO/Engineer computer-aided design software (Parametric Technology Corporation, Waltham, MA).

Roche, Joseph M.↗

Kepler Science Operations Center Pipeline Framework

The Kepler mission is designed to continuously monitor up to 170,000 stars at a 30 minute cadence for 3.5 years searching for Earth-size planets. The data are processed at the Science Operations Center (SOC) at NASA Ames Research Center. Because of the large volume of data and the memory and CPU-intensive nature of the analysis, significant computing hardware is required. We have developed generic pipeline framework software that is used to distribute and synchronize the processing across a cluster of CPUs and to manage the resulting products. The framework is written in Java and is therefore platform-independent, and scales from a single, standalone workstation (for development and research on small data sets) to a full cluster of homogeneous or heterogeneous hardware with minimal configuration changes. A plug-in architecture provides customized control of the unit of work without the need to modify the framework itself. Distributed transaction services provide for atomic storage of pipeline products for a unit of work across a relational database and the custom Kepler DB. Generic parameter management and data accountability services are provided to record the parameter values, software versions, and other meta-data used for each pipeline execution. A graphical console allows for the configuration, execution, and monitoring of pipelines. An alert and metrics subsystem is used to monitor the health and performance of the pipeline. The framework was developed for the Kepler project based on Kepler requirements, but the framework itself is generic and could be used for a variety of applications where these features are needed.

Klaus, Todd C.↗

Orion Launch Abort System Performance on Exploration Flight Test 1

This paper will present an overview of the flight test objectives and performance of the Orion Launch Abort System during Exploration Flight Test-1. Exploration Flight Test-1, the first flight test of the Orion spacecraft, was managed and led by the Orion prime contractor, Lockheed Martin, and launched atop a United Launch Alliance Delta IV Heavy rocket. This flight test was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety. This test included the first flight test of the Launch Abort System preforming Orion nominal flight mission critical objectives. NASA is currently designing and testing the Orion Multi-Purpose Crew Vehicle (MPCV). Orion will serve as NASA's new exploration vehicle to carry astronauts to deep space destinations and safely return them to earth. The Orion spacecraft is composed of four main elements: the Launch Abort System, the Crew Module, the Service Module, and the Spacecraft Adapter (Fig. 1). The Launch Abort System (LAS) provides two functions; during nominal launches, the LAS provides protection for the Crew Module from atmospheric loads and heating during first stage flight and during emergencies provides a reliable abort capability for aborts that occur within the atmosphere. The Orion Launch Abort System (LAS) consists of an Abort Motor to provide the abort separation from the Launch Vehicle, an Attitude Control Motor to provide attitude and rate control, and a Jettison Motor for crew module to LAS separation (Fig. 2). The jettison motor is used during a nominal launch to separate the LAS from the Launch Vehicle (LV) early in the flight of the second stage when it is no longer needed for aborts and at the end of an LAS abort sequence to enable deployment of the crew module's Landing Recovery System. The LAS also provides a Boost Protective Cover fairing that shields the crew module from debris and the aero-thermal environment during ascent. Although the Orion Program has tested a number of the critical systems of the Orion spacecraft on the ground, the launch environment cannot be replicated completely on Earth. A number of flight tests have been conducted and are planned to demonstrate the performance and enable certification of the Orion Spacecraft. Exploration Flight Test 1, the first flight test of the Orion spacecraft, was successfully flown on December 5, 2014 from Cape Canaveral Air Force Station's Space Launch Complex 37. Orion's first flight was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety, such as heat shield performance, separation events, avionics and software performance, attitude control and guidance, parachute deployment and recovery operations. One of the key separation events tested during this flight was the nominal jettison of the LAS. Data from this flight will be used to verify the function of the jettison motor to separate the Launch Abort System from the crew module so it can continue on with the mission. The LAS nominal jettison event on Exploration Flight Test 1 occurred at six minutes and twenty seconds after liftoff (See Fig. 3). The abort motor and attitude control motors were inert for Exploration Flight Test 1, since the mission did not require abort capabilities. A suite of developmental flight instrumentation was included on the flight test to provide data on spacecraft subsystems and separation events. This paper will focus on the flight test objectives and performance of the LAS during ascent and nominal jettison. Selected LAS subsystem flight test data will be presented and discussed in the paper. Exploration Flight Test -1 will provide critical data that will enable engineering to improve Orion's design and reduce risk for the astronauts it will protect as NASA continues to move forward on its human journey to Mars. The lessons learned from Exploration Flight Test 1 and the other Flight Test Vehicles will certainly contribute to the vehicle architecture of a human-rated space launch vehicle.

McCauley, R.↗

Electrical Ground Support Equipment for the Sampling Caching System of the Mars 2020 Rover

In this work we describe in detail the architecture, design, testing and operation of the Electrical Ground Support Equipment (EGSE) “Blue Box” used to test and validate the Sampling Caching System (SCS) of the Mars 2020 Perseverance rover. The Blue Box architecture is centered around COTS motor controllers and COTS input-output modules communicating over an EtherCAT bus. A custom, low-level safety subsystem ensures no harm can be done to the flight articles. The modular architecture of the EGSE reduces cost and complexity while expediting assembly time. The Blue Box drives the 19 actuators of the SCS which span the main robotic arm, the corer system, the internal sample handling arm, the sample tube sealing system and the gas dust removal tool; mimicking the Rover Motor Control Assembly (RMCA). Due to the limited availability of RMCA’s, the EGSE enabled and performed the bulk of testing activities for SCS. The majority of the SCS actuators are composed of a 3-phase DC brushless motors, hall sensors for commutation, dual resolvers for output angular measurement, brakes, heaters and platinum thermistors. Additionally, the EGSE read 12 strain gauges forming part of a force torque sensor, and switches used for external positioning references. Over the 3-year span of the V&V campaign for the SCS, over 32 EGSE systems were built, tested and deployed to test venues at JPL and externally. The EGSE tested several families of the SCS subsystem, ranging from engineering units, life test units and two flight units. Test venues that this EGSE supported included lab benches, ultra-clean cleanrooms, ATLO facilities, and thermal vacuum chambers. Together with the test software systems, SSDEV and SSDEV-ECAT, the Blue Box EGSE enabled the team to efficiently test flight hardware and flight software together. We go over the safety features and fault management techniques employed to protect flight hardware. The effects of the long, 50-feet, EGSE harnesses on motor performance, EMI, electrical noise, and motor control performance are explained. Mitigations to these unwanted effects, including shielding strategy and inductance compensation, are summarized. We go over an excerpt of notable anomalies that this EGSE suffered through its operation, along with investigations and resolutions. Lessons learned, areas of improvement as part of future work, and recommendations for future implementations for similar EGSE’s, are shared.

Levine, Dan↗

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

NASA Pilot-Engaged Expert Response Using IBM Watson Technology: Prototype Evaluation of Knowledge Retrieval System

NASA Langley Research Center and IBM have been investigating the use of IBM Watson technology in aerospace research and development. One application of Watson technology is the Pilot-Engaged Expert Response (PEER) use case. The PEER system is envisioned as an in-cockpit advisor that will act as a source of situationally-relevant information for pilots and other flight crew members to assist in decision making about real-time events and situations that arise in the course of aircraft operations. PEER will make available vast stores of knowledge and information quickly and directly, putting important informational resources where they are needed most. IBM has worked with NASA to develop an architecture and articulate a roadmap for the development of the PEER system. That vision is built around Watson Discovery Advisor (WDA) software solution, derived from IBM's Jeopardy!-winning automatic question answering system. PEER makes use of WDA's sophisticated question-answering capabilities as its core, adding important User Interface components and other customizations for the cockpit environment, including communication with flight systems and other external data sources. The development plan for PEER includes four development stages, with the current project constituting the first phase. In this project, a prototype instance of PEER was successfully adapted to the aviation domain, enabling users to ask questions about aviation topics and receive useful and accurate answers to these questions. Major tasks accomplished include the development of procedures for domain adaptation through automatic lexicon extraction from domain glossaries; generation of question-answer training data which was used to train the system; and assessment of the effectiveness of domain adaptation, which showed a dramatic improvement in the ability of the PEER system to answer domain-relevant questions. In addition, the vision for the PEER system was pushed forward by the articulation of a plan for the automatic enhancement of question-answering with contextual information. This initial phase focused on two main goals: 1) the targeted domain adaptation of the underlying WDA system to the aviation domain; and, 2) the design of the software systems needed to leverage flight-contextual data. Domain adaptation of the WDA system proceeds via three main activities: Domain data ingestion, lexical customization and model training. A textual corpus consisting of 1,147 individual documents with more than 7.5 million words of text was ingested into the system and this served as the basis of all further development. A domain lexicon of over 3,500 aviation-domain terms was semi-automatically generated from domain documents and used to train the system. In addition, a set of over 500 question-answer (QA) pairs relevant to the PEER use case was developed; these were used to train and assess the system. These important first steps established the basis for the PEER system. In addition, steps were taken towards the integration of the PEER system into the cockpit environment with the development of a functional design for the Contextual Data Augmentation (CDA) subsystem. This subsystem brings to bear contextual data to improve system responses. It has three main submodules: the Contextual Data Collection module, the Contextual Data Selection module, and the Contextual QA Augmentation module. These modules form a processing pipeline that addresses the problems associated with automatically integrating information from external resources into the knowledge-retrieval mechanism.

Machine learning↗

Liquid Oxygen/Liquid Methane Integrated Power and Propulsion

The proposed paper will cover ongoing work at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) on integrated power and propulsion for advanced human exploration. Specifically, it will present findings of the integrated design, testing, and operational challenges of a liquid oxygen / liquid methane (LOx/LCH4) propulsion brassboard and Solid Oxide Fuel Cell (SOFC) system. Human-Mars architectures point to an oxygen-methane economy utilizing common commodities, scavenged from the planetary atmosphere and soil via In-Situ Resource Utilization (ISRU), and common commodities across sub-systems. Due to the enormous mass gear-ratio required for human exploration beyond low-earth orbit, (for every 1 kg of payload landed on Mars, 226 kg will be required on Earth) increasing commonality between spacecraft subsystems such as power and propulsion can result in tremendous launch mass and volume savings. Historically, propulsion and fuel cell power subsystems have had little interaction outside of the generation (fuel cell) and consumption (propulsion) of electrical power. This was largely due to a mismatch in preferred commodities (hypergolics for propulsion; oxygen & hydrogen for fuel cells). Although this stove-piped approach benefits from simplicity in the design process, it means each subsystem has its own tanks, pressurization system, fluid feed system, etc. increasing overall spacecraft mass and volume. A liquid oxygen / liquid methane commodities architecture across propulsion and power subsystems would enable the use of common tankage and associated pressurization and commodity delivery hardware for both. Furthermore, a spacecraft utilizing integrated power and propulsion could use propellant residuals - propellant which could not be expelled from the tank near depletion due to hydrodynamic considerations caused by large flow demands of a rocket engine - to generate power after all propulsive maneuvers are complete thus utilizing previously wasted mass. Such is the case for human and robotic planetary landers. Although many potential benefits through integrated power & propulsion exist, integrated operations have yet to be successfully demonstrated and many challenges have already been identified the most obvious of which is the large temperature gradient. SOFC chemistry is exothermic with operating temperatures in excess of 1,000 K; however, any shared commodities will be undoubtedly stored at cryogenic temperatures (90-112 K) for mass efficiency reasons. Spacecraft packaging will drive these two subsystems in close proximity thus heat leak into the commodity tankage must be minimized and/or mitigated. Furthermore, commodities must be gasified prior to consumption by the SOFC. Excess heat generated by the SOFC could be used to perform this phase change; however, this has yet to be demonstrated. A further identified challenge is the ability of the SOFC to handle the sudden power spikes created by the propulsion system. A power accumulator (battery) will likely be necessary to handle these sudden demands while the SOFC thermally adjusts. JSC's current SOFC test system consists of a 1 kW fuel cell designed by Delphi. The fuel cell is currently undergoing characterization testing at the NASA JSC Energy Systems Test Area (ESTA) after which a Steam Methane Reformer (SMR) will be integrated and the combined system tested in closed-loop. The propulsion brassboard is approximately the size of what could be flown on a sounding rocket. It consists of one 100 lbf thrust "main" engine developed for NASA by Aerojet and two 10 lbf thrusters to simulate a reaction control system developed at NASA JSC. This system is also under development and initial testing at ESTA. After initial testing, combined testing will occur which will provide data on the fuel cell's ability to sufficiently handle the power spikes created by the propulsion system. These two systems will also be modeled using General-Use Nodal Network Solver (GUNNS) software. Once anchored with test data, this model will be used to extrapolate onto other firing profiles and used to size the power accumulator.

Banker, Brian↗

Human Exploration Spacecraft Testbed for Integration and Advancement (HESTIA)

The proposed paper will cover ongoing effort named HESTIA (Human Exploration Spacecraft Testbed for Integration and Advancement), led at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) to promote a cross-subsystem approach to developing Mars-enabling technologies with the ultimate goal of integrated system optimization. HESTIA also aims to develop the infrastructure required to rapidly test these highly integrated systems at a low cost. The initial focus is on the common fluids architecture required to enable human exploration of mars, specifically between life support and in-situ resource utilization (ISRU) subsystems. An overview of the advancements in both integrated technologies, in infrastructure, in simulation, and in modeling capabilities will be presented, as well as the results and findings of integrated testing,. Due to the enormous mass gear-ratio required for human exploration beyond low-earth orbit, (for every 1 kg of payload landed on Mars, 226 kg will be required on Earth), minimization of surface hardware and commodities is paramount. Hardware requirements can be minimized by reduction of equipment performing similar functions though for different subsystems. If hardware could be developed which meets the requirements of both life support and ISRU it could result in the reduction of primary hardware and/or reduction in spares. Minimization of commodities to the surface of mars can be achieved through the creation of higher efficiency systems producing little to no undesired waste, such as a closed-loop life support subsystem. Where complete efficiency is impossible or impractical, makeup commodities could be manufactured via ISRU. Although, utilization of ISRU products (oxygen and water) for crew consumption holds great promise of reducing demands on life support hardware, there exist concerns as to the purity and transportation of commodities. To date, ISRU has been focused on production rates and purities for propulsion needs. The meshing of requirements between all potential users, producers, and cleaners of oxygen and water is crucial to guiding the development of technologies which will be used to perform these functions. Various new capabilities are being developed as part of HESTIA, which will enable the integrated testing of these technologies. This includes the upgrading of a 20' diameter habitat chamber to eventually support long duration (90+ day) human-in-the-loop testing of advanced life support systems. Additionally, a 20' diameter vacuum chamber is being modified to create Mars atmospheric pressures and compositions. This chamber, designated the Mars Environment Chamber (MEC), will eventually be upgraded to include a dusty environment and thermal shroud to simulate conditions on the surface of Mars. In view that individual technologies will be in geographically diverse locations across NASA facilities and elsewhere in the world, schedule and funding constraints will likely limit the frequency of physical integration. When this is the case, absent subsystems can be either digitally or physically simulated. Using the Integrated Power Avionics and Software (iPAS) environment, HESTIA is able to bring together data from various subsystems in simulated surroundings, insert faults, errors, time delays, etc., and feed data into computer models or physical systems capable of reproducing the output of the absent subsystems for the consumption of a local subsystems. Although imperfect, this capability provides opportunities to test subsystem integration and interactions at a fraction of the cost. When a subsystem technology is too immature for integrated testing, models can be produced using the General-Use Nodal Network Solver (GUNNS) capability to simulate the overall system performance. In doing so, even technologies not yet on the drawing board can be integrated and overall system performance estimated. Through the integrated development of technologies, as well as of the infrastructure to rapidly and at a low cost, model, simulate, and test subsystem technologies early in their development, HESTIA is pioneering a new way of developing the future of human space exploration.

Banker, Brian F.↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗

Intelligent Integrated Health Management for a System of Systems

An intelligent integrated health management system (IIHMS) incorporates major improvements over prior such systems. The particular IIHMS is implemented for any system defined as a hierarchical distributed network of intelligent elements (HDNIE), comprising primarily: (1) an architecture (Figure 1), (2) intelligent elements, (3) a conceptual framework and taxonomy (Figure 2), and (4) and ontology that defines standards and protocols. Some definitions of terms are prerequisite to a further brief description of this innovation: A system-of-systems (SoS) is an engineering system that comprises multiple subsystems (e.g., a system of multiple possibly interacting flow subsystems that include pumps, valves, tanks, ducts, sensors, and the like); 'Intelligent' is used here in the sense of artificial intelligence. An intelligent element may be physical or virtual, it is network enabled, and it is able to manage data, information, and knowledge (DIaK) focused on determining its condition in the context of the entire SoS; As used here, 'health' signifies the functionality and/or structural integrity of an engineering system, subsystem, or process (leading to determination of the health of components); 'Process' can signify either a physical process in the usual sense of the word or an element into which functionally related sensors are grouped; 'Element' can signify a component (e.g., an actuator, a valve), a process, a controller, an actuator, a subsystem, or a system; The term Integrated System Health Management (ISHM) is used to describe a capability that focuses on determining the condition (health) of every element in a complex system (detect anomalies, diagnose causes, prognosis of future anomalies), and provide data, information, and knowledge (DIaK) not just data to control systems for safe and effective operation. A major novel aspect of the present development is the concept of intelligent integration. The purpose of intelligent integration, as defined and implemented in the present IIHMS, is to enable automated analysis of physical phenomena in imitation of human reasoning, including the use of qualitative methods. Intelligent integration is said to occur in a system in which all elements are intelligent and can acquire, maintain, and share knowledge and information. In the HDNIE of the present IIHMS, an SoS is represented as being operationally organized in a hierarchical-distributed format. The elements of the SoS are considered to be intelligent in that they determine their own conditions within an integrated scheme that involves consideration of data, information, knowledge bases, and methods that reside in all elements of the system. The conceptual framework of the HDNIE and the methodologies of implementing it enable the flow of information and knowledge among the elements so as to make possible the determination of the condition of each element. The necessary information and knowledge is made available to each affected element at the desired time, satisfying a need to prevent information overload while providing context-sensitive information at the proper level of detail. Provision of high-quality data is a central goal in designing this or any IIHMS. In pursuit of this goal, functionally related sensors are logically assigned to groups denoted processes. An aggregate of processes is considered to form a system. Alternatively or in addition to what has been said thus far, the HDNIE of this IIHMS can be regarded as consisting of a framework containing object models that encapsulate all elements of the system, their individual and relational knowledge bases, generic methods and procedures based on models of the applicable physics, and communication processes (Figure 2). The framework enables implementation of a paradigm inspired by how expert operators monitor the health of systems with the help of (1) DIaK from various sources, (2) software tools that assist in rapid visualization of the condition of the system, (3) analical software tools that assist in reasoning about the condition, (4) sharing of information via network communication hardware and software, and (5) software tools that aid in making decisions to remedy unacceptable conditions or improve performance.

Smith, Harvey↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗