SEARCH · Search NASA

Results for “core flight system”

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

SourceResearch connectionFrom yearThrough year

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

At least 289 records · Page 16

All sources NASA NTRS DOE OSTI

NASA NTRS2018

NASA's Space Launch System Gains Momentum Toward Integration and Testing

NASA’s Space Launch System (SLS) (Fig. 1) entered a new phase in 2017, completing major structural manufacturing on the core stage and delivering for launch the first flight hardware of the world’s most capable launch vehicle. The program is now in a stage of hardware assembly, integration and testing in preparation for the first integrated flight of SLS and the Orion crew vehicle. SLS is critical to U.S. leadership in future human and robotic space exploration, including a presence on the Moon in preparation for missions deeper into space. This paper will elaborate on SLS accomplishments in 2017 and plans for progress in 2018.

Askins, Bruce R.↗

NASA NTRSDate not supplied

Impact of NASA’s Entry Systems Modeling Project on Planetary Mission Design

Planetary missions continue to grow larger and more complex. Furthermore, the current focus on human exploration of the Moon and Mars, as well as Mars Sample Return(MSR), place increas-ingly stringent requirements on the reliability of the entry, descent, and landing (EDL) system that ensures the safe delivery of payload or crew to their destination. Planetary EDL is an area in which mission designers are critically reliant on modeling and simulation to demonstrate the reliability of the system, as there are no ground facilities that are able to fully test these systems in a flight-relevant environment. NASA’s state-of-the-art modeling and simulation capability must continually evolve to meet the needs of the next generation of planetary EDL. To accomplish this aim, NASA’s Entry Systems Modeling (ESM) Project was formed in 2013and is funded bythe Space Technology Mission Directorate(STMD) and Science Mission Directorate (SMD). ESM is the Agency’s only cross-cutting effort for advancing entry systems modeling and simulation capabilities across a range of technical disciplines and Solar System destinations. ESM is a portfolio project covering a variety of mid-TRL research efforts within four core EDL-related areas of investment: (1) Thermal protection material modeling, (2) Shock layer kinetics and radiation, (3) Aerosciences, and (4) Guidance, navigation, and con-trol. The material modeling group creates detailed material response modelsof thermal protection systems (TPS)from the micro to macro scale, and at the fun-damental and engineering levels. Shock layer kinetics and radiation focuses on radiative heating of space-craft, quantum chemistry and benchmark experiments for validation.Aerosciences is a broad research area that impacts many aspects of entry systems, including parachutes, aerodynamics, and turbulent heating augmentation due to TPS roughness.The guidance, navigation,and control effort under ESM is expanding the capabilities of NASA’s main flight mechanics tool, POST2, for use on high-performance computing architectures and to generalize interoperability with external applications for more detailed end-to-end simula-tion.In addition, several focusedresearch topics have been approvedto augment ESM’s core portfolio. These include efforts for deep post-flight analysis of Mars 2020/MEDLI2 flight data; development ofTPS failure models; improvement of hypersonic wakeflow models; and a recently concluded effort to provide material response models for NuSil-coated PICA heat-shield material. This presentation will discuss each of these investment areas and demonstrate via real mission examples how advances to the state-of-the-art enabled by ESM are directly impacting the missions of today and tomorrow, including InSight, Mars 2020, Mars Sample Return, Orion, and Dragonfly.

Entry Systems Modeling↗

NASA NTRS2020

Space Launch System Mobile Launcher Modal Pretest Analysis

