Search NASA⌕ Search

SEARCH · Search NASA

Results for “Autonomous Mitigation”

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

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

At least 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Crew Scheduling Performance

As NASA considers long-duration exploration missions (LDEMs), it is envisioned that crew will behave more autonomously as compared to low-Earth orbit missions. The necessary shift of Ops Planners’ complete management of scheduling and planning to provide flexibility for crew to manage their own schedule in real-time requires significant research and investigation in evaluation of concepts of operations, of software tools to support tasks, and of crew performance to complete scheduling tasks. Our research objective is to characterize the human performance envelope for the task of planning and scheduling (crew self-scheduling), develop countermeasures to mitigate adverse performance effects due to plan complexity, and inform performance standards and guidelines based on research results. In our efforts to understand and characterize scheduling performance of crew members, we have conducted subject matter expert interviews to obtain feedback on scheduling plan complexity drivers and plan goodness. Following the pilot study conducted last year, we designed a study and have begun remote human subject testing to evaluate non-expert human performance, workload, and situational awareness for the task of planning and scheduling. This study investigates the effects of the number and type of constraints on human performance, and the differences in scheduling metrics between scheduling and rescheduling tasks. Subject testing is currently in progress, and we aim to collect data from approximately thirty subjects. We will summarize the methods used and impacts of the number and type of scheduling constraints. We will also present lessons learned as well as relevant results of the study.

crew scheduling↗
NASA NTRSDate not supplied

From Simulation to Reality With Random Noise

The challenging environment of autonomous vehicle (AV) navigation necessitates certain functions be performed by deep neural networks. Optimizing these models involves collecting vast quantities of domain-specific training data and ensuring that the dataset is representative of expected conditions. High-fidelity simulation plays a vital role in making this process feasible, allowing a wide range of scenarios to be explored at low cost. However, learning from simulation introduces subtle biases into models, which can degrade real-world performance in unpredictable ways. This effect can be mitigated with learning schemes specialized to bridge distributional shifts (transfer learning). Given the complex nature of these methods, the underlying models, and their environments, meaningfully evaluating performance is notstraight forward. Many unrelated factors can effect an improvement in generalization accuracy, but a full ablation analysis is often difficult. To tease out signal from noise, it is necessary to understand how transfer learning performance is affected by noise itself. The goals of this paper are (i) to establish a domain randomization baseline for a simple classification transfer learning task and (ii) to validate the RRAV testbed as a platform for further research in sim-to-real learning. We generate imagery from a simulation of NASA Ames Research Center and train a small convolutional neural network (ConvNet) to classify position relative to a centerline. Further models are trained with different types of noise progressively added to the data. The models are deployed aboard the on-site test vehicle to test real-world performance. In our experiments, we find that such naive domain randomization raises sim-to-real accuracy from 64% to 79%, while training directly on real data yields an 89% accuracy ceiling. These results suggest that the isolated mechanism of domain randomization can significantly improve generalization.

simulation↗
NASA NTRS2002

REE radiation fault model: a tool for organizing and communication radiation test data and construction COTS based spacebourne computing systems

The growth in data rates of instruments on future NASA spacecraft continues to outstrip the improvement in communications bandwidth and processing capabilities of radiation-hardened computers. Sophisticated autonomous operations strategies will further increase the processing workload. Given the reductions in spacecraft size and available power, standard radiation hardened computing systems alone will not be able to address the requirements of future missions. The REE project was intended to overcome this obstacle by developing a COTS- based supercomputer suitable for use as a science and autonomy data processor in most space environments. This development required a detailed knowledge of system behavior in the presence of Single Event Effect (SEE) induced faults so that mitigation strategies could be designed to recover system level reliability while maintaining the COTS throughput advantage. The REE project has developed a suite of tools and a methodology for predicting SEU induced transient fault rates in a range of natural space environments from ground-based radiation testing of component parts. In this paper we provide an overview of this methodology and tool set with a concentration on the radiation fault model and its use in the REE system development methodology. Using test data reported elsewhere in this and other conferences, we predict upset rates for a particular COTS single board computer configuration in several space environments.

Radiation Effects Modeling COTS computers REE SEU ↗
NASA NTRSDate not supplied

