Search NASA⌕ Search

SEARCH · Search NASA

Results for “Ground Operational Support 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.

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

At least 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS1997

Surface Development and Test Facility (SDTF) New R&D Simulator for Airport Operations

A new simulator, the Surface Development and Test Facility (SDTF) is under construction at the NASA Ames Research Center in Mountain View, California. Jointly funded by the FAA (Federal Aviation Administration) and NASA, the SDTF will be a testbed for airport surface automation technologies of the future. The SDTF will be operational in the third quarter of 1998. The SDTF will combine a virtual tower with simulated ground operations to allow evaluation of new technologies for safety, effectiveness, reliability, and cost benefit. The full-scale level V tower will provide a seamless 360 degree high resolution out-the-window view, and a full complement of ATC (air traffic control) controller positions. The imaging system will be generated by two fully-configured Silicon Graphics Onyx Infinite Reality computers, and will support surface movement of up to 200 aircraft and ground vehicles. The controller positions, displays and consoles can be completely reconfigured to match the unique layout of any individual airport tower. Dedicated areas will accommodate pseudo-airport ramp controllers, pseudo-airport operators, and pseudo-pilots. Up to 33 total personnel positions will be able to participate in simultaneous operational scenarios. A realistic voice communication infrastructure will emulate the intercom and telephone communications of a real airport tower. Multi-channel audio and video recording and a sophisticated data acquisition system will support a wide variety of research and development areas, such as evaluation of automation tools for surface operations, human factors studies, integration of terminal area and airport technologies, and studies of potential airport physical and procedural modifications.

Dorighi, Nancy S.↗
NASA NTRS1996

Modular Software for Spacecraft Navigation Using the Global Positioning System (GPS)

The Goddard Space Flight Center Flight Dynamics and Mission Operations Divisions have jointly investigated the feasibility of engineering modular Global Positioning SYSTEM (GPS) navigation software to support both real time flight and ground postprocessing configurations. The goals of this effort are to define standard GPS data interfaces and to engineer standard, reusable navigation software components that can be used to build a broad range of GPS navigation support applications. The paper discusses the GPS modular software (GMOD) system and operations concepts, major requirements, candidate software architecture, feasibility assessment and recommended software interface standards. In additon, ongoing efforts to broaden the scope of the initial study and to develop modular software to support autonomous navigation using GPS are addressed,

Truong, S. H.↗
NASA NTRS2005

A Reusable Design for Precision Lunar Landing Systems

The top-level architecture to accomplish NASA's Vision for Space Exploration is to use Lunar missions and systems not just as an end in themselves, but also as testbeds for the more ambitious goals of Human Mars Exploration (HME). This approach means that Lunar missions and systems are most likely going to be targeted for (Lunar) polar missions, and also for long-duration (months) surface stays. This overacting theme creates basic top-level requirements for any next-generation lander system: 1) Long duration stays: a) Multiple landers in close proximity; b) Pinpoint landings for "surface rendezvous"; c) Autonomous landing of pre-positioned assets; and d) Autonomous Hazard Detection and Avoidance. 2) Polar and deep-crater landings (dark); 3) Common/extensible systems for Moon and Mars, crew and cargo. These requirements pose challenging technology and capability needs. Compare and contrast: 4) Apollo: a) 1 km landing accuracy; b) Lunar near-side (well imaged and direct-to-Earth com. possible); c) Lunar equatorial (landing trajectories offer best navigation support from Earth); d) Limited lighting conditions; e) Significant ground-in-the-loop operations; 5) Lunar Access: a) 10-100m landing precision; b) "Anywhere" access includes polar (potentially poor nav. support from Earth) and far side (poor gravity and imaging; no direct-to-Earth com); c) "Anytime" access includes any lighting condition (including dark); d) Full autonomous landing capability; e) Extensible design for tele-operation or operator-in-the-loop; and f) Minimal ground support to reduce operations costs. The Lunar Access program objectives, therefore, are to: a) Develop a baseline Lunar Precision Landing System (PLS) design to enable pinpoint "anywhere, anytime" landings; b) landing precision 10m-100m; c) Any LAT, LON; and d) Any lighting condition; This paper will characterize basic features of the next generation Lunar landing system, including trajectory types, sensor suite options and a reference system architecture.

