Search NASA⌕ Search

SEARCH · Search NASA

Results for “Avionics Requirements and ARchitecture”

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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Fault-tolerant software - Experiment with the sift operating system

Results are presented of an experiment conducted in the NASA Avionics Integrated Research Laboratory (AIRLAB) to investigate the implementation of fault-tolerant software techniques on fault-tolerant computer architectures, in particular the Software Implemented Fault Tolerance (SIFT) computer. The N-version programming and recovery block techniques were implemented on a portion of the SIFT operating system. The results indicate that, to effectively implement fault-tolerant software design techniques, system requirements will be impacted and suggest that retrofitting fault-tolerant software on existing designs will be inefficient and may require system modification.

Brunelle, J. E.↗
NASA NTRS2020

An Enhanced Autonomy Approach to Automated Trajectory Negotiation

Improved real-time decision-making capabilities in both civil transport avionics and airline dispatcher workstations are helping to improve commercial aviation operations in many ways. One emerging capability is the automated derivation of alternate flight plans that yield both flight cost savings and smoother workflow. This emerging capability may be complemented with automated trajectory negotiation capabilities. Here we explore such automated trajectory negotiation capabilities, potential benefit mechanisms, and the required tools, procedures, and architectures.

Trajectory↗
NASA NTRS2018

Development of a Ground Test and Analysis Protocol for NASA's NextSTEP Phase 2 Habitation Concepts

The NASA Next Space Technologies for Exploration Partnerships (NextSTEP) program is a public-private partnership model that seeks commercial development of deep space exploration capabilities to support human spaceflight missions around and beyond cislunar space. NASA first issued the Phase 1 NextSTEP Broad Agency Announcement to U.S. industries in 2014, which called for innovative cislunar habitation concepts that leveraged commercialization plans for low-Earth orbit. These habitats will be part of the Deep Space Gateway (DSG), the cislunar space station planned by NASA for construction in the 2020s. In 2016, Phase 2 of the NextSTEP program selected five commercial partners to develop ground prototypes. A team of NASA research engineers and subject matter experts (SMEs) have been tasked with developing the ground-test protocol that will serve as the primary means by which these Phase 2 prototypes will be evaluated. Since 2008, this core test team has successfully conducted multiple spaceflight analog mission evaluations utilizing a consistent set of operational tools, methods, and metrics to enable the iterative development, testing, analysis, and validation of evolving exploration architectures, operations concepts, and vehicle designs. The purpose of implementing a similar evaluation process for the Phase 2 Habitation Concepts is to consistently evaluate different commercial partner ground prototypes to provide data-driven, actionable recommendations for Phase 3. This paper describes the process by which the ground test protocol was developed and the objectives, methods, and metrics by which the NextSTEP Phase 2 Habitation Concepts will be rigorously and systematically evaluated. The protocol has been developed using both a top-down and bottom-up approach. Top-down development began with the Human Exploration and Operations Mission Directorate (HEOMD) exploration objectives and ISS Exploration Capability Study Team (IECST) candidate flight objectives. Strategic questions and associated rationales, derived from these candidate architectural objectives, provide the framework by which the ground-test protocol will address the DSG stack elements and configurations, systems and subsystems, and habitation, science, and EVA functions. From these strategic questions, high-level functional requirements for the DSG were drafted and associated ground-test objectives and analysis protocols were established. Bottom-up development incorporated objectives from NASA SMEs in autonomy, avionics and software, communication, environmental control and life support systems, exercise, extravehicular activity, exploration medical operations, guidance navigation and control, human factors and behavioral performance, human factors and habitability, logistics, Mission Control Center operations, power, radiation, robotics, safety and mission assurance, science, simulation, structures, thermal, trash management, and vehicle health. Top-down and bottom-up objectives were integrated to form overall functional requirements - ground-test objectives and analysis mapping. From this mapping, ground-test objectives were organized into those that will be evaluated through inspection, demonstration, analysis, subsystem standalone testing, and human-in-the-loop (HITL) testing. For the HITL tests, mission-like timelines, procedures, and flight rules have been developed to directly meet ground test objectives and evaluate specific functional requirements. Data collected from these assessments will be analyzed to determine the acceptability of habitation element configurations and the combinations of capabilities that will result in the best habitation platform to be recommended by the test team for Phase 3.