Large Vehicle Lunar Landing Surface Interaction and In-Situ Resource Based Risk Mitigation: Landing & Launch Pads

A key capability required for the exploration of planetary bodies is the ability to land on the surface. Previous work performed by NASA and other institutions has primarily focused on landing small spacecraft on planetary surfaces and the associated small-to-medium thrusters required for the soft landing. In the case of human exploration—particularly the establishment of long duration exploration and habitation outposts—the ability to land large landers, such as the SpaceX Starship, is necessary. These larger landing systems require the use of more powerful engines, with higher engine exhaust temperatures and higher landing loads. Understanding the excavation of material by the engines, as well as the potential for the landing legs to sink into the subsurface, is key in ensuring reliable and safe landings. A further improvement in landing reliability can be achieved by constructing landing / launch pads, especially with in-situ resources. Some material excavation by the plume is inevitable, leaving at least a portion of the surface scoured and uneven under the lander and ejecting regolith particles and rocks at very high velocities. One possible solution would be to robotically build landing / launch pads (ideally autonomously) at the destination using in-situ materials. In this case, the first one or few landers will need to land on unimproved surfaces at higher risk; however, they would bring the required equipment to build the landing pads with mostly local resources, thus increasing the reliability of safe landing for subsequent larger landers. A number of methods to build in-situ landing and launch pads have already been developed. These methods include no, or some, addition of required binder additives to the local regolith material, different processing approaches and result in varying landing pad strengths. A sub-scale rocket engine plume, was used to simulate some of the conditions of a landing on the Moon to assess the effectiveness of various materials for an in-situ built landing pad, The GO2/GCH4rocket engine fired on a 1m2area coupons of representative pad materials. The results will allow continued development towards materials that satisfy the landing pad properties required for the effective risk reduction and increased reliability for landing people and equipment on the lunar surface. This work contained two parts: (1) computer modeling of a large rocket engine plume interacting with regolith on the Moon, using the Granular Gas Flow Solver (GGFS) provided by CFD Research Corporation as well as other computational fluid dynamics codes (CFD) such as Loci/CHEM. (2) Developing landing/launch pad materials that could be used for in-situ construction on the lunar surface in the future, to mitigate the calculated effects of a large vehicle rocket engine landing and launching on the Moon.

Lunar↗
NASA NTRSDate not supplied

Large Vehicle Lunar Landing Surface Interaction and In-Situ Resource Based Risk Mitigation: Landing & Launch Pads

A key capability required for the exploration of planetary bodies is the ability to land on the surface. Previous work performed by NASA and other institutions has primarily focused on landing small spacecraft on planetary surfaces and the associated small-to-medium thrusters required for the soft landing. In the case of human exploration—particularly the establishment of long duration exploration and habitation outposts—the ability to land large landers, such as the SpaceX Starship, is necessary. These larger landing systems require the use of more powerful engines, with higher engine exhaust temperatures and higher landing loads. Understanding the excavation of material by the engines, as well as the potential for the landing legs to sink into the subsurface, is key in ensuring reliable and safe landings. A further improvement in landing reliability can be achieved by constructing landing / launch pads, especially with in-situ resources. Some material excavation by the plume is inevitable, leaving at least a portion of the surface scoured and uneven under the lander and ejecting regolith particles and rocks at very high velocities. One possible solution would be to robotically build landing / launch pads (ideally autonomously) at the destination using in-situ materials. In this case, the first one or few landers will need to land on unimproved surfaces at higher risk; however, they would bring the required equipment to build the landing pads with mostly local resources, thus increasing the reliability of safe landing for subsequent larger landers. A number of methods to build in-situ landing and launch pads have already been developed. These methods include no or some addition of required binder additives to the local regolith material, different processing approaches and result in varying landing pad strengths. A sub-scale rocket engine plume, was used to simulate some of the conditions of a landing on the Moon to assess the effectiveness of various materials for an in-situ built landing pad, The GO2/GCH4 rocket engine fired on 1m2 area coupons of representative pad materials. The results will allow continued development towards materials that satisfy the landing pad properties required for the effective risk reduction and increased reliability for landing people and equipment on the lunar surface. This work contained two parts: (1) computer modeling of a large rocket engine plume interacting with regolith on the Moon, using the Granular Gas Flow Solver (GGFS) provided by CFD Research Corporation as well as other computational fluid dynamics codes (CFD) such as Loci/CHEM. (2) Developing landing/launch pad materials that could be used for in-situ construction on the lunar surface in the future, to mitigate the calculated effects of a large vehicle rocket engine landing and launching on the Moon. The resulting computed values of plume impingement surface temperature, stagnation pressure, gas velocity, shear stress and heat flux were then matched as closely as possible in the Earth’s atmosphere in a sub-scale rocket engine GO2/CH4 test which was provided by Masten Space Systems in Mojave, California. The rocket engine was mounted on a test stand with vertical translation capabilities so that the landing operations of a lander could be simulated (Figure 1).The pad materials test coupons were placed at the surface of a large bin containing simulated lunar basalt regolith and subjected to a test firing as shown in Figure 2. The results of this testing will be presented with related findings, analysis and discussion.

