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.

194 records · Page 11

The Habitat Demonstration Unit Project Overview

This paper will describe an overview of the National Aeronautics and Space Administration (NASA) led multi-center Habitat Demonstration Unit (HDU) Project. The HDU project is a "technology-pull" project that integrates technologies and innovations from numerous NASA centers. This project will be used to investigate and validate surface architectures, operations concepts, and requirements definition of various habitation concepts. The first habitation configuration this project will build and test is the Pressurized Excursion Module (PEM). This habitat configuration - the PEM - is based on the Constellation Architecture Scenario 12.1 concept of a vertically oriented habitat module. The HDU project will be tested as part of the 2010 Desert Research and Technologies Simulations (D-RATS) test objectives. The purpose of this project is to develop, integrate, test, and evaluate a habitat configuration in the context of the mission architectures and surface operation concepts. A multi-center approach will be leveraged to build, integrate, and test the PEM through a shared collaborative effort of multiple NASA centers. The HDU project is part of the strategic plan from the Exploration Systems Mission Directorate (ESMD) Directorate Integration Office (DIO) and the Lunar Surface Systems Project Office (LSSPO) to test surface elements in a surface analog environment. The 2010 analog field test will include two Lunar Electric Rovers (LER) and the PEM among other surface demonstration elements. This paper will describe the overall objectives, its various habitat configurations, strategic plan, and technology integration as it pertains to the 2010 and 2011 field analog tests. To accomplish the development of the PEM from conception in June 2009 to rollout for operations in July 2010, the HDU project team is using a set of design standards to define the interfaces between the various systems of PEM and to the payloads, such as the Geology Lab, that those systems will support. Scheduled activities such as early fit-checks and the utilization of a habitat avionics test bed prior to equipment installation into PEM are planned to facilitate the integration process.

Kennedy, Kriss J.↗

SpaceCube Version 1.5

SpaceCube 1.5 is a high-performance and low-power system in a compact form factor. It is a hybrid processing system consisting of CPU (central processing unit), FPGA (field-programmable gate array), and DSP (digital signal processor) processing elements. The primary processing engine is the Virtex- 5 FX100T FPGA, which has two embedded processors. The SpaceCube 1.5 System was a bridge to the SpaceCube 2.0 and SpaceCube 2.0 Mini processing systems. The SpaceCube 1.5 system was the primary avionics in the successful SMART (Small Rocket/Spacecraft Technology) Sounding Rocket mission that was launched in the summer of 2011. For SMART and similar missions, an avionics processor is required that is reconfigurable, has high processing capability, has multi-gigabit interfaces, is low power, and comes in a rugged/compact form factor. The original SpaceCube 1.0 met a number of the criteria, but did not possess the multi-gigabit interfaces that were required and is a higher-cost system. The SpaceCube 1.5 was designed with those mission requirements in mind. The SpaceCube 1.5 features one Xilinx Virtex-5 FX100T FPGA and has excellent size, weight, and power characteristics [4×4×3 in. (approx. = 10×10×8 cm), 3 lb (approx. = 1.4 kg), and 5 to 15 W depending on the application]. The estimated computing power of the two PowerPC 440s in the Virtex-5 FPGA is 1100 DMIPS each. The SpaceCube 1.5 includes two Gigabit Ethernet (1 Gbps) interfaces as well as two SATA-I/II interfaces (1.5 to 3.0 Gbps) for recording to data drives. The SpaceCube 1.5 also features DDR2 SDRAM (double data rate synchronous dynamic random access memory); 4- Gbit Flash for storing application code for the CPU, FPGA, and DSP processing elements; and a Xilinx Platform Flash XL to store FPGA configuration files or application code. The system also incorporates a 12 bit analog to digital converter with the ability to read 32 discrete analog sensor inputs. The SpaceCube 1.5 design also has a built-in accelerometer. In addition, the system has 12 receive and transmit RS- 422 interfaces for legacy support. The SpaceCube 1.5 processor card represents the first NASA Goddard design in a compact form factor featuring the Xilinx Virtex- 5. The SpaceCube 1.5 incorporates backward compatibility with the Space- Cube 1.0 form factor and stackable architecture. It also makes use of low-cost commercial parts, but is designed for operation in harsh environments.