Fuhrman, Linda↗
NASA NTRS1993

Proposed ground-based control of accelerometer on Space Station Freedom

This paper describes the innovative control of an accelerometer to support the needs of the scientists operating science experiments that are on-board Space Station Freedom (SSF). Accelerometers in support of science experiments on the shuttle have typically been passive, record-only devices that present data only after the mission or that present limited data to the crew or ground operators during the mission. With the advent of science experiment operations on SSF, the principal investigators will need microgravity acceleration data during, as well as after, experiment operations. Because their data requirements may change during the experiment operations, the principal investigators will be allocated some control of accelerometer parameters. This paper summarizes the general-purpose Space Acceleration Measurement System (SAMS) operation that supports experiments on the shuttle and describes the control of the SAMS for Space Station Freedom. Emphasis is placed on the proposed ground-based control of the accelerometer by the principal investigators.

Delombard, Richard↗
NASA NTRS1993

Proposed ground-based control of accelerometer on Space Station Freedom

This paper describes the innovative control of an accelerometer to support the needs of the scientists operating science experiments that are on-board Space Station Freedom (SSF). Accelerometers in support of science experiments on the shuttle have typically been passive, record-only devices that present data only after the mission or that present limited data to the crew or ground operators during the mission. With the advent of science experiment operations on SSF, the principal investigators will need microgravity acceleration data during, as well as after, experiment operations. Because their data requirements may change during the experiment operations, the principal investigators will be allocated some control of accelerometer parameters. This paper summarizes the general-purpose Space Acceleration Measurement System (SAMS) operation that supports experiments on the shuttle and describes the control of the SAMS for Space Station Freedom. Emphasis is placed on the proposed ground-based control of the accelerometer by the principal investigators.

Delombard, Richard↗
NASA NTRS2012

Mass Analyzers Facilitate Research on Addiction

The famous go/no go command for Space Shuttle launches comes from a place called the Firing Room. Located at Kennedy Space Center in the Launch Control Center (LCC), there are actually four Firing Rooms that take up most of the third floor of the LCC. These rooms comprise the nerve center for Space Shuttle launch and processing. Test engineers in the Firing Rooms operate the Launch Processing System (LPS), which is a highly automated, computer-controlled system for assembly, checkout, and launch of the Space Shuttle. LPS monitors thousands of measurements on the Space Shuttle and its ground support equipment, compares them to predefined tolerance levels, and then displays values that are out of tolerance. Firing Room operators view the data and send commands about everything from propellant levels inside the external tank to temperatures inside the crew compartment. In many cases, LPS will automatically react to abnormal conditions and perform related functions without test engineer intervention; however, firing room engineers continue to look at each and every happening to ensure a safe launch. Some of the systems monitored during launch operations include electrical, cooling, communications, and computers. One of the thousands of measurements derived from these systems is the amount of hydrogen and oxygen inside the shuttle during launch.

Source record↗
NASA NTRS1991

Space transfer concepts and analysis for exploration missions. Implementation plan and element description document (draft final). Volume 2: Cryo/aerobrake vehicle

The cryogenic/aerobrake (CAB) and the cryogenic all-propulsive (CAP) concept designs developed in support of the Space Transfer Concepts and Analysis for Exploration Missions (STCAEM) study are presented. The evolution of the CAB and CAP concepts is described along with the requirements, guidelines and assumptions for the designs. Operating modes and options are defined and systems descriptions of the vehicles are presented. Artificial gravity configuration options and space and ground support systems are discussed. Finally, an implementation plan is presented which addresses technology needs, schedules, facilities, and costs.

