Search NASA⌕ Search

SEARCH · Search NASA

Results for “risk requirements architectures”

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 199 records · Page 11

A Multi-Purpose Modular Electronics Integration Node for Exploration Extravehicular Activity

As NASA works to develop an effective integrated portable life support system design for exploration Extravehicular activity (EVA), alternatives to the current system s electrical power and control architecture are needed to support new requirements for flexibility, maintainability, reliability, and reduced mass and volume. Experience with the current Extravehicular Mobility Unit (EMU) has demonstrated that the current architecture, based in a central power supply, monitoring and control unit, with dedicated analog wiring harness connections to active components in the system has a significant impact on system packaging and seriously constrains design flexibility in adapting to component obsolescence and changing system needs over time. An alternative architecture based in the use of a digital data bus offers possible wiring harness and system power savings, but risks significant penalties in component complexity and cost. A hybrid architecture that relies on a set of electronic and power interface nodes serving functional models within the Portable Life Support System (PLSS) is proposed to minimize both packaging and component level penalties. A common interface node hardware design can further reduce penalties by reducing the nonrecurring development costs, making miniaturization more practical, maximizing opportunities for maturation and reliability growth, providing enhanced fault tolerance, and providing stable design interfaces for system components and a central control. Adaptation to varying specific module requirements can be achieved with modest changes in firmware code within the module. A preliminary design effort has developed a common set of hardware interface requirements and functional capabilities for such a node based on anticipated modules comprising an exploration PLSS, and a prototype node has been designed assembled, programmed, and tested. One instance of such a node has been adapted to support testing the swingbed carbon dioxide and humidity control element in NASA s advanced PLSS 2.0 test article. This paper will describe the common interface node design concept, results of the prototype development and test effort, and plans for use in NASA PLSS 2.0 integrated tests.

Hodgson, Edward↗

Crew Health and Performance Integrated Data System Platform Project Updates

Future human exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting crew autonomy for future exploration missions. An integrated data system platform is needed to mitigate these risks by supporting a new generation of technologies and employing advanced analytical and predictive modeling techniques to enable crew autonomy for future exploration missions. The Crew Health and Performance Integrated Data System Platform (CHP-IDSP) project is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. This cohesive integration point will streamline the management of CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.) and facilitate situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the ongoing development effort of the path-to-flight CHP-IDSP software and the demonstration of its core capabilities. This includes a brief history of the project, the human-centered process used to identify data needs and workflows feeding the development of scenarios and requirements, and current subsystem development status. Current integrations, including the Chiron exploration electronic health record application, will be discussed. Future work includes collaboration with additional CHP domains and a flight technology demonstration.

Data integration↗

Crew Health and Performance Integrated Data Service Platform (CHP-IDSP): Project Updates

Future human exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting crew autonomy for future exploration missions. An integrated data services platform is needed to mitigate these risks by supporting a new generation of technologies and employing advanced analytical and predictive modeling techniques to enable crew autonomy for future exploration missions. The Crew Health and Performance Integrated Data System Platform (CHP-IDSP) project is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. This cohesive integration point will streamline the management of CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.) and facilitate situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the ongoing development effort of the path-to-flight CHP-IDSP software and the demonstration of its core capabilities. This includes a brief history of the project, the human-centered process used to identify data needs and workflows feeding the development of scenarios and requirements, and current subsystem development status. Current integrations, including the Chiron exploration electronic health record application, will be discussed. Future work includes collaboration with additional CHP domains and a flight technology demonstration.

Software↗

Light Water Sustainability Program: Optimizing Information Automation Using a New Method Based on System-Theoretic Process Analysis