Geist, Alessandro↗

NASA SpaceCube Intelligent Multi-Purpose System for Enabling Remote Sensing, Communication, and Navigation in Mission Architectures

New, innovative CubeSat mission concepts demand modern capabilities such as artificial intelligence and autonomy, constellation coordination, fault mitigation, and robotic servicing –all of which require vastly more processing resources than legacy systems are capable of providing. Enabling these domains within a scalable, configurable processing architecture is advantageous because it also allows for the flexibility to address varying mission roles, such as a command and data-handling system, a high-performance application processor extension, a guidance and navigation solution, or an instrument/sensor interface. This paper describes the NASA SpaceCube Intelligent Multi-Purpose System (IMPS), which allows mission developers to mix-and-match 1U (10 cm × 10 cm) CubeSat payloads configured for mission-specific needs. The central enabling component of the system architecture to address these concerns is the SpaceCube v3.0 Mini Processor. This single-board computer features the 20nm Xilinx Kintex UltraScale FPGA combined with a radiation-hardened FPGA monitor, and extensive IO to integrate and interconnect varying cards within the system. To unify the re-usable designs within this architecture, the CubeSat Card Standard was developed to guide design of 1U cards. This standard define spinout configurations, mechanical, and electrical specifications for 1U CubeSat cards, allowing the backplane and mechanical enclosure to be easily extended. NASA has developed several cards adhering to the standard (System-on-Chip, power card, etc.), which allows the flexibility to configure a payload from a common catalog of cards.

Advanced Avionics, Hybrid Processing, Data Process↗

How Can We Efficiently Build A Spacecraft That Has Longevity? Experiences From the GSFC Perspective to Inform Lunar Exploration and Science Orbiter’s Architecture

Recent successes in NASA planetary science missions has shown that long-lived missions can yield significant science return. These missions, despite their longevity, were not planned to operate beyond their deign life. For example, the Lunar Reconnaissance Orbiter has a design life of 2-3 years, and yet we are entering its 14th year on orbit. Spacecraft longevity in practice has been related to: 1) mission class; 2) did we test it long enough and resolve all the anomalies to be beyond the early failure curve; 3) consumables budgets, and 4) how components are de-signed and tested. Mission class has been perceived as one of the primary ways to drive longevity. But higher mission class is a significant cost and mission driver. Parts selection only from the limited military standard parts and extensive parts qualification adds to development time and cost. Largely redundant (often erroneously interpreted as fully redundant) adds to launch mass and increases testing complexity (which may reduce the amount of testing in the nominal con-figuration). Lower Risk Posture (reflected in a higher mission class) drives significant additional processes and quality assurance analyses. Higher mission class also drives significantly greater sparing and life testing costs. This discussion focuses on whether this is indeed the best way to achieve longevity efficiently or whether there are more efficient ways to achieve longevity. Empirical evidence shows that lower mission classes that implement effective risk reduction and selective redundancy generally results in long life at a lower Spacecraft bus cost. By evaluating redundancy careful-ly, spacecraft cost can be lowered which can enable a more capable payload. Risk of the mission is highly dependent on the complexity of the mission and is only loosely dependent on Class of Mission. High complexity missions can have many single point failures and require the development of new technology, while lower class mission can have lower risk by baselining or incorporating: (selective) redundancy, fault-tolerant design, design for minimum risk, ability to reset, and/or design for graceful degradation. The team met with Goddard Space Flight Center Space Systems Mission Operations leaders to discuss which avionics have proven in flight to be the most reliable and which have had lifetime issues. The paper proposes a list of components to focus on for redundancy for a long-lived lunar mission. Reliability numbers are presented for both single string and dual string missions. The history of life-time performance versus planned mission life according to mission class is presented. A mission with well thought out selective redundancy and effective on the ground test program, can be expected to last well beyond its mission lifetime and provided enhanced return for the community. This approach minimizes project expenditures that do not retire significant risk and allows the project to focus risk mitigation efforts on those risks that will have a significant likelihood of threatening mission success. This is aided by keeping the amount of technology maturation and mission complexity low, while focusing effort on ensuring all component stress-ing parameters well within the bounds of their capabilities.