Source record↗
NASA NTRS2005

Space Shuttle Operations and Infrastructure: A Systems Analysis of Design Root Causes and Effects

This NASA Technical Publication explores and documents the nature of Space Shuttle operations and its supporting infrastructure and addresses fundamental questions often asked of the Space Shuttle program why does it take so long to turnaround the Space Shuttle for flight and why does it cost so much? Further, the report provides an overview of the cause-and effect relationships between generic flight and ground system design characteristics and resulting operations by using actual cumulative maintenance task times as a relative measure of direct work content. In addition, this NASA TP provides an overview of how the Space Shuttle program's operational infrastructure extends and accumulates from these design characteristics. Finally, and most important, the report derives a set of generic needs from which designers can revolutionize space travel from the inside out by developing and maturing more operable and supportable systems.

McCleskey, Carey M.↗
NASA NTRS2018

Cooperative Automation Supporting Pilot-Dispatch Negotiation of Enroute Trajectory Change Requests

The advent of advanced technologies in communication, navigation, and surveillance is enabling more integration between the aircraft and the ground systems in managing air traffic operations. As a result, automation has evolved to provide the flight crew, air traffic controllers, and traffic flow managers with capabilities for collaborating on information access, analysis, and decision making. In this paper, we investigate different cooperative schemes between these agents, supported by automation, in managing dynamic trajectory changes while the flight is en route to improve flight and system performance. The analysis was conducted using an abstract cognitive tasking framework to identify trajectory change tasks independently from the agent performing them. Cooperation schemes were then derived by assessing different levels of cooperation on each task between the air and ground agents and their automation. The assessment was based on which automation-supported agent is more capable of performing the task and the expected benefit mechanisms that result from cooperating. The cooperation schemes were compared based on a qualitative, but objective, assessment of the benefits expected from cooperation.

air-ground integration↗
NASA NTRS2008

Linking and Combining Distributed Operations Facilities using NASA's "GMSEC" Systems Architectures

NASA's Goddard Mission Services Evolution Center (GMSEC) ground system architecture has been in development since late 2001, has successfully supported eight orbiting satellites and is being applied to many of NASA's future missions. GMSEC can be considered an event-driven service-oriented architecture built around a publish/subscribe message bus middleware. This paper briefly discusses the GMSEC technical approaches which have led to significant cost savings and risk reduction for NASA missions operated at the Goddard Space Flight Center (GSFC). The paper then focuses on the development and operational impacts of extending the architecture across multiple mission operations facilities.

Smith, Danford↗
NASA NTRS2003

Experiences with Testing the Largest Ground System NASA Has Ever Built