Plume Surface Interaction↗
NASA NTRS1992

Shuttle-food consumption, body composition and body weight in women

An experiment is conducted to determine whether the NASA Space Shuttle food system can provide the food and fluid required to mitigate weight loss and physical decomposition in 12 female subjects for 28 days. Subjects receive only foods from the Space Shuttle system for four weeks within an 11-wk monitoring period. Dual-energy X-ray absorptiometry is employed throughout the trial period to study lean body mass, percent body fat, and energy-intake levels with attention given to differences the experimental diet and the subjects' typical diet. Percent body fat is found to change significantly with losses of less than 0.05 percent, whereas energy intake based on autonomous diet choices by the participants does not vary significantly. Lean body mass remains unchanged throughout the study in which the subjects receive a relatively low-fat and low-protein menu. The 100 items on the space shuttle list of approved food items are shown to provide a palatable dietary framework for maintaining the health of female astronauts.

Lane, Helen W.↗
NASA NTRS2006

Fault Management Techniques in Human Spaceflight Operations

This paper discusses human spaceflight fault management operations. Fault detection and response capabilities available in current US human spaceflight programs Space Shuttle and International Space Station are described while emphasizing system design impacts on operational techniques and constraints. Preflight and inflight processes along with products used to anticipate, mitigate and respond to failures are introduced. Examples of operational products used to support failure responses are presented. Possible improvements in the state of the art, as well as prioritization and success criteria for their implementation are proposed. This paper describes how the architecture of a command and control system impacts operations in areas such as the required fault response times, automated vs. manual fault responses, use of workarounds, etc. The architecture includes the use of redundancy at the system and software function level, software capabilities, use of intelligent or autonomous systems, number and severity of software defects, etc. This in turn drives which Caution and Warning (C&W) events should be annunciated, C&W event classification, operator display designs, crew training, flight control team training, and procedure development. Other factors impacting operations are the complexity of a system, skills needed to understand and operate a system, and the use of commonality vs. optimized solutions for software and responses. Fault detection, annunciation, safing responses, and recovery capabilities are explored using real examples to uncover underlying philosophies and constraints. These factors directly impact operations in that the crew and flight control team need to understand what happened, why it happened, what the system is doing, and what, if any, corrective actions they need to perform. If a fault results in multiple C&W events, or if several faults occur simultaneously, the root cause(s) of the fault(s), as well as their vehicle-wide impacts, must be determined in order to maintain situational awareness. This allows both automated and manual recovery operations to focus on the real cause of the fault(s). An appropriate balance must be struck between correcting the root cause failure and addressing the impacts of that fault on other vehicle components. Lastly, this paper presents a strategy for using lessons learned to improve the software, displays, and procedures in addition to determining what is a candidate for automation. Enabling technologies and techniques are identified to promote system evolution from one that requires manual fault responses to one that uses automation and autonomy where they are most effective. These considerations include the value in correcting software defects in a timely manner, automation of repetitive tasks, making time critical responses autonomous, etc. The paper recommends the appropriate use of intelligent systems to determine the root causes of faults and correctly identify separate unrelated faults.

O'Hagan, Brian↗
NASA NTRS2015

Technology Advancement for Active Remote Sensing of Carbon Dioxide from Space Using the ASCENDS CarbonHawk Experiment Simulator: First Results

