Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission software”

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 991 records · Page 55
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

Minimum deltaV Burn Planning for the International Space Station Using a Hybrid Optimization Technique, Level 1

The International Space Station's (ISS) trajectory is coordinated and executed by the Trajectory Operations and Planning (TOPO) group at NASA's Johnson Space Center. TOPO group personnel routinely generate look-ahead trajectories for the ISS that incorporate translation burns needed to maintain its orbit over the next three to twelve months. The burns are modeled as in-plane, horizontal burns, and must meet operational trajectory constraints imposed by both NASA and the Russian Space Agency. In generating these trajectories, TOPO personnel must determine the number of burns to model, each burn's Time of Ignition (TIG), and magnitude (i.e. deltaV) that meet these constraints. The current process for targeting these burns is manually intensive, and does not take advantage of more modern techniques that can reduce the workload needed to find feasible burn solutions, i.e. solutions that simply meet the constraints, or provide optimal burn solutions that minimize the total DeltaV while simultaneously meeting the constraints. A two-level, hybrid optimization technique is proposed to find both feasible and globally optimal burn solutions for ISS trajectory planning. For optimal solutions, the technique breaks the optimization problem into two distinct sub-problems, one for choosing the optimal number of burns and each burn's optimal TIG, and the other for computing the minimum total deltaV burn solution that satisfies the trajectory constraints. Each of the two aforementioned levels uses a different optimization algorithm to solve one of the sub-problems, giving rise to a hybrid technique. Level 2, or the outer level, uses a genetic algorithm to select the number of burns and each burn's TIG. Level 1, or the inner level, uses the burn TIGs from Level 2 in a sequential quadratic programming (SQP) algorithm to compute a minimum total deltaV burn solution subject to the trajectory constraints. The total deltaV from Level 1 is then used as a fitness function by the genetic algorithm in Level 2 to select the number of burns and their TIGs for the next generation. In this manner, the two levels solve their respective sub-problems separately but collaboratively until a burn solution is found that globally minimizes the deltaV across the entire trajectory. Feasible solutions can also be found by simply using the SQP algorithm in Level 1 with a zero cost function. This paper discusses the formulation of the Level 1 sub-problem and the development of a prototype software tool to solve it. The Level 2 sub-problem will be discussed in a future work. Following the Level 1 formulation and solution, several look-ahead trajectory examples for the ISS are explored. In each case, the burn targeting results using the current process are compared against a feasible solution found using Level 1 in the proposed technique. Level 1 is then used to find a minimum deltaV solution given the fixed number of burns and burn TIGs. The optimal solution is compared with the previously found feasible solution to determine the deltaV (and therefore propellant) savings. The proposed technique seeks to both improve the current process for targeting ISS burns, and to add the capability to optimize ISS burns in a novel fashion. The optimal solutions found using this technique can potentially save hundreds of kilograms of propellant over the course of the ISS mission compared to feasible solutions alone. While the software tool being developed to implement this technique is specific to ISS, the concept is extensible to other long-duration, central-body orbiting missions that must perform orbit maintenance burns to meet operational trajectory constraints.

Brown, Aaron J.↗
NASA NTRS2016

Topic Modeling of NASA Space System Problem Reports: Research in Practice

Problem reports at NASA are similar to bug reports: they capture defects found during test, post-launch operational anomalies, and document the investigation and corrective action of the issue. These artifacts are a rich source of lessons learned for NASA, but are expensive to analyze since problem reports are comprised primarily of natural language text. We apply topic modeling to a corpus of NASA problem reports to extract trends in testing and operational failures. We collected 16,669 problem reports from six NASA space flight missions and applied Latent Dirichlet Allocation topic modeling to the document corpus. We analyze the most popular topics within and across missions, and how popular topics changed over the lifetime of a mission. We find that hardware material and flight software issues are common during the integration and testing phase, while ground station software and equipment issues are more common during the operations phase. We identify a number of challenges in topic modeling for trend analysis: 1) that the process of selecting the topic modeling parameters lacks definitive guidance, 2) defining semantically-meaningful topic labels requires nontrivial effort and domain expertise, 3) topic models derived from the combined corpus of the six missions were biased toward the larger missions, and 4) topics must be semantically distinct as well as cohesive to be useful. Nonetheless,topic modeling can identify problem themes within missions and across mission lifetimes, providing useful feedback to engineers and project managers.