This report describes the interim progress for research supporting the design and optimization of information automation systems for nuclear power plants. Much of the domestic nuclear fleet is currently focused on modernizing technologies and processes, including transitioning toward digitalization in the control room and elsewhere throughout the plant, along with a greater use of automation, artificial intelligence, robotics, and other emerging technologies. While there are significant opportunities to apply these technologies toward greater plant safety, efficiency, and overall cost-effectiveness, optimizing their design and avoiding potential safety and performance risks depends on ensuring that human-performance-related organizational and technical design issues are identified and addressed. This report describes modeling tools and techniques, based on sociotechnical system theory, to support these design goals and their application in the current research effort. The report is intended for senior nuclear energy stakeholders, including regulators, corporate management, and senior plant management. We have developed and employed a method to design an optimized information automation ecosystem (IAE) based on the systems-theoretic constructs underlying sociotechnical systems theory in general and the Systems-Theoretic Accident Modeling and Processes (STAMP) approach in particular. We argue that an IAE can be modeled as an interactive information control system whose behavior can be understood in terms of dynamic control and feedback relationships amongst the system’s technical and organizational components. Up to this point, we have employed a Causal Analysis based on STAMP (CAST) technique to examine a performance- and safety-related incident at an industry partner’s plant that involved the unintentional activation of an emergency diesel generator. This analysis provided insight into the behavior of the plant’s current information control structure within the context of a specific, significant event. Our ongoing analysis is focused on identifying near-term process improvements and longer-term design requirements for an optimized IAE system. The latter analyses will employ a second STAMP-derived technique, System-Theoretic Process Analysis (STPA). STPA is a useful modeling tool for generating and analyzing actual or potential information control structures. Finally, we have begun modeling plantwide organizational relationships and processes. Organizational system modeling will supplement our CAST and STPA findings and provide a basis for mapping out a plantwide information control architecture. CAST analysis findings indicate an important underlying contributor to the incident under investigation, and a significant risk to information automation system performance, was perceived schedule pressure, which exposed weaknesses in interdepartmental coordination between and within responsible plant organizations and challenged the resilience of established plant processes, until a human caused the initiating event. These findings are discussed in terms of their risk to overall system performance and their implications for information automation system resilience and brittleness. We present two preliminary information automation models. The proactive issue resolution model is a test case of an information automation concept with significant near-term potential for application and subsequent reduction in significant plant events. The IAE model is a more general representation of a broader, plantwide information automation system. From our results, we have generated a set of preliminary system-level requirements and safety constraints. These requirements will be further developed over the remainder of our project in collaboration with nuclear industry subject matter experts and specialists in the technical systems under consideration. Additionally, we will continue to pursue the system analyses initiated in the first part of our effort, with a particular emphasis on STPA as the main tool to identify weak or weakening control structures that affect the resilience of organizations and programs. Our intent is to broaden the scope of the analysis from an individual use case to a related set of use cases (e.g., maintenance tasks, compliance tasks) with similar human-system performance challenges. This will enable more generalized findings to refine the Proactive Issue Resolution and IAE models, as well as their system-level requirements and safety constraints. We will use organizational system modeling analyses to supplement STPA findings and model development. We conclude the report with a set of summary recommendations and an initial draft list of system-level requirements and safety constraints for optimized information automation systems.

99 GENERAL AND MISCELLANEOUS↗

Is Mars Sample Return Required Prior to Sending Humans to Mars?

Prior to potentially sending humans to the surface of Mars, it is fundamentally important to return samples from Mars. Analysis in Earth's extensive scientific laboratories would significantly reduce the risk of human Mars exploration and would also support the science and engineering decisions relating to the Mars human flight architecture. The importance of measurements of any returned Mars samples range from critical to desirable, and in all cases these samples will would enhance our understanding of the Martian environment before potentially sending humans to that alien locale. For example, Mars sample return (MSR) could yield information that would enable human exploration related to 1) enabling forward and back planetary protection, 2) characterizing properties of Martian materials relevant for in situ resource utilization (ISRU), 3) assessing any toxicity of Martian materials with respect to human health and performance, and 4) identifying information related to engineering surface hazards such as the corrosive effect of the Martian environment. In addition, MSR would be engineering 'proof of concept' for a potential round trip human mission to the planet, and a potential model for international Mars exploration.