The ASCENDS CarbonHawk Experiment Simulator (ACES) is a newly developed lidar developed at NASA Langley Research Center and funded by NASA's Earth Science Technology Office (ESTO) Instrument Incubator Program (IIP) that seeks to advance technologies critical to measuring atmospheric column carbon dioxide (CO2) mixing ratios in support of the NASA Active Sensing of CO2 Emissions over Nights, Days, and Seasons (ASCENDS) mission. The technology advancements targeted include: (1) increasing the power-aperture product to approach ASCENDS mission requirements by implementing multi-aperture telescopes and multiple co-aligned laser transmitters; (2) incorporating high-efficiency, high-power Erbium-Doped Fiber Amplifiers (EDFAs); (3) developing and incorporating a high-bandwidth, low-noise HgCdTe detector and transimpedence amplifier (TIA) subsystem capable of long-duration autonomous operation on Global Hawk aircraft, and (4) advancing algorithms for cloud and aerosol discrimination. The ACES instrument architecture is being developed for operation on high-altitude aircraft and will be directly scalable to meet the ASCENDS mission requirements. These technologies are critical towards developing not only spaceborne instruments but also their airborne simulators, with lower platform requirements for size, mass, and power, and with improved instrument performance for the ASCENDS mission. ACES transmits five laser beams: three from commercial EDFAs operating near 1.57 microns, and two from the Exelis oxygen (O2) Raman fiber laser amplifier system operating near 1.26 microns. The three EDFAs are capable of transmitting up to 10 watts average optical output power each and are seeded by compact, low noise, stable, narrow-linewidth laser sources stabilized with respect to a CO2 absorption line using a multi-pass gas absorption cell. The Integrated-Path Differential Absorption (IPDA) lidar approach is used at both wavelengths to independently measure the CO2 and O2 column number densities and retrieve the average column CO2 mixing ratio. The ACES receiver uses three fiber-coupled 17.8-cm diameter athermal telescopes. The transmitter assembly consists of five fiber-coupled laser collimators and an associated Risley prism pair for each laser to co-align the outgoing laser beams and to align them with the telescope field of view. The backscattered return signals collected by the three telescopes are combined in a fiber bundle and sent to a single low noise detector. The detector/TIA development has improved the existing detector subsystem by increasing its bandwidth to 4.7 MHz from 500 kHz and increasing the duration of autonomous, service-free operation periods from 4 hours to >24 hours. The new detector subsystem enables the utilization of higher laser modulation rates, which provides greater flexibility for implementing advanced thin-cloud discrimination algorithms as well as improving range-determination resolution and error reduction. The cloud/aerosol discrimination algorithm development by Langley and Exelis features a new suite of algorithms for the minimization/elimination of bias errors in the return signal induced by the presence of intervening thin clouds. Multiple laser modulation schemes are being tested in an effort to significantly mitigate the effects of thin clouds on the retrieved CO2 column amounts. Full instrument development concluded in the spring of 2014. After ground range tests of the instrument, ACES successfully completed six test flights on the Langley Hu-25 aircraft in July, 2014, and recorded data at multiple altitudes over land and ocean surfaces with and without intervening clouds. Preliminary results from these test flights will be presented in this paper.

Obland, Michael D.↗
NASA NTRSDate not supplied

NASA Lunar Surface Innovation Initiative: Ensuring a Cohesive, Executable Strategy for Technology Development