In the 1980s, the National Aeronautics and Space Administration (NASA) embarked upon a major Earth-focused program called Mission to Planet Earth. The Goddard Space Flight Center (GSFC) was selected to manage and develop a key component - the Earth Observing System (EOS). The EOS consisted of four major missions designed to monitor the Earth. The missions included 4 spacecraft. Terra (launched December 1999), Aqua (launched May 2002), ICESat (Ice, Cloud, and Land Elevation Satellite, launched January 2003), and Aura (scheduled for launch January 2004). The purpose of these missions was to provide support for NASA s long-term research effort for determining how human-induced and natural changes affect our global environment. The EOS Data and Information System (EOSDIS), a globally distributed, large-scale scientific system, was built to support EOS. Its primary function is to capture, collect, process, and distribute the most voluminous set of remotely sensed scientific data to date estimated to be 350 Gbytes per day. The EOSDIS is composed of a diverse set of elements with functional capabilities that require the implementation of a complex set of computers, high-speed networks, mission-unique equipment, and associated Information Technology (IT) software along with mission-specific software. All missions are constrained by schedule, budget, and staffing resources, and rigorous testing has been shown to be critical to the success of each mission. This paper addresses the challenges associated with the planning, test definition. resource scheduling, execution, and discrepancy reporting involved in the mission readiness testing of a ground system on the scale of EOSDIS. The size and complexity of the mission systems supporting the Aqua flight operations, for example, combined with the limited resources available, prompted the project to challenge the prevailing testing culture. The resulting success of the Aqua Mission Readiness Testing (MRT) program was due in no small measure to re-structuring the traditional programmatic and technical approach to a more efficient and robust program. Programmatically, it meant gaining the endorsement, commitment, and cooperation of the numerous subsystem element managers and other stakeholder organizations. Technically, it required an MRT program that was agile, could rapidly adapt to requirements changes, and was flexible in its overall approach. Furthermore, this paper addresses the following questions: 1. What are the key ingredients (e.g., test tools, organization) needed to conduct a successful MRT program? 2. What distinguishes EOS MRT from the traditional system testing approach? 3. Where should the focus of testing be since it is infeasible to test every element or subsystem? 4. How can MRT be applied effectively to other systems or missions? To provide answers to these questions, this paper relies heavily on real-life, hands-on experiences ("lessons learned") gained during mission readiness testing of the Terra ground system and, most recently, the Aqua and ICESat missions. Moreover, this paper explores how lessons learned were turned into lessons applied for the upcoming Aura mission. Although derived from the EOS missions, MRT techniques and strategies can be applied to enhance the testing of other missions.

Lehtonen, Ken↗
NASA NTRS2010

A Comparison Between Orion Automated and Space Shuttle Rendezvous Techniques

The Orion spacecraft will replace the space shuttle and will be the first human spacecraft since the Apollo program to leave low earth orbit. This vehicle will serve as the cornerstone of a complete space transportation system with a myriad of mission requirements necessitating rendezvous to multiple vehicles in earth orbit, around the moon and eventually beyond . These goals will require a complex and robust vehicle that is, significantly different from both the space shuttle and the command module of the Apollo program. Historically, orbit operations have been accomplished with heavy reliance on ground support and manual crew reconfiguration and monitoring. One major difference with Orion is that automation will be incorporated as a key element of the man-vehicle system. The automated system will consist of software devoted to transitioning between events based on a master timeline. This effectively adds a layer of high level sequencing that moves control of the vehicle from one phase to the next. This type of automated control is not entirely new to spacecraft since the shuttle uses a version of this during ascent and entry operations. During shuttle orbit operations however many of the software modes and hardware switches must be manually configured through the use of printed procedures and instructions voiced from the ground. The goal of the automation scheme on Orion is to extend high level automation to all flight phases. The move towards automation represents a large shift from current space shuttle operations, and so these new systems will be adopted gradually via various safeguards. These include features such as authority-to-proceed, manual down modes, and functional inhibits. This paper describes the contrast between the manual and ground approach of the space shuttle and the proposed automation of the Orion vehicle. I will introduce typical orbit operations that are common to all rendezvous missions and go on to describe the current Orion automation architecture and contrast it with shuttle rendezvous techniques and circumstances. The shuttle rendezvous profile is timed to take approximately 3 days from orbit insertion to docking at the International Space Station (ISS). This process can be divided into 3 phases: far-field, mid-field and proximity operations. The far-field stage is characterized as the most quiescent phase. The spacecraft is usually too far to navigate using relative sensors and uses the Inertial Measurement Units (IMU s) to numerically solve for its position. The maneuvers are infrequent, roughly twice per day, and are larger than other burns in the profile. The shuttle uses this opportunity to take extensive ground based radar updates and keep high fidelity orbit states on the ground. This state is then periodically uplinked to the shuttle computers. The targeting solutions for burn maneuvers are also computed on the ground and uplinked. During the burn the crew is responsible for setting the shuttle attitude and configuring the propulsion system for ignition. Again this entire process is manually driven by both crew and ground activity. The only automatic processes that occur are associated with the real-time execution of the burn. The Orion automated functionality will seek to relieve the workload of both the crew and ground during this phase