biohazards↗

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-loop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of"pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS. The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (1) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multi-sensor series of trajectories.

Brewster, L.↗

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Lab

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success ofthe Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-Ioop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of "pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS.' The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (l) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multisensor series oftrajectories

Brewster, Linda L.↗

Direct Data Distribution From Low-Earth Orbit

NASA Lewis Research Center (LeRC) is developing the space and ground segment technologies necessary to demonstrate a direct data distribution (1)3) system for use in space-to-ground communication links from spacecraft in low-Earth orbit (LEO) to strategically located tracking ground terminals. The key space segment technologies include a K-band (19 GHz) MMIC-based transmit phased array antenna, and a multichannel bandwidth- and power-efficient digital encoder/modulate with an aggregate data rate of 622 Mb/s. Along with small (1.8 meter), low-cost tracking terminals on the ground, the D3 system enables affordable distribution of data to the end user or archive facility through interoperability with commercial terrestrial telecommunications networks. The D3 system is applicable to both government and commercial science and communications spacecraft in LEO. The features and benefits of the D3 system concept are described. Starting with typical orbital characteristics, a set of baseline requirements for representative applications is developed, including requirements for onboard storage and tracking terminals, and sample link budgets are presented. Characteristics of the transmit array antenna and digital encoder/modulator are described. The architecture and components of the tracking terminal are described, including technologies for the next generation terminal. Candidate flights of opportunity for risk mitigation and space demonstration of the D3 features are identified.

Budinger, James M.↗

System-Level Reuse of Space Systems Simulations

One of the best ways to enhance space systems simulation fidelity is to leverage off of (reuse) existing high-fidelity simulations. But what happens when the model you would like to reuse is in a different coding language or other barriers arise that make one want to just start over with a clean sheet of paper? Three diverse system-level simulation reuse case studies are described based on experience to date in the development of NASA's Space Station Training Facility (SSTF) at the Johnson Space Center in Houston, Texas. Case studies include (a) the Boeing/Rocketdyne-provided Electrical Power Simulation (EPSIM), (b) the NASA Automation and Robotics Division-provided TRICK robotics systems model, and (c) the Russian Space Agency- provided Russian Segment Trainer. In each case, there was an initial tendency to dismiss simulation reuse candidates based on an apparent lack of suitability. A more careful examination based on a more structured assessment of architectural and requirements-oriented representations of the reuse candidates revealed significant reuse potential. Specific steps used to conduct the detailed assessments are discussed. The steps include the following: 1) Identifying reuse candidates; 2) Requirements compatibility assessment; 3) Maturity assessment; 4) Life-cycle cost determination; and 5) Risk assessment. Observations and conclusions are presented related to the real cost of system-level simulation component reuse. Finally, lessons learned that relate to maximizing the benefits of space systems simulation reuse are shared. These concepts should be directly applicable for use in the development of space systems simulations in the future.

Hazen, Michael R.↗

Color Choice is Everything - Impacts Color makes to the Lighting Environment

When contracts are let out to design multiple systems in a vehicle, it is a challenge to maintain integration between system leads. Designers on niche systems, like lighting and control panel design, often get caught up in the challenge of designing the light source or visual interface and fail to include time in their schedule to work with system architects on how their lighting system will be integrated. Additionally, behavioral scientists, industrial designers, and materials engineers get caught up with the materials and look of the system, but often fail to consider how the selection of their materials could affect the certification or performance of electronic devices like lighting systems. Additionally, computer modeling of the system architecture often assumes a perfect environment without the clutter of actual human use (dirt, stowage, crowding). As a result, lighting systems, and backlit displays run the risk of being overdesigned or under designed. Engineers making the assumption that because they have no input or there is no requirement on work surface reflectance, make the assumption that they can t count on good material choices and thus may install more lighting than is necessary. While having more lights may seem better, for a vehicle that is trying to conserve power, more lights may not be a good option. On the other hand, designers who made the opposite assumption and designed a lighting system that only produced just enough light, often wind up with a system that did conserve power, but didn t produce enough light. These situations are exasperated when the system starts to be used and the models are not perfect anymore. The lack of coordination and iterative design not only can impact lighting levels within an environment, but also can affect color perception. This is because, if materials do not represent a gradation of white or black, the material unevenly absorbs and reflects light at different wavelengths of the visual spectrum. The lighting designer may have built a light that meets light spectra requirements, but the eventual light reaching the human user may not be the spectra of light architects intended, if materials near the light source change the spectrum just by how much color is absorbed or reflected. With the recent findings concerning Circadian rhythm, where the spectra of light is extremely important for addressing crew sleep and wake cycles, system architects should pay considerable attention on the impact material choices have in changing the light spectrum in an environment. This presentation will show examples of how material choices impact the resulting illuminance, color spectrum, and power usage of an illuminated space. Its goal is to encourage system designers and planners to use more care in development of requirements and the verification of systems intended for the human visual interface.