Establishing a sustainable human presence on the Moon allows NASA to develop and test new approaches, technologies, and systems that will enable us to function in other, more challenging environments. The Lunar Surface Innovation Initiative (LSII) was established in 2019 and has evolved into a key agency asset to spur technology development and provide risk reduction for lunar surface system development and flight demonstrations. LSII coordinates activities implemented through a combination of in-house activities, competitive programs, and public-private partnerships to create transformative technologies needed for lunar surface exploration. This paper will outline the LSII model used to develop a technology pipeline that will retire the primary technology hurdles in six capability areas. In-situ resource utilization technologies for collecting, processing, storing, and using material found or manufactured on the Moon. Surface power technologies that provide the capability for sustainable, continuous power throughout the day and night for lunar missions. Dust mitigation strategies that diminish lunar dust hazards on lunar surface systems such as cameras, solar panels, space suits, habitats, and instrumentation. Extreme environments technologies that enable systems to operate throughout the full range of lunar surface conditions, including lunar noon (up to 150 at the equator), night (down to - 180 at the equator), multiple day/night cycles, and in permanently shadowed regions (down to -250). Extreme access technologies that enable humans or robotic systems to access, navigate, and explore previously inaccessible lunar surface or subsurface areas. Excavation and construction technologies that will allow affordable, autonomous manufacturing or construction. We outline key results, including milestones and achievements related to the capability areas and outcomes from partnerships with the commercial sector. A key tenet of the LSII is the Lunar Surface Innovation Consortium (LSIC), a collaboration across industry, academia, and government to successfully develop the transformative capabilities for lunar surface exploration. LSIC provides a forum for NASA to communicate technological requirements, needs, and opportunities and for the community to share existing capabilities and identify critical gaps with NASA. By working side by side with commercial enterprises and our international partners, NASA is able to combine the knowledge and expertise needed to explore the lunar surface and make technical advances that will feed technological and economic growth. Since its inception, LSII has engaged over 600 organizations across the United States and 46 countries to shape the technologies and systems needed to explore the lunar surface and stimulate a lunar surface economy.

lunar, lunar surface, technology development, ISRU↗
NASA NTRSDate not supplied

NASA Lunar Surface Innovation Initiative: Ensuring a Cohesive, Executable Strategy for Technology

Establishing a sustainable human presence on the Moon allows NASA to develop and test new approaches, technologies, and systems that will enable us to function in other, more challenging environments. The Lunar Surface Innovation Initiative (LSII) was established in 2019 and has evolved into a key agency asset to spur technology development and provide risk reduction for lunar surface system development and flight demonstrations. LSII coordinates activities implemented through a combination of in-house activities, competitive programs, and public-private partnerships to create transformative technologies needed for lunar surface exploration. This paper will outline the LSII model used to develop a technology pipeline that will retire the primary technology hurdles in six capability areas. In-situ resource utilization technologies for collecting, processing, storing, and using material found or manufactured on the Moon. Surface power technologies that provide the capability for sustainable, continuous power throughout the day and night for lunar missions. Dust mitigation strategies that diminish lunar dust hazards on lunar surface systems such as cameras, solar panels, space suits, habitats, and instrumentation. Extreme environments technologies that enable systems to operate throughout the full range of lunar surface conditions, including lunar noon (up to 150 at the equator), night (down to - 180 at the equator), multiple day/night cycles, and in permanently shadowed regions (down to -250). Extreme access technologies that enable humans or robotic systems to access, navigate, and explore previously inaccessible lunar surface or subsurface areas. Excavation and construction technologies that will allow affordable, autonomous manufacturing or construction. We outline key results, including milestones and achievements related to the capability areas and outcomes from partnerships with the commercial sector. A key tenet of the LSII is the Lunar Surface Innovation Consortium (LSIC), a collaboration across industry, academia, and government to successfully develop the transformative capabilities for lunar surface exploration. LSIC provides a forum for NASA to communicate technological requirements, needs, and opportunities and for the community to share existing capabilities and identify critical gaps with NASA. By working side by side with commercial enterprises and our international partners, NASA is able to combine the knowledge and expertise needed to explore the lunar surface and make technical advances that will feed technological and economic growth. Since its inception, LSII has engaged over 600 organizations across the United States and 46 countries to shape the technologies and systems needed to explore the lunar surface and stimulate a lunar surface economy.

Lunar↗
NASA NTRSDate not supplied

Communication Network Awareness Machine System Phase I Development: The Intelligent Party-Line Schema

As NextGen continues toward the full implementation of a Net-Centric Architecture (N-CA)it will inherently provide a continuous increase to the Three-Vs components (Volume, Velocity, and Variety) of big data . This will create an insurmountable environment for direct-action aviation personnel (DAAP)as the DAAP’s natural abilities to manage and process data into actionable information will be overmatched by the Three-Vs. Therefore, conducting operations within a N-CA requires that new tools and applications be researched and developed to aid the DAAP’s ability to understand and manage data, mitigate non-normals, create contingency plans and actions. This paper will describe a research area at NASA Langley Research Center known as the Intelligent Party-Line (IPL).