Data Mining↗
NASA NTRSDate not supplied

Medical Database Accomplishments and Lessons Learned - 2021

The Medical Database (MD) is a virtual repository consisting of two software components: the Medical Item Database (MedID) and the Evidence Library (EL). MedID consists of engineering data and associated information for specific medical resource items (e.g., pharmaceutical, medical devices, and supporting components), while the EL is a tool which provides all of the medical evidence necessary. The Medical Database will serve as the single “source of truth” for the Informing Mission Planning via Analysis of Complex Tradespaces (IMPACT) tool suite for both medical evidence and medical resource engineering data. It will be used in conjunction with the IMPACT tool suite to inform research prioritizations and perform systematic trade study evaluations using probabilistic risk assessment and simulated human spaceflight missions to aid stakeholders in making informed decisions during Pre-Phase-A planning of human spaceflight missions. The IMPACT project is conducted under the Exploration Medical Capability (ExMC) element of the Human Research Program (HRP), within NASA’s Human Exploration and Operations Mission Directorate. Over the past year, the MedID software has been successfully merged with the Evidence Library into one cohesive Medical Database with two independent user interface experiences for modifying either clinical evidence or resource engineering data. As MD has evolved substantially over the past year, a number of challenges have been encountered and overcome along the way. A number of ‘lessons learned’ and practical/logistical realizations have emerged which will be detailed in the forthcoming Medical Database presentation.

Exploration Medical Capability↗
NASA NTRS1991

Flight dynamics facility operational orbit determination support for the ocean topography experiment

The Ocean Topography Experiment (TOPEX/POSEIDON) mission is designed to determine the topography of the Earth's sea surface across a 3 yr period, beginning with launch in June 1992. The Goddard Space Flight Center Dynamics Facility has the capability to operationally receive and process Tracking and Data Relay Satellite System (TDRSS) tracking data. Because these data will be used to support orbit determination (OD) aspects of the TOPEX mission, the Dynamics Facility was designated to perform TOPEX operational OD. The scientific data require stringent OD accuracy in navigating the TOPEX spacecraft. The OD accuracy requirements fall into two categories: (1) on orbit free flight; and (2) maneuver. The maneuver OD accuracy requirements are of two types; premaneuver planning and postmaneuver evaluation. Analysis using the Orbit Determination Error Analysis System (ODEAS) covariance software has shown that, during the first postlaunch mission phase of the TOPEX mission, some postmaneuver evaluation OD accuracy requirements cannot be met. ODEAS results also show that the most difficult requirements to meet are those that determine the change in the components of velocity for postmaneuver evaluation.

Bolvin, D. T.↗
NASA NTRS2021

On-Board Model Based Fault Diagnosis for CubeSat Attitude Control Subsystem: Flight Data Results

Self-sufficient, robotic spacecraft require estimates of their hardware health state in order to project future system state and plan actions toward achieving mission goals. In this paper, we report on integration of a Model-Based Fault Diagnosis (MBFD) model and reasoning engine into flight software leveraging the Arcsecond Space Telescope Enabling Research in Astrophysics (ASTERIA) mission, including test results against captured flight data using the ASTERIA system testbed. Our effort integrated the Model-based Off-Nominal State Identification and Detection (MONSID) model-based reasoning system, developed by Okean Solutions, into ASTERIA flight software using the F Prime software framework. The MONSID engine was supplied with a model of the Blue Canyon Technologies XACT attitude control system (ACS) and tested against flight data and seeded fault tests. While we were unable to conduct an on-board experiment due to the premature loss of ASTERIA, our effort proved the feasibility of on-board model-based fault management, demonstrating reliable and accurate diagnosis using captured data, and further supporting a closed-loop spacecraft autonomy demonstration including autonomous navigation in off-nominal conditions.