NASA is developing an expendable heavy lift launch vehicle capability, the Space Launch System, to support lunar and deep space exploration. To support this capability, an updated ground infrastructure is required including modifying an existing Mobile Launcher system. The Mobile Launcher is a very large heavy beam/truss steel structure designed to support the Space Launch System during its buildup and integration in the Vehicle Assembly Building, transportation from the Vehicle Assembly Building out to the launch pad, and provides the launch platform at the launch pad. The previous Saturn/Apollo and Space Shuttle programs had integrated vehicle ground vibration tests of their integrated launch vehicles performed with simulated free-free boundary conditions to experimentally anchor and validate structural and flight controls analysis models. For the Space Launch System program, the Mobile Launcher will be used as the modal test fixture for the ground vibration test of the first Space Launch System flight vehicle, Exploration Mission ? 1( now referred to as Artemis 1), programmatically referred to as the Integrated vehicle modal test. The Integrated vehicle modal test of the Exploration Mission - 1 integrated launch vehicle will have its core and second stages unfueled while mounted to the ML while inside the Vehicle Assembly Building, which is currently scheduled for the late spring or early summer of 2020. The Space Launch System program has implemented a building block approach for dynamic model validation. The modal test of the Mobile Launcher is an important part of this building block approach in supporting the integrated vehicle modal test since the Mobile Launcher will serve as a structurally dynamic test fixture whose modes will couple with the modes of the Exploration Mission ? 1 test vehicle. The Mobile Launcher modal test will further support understanding the structural dynamics of the Mobile Launcher and SLS during rollout to the launch pad, which will play a key role in better understanding and prediction of the rollout forces acting on the launch vehicle. The Mobile Launcher modal test is currently scheduled for the summer of 2019. Due to a very tight modal testing schedule, this Mobile Launcher modal pretest analysis has been performed to ensure there is a high likelihood of being able to successfully complete the modal test (i.e. identify the primary target modes) using the planned instrumentation, shakers, and excitation types. This paper will discuss this Mobile Launcher modal pretest analysis and the unique challenges faced due to the Mobile Launcher's size and weight, which are typically not faced when modal testing aerospace structures.

Akers, James C.↗

NASA NTRS2004

Assessment of Technology Readiness Level of a Carbon Dioxide Reduction Assembly (CRA) for use on International Space Station

When technologies are traded for incorporation into vehicle systems to support a specific mission scenario, they are often assessed in terms of Technology Readiness Level (TRL). TRL is based on three major categories of Core Technology Components, Ancillary Hardware and System Maturity, and Control and Control Integration. This paper describes the Technology Readiness Level assessment of the Carbon Dioxide Reduction Assembly (CRA) for use on the International Space Station. A team comprising of the NASA Johnson Space Center, Marshall Space Flight Center, Southwest Research Institute and Hamilton Sundstrand Space Systems International have been working on various aspects of the CRA to bring its TRL from 4/5 up to 6. This paper describes the work currently being done in the three major categories. Specific details are given on technology development of the Core Technology Components including the reactor, phase separator and CO2 compressor.

Murdoch, Karen↗

NASA NTRS2023

Development of Two High-Energy Bus ‘Cores’ for Rapid Support of Low-TRL and Educational Payloads: A Software-Configured EPS Combined with Flexible C&DH