Gernhardt, Michael L.↗
NASA NTRS2016

Status of NASA's Space Launch System

NASA's Space Launch System (SLS) continued to make significant progress in 2015, completing hardware and testing that brings NASA closer to a new era of deep space exploration. The most significant program milestone of the year was completion of Critical Design Review (CDR). A team of independent reviewers concluded that the vehicle design is technically and programmatically ready to move to Design Certification Review (DCR) and launch readiness in 2018. Just four years after program start, every major element has amassed development and flight hardware and completed key tests that will set the stage for a growing schedule of manufacturing and testing in 2016. Key to SLS' rapid progress has been the use of existing technologies adapted to the new launch vehicle. The space shuttle-heritage RS-25 engine is undergoing adaptation tests to prove it can meet SLS requirements and environments with minimal change. The four-segment shuttle-era booster has been modified and updated with an additional propellant segment, new insulation, and new avionics. The Interim Cryogenic Upper Stage is a modified version of an existing upper stage. The first Block I SLS configuration will launch a minimum of 70 metric tons of payload to low Earth orbit (LEO). The vehicle architecture has a clear evolutionary path to more than 100 metric tons and, ultimately, to 130 metric tons. Among the program's major accomplishments in 2015 were the first booster qualification hotfire test, a series of seven RS-25 adaptation hotfire tests, manufacturing of most of the major components for both core stage test articles and first flight tank, delivery of the Pegasus core stage barge, and the upper stage simulator. Renovations to the B-2 test stand for stage green run testing was completed at NASA Stennis Space Center. This year will see the second booster qualification motor hotfire, flight and additional development RS-25 engine tests, and completion of core stage test articles and test stands and several flight article sections. This paper will discuss these and other technical and programmatic successes and challenges over the past year and provide a preview of work ahead before the first flight of this new capability.

Honeycutt, John↗
NASA NTRSDate not supplied

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗
NASA NTRSDate not supplied

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗
NASA NTRSDate not supplied

A Novel RF Architecture for Simultaneous Communication, Navigation, and Remote Sensing with Software-Defined Radio

The rapid growth of SmallSat and CubeSat missions at NASA has necessitated a re-evaluation of communication and remote-sensing architectures. Novel designs for CubeSat-sized single-board computers can now include larger Field-Programmable Gate Arrays (FPGAs) and faster System-on-Chip (SoCs) devices. These components substantially improve onboard processing capabilities so that varying subsystems no longer require an independent processor. By replacing individual Radio Frequency (RF) systems with a single software-defined radio (SDR) and processor, mission designers have greater control over reliability, performance, and efficiency. The presented architecture combines individual processing systems into a single design and establishes a modular SDR architecture capable of both remote-sensing and communication applications. This new approach based on a multi-input multi-output (MIMO) SDR features a scalable architecture optimized for Size, Weight, Power, and Cost (SWaP-C), with sufficient noise performance and phase-coherence to enable both remote-sensing and navigation applications, while providing a communication solution for simultaneous S-band and X-band transmission. This SDR design is developed around the NASA CubeSat Card Standard (CS2) that provides the required modularity through simplified backplane and interchangeable options for multiple radiation-hardened/tolerant processors. This architecture provides missions with a single platform for high-rate communication and a future platform to develop cognitive radio systems.

Advanced Avionics, Hybrid Processing, Data Process↗
NASA NTRS2014

SpaceCube v2.0 Space Flight Hybrid Reconfigurable Data Processing System