Lessons Learned↗

The Pressurized Logistics Module: Providing Consumables and Resupply Logistics to the Lunar Surface for a Long-duration Manned Mission

In response to President Bush s 2004 Vision for Space Exploration initiative, NASA established an agency-wide Lunar Architecture Team (LAT) to develop the high-level requirements, assumptions, ground-rules and objectives for a manned mission to the moon. During Phase II of the evaluation, the Habitation Focus Element Group was directed to conceptually develop and design a Pressurized Logistics Module (PLM). The PLM task was delivered with one major requirement: to derive a system with minimal mass and cost, and a maximum, functional, internal volumetric area in order to provide the maximum amount of consumables, supportability and logistic re-supply for a crew of four to the Lunar surface with an overall integrated maximum weight of 5200kg. The PLM was derived from the Habitation Group s "mini-Hab" option. This concept required that the PLM have an aluminum-clad graphite epoxy external truss, utilized for increased mobility and stability, which would encompass a 2.7 meter diameter pressurized aluminum-lithium cylinder. Several trade studies and analyses were performed to determine the final length and orientation of the module, the number of systems required to maintain the PLM, and the number of hatches/mating mechanisms which would successfully and efficiently meet the requirements. Of the five specific configurations assessed, the PLM was determined to have a 3 meter by 3 meter by 5 meter external truss with a 2.7 meter diameter and 5 meter long horizontal, pressurized cylinder with one hatch/mating mechanism on one end cone. Two major assumptions aided in the formulation of the technical baseline: 1) the PLM should be sustainable for up to 18 months on the Lunar Lander without connection to its final destination, the Lunar Outpost, and 2) it must be self-sufficient to withstand a maximum eight hour transit from the Lander to the Outpost. Per these assumptions, eight major systems constitute the PLM: structures, passive mating, protection, power, thermal, avionics, life support and outfitting. Including a conservative 20% growth, the overall estimated tare weight for the PLM was determined to be 2181kg. The tare weight of the design allowed the available internal volume of the cylinder with a 0.20 meter high floor to transport the maximum of either 176 single Crew Transfer Bags (CTBs) or 3019kg.

Carpenter, Amanda↗

An Introduction to Flight Software Development: FSW Today, FSW 2010

Experience and knowledge gained from ongoing maintenance of Space Shuttle Flight Software and new development projects including Cockpit Avionics Upgrade are applied to projected needs of the National Space Exploration Vision through Spiral 2. Lessons learned from these current activities are applied to create a sustainable, reliable model for development of critical software to support Project Constellation. This presentation introduces the technologies, methodologies, and infrastructure needed to produce and sustain high quality software. It will propose what is needed to support a Vision for Space Exploration that places demands on the innovation and productivity needed to support future space exploration. The technologies in use today within FSW development include tools that provide requirements tracking, integrated change management, modeling and simulation software. Specific challenges that have been met include the introduction and integration of Commercial Off the Shelf (COTS) Real Time Operating System for critical functions. Though technology prediction has proved to be imprecise, Project Constellation requirements will need continued integration of new technology with evolving methodologies and changing project infrastructure. Targets for continued technology investment are integrated health monitoring and management, self healing software, standard payload interfaces, autonomous operation, and improvements in training. Emulation of the target hardware will also allow significant streamlining of development and testing. The methodologies in use today for FSW development are object oriented UML design, iterative development using independent components, as well as rapid prototyping . In addition, Lean Six Sigma and CMMI play a critical role in the quality and efficiency of the workforce processes. Over the next six years, we expect these methodologies to merge with other improvements into a consolidated office culture with all processes being guided by automated office assistants. The infrastructure in use today includes strict software development and configuration management procedures, including strong control of resource management and critical skills coverage. This will evolve to a fully integrated staff organization with efficient and effective communication throughout all levels guided by a Mission-Systems Architecture framework with focus on risk management and attention toward inevitable product obsolescence. This infrastructure of computing equipment, software and processes will itself be subject to technological change and need for management of change and improvement,