Intelligent Party-Line↗
NASA NTRS2010

Terrain Hazard Detection and Avoidance During the Descent and Landing Phase of the Altair Mission

This paper describes some of the environmental challenges associated with landing a crewed or robotic vehicle at any certified location on the lunar surface (i.e. not a mountain peak, permanently dark crater floor or overly steep terrain), with a specific focus on how hazard detection technology may be incorporated to mitigate these challenges. For this discussion, the vehicle of interest is the Altair Lunar Lander, being the vehicle element of the NASA Constellation Program aimed at returning humans to the moon. Lunar environmental challenges for such global lunar access primarily involve terrain and lighting. These would include sizable rocks and slopes, which are more concentrated in highland areas; small craters, which are essentially everywhere independent of terrain type; and for polar regions, low-angle sunlight, which leaves significant terrain in shadow. To address these issues, as well as to provide for precision landing, the Autonomous Landing and Hazard Avoidance Technology (ALHAT) Project was charted by NASA Headquarters, and has since been making significant progress. The ALHAT team considered several sensors for real-time hazard detection, settling on the use of a Flash Lidar mounted to a high-speed gimbal, with computationally intense image processing and elevation interpretation software. The Altair Project has been working with the ALHAT team to understand the capabilities and limitations of their concept, and has incorporated much of the ALHAT hazard detection system into the Altair baseline design. This integration, along with open issues relating to computational performance, the need for system redundancy, and potential pilot interaction, will be explored further in this paper.

Strhan, Alan L.↗
NASA NTRS2009

Human Factors in Training

Future space missions will be significantly longer than current shuttle missions and new systems will be more complex than current systems. Increasing communication delays between crews and Earth-based support means that astronauts need to be prepared to handle the unexpected on their own. As crews become more autonomous, their potential span of control and required expertise must grow to match their autonomy. It is not possible to train for every eventuality ahead of time on the ground, or to maintain trained skills across long intervals of disuse. To adequately prepare NASA personnel for these challenges, new training approaches, methodologies, and tools are required. This research project aims at developing these training capabilities. By researching established training principles, examining future needs, and by using current practices in space flight training as test beds, both in Flight Controller and Crew Medical domains, this research project is mitigating program risks and generating templates and requirements to meet future training needs. Training efforts in Fiscal Year 08 (FY08) strongly focused on crew medical training, but also began exploring how Space Flight Resource Management training for Mission Operations Directorate (MOD) Flight Controllers could be integrated with systems training for optimal Mission Control Center (MCC) operations. The Training Task addresses Program risks that lie at the intersection of the following three risks identified by the Project: (1) Risk associated with poor task design (2) Risk of error due to inadequate information (3) Risk associated with reduced safety and efficiency due to poor human factors design

Barshi, Immanuel↗
NASA NTRS2010

Human Factors in Training

Future space missions will be significantly longer than current shuttle missions and new systems will be more complex than current systems. Increasing communication delays between crews and Earth-based support means that astronauts need to be prepared to handle the unexpected on their own. As crews become more autonomous, their potential span of control and required expertise must grow to match their autonomy. It is not possible to train for every eventuality ahead of time on the ground, or to maintain trained skills across long intervals of disuse. To adequately prepare NASA personnel for these challenges, new training approaches, methodologies, and tools are required. This research project aims at developing these training capabilities. By researching established training principles, examining future needs, and by using current practices in space flight training as test beds, both in Flight Controller and Crew Medical domains, this research project is mitigating program risks and generating templates and requirements to meet future training needs. Training efforts in Fiscal Year 09 (FY09) strongly focused on crew medical training, but also began exploring how Space Flight Resource Management training for Mission Operations Directorate (MOD) Flight Controllers could be integrated with systems training for optimal Mission Control Center (MCC) operations. The Training Task addresses Program risks that lie at the intersection of the following three risks identified by the Project: 1) Risk associated with poor task design; 2) Risk of error due to inadequate information; and 3) Risk associated with reduced safety and efficiency due to poor human factors design.

Barshi, Immanuel↗
NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to 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 International Space Station (ISS) 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 variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Data management↗
NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to 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 International Space Station (ISS) 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 variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support.To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Exploration medical system↗
NASA NTRS2020

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

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to 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.↗
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.↗