For several years the TechEdSat flight series (TES-n), developed by the Nano Orbital Workshop (NOW) group at NASA Ames, has relied upon an in-house developed unit to serve both EPS (Electrical Power System) and C&DH (Command and Data Handling) roles along with low data-rate telemetry functions, i.e., serving as the ‘core’ of the spacecraft bus. This ‘core’ has a considerable task given the rapid cadence of the TES program and the typically low-TRL of payloads; configurability and compatibility are key to prevent mission-specific hardware. However, at only 15 watts the current core has become insufficient to support the program’s growing missions and increasingly demanding payloads. To this end, the NOW program is developing new cores to support two TES mission classes: a single-PCB ‘MiniCore’ designed to support 80-watt missions 6U or smaller in LEO, and a three-PCB, radiation-tolerant ‘StackCore’ designed to support 6U and larger missions over 500 watts in LEO and beyond. The ‘MiniCore’ design consists of three main segments: a processor-agnostic C&DH, a software-configured EPS, and a backup low data-rate radio. The design philosophy was to enable rapid-manufacture in a turbulent supply chain, hence the design consists of COTS parts with a focus on those able to be drop-in replaced with radiation-tolerant versions when demanded by the mission. As a single PC-104 sized circuit board, power density and ease of integration also dominated design, demanding the use of modern features such as single-point USB-C for easy charging and monitoring of the spacecraft on the ground. The ‘MiniCore’ can support 80 watts of load, 140 watt-hours of storage, and over 20 watts of optimized solar generation with extensive power monitoring throughout. The ‘MiniCore’ supports one battery pack, six solar-panels, six loads, five actuators, Iridium SBD, and an internal 802.15.4 network. Additionally, the processor-agnostic design can accept any PJRC Teensy 3.x or Adafruit Feather microcontroller unit to enable processor scaling with mission requirements or environment. It is expected a development unit of this design will be completed before conference. The ‘StackCore’ design consists of three stacked PC-104 sized circuit boards: one dedicated to power generation and storage, one dedicated to power distribution, and one dedicated to C&DH tasks. This delineation is necessary to support the transition from highly integrated ICs to discrete analog circuitry, enabling a primarily analog control power system able to operate without software in a radiation environment with finer monitoring compared to the ‘MiniCore’ design. The planned base architecture supports over 500 watts of load, 250 watt-hours of storage, and over 80 watts of optimized solar generation. The power distribution board allows for the use of daughter cards hosting custom converters or interfaces for payloads, in addition to the software-configured supplies used on the ‘MiniCore’. This core stack will be managed by a Vorago ARM M4 microcontroller and support the same wireless communications as the ‘MiniCore’, with optional integration of a NOW S-band radio and attitude determination sensors for ‘black box’ functionality. It is expected the prototype will still be in development during conference.

Spacecraft↗

NASA NTRSDate not supplied

Development of Two High-Energy Bus ‘Cores’ for Rapid Support of Low-TRL and Educational Payloads: A Software-Configured EPS Combined with Flexible C&DH

Spacecraft↗

NASA NTRS2015

Software Innovation in a Mission Critical Environment

Operating in mission-critical environments requires trusted solutions, and the preference for "tried and true" approaches presents a potential barrier to infusing innovation into mission-critical systems. This presentation explores opportunities to overcome this barrier in the software domain. It outlines specific areas of innovation in software development achieved by the Johnson Space Center (JSC) Engineering Directorate in support of NASA's major human spaceflight programs, including International Space Station, Multi-Purpose Crew Vehicle (Orion), and Commercial Crew Programs. Software engineering teams at JSC work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements for genuinely mission critical applications. The innovations described, including the use of NASA Core Flight Software and its associated software tool chain, can lead to software that is more affordable, more reliable, better modelled, more flexible, more easily maintained, better tested, and enabling of automation.

Fredrickson, Steven↗

NASA NTRS1996

Tethered Satellite System (TSS-1R)-Post Flight (STS-75) Engineering Performance Report

The first mission of the Tethered Satellite deployer was flown onboard Atlantis in 1992 during the Space Transportation System (STS) flight STS-46. Due to a mechanical interference with the level wind mechanism the satellite was only Deployed to 256 m rather than the planned 20,000 m. Other problems were also experienced during the STS-46 flight and several modifications were made to the Deployer and Satellite. STS-75 was a reflight of the Tethered Satellite System 1 (TSS-1) designated as Tethered Satellite System 1 Reflight (TSS-1 R) onboard Columbia. As on STS-46, the TSS payload consisted of the Deployer, the Satellite, 3 cargo bay mounted experiments: Shuttle Electrodynamic Tether System (SETS), Shuttle Potential and Return Electron Experiment (SPREE), Deployer Core Equipment (DCORE) 4 Satellite mounted experiments: Research on Electrodynamics Tether Effects (RETE), Research on Orbital Plasma Electrodynamics (ROPE), Satellite Core Instruments (SCORE), Tether Magnetic Field Experiment (TEMAG) and an aft flight deck camera: Tether Optical Phenomena Experiment (TOP). Following successful pre-launch, launch and pre-deployment orbital operations, the Deployer deployed the Tethered Satellite to 19,695 m at which point the tether broke within the Satellite Deployment Boom (SDB). The planned length for On-Station I (OST1) was 20,700 m The Satellite flew away from the Orbiter with the tether attached. The satellite was "safed" and placed in a limited power mode via the RF link. The Satellite was contacted periodically during overflights of ground stations. Cargo bay science activities continued for the period of time allocated to TSS-1 R operations.