Ruiz, Jose O,↗
NASA NTRS2008

GSFC Technical Outreach: The Capitol College Model

In February 2005, as part of the National Aeronautic and Space Administration (NASA) Technical Outreach Program, Goddard Space Flight Center (GSFC) awarded Capitol College of Laurel, Maryland an Educational Grant to establish a Space Operation academic curriculum to meet the future needs of mission operations engineers. This was in part due to the aerospace industry and GSFC concerns that a large number of professional engineers are projected to retire in the near term with evidence showing that current enrollment in engineering schools will not produce sufficient number of space operation trained engineers that will meet industry and government demands. Capitol College, under the agreement of the Educational Grant, established the Space Operations Institute (SOI) with a new curriculum in Space Operations that was approved and certified by the State of Maryland. The SO1 programs focuses on attracting, recruiting, and training a pipeline of highly qualified engineers with experience in mission operations, system engineering and development. The selected students are integrated as members of the engineering support team in any of the missions supported by the institute. The students are mentored by professional engineers from several aerospace companies that support GSFC. Initially, the institute was involved in providing console engineers and mission planning trainees for the Upper Atmosphere Research Satellite (UARS), the Earth Radiation Budget Satellite (ERBS) and the Total Ozone Mapping Spectrometer mission (TOMS). Subsequently, the students were also involved in the technology refresh of the TOMS ground system and other mission operations development. Further mission assignment by GSFC management included participation in the Tropical Rainfall Measuring Mission (TRMM) mission operations and ground system technology refresh. The SOI program has been very successful. Since October 2005, sixty-four students have been enrolled in the SOI program and twenty-five have already graduated from the program, nineteen of whom are employed by company's supporting GSFC. Due to the success of the program, the initial grant period was extended for another period of two years. This paper presents the process that established the SOI as a viable pipeline of mission operations engineers, the lessons learned in the process of dealing with grants, and experience gained in mentoring engineering students that are responsible for particular areas of expertise and functionality. This paper can also be considered a case study and model for integrating a student team with government and industry professionals in the real world of mission operations.

Marius, Julio L.↗
DOE OSTI2026

Wind and Temperature Consensus at Horn Point, HU-Beltsville, Piney Run (Maryland) in support of CoURAGE