This paper details the design architecture, design methodology, and the advantages of the SpaceCube v2.0 high performance data processing system for space applications. The purpose in building the SpaceCube v2.0 system is to create a superior high performance, reconfigurable, hybrid data processing system that can be used in a multitude of applications including those that require a radiation hardened and reliable solution. The SpaceCube v2.0 system leverages seven years of board design, avionics systems design, and space flight application experiences. This paper shows how SpaceCube v2.0 solves the increasing computing demands of space data processing applications that cannot be attained with a standalone processor approach.The main objective during the design stage is to find a good system balance between power, size, reliability, cost, and data processing capability. These design variables directly impact each other, and it is important to understand how to achieve a suitable balance. This paper will detail how these critical design factors were managed including the construction of an Engineering Model for an experiment on the International Space Station to test out design concepts. We will describe the designs for the processor card, power card, backplane, and a mission unique interface card. The mechanical design for the box will also be detailed since it is critical in meeting the stringent thermal and structural requirements imposed by the processing system. In addition, the mechanical design uses advanced thermal conduction techniques to solve the internal thermal challenges.The SpaceCube v2.0 processing system is based on an extended version of the 3U cPCI standard form factor where each card is 190mm x 100mm in size The typical power draw of the processor card is 8 to 10W and scales with application complexity. The SpaceCube v2.0 data processing card features two Xilinx Virtex-5 QV Field Programmable Gate Arrays (FPGA), eight memory modules, a monitor FPGA with analog monitoring, Ethernet, configurable interconnect to the Xilinx FPGAs including gigabit transceivers, and the necessary voltage regulation. The processor board uses a back-to-back design methodology for common parts that maximizes the board real estate available. This paper will show how to meet the IPC 6012B Class 3A standard with a 22-layer board that has two column grid array devices with 1.0mm pitch. All layout trades such as stack-up options, via selection, and FPGA signal breakout will be discussed with feature size results. The overall board design process will be discussed including parts selection, circuit design, proper signal termination, layout placement and route planning, signal integrity design and verification, and power integrity results. The radiation mitigation techniques will also be detailed including configuration scrubbing options, Xilinx circuit mitigation and FPGA functional monitoring, and memory protection.Finally, this paper will describe how this system is being used to solve the extreme challenges of a robotic satellite servicing mission where typical space-rated processors are not sufficient enough to meet the intensive data processing requirements. The SpaceCube v2.0 is the main payload control computer and is required to control critical subsystems such as autonomous rendezvous and docking using a suite of vision sensors and object avoidance when controlling two robotic arms.

Xilinx FPGA↗
NASA NTRS2016

Status of NASA's Space Launch System

NASA's Space Launch System (SLS) continued to make significant progress in 2015 and 2016, completing hardware and testing that brings NASA closer to a new era of deep space exploration. Programmatically, SLS completed Critical Design Review (CDR) in 2015. A team of independent reviewers concluded that the vehicle design is technically and programmatically ready to move to Design Certification Review (DCR) and launch readiness in 2018. Just five years after program start, every major element has amassed development and flight hardware and completed key tests that will lead to an accelerated pace of manufacturing and testing in 2016 and 2017. Key to SLS' rapid progress has been the use of existing technologies adapted to the new launch vehicle. The existing fleet of RS-25 engines is undergoing adaptation tests to prove it can meet SLS requirements and environments with minimal change. The four-segment shuttle-era booster has been modified and updated with a fifth propellant segment, new insulation, and new avionics. The Interim Cryogenic Upper Stage is a modified version of an existing upper stage. The first Block I SLS configuration will launch a minimum of 70 metric tons (t) of payload to low Earth orbit (LEO). The vehicle architecture has a clear evolutionary path to more than 100t and, ultimately, to 130t. Among the program's major 2015-2016 accomplishments were two booster qualification hotfire tests, a series of RS-25 adaptation hotfire tests, manufacturing of most of the major components for both core stage test articles and first flight tank, delivery of the Pegasus core stage barge, and the upper stage simulator. Renovations to the B-2 test stand for stage green run testing was completed at NASA Stennis Space Center. This year will see the completion of welding for all qualification and flight EM-1 core stage components and testing of flight avionics, completion of core stage structural test stands, casting of the EM-1 solid rocket motors, additional testing of RS-25 engines and flight engine controllers This paper will discuss these and other technical and programmatic successes and challenges over the past year and provide a preview of work ahead before the first flight of this new capability.