Clark, Toni A.↗

Space station data system analysis/architecture study. Task 2: Options development, DR-5. Volume 2: Design options

The primary objective of Task 2 is the development of an information base that will support the conduct of trade studies and provide sufficient data to make key design/programmatic decisions. This includes: (1) the establishment of option categories that are most likely to influence Space Station Data System (SSDS) definition; (2) the identification of preferred options in each category; and (3) the characterization of these options with respect to performance attributes, constraints, cost and risk. This volume contains the options development for the design category. This category comprises alternative structures, configurations and techniques that can be used to develop designs that are responsive to the SSDS requirements. The specific areas discussed are software, including data base management and distributed operating systems; system architecture, including fault tolerance and system growth/automation/autonomy and system interfaces; time management; and system security/privacy. Also discussed are space communications and local area networking.

Source record↗

Future Improvements to Impact for Long Duration Exploration Spaceflight

BACKGROUND: While NASA currently uses the Integrated Medical Model (IMM) to model spaceflight medical risk for Low Earth Orbit missions, IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) was created to improve the fidelity of medical risk analysis for exploration missions involving the Lunar surface and beyond. OVERVIEW: While completion work continues on the initial version of the IMPACT tool, work has already begun to investigate ways to further enhance the fidelity of the model and its utility to stakeholders. DISCUSSION: Future additions leveraging the more robust and flexible IMPACT architecture include analyzing mission segments to account for segment-specific environments (ie. Lunar surface or microgravity), clinically tracible outcomes based on partial treatment of conditions, the ability to model mission outcomes based on provider Knowledge, Skills, and Abilities (KSAs), and the ability to affect the incidence of conditions based on the occurrence of related conditions (e.g. UTI progressing to sepsis). IMPACT also enables the addition of new conditions to its database as required to meet future risk assessment needs. Ultimately, the desire is to broaden IMPACT from a tool that models/trades medical risk to one that does so for all crew health and performance relevant systems (e.g., food, exercise, etc.).

E Stratton↗

NASA Crew Exploration Vehicle, Thermal Protection System, Lessons Learned