The Maryland Department of the Environment (MDE) operates a ground-based atmospheric profiling network consisting of collocated radar wind profilers (RWP) and radio acoustic sounding systems (RASS) as part of its Ambient Air Monitoring Program. This network provides continuous observations of wind and temperature structure in the lower troposphere to support air quality forecasting, regulatory analysis, and atmospheric research. The network currently includes three fixed sites across Maryland: Horn Point (HP, lower eastern shore) [38.587525°,-76.141006°], Howard University-Beltsville (HUB, central Maryland) [39.055277°, -76.878632°], and Piney Run (PR, western Maryland) [39.705950°, -79.012000°] The network is designed to capture regional variability in atmospheric transport and boundary-layer processes. These systems measure vertical profiles of horizontal wind speed and direction using Doppler radar techniques, with observations typically spanning from ~100 m above ground level up to approximately 2.5–4 km. Measurements are derived from the Doppler shift of backscattered electromagnetic signals, enabling retrieval of wind vectors at multiple altitudes with high temporal resolution (e.g., 30-minute averages reported every 6 minutes). Each radar wind profiler is paired with a Radio Acoustic Sounding System (RASS) to provide profiles of virtual temperature in the lower atmosphere (~100–200 m AGL) by measuring the propagation speed of acoustic waves. Together, the RWP/RASS system yields a coupled data set of thermodynamic and kinematic atmospheric structure, including additional parameters such as vertical velocity, radial velocity, signal-to-noise ratio, and spectral width for advanced analysis. There are two types of files for each station: wind data (files with a "w" prefix) and virtual temperature RASS data (files with a "t" prefix). The wind data files are in the format wYYDDD.cns, where YY is the 2-digit year and DDD is the day of the year. The RASS virtual temperature data files are in the format tYYDDD.cns. Each record has the following header structure: Line 1 : Station Name RASS files Line 2 : RASS rev DeTect_2.0, WINDS files Line 2 : WINDS rev ATI 5.1 Line 3 : N latitude, W longitude, and site elevation (m) Line 4 : Date and begin time of consensus: yy mm dd hh mn ss plus # minutes to add to get UTC Line 5 : Consensus averaging time (minutes); number of beams; number of range gates Line 6 : Number of records required to make consensus (num) total number of records (tot) and the consensus window size (m/s) in the format: num:tot (window) RASS files Line 7 : no. of coded cells, no. of spec, pulse width (ns), and inter-pulse period (µs), WINDS files Line 7 : No. of coded cells, no. of spectra, pulse width (ns), and inter-pulse period (µs), each with a pair of values: first value is for oblique beams, second for vertical RASS files Line 8 : Full scale Doppler value (m/s) Delay to first gate (ns) Number of gates Spacing of gates (ns), WINDS files Line 8 : Full scale Doppler velocity (m/s), oblique and vertical Vertical correction applied to oblique beams? (0 = no, 1 = yes) Delay to first gate (ns), oblique and vertical Number of gates, oblique and vertical Spacing of gates (ns), oblique and vertical Line 9 : Azimuth and elevation (9s indicate vertical beam not used) RASS files Line 10, values : HT = Height above ground (km), T = Uncorrected virtual temperature consensus (deg C), Tc = Corrected virtual temperature consensus (deg C), W = Vertical wind consensus (9s indicate vertical beam not used, w-component, positive upward, m/s), CNT = Number of records that made consensus (for the 3 values in same order), SNR = Average signal to noise ratio (dB) of records in consensus (same order) WINDS files Line 10, values : HT = Height above ground (km), SPD = Wind speed (m/s), DIR = Wind direction (deg E of N from N), RAD = Radial velocities for each beam (m/s) in order given in azimuth and elevation line (positive toward radar; 9s indicate vertical beam not used, CNT = Number of records that made consensus, SNR = Average signal to noise ratio (dB) of records in consensus

{"wind speed and direction",temperature}↗
NASA NTRS1979

Satellite communications for disaster relief operations

The use of existing and planned communication satellite systems to provide assistance in the implementation of disaster relief operations on a global basis was discussed along with satellite communications system implications and their potential impact on field operations in disaster situations. Consideration are given to the utilization of both INTELSAT and MARISAT systems operating at frequencies ranging from 1.5 to 4 GHz and to the size and type of ground terminals necessary for satellite access. Estimates of communication requirements for a global system are given. Some discussion of cost estimates for satellite services to support operations are included. Studies of communication satellites for both pre and post disaster applications conducted for NOAA are included as well as recent experiments conducted in conjunction with the Office of Foreign Disaster Assistance of the Agency for International Development.

Sivo, J. N.↗
NASA NTRS2002

NASA 2nd Generation RLV Program Introduction, Status and Future Plans

The Space Launch Initiative (SLI), managed by the Second Generation Reusable Launch Vehicle (2ndGen RLV) Program, was established to examine the possibility of revolutionizing space launch capabilities, define conceptual architectures, and concurrently identify the advanced technologies required to support a next-generation system. Initial Program funds have been allocated to design, evaluate, and formulate realistic plans leading to a 2nd Gen RLV full-scale development (FSD) decision by 2006. Program goals are to reduce both risk and cost for accessing the limitless opportunities afforded outside Earth's atmosphere fo civil, defense, and commercial enterprises. A 2nd Gen RLV architecture includes a reusable Earth-to-orbit launch vehicle, an on-orbit transport and return vehicle, ground and flight operations, mission planning, and both on-orbit and on-the-ground support infrastructures All segments of the architecture must advance in step with development of the RLV if a next-generation system is to be fully operational early next decade. However, experience shows that propulsion is the single largest contributor to unreliability during ascent, requires the largest expenditure of time for maintenance, and takes a long time to develop; therefore, propulsion is the key to meeting safety, reliability, and cost goals. For these reasons, propulsion is SLI's top technology investment area.