Honeycutt, John↗
NASA NTRS2016

Status of NASA's Space Launch System

NASA's Space Launch System (SLS) continued to make significant progress in 2015, completing hardware and testing that brings NASA closer to a new era of deep space exploration. The most significant program milestone of the year was completion of Critical Design Review (CDR). A team of independent reviewers concluded that the vehicle design is technically and programmatically ready to move to Design Certification Review (DCR) and launch readiness in 2018. Just four years after program start, every major element has amassed development and flight hardware and completed key tests that will set the stage for a growing schedule of manufacturing and testing in 2016. Key to SLS' rapid progress has been the use of existing technologies adapted to the new launch vehicle. The space shuttle-heritage RS-25 engine is undergoing adaptation tests to prove it can meet SLS requirements and environments with minimal change. The four-segment shuttle-era booster has been modified and updated with an additional propellant segment, new insulation, and new avionics. The Interim Cryogenic Upper Stage is a modified version of an existing upper stage. The first Block I SLS configuration will launch a minimum of 70 metric tons (t) of payload to low Earth orbit (LEO). The vehicle architecture has a clear evolutionary path to more than 100t and, ultimately, to 130t. Among the program's major accomplishments in 2015 were the first booster qualification hotfire test, a series of seven RS-25 adaptation hotfire tests, manufacturing of most of the major components for both core stage test articles and first flight tank, delivery of the Pegasus core stage barge, and the upper stage simulator. Renovations to the B-2 test stand for stage green run testing was completed at NASA Stennis Space Center. This year will see the second booster qualification motor hotfire, flight and additional development RS-25 engine tests, and completion of core stage test articles and test stands and several flight article sections. This paper will discuss these and other technical and programmatic successes and challenges over the past year and provide a preview of work ahead before the first flight of this new capability.

Lyles, Garry↗
NASA NTRS2004

New Generation Power System for Space Applications

The Deep Space Avionics (DSA) Project is developing a new generation of power system building blocks. Using application specific integrated circuits (ASICs) and power switching modules a scalable power system can be constructed for use on multiple deep space missions including future missions to Mars, comets, Jupiter and its moons. The key developments of the DSA power system effort are five power ASICs and a mod ule for power switching. These components enable a modular and scalab le design approach, which can result in a wide variety of power syste m architectures to meet diverse mission requirements and environments . Each component is radiation hardened to one megarad) total dose. The power switching module can be used for power distribution to regular spacecraft loads, to propulsion valves and actuation of pyrotechnic devices. The number of switching elements per load, pyrotechnic firin gs and valve drivers can be scaled depending on mission needs. Teleme try data is available from the switch module via an I2C data bus. The DSA power system components enable power management and distribution for a variety of power buses and power system architectures employing different types of energy storage and power sources. This paper will describe each power ASIC#s key performance characteristics as well a s recent prototype test results. The power switching module test results will be discussed and will demonstrate its versatility as a multip urpose switch. Finally, the combination of these components will illu strate some of the possible power system architectures achievable fro m small single string systems to large fully redundant systems.

power switching↗
NASA NTRS2010

SMART: The Future of Spaceflight Avionics

A novel avionics approach is necessary to meet the future needs of low cost space and lunar missions that require low mass and low power electronics. The current state of the art for avionics systems are centralized electronic units that perform the required spacecraft functions. These electronic units are usually custom-designed for each application and the approach compels avionics designers to have in-depth system knowledge before design can commence. The overall design, development, test and evaluation (DDT&E) cycle for this conventional approach requires long delivery times for space flight electronics and is very expensive. The Small Multi-purpose Advanced Reconfigurable Technology (SMART) concept is currently being developed to overcome the limitations of traditional avionics design. The SMART concept is based upon two multi-functional modules that can be reconfigured to drive and sense a variety of mechanical and electrical components. The SMART units are key to a distributed avionics architecture whereby the modules are located close to or right at the desired application point. The drive module, SMART-D, receives commands from the main computer and controls the spacecraft mechanisms and devices with localized feedback. The sensor module, SMART-S, is used to sense the environmental sensors and offload local limit checking from the main computer. There are numerous benefits that are realized by implementing the SMART system. Localized sensor signal conditioning electronics reduces signal loss and overall wiring mass. Localized drive electronics increase control bandwidth and minimize time lags for critical functions. These benefits in-turn reduce the main processor overhead functions. Since SMART units are standard flight qualified units, DDT&E is reduced and system design can commence much earlier in the design cycle. Increased production scale lowers individual piece part cost and using standard modules also reduces non-recurring costs. The benefit list continues, but the overall message is already evident: the SMART concept is an evolution in spacecraft avionics. SMART devices have the potential to change the design paradigm for future satellites, spacecraft and even commercial applications.