Prather, Maurice↗
NASA NTRS1990

Advanced engineering software for in-space assembly and manned planetary spacecraft

Meeting the objectives of the Lunar/Mars initiative to establish safe and cost-effective extraterrestrial bases requires an integrated software/hardware approach to operational definitions and systems implementation. This paper begins this process by taking a 'software-first' approach to systems design, for implementing specific mission scenarios in the domains of in-space assembly and operations of the manned Mars spacecraft. The technological barriers facing implementation of robust operational systems within these two domains are discussed, and preliminary software requirements and architectures that resolve these barriers are provided.

Delaquil, Donald↗
NASA NTRS2009

NASA's OCA Mirroring System: An Application of Multiagent Systems in Mission Control

Orbital Communications Adaptor (OCA) Flight Controllers, in NASA's International Space Station Mission Control Center, use different computer systems to uplink, downlink, mirror, archive, and deliver files to and from the International Space Station (ISS) in real time. The OCA Mirroring System (OCAMS) is a multiagent software system (MAS) that is operational in NASA's Mission Control Center. This paper presents OCAMS and its workings in an operational setting where flight controllers rely on the system 24x7. We also discuss the return on investment, based on a simulation baseline, six months of 24x7 operations at NASA Johnson Space Center in Houston, Texas, and a projection of future capabilities. This paper ends with a discussion of the value of MAS and future planned functionality and capabilities.

Sierhuis, Maarten↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRS2005

Trusted Autonomy for Space Flight Systems

NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.

Freed, Michael↗
NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗
NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗
NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗
NASA NTRS1984

The Mariner Mark II progream

The concept used in the design of the Mariner Mark II (MMII) spacecraft is consistent with the solar system exploration strategies which were developed by the Space Science Board of the National Academy of Sciences. The missions to comets, main belt asteroids, and outer planets are sufficiently similar to make possible a use of almost all of the design, hardware, and software in most engineering subsystems, without significant modification, for subsequent missions. Mariner Mark II missions are discussed, taking into account a comet rendezvous with asteroid flyby, the Saturn Flyby/Titan Probe, the Cassini or Saturn Orbiter/Titan Probe, the Main Belt Asteroid Rendezvous mission, the Uranus Flyby/Uranus Probe mission, and the Neptune Flyby/Neptune Probe mission.

Draper, R. F.↗
NASA NTRS2010

In-Situ Pointing Correction and Rover Microlocalization

Two software programs, marstie and marsnav, work together to generate pointing corrections and rover micro-localization for in-situ images. The programs are based on the PIG (Planetary Image Geometry) library, which handles all mission dependencies. As a result, there is no mission-specific code in either of these programs. This software corrects geometric seams in images as much as possible.

Deen, Robert G.↗
NASA NTRS2010

GOATS - Orbitology Component

The GOATS Orbitology Component software was developed to specifically address the concerns presented by orbit analysis tools that are often written as stand-alone applications. These applications do not easily interface with standard JPL first-principles analysis tools, and have a steep learning curve due to their complicated nature. This toolset is written as a series of MATLAB functions, allowing seamless integration into existing JPL optical systems engineering modeling and analysis modules. The functions are completely open, and allow for advanced users to delve into and modify the underlying physics being modeled. Additionally, this software module fills an analysis gap, allowing for quick, high-level mission analysis trades without the need for detailed and complicated orbit analysis using commercial stand-alone tools. This software consists of a series of MATLAB functions to provide for geometric orbit-related analysis. This includes propagation of orbits to varying levels of generalization. In the simplest case, geosynchronous orbits can be modeled by specifying a subset of three orbit elements. The next case is a circular orbit, which can be specified by a subset of four orbit elements. The most general case is an arbitrary elliptical orbit specified by all six orbit elements. These orbits are all solved geometrically, under the basic problem of an object in circular (or elliptical) orbit around a rotating spheroid. The orbit functions output time series ground tracks, which serve as the basis for more detailed orbit analysis. This software module also includes functions to track the positions of the Sun, Moon, and arbitrary celestial bodies specified by right ascension and declination. Also included are functions to calculate line-of-sight geometries to ground-based targets, angular rotations and decompositions, and other line-of-site calculations. The toolset allows for the rapid execution of orbit trade studies at the level of detail required for the early stage of mission concept development.