The Orion (CEV) thermal protection system (TPS) advanced development project (ADP) was initiated in late 2006 to reduce developmental risk by significant investment in multiple heat shield architectural solutions that can meet the needs both the Low Earth orbit (LEO) and Lunar return missions. At the same time, the CEV TPS ADP was also charged with developing a preliminary design for the heat shield to meet the PDR requirement and at the time of the PDR, transfer the design to Lockheed- Martin, the prime contractor. We reported on the developmental activities of the first 18 months at the IPPW5 in Bordeaux, France, last summer. In June 08, at the time of the IPPW6, the CEV TPS ADP would have nearly completed the preparation for the Orion PDR and would be close to the original three-year mark. We plan to report on the progress at the Atlanta workshop. In the past year, Orion TPS ADP investment in TPS Technology, especially in PICA ablative Heat-shield design, development, testing and engineering (DDTE) has paid off in enabling MSL mission to switch from SLA 561 V heat shield to PICA heat shield. CEV TPS ADP considered SLA 561 V as a candidate for LEO missions and our testing identified failure modes in SLA and as a result, we dropped SLA for further evaluation. This close synergy between two projects is a highly visible example of how investment in technology areas can and does benefit multiple missions. In addition, CEV TPS ADP has been able to revive the Apollo ablative system namely AVCOAT honeycomb architecture as an alternate to the baseline PICA architecture and we plan to report the progress we have made in AVCOAT. CEV TPS ADP has invested considerable resources in developing analytical models for PICA and AVCOAT, material property measurements that is essential to the design of the heat-shield, in arcjet testing, in understanding the differences between different arc jet facilities, namely NASA Ames, NASA JSC and Air Force's AEDC, and in Non-Destructive Evaluation (NDE), and in integration of and manufacturing heat shield as a system. The capabilities of the two heat shield systems including failure modes via testing and analysis, once established, can serve the Probe Community and future mission designers to inner and outer planetary exploration very well. For example, missions to Venus, Mars and Titan can use either one of the system by selecting the mission design parameters that utilizes the full characteristics of these system to make use of system efficiency that will result in reduced heat shield mass, system robustness that will enhance mission success and cost. We plan to present significant progresses of the past three years and highlight the significant contributions CEV TPS ADP Project has made to advance the state of the art in Thermal Protection System technology that has and will continue to benefit future entry probe missions.

NASA Crew Exploration Vehicle↗

The Near Earth Asteroid Medical Conditions List

Purpose: The Exploration Medical Capability (ExMC) element is one of six elements within NASA s Human Research Program (HRP) and is responsible for addressing the risk of "the inability to adequately recognize or treat an ill or injured crewmember" for exploration-class missions. The Near Earth Asteroid (NEA) Medical Conditions List, constructed by ExMC, is the first step in addressing the above-mentioned risk for the 13-month long NEA mission. The NEA mission is being designed by NASA's Human Space Flight Architecture Team (HAT). The purpose of the conditions list is to serve as an evidence-based foundation for determining which medical conditions could affect a crewmember during the NEA mission, which of those conditions would be of concern and require treatment, and for which conditions a gap in knowledge or technology development exists. This information is used to focus research efforts and technology development to ensure that the appropriate medical capabilities are available for exploration-class missions. Scope and Approach: The NEA Medical Conditions List is part of a broader Space Medicine Exploration Medical Conditions List (SMEMCL), which incorporates various exploration-class design reference missions (DRMs). The conditions list contains 85 medical conditions which could occur during space flight and which are derived from several sources: Long-Term Surveillance of Astronaut Health (LSAH) in-flight occurrence data, The Space Shuttle (STS) Medical Checklist, The International Space Station (ISS) Medical Checklist, and subject matter expert opinion. Each medical condition listed has been assigned a clinical priority and a clinical priority rationale based on incidence, consequence, and mitigation capability. Implementation: The conditions list is a "living document" and as such, new conditions can be added to the list, and the priority of conditions on the list can be adjusted as the DRM changes, and as screening, diagnosis, or treatment capabilities change. The NEA medical conditions list was used recently as the basis for identifying gaps in in-flight medical evaluation (screening) capabilities. Learning Objectives: The audience will become familiar with the approach taken by NASA's Exploration Medical Capability element in addressing the risk of inability to recognize and treat medical conditions in the setting of a Near Earth Asteroid mission. Which one of the following statements is incorrect? a) The Near Earth Asteroid (NEA) medical conditions list includes 85 medical conditions which could occur during space flight. b) Each condition on the NEA medical conditions list has been assigned a clinical priority and a clinical priority rationale. c) The NEA medical conditions list targets a mission to Mars. d) The NEA medical conditions list should be viewed as a "living document" where new conditions can be added and clinical priorities adjusted to address changes in the design reference mission or medical capabilities. The incorrect answer is c). The NEA medical conditions list targets a mission to a Near Earth Asteroid.

Barr, Yael R.↗

Mars Soil-Based Resource Processing and Planetary Protection