Alhorn, Dean C.↗
NASA NTRS2006

Efficient and Robust Data Collection Using Compact Micro Hardware, Distributed Bus Architectures and Optimizing Software

Future In-Space propulsion systems for exploration programs will invariably require data collection from a large number of sensors. Consider the sensors needed for monitoring several vehicle systems states of health, including the collection of structural health data, over a large area. This would include the fuel tanks, habitat structure, and science containment of systems required for Lunar, Mars, or deep space exploration. Such a system would consist of several hundred or even thousands of sensors. Conventional avionics system design will require these sensors to be connected to a few Remote Health Units (RHU), which are connected to robust, micro flight computers through a serial bus. This results in a large mass of cabling and unacceptable weight. This paper first gives a survey of several techniques that may reduce the cabling mass for sensors. These techniques can be categorized into four classes: power line communication, serial sensor buses, compound serial buses, and wireless network. The power line communication approach uses the power line to carry both power and data, so that the conventional data lines can be eliminated. The serial sensor bus approach reduces most of the cabling by connecting all the sensors with a single (or redundant) serial bus. Many standard buses for industrial control and sensor buses can support several hundreds of nodes, however, have not been space qualified. Conventional avionics serial buses such as the Mil-Std-1553B bus and IEEE 1394a are space qualified but can support only a limited number of nodes. The third approach is to combine avionics buses to increase their addressability. The reliability, EMI/EMC, and flight qualification issues of wireless networks have to be addressed. Several wireless networks such as the IEEE 802.11 and Ultra Wide Band are surveyed in this paper. The placement of sensors can also affect cable mass. Excessive sensors increase the number of cables unnecessarily. Insufficient number of sensors may not provide adequate coverage of the system. This paper also discusses an optimal technique to place and validate sensors.

micro hardware↗
NASA NTRS2005

Remotely Operated Aircraft (ROA) Impact on the National Airspace System (NAS) Work Package, 2005: Composite Report on FAA Flight Plan and Operational Evaluation Plan. Version 7.0

The purpose of this document is to present the findings that resulted from a high-level analysis and evaluation of the following documents: (1) The OEP (Operational Evolution Plan) Version 7 -- a 10-year plan for operational improvements to increase capacity and efficiency in U.S. air travel and transport and other use of domestic airspace. The OEP is the FAA commitment to operational improvements. It is outcome driven, with clear lines of accountability within FAA organizations. The OEP concentrates on operational solutions and integrates safety, certification, procedures, staffing, equipment, avionics and research; (2) The Draft Flight Plan 2006 through 2010 -- a multi-year strategic effort, setting a course for the FAA through 2001, to provide the safest and most efficient air transportation system in the world; (3) The NAS System Architecture Version 5 -- a blueprint for modernizing the NAS and improving NAS services and capabilities through the year 2015; and (4) The NAS-SR-1000 System Requirements Specification (NASSRS) -- a compilation of requirements which describe the operational capabilities for the NAS. The analysis is particularly focused on examining the documents for relevance to existing and/or planned future UAV operations. The evaluation specifically focuses on potential factors that could materially affect the development of a commercial ROA industry, such as: (1) Design limitations of the CNS/ATM system, (2) Human limitations, The information presented was taken from program specifications or program office lead personnel.

Source record↗
NASA NTRS2006

Crew Launch Vehicle (CLV) Avionics and Software Integration Overview