Lavoie, Anthony R.↗

DOE OSTI2020

The Kokkos Ecosystem [Brief]

In 2016/2017, the field of High-Performance Computing (HPC) entered a new era driven by fundamental physics challenges to produce ever more energy and cost-efficient processors. Since the convergence on the Message-Passing Interface (MPI) standard in the mid-1990s, application developers enjoyed a seemingly static view of the underlying machine — that of a distributed collection of homogeneous nodes executing in collaboration. However, after almost two decades of dominance, the sole use of MPI to derive parallelism acted as a limiter to improved future performance. While MPI is widely expected to continue to function as the basic mechanism for communication between compute nodes for the immediate future, additional parallelism is required on the computing node itself if high performance and efficiency goals are to be realized. When reviewing the architectures of the top HPC systems today, the change in paradigm is clear: the compute nodes of the leading machines in the world are either powered by many-core chips with a few dozen cores each, or use heterogeneous designs, where traditional CPUs marshal work to massively parallel compute accelerators which has as many as 200,000 processing threads in flight simultaneously. Complicating matters further for application developers, each processor vendor has its own preferred way of writing code for their architecture.The Kokkos EcoSystem was released by Sandia in 2017 to address this new era in HPC system design by providing a vendor independent performance portable programming system for scientific, engineering, and mathematical software applications written in the C++ programming language. Using Kokkos, application developers can be more productive because they will not have to create and maintain separate versions of their software for each architecture, nor will they have to be experts in each architecture's peculiar requirements. Instead, they will have a single method of programming for the diverse set of modern HPC architectures. While Kokkos started in 2011 as a programming model only, it soon became clear that complex applications needed more. It is also critical to have a portable mathematical functions and developers need tools to debug their applications, gain insight into the performance characteristics of their codes and tune algorithm performance parameters through automated processes. The Kokkos EcoSystem addresses those needs through its three main components: the Kokkos Core programming model, the Kokkos Kernels math library, and the Kokkos Tools project.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1993

Space Station Freedom (SSF) Data Management System (DMS) performance model data base