Gouvela, John↗

High-Altitude ADS-B/GPS LPV Flight Tests on a NASA ER-2 Research Airplane

The research presented in this paper describes the conceptual design of a system architecture that integrates Automatic Dependent Surveillance-Broadcast (ADS-B) and Global Positioning System (GPS) Localizer Performance Vertical (LPV) guidance technology onto a unique high-altitude research airplane: a United States Air Force (USAF) / Lockheed Martin (Bethesda, Maryland) Aeronautics U-2S airplane. The design features modern display capabilities to provide air-to-air surveillance and precision navigation, to adhere to Federal Aviation Administration (FAA) certification standards for operations in upper Class E airspace. The National Aeronautics and Space Administration (NASA) variant of the U-2S, now called the Earth Resources (ER-2) airplane, remains unrivaled in the art of sustained high-altitude flight for scientific expeditions. Capable of routinely cruising above flight level (FL) 650 that had been considered, at inception, the domain of only the most elite experimental research aircraft types. Nicknamed the Dragon Lady, this U-2S research testbed is still one of the most advanced aircraft in the world. The exceptional military design of the vehicle, security guidelines, and the performance envelope of the ER-2 posed unique challenges to the integration of modern civilian avionics. ADS-B epitomizes the next generation of surveillance technology, incorporating both air and ground aspects. ADS-B provides air traffic control (ATC) with a more accurate picture of the three-dimensional positioning of aircraft in various phases of flight, including en route, terminal, approach, and ground operations. The airborne surveillance system broadcasts its identification, position, altitude, velocity, and other information. GPS LPV represents a significant advancement in aviation technology, emphasizing the pivotal role that GPS and Performance-Based Navigation concepts will play in the foreseeable future. This technology represents a shift from sensor-based navigation to performance-based navigation, allowing for more flexible and efficient use of airspace. This research described herein is structured as follows: Section II, “Systems Background,” provides a systems background and description of an ADS-B and GPS LPV system equipped on the high-altitude ER-2 research airplane to satisfy the FAA airworthiness requirements for high-altitude flight operations. Section III, “Flight Test System,” describes the flight-test airplane systems. Section IV, “Analysis of GPS SBAS, Safety, and Ground Tests,” provides an overview of the GPS Satellite-Based Augmentation System (SBAS) and an analysis of the GPS LPV metrics, safety, and ground tests. Section V, “High-Altitude Flight Tests,” describes the high-altitude flight tests, including 3 flight-test results, analysis, human factors, and lessons learned. Section VI, the conclusion, draws insights from the lessons learned, discusses the design challenges associated with ADS-B and GPS LPV, and showcases the paramount significance of these pivotal technologies in aircraft surveillance and navigation.

Ricardo A. Arteaga↗

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗

Human Exploration Spacecraft Testbed for Integration and Advancement (HESTIA)