On January 14, 2004, the President of the United States announced a new plan to explore space and extend a human presence across our solar system. The National Aeronautics and Space Administration (NASA) established the Exploration Systems Mission Directorate (ESMD) to develop and field a Constellation Architecture that will bring the Space Exploration vision to fruition. The Constellation Architecture includes a human-rated Crew Launch Vehicle (CLV) segment, managed by the Marshall Space Flight Center (MSFC), comprised of the First Stage (FS), Upper Stage (US), and Upper Stage Engine (USE) elements. The CLV s purpose is to provide safe and reliable crew and cargo transportation into Low Earth Orbit (LEO), as well as insertion into trans-lunar trajectories. The architecture's Spacecraft segment includes, among other elements, the Crew Exploration Vehicle (CEV), managed by the Johnson Space Flight Center (JSC), which is launched atop the CLV. MSFC is also responsible for CLV and CEV stack integration. This paper provides an overview of the Avionics and Software integration approach (which includes the Integrated System Health Management (ISHM) functions), both within the CLV, and across the CEV interface; it addresses the requirements to be met, logistics of meeting those requirements, and the roles of the various groups. The Avionics Integration and Vehicle Systems Test (ANST) Office was established at the MSFC with system engineering responsibilities for defining and developing the integrated CLV Avionics and Software system. The AIVST Office has defined two Groups, the Avionics and Software Integration Group (AVSIG), and the Integrated System Simulation and Test Integration Group (ISSTIG), and four Panels which will direct trade studies and analyses to ensure the CLV avionics and software meet CLV system and CEV interface requirements. The four panels are: 1) Avionics Integration Panel (AIP), 2) Software Integration Panel, 3) EEE Panel, and 4) Systems Simulation and Test Panel. Membership on the groups and panels includes the MSFC representatives from the requisite engineering disciplines, the First Stage, the Upper Stage, the Upper Stage Engine projects, and key personnel from other NASA centers. The four panels will take the results of trade studies and analyses and develop documentation in support of Design Analysis Cycle Reviews and ultimately the System Requirements Review.

Monell, Donald W.↗
NASA NTRS2020

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

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

Krihak, M.↗
NASA NTRS2020

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

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

Krihak, M.↗
NASA NTRS2013

Orion GNC Mitigation Efforts for Van Allen Radiation

The Orion Crew Module (CM) is NASA's next generation manned space vehicle, scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and GN&C architectures have progressed through a number of project phases and are nearing completion of a major milestone. The first unmanned test mission, dubbed "Exploration Flight Test One" (EFT-1) is scheduled to launch from NASA Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and software. The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, which will be launched on an expendable launch vehicle (ELV). The ELV will place CM and the ELV upper stage into a low Earth orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a relatively high velocity, high heating environment. While not producing entry velocities as high as those experienced in returning from a lunar orbit, the trajectory was chosen to provide higher stresses on the thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required entry geometry with constraints on inclination and landing site result in a trajectory that lingers for many hours in the Van Allen radiation belts. This exposes the vehicle and avionics to much higher levels of high energy proton radiation than a typical LEO or lunar trajectory would encounter. As a result, Van Allen radiation poses a significant risk to the Orion avionics system, and particularly the Flight Control Module (FCM) computers that house the GN&C flight software. The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated with the Van Allen radiation on EFT-1 are covered in the paper. Background on the Orion avionics subsystem is provided, as well as an overview of the GN&C software architecture. The measures taken to handle radiation induced failure of the one or both of the FCM's are presented, and finally simulation and actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. The paper presents an overview of the Orion avionics architecture describing the GNC sensors, onboard data network as well as the flight control computers and their planned restart capabilities. GN&C sensors include two Orion Inertial Measurement Units (OIMU's), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters and a single GPS receiver. All of the sensors communicate to one of two Power and Data Units (PDU's). The PDU's multiplex analog and serial data from the sensors and write the data to the Orion Data Network (ODN). The OIMU s write measurement messages directly as onto the ODN, but they are routed through PDU network switches.

King, Ellis T.↗