Haber, Benjamin M.↗
NASA NTRSDate not supplied

VIPER Lunar Rover Agile Mission Systems

The VIPER Lunar Rover, scheduled for a November, 2024 launch, is a solar powered rover that will search for volatiles at the lunar south pole. VIPER is an operationally complex mission operating in a challenging lighting and communications environment, requiring new design in a number of areas, from mission planning, to real-time waypoint driving. The combination of solar power, limited battery and the dynamic movement of shadows at the south pole gives VIPER small operational margins. The Mission System will be used to operate VIPER during cruise and on the lunar surface. To maximize efficiency and flexibility in Mission System design and thus to improve the performance and reliability of the resulting Mission System, we are tailoring Agile principles that we have used effectively in ground data system software development and applying those principles to the design of elements of the mission system.

Agile↗
NASA NTRSDate not supplied

Clinical Decision Support - Concepts of Operation

We are entering a new era in space exploration to return to the moon and explore Mars. These ambitious goals will require significant changes to in-flight and habitat medical care due to constraints on mass, volume, power, crew time and medical evacuation capabilities. These constraints make it absolutely necessary to develop transformative solutions using new technologies. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) pushes the boundary of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit by identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses the gap Medical-701 within the Inflight Medical Conditions risk: Enhance medical capabilities within an exploration medical system. For long-duration, deep space missions, computational and data resources will play an important role in maintaining crew health, wellness and performance where the crew will need to be more self-reliant. The aim of the CDS project is to develop and provide recommended requirements for an in-vehicle CDSS that acts as an assistant for delivering optimal health and performance and medical care during exploration missions. The CDSS is envisioned as a software-based tool that will augment a crewmembers’ knowledge, skills and abilities to assist in decision-making and crew health and performance (CHP) management thus increasing CHP systems capabilities. The human interface will be context aware and lessen the cognitive load to assimilate and use information as well as combine large disparate data sets in such a manner that provides the crew with actionable insight to decisions related to crew medical, health and performance management. Crew autonomy will be provided through a CDS that presents knowledge and data in a context aware manner to augment a crew members’ knowledge, skills and abilities during the process of observation, orientation, decisions and action. The CDS project addresses the need for crew members to operate independently during long duration space exploration missions that require medical Levels of Care (LoC) V, the highest level specified by NASA-STD-3001 and described in more detail by the ExMC interpretation of LoC document (NASA/TM-2017-219290), where significant changes to in-flight and habitat medical care necessitate increasing crew autonomy in decision making and task performance. The CDS project will develop and test a series of iterative and increasingly more complex system prototypes. These annual demonstrations of the data system integration with the crew health and performance domain will inform exploration medical system requirements for an on-board Clinical Decision Support System (CDSS) through a series of use cases that guide CDS prototype functionality. CDS concepts are based on ExMC Concept of Operations documents (presented separately) and will highlight architecture extensibility to other more complex analyses and tests using core crew health and performance integrated data management, processing and visualization capabilities. This approach also establishes how externally developed analyses and approaches could be added to expand a clinical decision support system and thus highlight how a comprehensive system can be commercially and/or globally developed. The CDS project will build upon the concept of an integrated data management approach based on the Medical Data Architecture (MDA) project to more fully address challenges associated with in-flight and habitat medical, health and performance care due to constraints on mass, volume, power, crew time and medical evacuation capabilities required for medical LoC V. These requirements will be derived through systems engineering approaches and software prototype developments over the course of the multi-year CDS project to address crew health and performance decision-making and task performance, often autonomously executed by the crew, in a manner that is consistent with the appropriate medical level of care for the mission. This presentation will provide an overview of the vision for the CDS project and highlight the initial accomplishments in project planning, implementation and requirements identification in fiscal year 2020.

clinical decision support↗