The proposed paper will cover ongoing effort named HESTIA (Human Exploration Spacecraft Testbed for Integration and Advancement), led at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) to promote a cross-subsystem approach to developing Mars-enabling technologies with the ultimate goal of integrated system optimization. HESTIA also aims to develop the infrastructure required to rapidly test these highly integrated systems at a low cost. The initial focus is on the common fluids architecture required to enable human exploration of mars, specifically between life support and in-situ resource utilization (ISRU) subsystems. An overview of the advancements in both integrated technologies, in infrastructure, in simulation, and in modeling capabilities will be presented, as well as the results and findings of integrated testing,. Due to the enormous mass gear-ratio required for human exploration beyond low-earth orbit, (for every 1 kg of payload landed on Mars, 226 kg will be required on Earth), minimization of surface hardware and commodities is paramount. Hardware requirements can be minimized by reduction of equipment performing similar functions though for different subsystems. If hardware could be developed which meets the requirements of both life support and ISRU it could result in the reduction of primary hardware and/or reduction in spares. Minimization of commodities to the surface of mars can be achieved through the creation of higher efficiency systems producing little to no undesired waste, such as a closed-loop life support subsystem. Where complete efficiency is impossible or impractical, makeup commodities could be manufactured via ISRU. Although, utilization of ISRU products (oxygen and water) for crew consumption holds great promise of reducing demands on life support hardware, there exist concerns as to the purity and transportation of commodities. To date, ISRU has been focused on production rates and purities for propulsion needs. The meshing of requirements between all potential users, producers, and cleaners of oxygen and water is crucial to guiding the development of technologies which will be used to perform these functions. Various new capabilities are being developed as part of HESTIA, which will enable the integrated testing of these technologies. This includes the upgrading of a 20' diameter habitat chamber to eventually support long duration (90+ day) human-in-the-loop testing of advanced life support systems. Additionally, a 20' diameter vacuum chamber is being modified to create Mars atmospheric pressures and compositions. This chamber, designated the Mars Environment Chamber (MEC), will eventually be upgraded to include a dusty environment and thermal shroud to simulate conditions on the surface of Mars. In view that individual technologies will be in geographically diverse locations across NASA facilities and elsewhere in the world, schedule and funding constraints will likely limit the frequency of physical integration. When this is the case, absent subsystems can be either digitally or physically simulated. Using the Integrated Power Avionics and Software (iPAS) environment, HESTIA is able to bring together data from various subsystems in simulated surroundings, insert faults, errors, time delays, etc., and feed data into computer models or physical systems capable of reproducing the output of the absent subsystems for the consumption of a local subsystems. Although imperfect, this capability provides opportunities to test subsystem integration and interactions at a fraction of the cost. When a subsystem technology is too immature for integrated testing, models can be produced using the General-Use Nodal Network Solver (GUNNS) capability to simulate the overall system performance. In doing so, even technologies not yet on the drawing board can be integrated and overall system performance estimated. Through the integrated development of technologies, as well as of the infrastructure to rapidly and at a low cost, model, simulate, and test subsystem technologies early in their development, HESTIA is pioneering a new way of developing the future of human space exploration.

Banker, Brian F.↗

BRAINSTACK – A Platform for Artificial Intelligence & Machine Learning Collaborative Experiments on a Nano-Satellite

As the space economy continues to expand through increasingly easy access to advanced and inexpensive technology, space missions themselves have become more ambitious with exploration targets growing ever distant while simultaneously requiring larger guidance and communication budgets. These conflicting desires of distance and control drive the need for advanced on-board intelligent decision making to reduce communication and control limitations by automating as many mission functions as possible in-situ. While the amount of research on such Artificial Intelligence and Machine Learning (AI/ML) software modules has grown exponentially, the capacity to experimentally validate such software modules in space in a rapid and inexpensive format has not. To this end, the Nano Orbital Workshop (NOW) group at NASA Ames Research Center has been at the forefront of performing initial flight evaluation tests of ‘commercially’ available bleeding-edge computational platforms via what is programmatically referred to as the BrainStack on the TechEdSat (TES-n) flight series. This on-orbit computational platform provides an evaluation laboratory where advanced software experiments are pre-loaded into memory prior to launch, then executed as payloads during mission operations with results reported back and program tweaks or new training sets uploaded as needed. Processors selected as part of the BrainStack are of ideal size, packaging, and power consumption for easy integration into a cube satellite structure. These experiments have included the evaluation of small, high-performance GPUs and, more recently, neuromorphic processors, in LEO operations. Neuromorphic processors are of particular interest due to their superior power efficiency over GPUs in intelligent automation applications. The first TES-n flight test of an Intel first-generation Loihi neuromorphic processor launched on TES-13, January 13, 2022, and continues to operate in orbit despite no significant modifications to harden the processor against the space environment. The Intel Loihi Gen-1 on TES-13 is characterized by a 14nm 128-core Spiking Neural Network (SNN) able to support on-chip training. The processor is packaged in the Kapoho Bay USB module, providing a relatively straight-forward interface to the bus avionics system. The Kapoho Bay was in turn managed by an Intel Pentium single-board computer to handle scheduling of the software application payloads and communications with the satellite’s primary computer. The recently released Intel Loihi Gen-2, able to support integer-valued spike payloads and produced using 7nm process, will form part of the continually evolving BrainStack in the upcoming three TES-n/NOW flights. The Kapoho Point unit will incorporate eight Loihi-2 processors, enabling neural networks of up to one million neurons and one billion synapsis. Additionally, it is planned to measure the radiation environment these processors experience to understand any degradation or computational artifacts caused by long term space radiation exposure on these novel architectures. This evolving flexible and collaborative environment involving various research teams across NASA and other organizations is intended to be a convenient orbital test platform from which many anticipated future space automation applications may be initially tested.