Dumbacher, Dan L.↗
NASA NTRS2004

Telescience Resource Kit Software Capabilities and Future Enhancements

The Telescience Resource Kit (TReK) is a suite of PC-based software applications that can be used to monitor and control a payload on board the International Space Station (ISS). This software provides a way for payload users to operate their payloads from their home sites. It can be used by an individual or a team of people. TReK provides both local ground support system services and an interface to utilize remote services provided by the Payload Operations Integration Center (POIC). by the POIC and to perform local data functions such as processing the data, storing it in local files, and forwarding it to other computer systems. TReK can also be used to build, send, and track payload commands. In addition to these features, work is in progress to add a new command management capability. This capability will provide a way to manage a multi- platform command environment that can include geographically distributed computers. This is intended to help those teams that need to manage a shared on-board resource such as a facility class payload. The environment can be configured such that one individual can manage all the command activities associated with that payload. This paper will provide a summary of existing TReK capabilities and a description of the new command management capability. For example, 7'ReK can be used to receive payload data distributed

Schneider, Michelle↗
NASA NTRSDate not supplied

Custom Integration of Multiple Medical Functionalities

INTRODUCTION: Previous spaceflight experience and results from probabilistic risk assessment of spaceflight medical risk have highlighted the need for vital sign measurements, medical scopes, and clinical imaging tools for managing medical conditions during spaceflight. The Human Research Program’s Exploration Medical Capability (ExMC) Element and the Mars Campaign Office’s Exploration Medical Integrated Product Team (XMIPT) have performed ground-based evaluations of two Commercial-off-the-Shelf (COTS) Multi-functional Integrated Medical (MIM) devices, which integrate various medical capabilities together in one device. The key findings from these evaluations are presented in a complementary presentation, leaving this presentation to focus on forward recommendations for customized integration of multiple medical functionalities. KEY COMPONENTS: The key features of a custom integration of multiple medical functionalities includes devices and capabilities that optimally reduce medical risk. The COTS MIM devices incorporated functionality for best supporting Earth-based, emergency, pre-hospital care. Our custom integration will use probabilistic risk assessment tools, such as the Medical Extensible Dynamic Probabilistic Risk Assessment Tool (MEDPRAT), to determine the optimal functionality to include based on medical risk minimization. An additional feature of custom integration includes the ability to adapt to different requirements within different vehicles and/or missions. The COTS MIM devices store data in patient specific records, however, the format of the records is not modifiable, and data are not easily transferred from the MIM device to a central data architecture outside of the manufacturer’s established system. Our concept for custom integration will use devices that have an open application programming interface, which can easily connect to independent data architectures and third-party visualization software. The ultrasound capabilities included within the COTS MIM devices did not satisfy many of the Artemis Research and Operations Working Group’s ultrasound functional needs, and therefore, incorporation of higher quality ultrasound capabilities within a customized integration will be beneficial. The COTS MIM devices included minimal procedural guidance and clinical decision support tools. Supplemental tools of this type would need to be supplied along with the COTS MIM devices if they were to be used operationally, so another advantage of customization is the ability to integrate these support tools along with the medical functionality, for a more streamlined user experience. CONCLUSION: Investigation of a customized integration of medical functionality provides a method for further understanding the needs of a long-term exploration spaceflight medical system. The crew members of these exploration missions will need to operate more and more independently from Earth-based ground support. Therefore, having an optimized, streamlined medical system, which contains the functionality and supporting information needed, while remaining within mission and vehicle constraints, will help to maintain crew health and performance, which is necessary for achieving high levels of mission success.

B E Lewandowski↗