The ability to extract and process resources at the site of exploration into products and services, commonly referred to as In Situ Resource Utilization (ISRU), can have significant benefits for robotic and human exploration missions. In particular, the ability to use in situ resources to make propellants, fuel cell reactants, and life support consumables has been shown in studies to significantly reduce mission mass, cost, and risk, while enhancing or enabling missions not possible without the incorporation of ISRU. In December 2007, NASA completed the Mars Human Design Reference Architecture (DRA) 5.0 study. For the first time in a large scale Mars architecture study, water from Mars soil was considered as a potential resource. At the time of the study, knowledge of water resources (their form, concentration, and distribution) was extremely limited. Also, due to lack of understanding of how to apply planetary protection rules and requirements to ISRU soil-based excavation and processing, an extremely conservative approach was incorporated where only the top several centimeters of ultraviolet (UV) radiated soil could be processed (assumed to be 3% water by mass). While results of the Mars DRA 5.0 study showed that combining atmosphere processing to make oxygen and methane with soil processing to extract water provided the lowest mission mass, atmosphere processing to convert carbon dioxide (CO2) into oxygen was baselined for the mission since it was the lowest power and risk option. With increased knowledge and further clarification of Mars planetary protection rules, and the recent release of the Mars Exploration Program Analysis Group (MEPAG) report on "Special Regions and the Human Exploration of Mars", it is time to reexamine potential water resources on Mars, options for soil processing to extract water, and the implications with respect to planetary protection and Special Regions on Mars.

Sanders, G. B.↗

Effect of GPS Manipulation to Traditional and Next Generation Relay Protection

This project’s objective is to test the effect of GPS timing variations on relay protection algorithms to determine vulnerabilities and the associated hazards to the electric grid. This will focus on differential protection which utilizes peer to peer communication between substations to determine if the current is not equivalent. This requires the use of GPS to sync the two substations and can be vulnerable to GPS manipulation. However, the effects of GPS manipulation are not a commonly known risk. Therefore, this LDRD will address the risks of GPS manipulation for such a widely implemented technology. For differential protection a GPS resilient architecture was implemented and tested for differential protective relays through a direct serial fiber connection between the two relays. This allows for one relay to be the master and provide synchronization outside of timestamp for differential protection.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Hatch Integration Testing of a NASA TransHab Derivative Woven Inflatable Module

Current options for Lunar habitat architecture include inflatable habitats and airlocks. Inflatable structures can have mass and volume advantages over conventional structures. However, inflatable structures are also perceived to carry additional risk because they are at a lower Technical Readiness Level (TRL) than more conventional metallic structures. The use of inflatable structures for habitation will require large penetrations in the inflatable structure to accommodate hatches and/or windows The Hatch Integration Test is designed to study the structural integrity of an expandable structure with an integrated hatch, and to verify mathematical models of the structure. The TransHab project developed an experimental inflatable module at Johnson Space Center in the 1990's. The TransHab design was originally envisioned for use in Mars Transits but was also studied as a potential habitat for the International Space Station (ISS).

Edgecombe, John↗

Fe(3): An Evaluation Tool for Low-Altitude Air Traffic Operations

The concepts of unmanned aircraft system traffic management (UTM) and urban air mobility (UAM) are introducing high-density operations in low altitude airspace in closer proximity to populated areas than conventional high-altitude air traffic. The Flexible engine for Fast-time Evaluation of Flight Environments (Fe (sup 3)) provides the capability of statistically analyzing the high-density, high-fidelity, and low-altitude traffic system under numerous scenarios, such that stake holders can study impacts of factors in the low-altitude high-density traffic system and define requirements, policies, and protocols needed to support a safe yet efficient traffic system, and even assess operational risks and optimize flight schedules without conducting infeasible and cost-prohibitive flight tests that involve a large volume of aerial vehicles. This work provides an introduction to this simulation tool including its architecture and various models involved. Its performance and sample application in UAM and UTM are also presented.

Collision Avoidance↗