Artificial Intelligence↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗

Computational Modeling to Limit the Impact Displays and Indicator Lights Have on Habitable Volume Operational Lighting Constraints

NASA has demonstrated an interest in improving astronaut health and performance through the installment of a new lighting countermeasure on the International Space Station. The Solid State Lighting Assembly (SSLA) system is designed to positively influence astronaut health by providing a daily change to light spectrum to improve circadian entrainment. Unfortunately, existing NASA standards and requirements define ambient light level requirements for crew sleep and other tasks, yet the number of light-emitting diode (LED) indicators and displays within a habitable volume is currently uncontrolled. Because each of these light sources has its own unique spectral properties, the additive lighting environment ends up becoming something different from what was planned or researched. Restricting the use of displays and indicators is not a solution because these systems provide beneficial feedback to the crew. The research team for this grant used computer-based computational modeling and real-world lighting mockups to document the impact that light sources other than the ambient lighting system contribute to the ambient spectral lighting environment. In particular, the team was focused on understanding the impacts of long-term tasks located in front of avionics or computer displays. The team also wanted to understand options for mitigating the changes to the ambient light spectrum in the interest of maintaining the performance of a lighting countermeasure. The project utilized a variety of physical and computer-based simulations to determine direct relationships between system implementation and light spectrum. Using real-world data, computer models were built in the commercially available optics analysis software Zemax Optics Studio(c). The team also built a mockup test facility that had the same volume and configuration as one of the Zemax models. The team collected over 1200 spectral irradiance measurements, each representing a different configuration of the mockup. Analysis of the data showed a measurable impact on ambient light spectrum. This data showed that obvious design techniques exist that can be used to bind the ambient light spectrum closer to the planned spectral operating environment for the observer's eye point. The following observations should be considered when designing an operational environment that is dominated by computer displays. When more light is directed into the field of view of the observer, the greater the impact it will make on various human factors issues that depend on spectral shape and intensity. Because viewing angle has a large part to play in the amount of light flux on the crewmember's retina, beam shape, combined with light source location is an important factor for determining percent probable incident flux on the observer from any combination of light sources. Computer graphics design and display lumen output are major factors influencing the amount of spectrally intense light projected into the environment and in the viewer's direction. Use of adjustable white point display software was useful only if the predominant background color was white and if it matched the ambient light system's color. Display graphics that used a predominantly black background had the least influence on unplanned spectral energy projected into the environment. Percent reflectance makes a difference in total energy reflected back into an environment, and within certain architectural geometries, reflectance can be used to control the amount of a light spectrum that is allowed to perpetuate in the environment. Data showed that room volume and distance from significant light sources influence the total spectrum in a room. Smaller environments had a homogenizing effect on total light spectrum, whereas light from multiple sources in larger environments was less mixed. The findings indicated above should be considered when making recommendations for practice or standards for architectural systems. The ambient lighting system, surface reflectance, and display and indicator implementation all factor into the users' spectral environment. A variety of low-cost solutions exist to mitigate the impact of light from non-architectural lighting systems, and much potential for system automation and integration of display systems with the ambient environment. This team believes that proper planning can be used to avoid integration problems and also believes that human-in-the-loop evaluations, real-world test and measurement, and computer modeling can be used to determine how changes to a process, display graphics, and architecture will help maintain the planned spectral operating lighting environment.

Clark, T. A.↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