The purpose of this document was originally to be a working document summarizing Space Station Freedom (SSF) Data Management System (DMS) hardware and software design, configuration, performance and estimated loading data from a myriad of source documents such that the parameters provided could be used to build a dynamic performance model of the DMS. The document is published at this time as a close-out of the DMS performance modeling effort resulting from the Clinton Administration mandated Space Station Redesign. The DMS as documented in this report is no longer a part of the redesigned Space Station. The performance modeling effort was a joint undertaking between the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) Flight Data Systems Division (FDSD) and the NASA Ames Research Center (ARC) Spacecraft Data Systems Research Branch. The scope of this document is limited to the DMS core network through the Man Tended Configuration (MTC) as it existed prior to the 1993 Clinton Administration mandated Space Station Redesign. Data is provided for the Standard Data Processors (SDP's), Multiplexer/Demultiplexers (MDM's) and Mass Storage Units (MSU's). Planned future releases would have added the additional hardware and software descriptions needed to describe the complete DMS. Performance and loading data through the Permanent Manned Configuration (PMC) was to have been included as it became available. No future releases of this document are presently planned pending completion of the present Space Station Redesign activities and task reassessment.

Stovall, John R.↗

NASA NTRS2019

Assembling and Testing NASA’s Space Launch System for First Flight

NASA is planning its next step toward human expansion into the solar system. The Space Launch System (SLS) (Figure 1) is a critical enabling component of that expansion. SLS payloads for its early missions include the Orion crew vehicle and components for Gateway, a lunar outpost orbiting the Moon that will facilitate research, technology and partnerships for eventual Mars missions. All major core stage hardware for test and flight completed structural manufacturing in 2018. The major components for the first flight vehicle are complete or approaching completion of internal equipment installation. The core stage forward join operation is also complete. The 10 booster segments needed for first flight have been cast and are ready to ship to NASA’s Kennedy Space Center (KSC) for mating and stacking. The four RS-25 core stage engines completed processing at NASA’s Stennis Space Center (SSC) and are ready for core stage integration. The Orion Stage Adapter (OSA) joined the Interim Cryogenic Propulsion Stage (ICPS) at KSC to await the rest of SLS flight hardware. Production and preparation of hardware for the second mission is also underway. Looking ahead to a busy 2019, liquid oxygen (LOX) tank, liquid hydrogen (LH2) tank and intertank structural testing will take place. This paper will discuss the current and planned status of SLS development in context of NASA’s overall exploration plans.

Askin, Bruce R.↗

NASA NTRSDate not supplied

NASA Space Launch System Completes Key Hot Fire Test and Begins Vehicle Integration

The Moon is again in reach. NASA and its commercial and international partners are on the way back. The team is working to land the first woman and the first person of color on the planetary body. NASA and its partners made significant progress towards that goal in the latter half of 2020 and the first half of 2021, including on the agency’s Space Launch System (SLS) rocket – a key part of the Artemis program. The SLS core stage for the Artemis I mission – the first launch of SLS and an uncrewed Orion capsule – completed the Green Run test series and was successfully mated with the SLS twin solid rocket boosters on the mobile launcher at Kennedy Space Center (KSC). All of the major systems for Artemis I are at KSC for assembly, integration, and launch, targeted for late 2021. Work also continued on SLS hardware for Artemis II, which will be the first flight of crew on Orion and SLS. Work progressed on core stage components, booster segments, and other hardware for Artemis III and future missions. This paper will detail the progress made.

John Honeycutt↗

NASA NTRS1987

NASA Systems Autonomy Demonstration Program - A step toward Space Station automation

This paper addresses a multiyear NASA program, the Systems Autonomy Demonstration Program (SADP), whose main objectives include the development, integration, and demonstration of automation technology in Space Station flight and ground support systems. The role of automation in the Space Station is reviewed, and the main players in SADP and their roles are described. The core research and technology being promoted by SADP are discussed, and a planned 1988 milestone demonstration of the automated monitoring, operation, and control of a complete mission operations subsystem is addressed.

Starks, S. A.↗

NASA NTRS1991

NERVA upgrade: Non-nuclear components

The design of engine based upon the original accomplishmentns of the ROVER/NERVA program (but with the use of advanced technologies) is discussed. Some hypothetical requirements for a typical manned Mars mission are outlined. The following subject areas are covered: typical mission NTR propulsion requirements; performance of NTR operating with high pressure hydrogen; NTR expander cycles; ROVER/NERVA core reactor; Mars propulsion 100 K NTR thrust chamber thermal design parameters; 100 K NTR nozzle assembly; NTR integrated pneumatic-fluidics control system; and 100 K flight thrust module/feed system module assembly.

Gunn, Stanley↗

NASA NTRS1996

A preliminary study of a wake vortex encounter hazard boundary for a B737-100 airplane

A preliminary batch simulation study was conducted to define the wake decay required for a Boeing 737-100 airplane to safely encounter a Boeing 727 wake and land. The baseline six-degree-of-freedom B737 simulation was modified to include a wake model and the strip-theory calculation of the vortex-induced forces and moments. The guidance and control inputs for the airplane were provided by an autoland system. The wake strength and encounter altitude were varied to establish a safe encounter boundary. The wake was positioned such that the desired flight path traversed the core of the port Vortex. Various safe landing criteria were evaluated for defining a safe encounter boundary. A sensitivity study was also conducted to assess the effects of encounter model inaccuracies.

Reimer, Heidi M.↗

NASA NTRS2012

Use of CCSDS Packets Over SpaceWire to Control Hardware

For the Lunar Reconnaissance Orbiter, the Command and Data Handling subsystem consisted of several electronic hardware assemblies that were connected with SpaceWire serial links. Electronic hardware would be commanded/controlled and telemetry data was obtained using the SpaceWire links. Prior art focused on parallel data buses and other types of serial buses, which were not compatible with the SpaceWire and the core flight executive (CFE) software bus. This innovation applies to anything that utilizes both SpaceWire networks and the CFE software. The CCSDS (Consultative Committee for Space Data Systems) packet contains predetermined values in its payload fields that electronic hardware attached at the terminus of the SpaceWire node would decode, interpret, and execute. The hardware s interpretation of the packet data would enable the hardware to change its state/configuration (command) or generate status (telemetry). The primary purpose is to provide an interface that is compatible with the hardware and the CFE software bus. By specifying the format of the CCSDS packet, it is possible to specify how the resulting hardware is to be built (in terms of digital logic) that results in a hardware design that can be controlled by the CFE software bus in the final application

Haddad, Omar↗

NASA NTRS2018

Orion Optical Navigation Progress Toward Exploration: Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. It shares a history with the "method of lunar distances" that was used in the 18th century and gained some notoriety after its use by Captain James Cook during his 1768 Pacific voyage of the HMS Endeavor. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is being worked as a Government Furnished Equipment (GFE) project delivered as an application within the Core Flight Software of the Orion camera controller module. The mathematical formulation behind the initial ellipse fit in the image processing is detailed in Christian. The non-linear least squares refinement then follows the technique of Mortari as an estimation process of the planetary limb using the sigmoid function. The Orion optical navigation system uses a body fixed camera, a decision that was driven by mass and mechanism constraints. The general concept of operations involves a 2-hour pass once every 24 hours, with passes specifically placed before all maneuvers to supply accurate navigation information to guidance and targeting. The pass lengths are limited by thermal constraints on the vehicle since the OpNav attitude generally deviates from the thermally stable tail-to-sun attitude maintained during the rest of the orbit coast phase. Calibration is scheduled prior to every pass due to the unknown nature of thermal effects on the lens distortion and the mounting platform deformations between the camera and star trackers. The calibration technique is described in detail by Christian, et al. and simultaneously estimates the Brown-Conrady coefficients and the Star Tracker/Camera interlock angles. Accurate attitude information is provided by the star trackers during each pass. Figure 1 shows the various phases of lunar return navigation when the vehicle is in autonomous operation with lost ground communication. The midcourse maneuvers are placed to control the entry interface conditions to the desired corridor for safe landing. The general form of optical navigation on Orion is where still images of the Moon or Earth are processed to find the apparent angular diameter and centroid in the camera focal plane. This raw data is transformed into range and bearing angle measurements using planetary data and precise star tracker inertial attitude. The measurements are then sent to the main flight computer's Kalman filter to update the onboard state vector. The images are, of course, collected over an arc to converge the state and estimate velocity. The same basic technique was used by Apollo to satisfy loss-of-comm, but Apollo used manual crew sightings with a vehicle-integral sextant instead of autonomously processing optical imagery. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. In support of this, a hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. Figure 2 shows the rig, which the test team has dubbed OCILOT (Orion Camera In the Loop Optical Testbed). Analysis performed to date shows a delivery that satisfies an allowable entry corridor as shown in Figure 3.

Holt, Greg N.↗

NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for A Medical Data System for Exploration Missions

Minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions.In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