Results for “core Flight Software” — Page 8

NASA NTRS1991

The development of a post-test diagnostic system for rocket engines

An effort was undertaken by NASA to develop an automated post-test, post-flight diagnostic system for rocket engines. The automated system is designed to be generic and to automate the rocket engine data review process. A modular, distributed architecture with a generic software core was chosen to meet the design requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine data review process. The system modules currently under development are the session/message manager, and portions of the applications section, the component analysis section, and the intelligent knowledge server. An overview is presented of a rocket engine data review process, the design requirements and guidelines, the architecture and modules, and the projected benefits of the automated diagnostic system.

Zakrajsek, June F.↗

NASA NTRS2000

X-33 Leading the Way to VentureStar(Trademark) in this Decade

The X-33, reusable space plane technology demonstrator is on course to begin the flights of the X-33 by the end of 2002 that will serve as a basis for industry and government decisions that could lead to VentureStar(Trademark). Lockheed Martin has placed the VentureStar(Trademark) LLC in it's Space Company and is now competing in an industry wide effort that will permit NASA to select a Second Generation RLV source by 2005. This move provides the focus for firm business planning needed to enable the decision by the time X-33 flies in mid 2002 and possibly with upgraded technologies a year or so later. Since the IAF 50th Congress in Amsterdam, most of the major hardware elements of X-33 have been through their assembly and test. The flight liquid oxygen tank was the first major element to complete final assembly. Aerospike Engine qualification testing has progressed successfully through its test objectives and the two flight engines are in preparation to be delivered to the Assembly Facility in Palmdale. All Thermal Protection System (TPS) metallic panels have completed qualification testing and have been delivered to Palmdale and all remaining TPS elements have been assembled and are ready for delivery. Flight Software and Avionics have been delivered and are in integration testing. In November 1999, the first graphite composite liquid hydrogen tank experienced a debond between the tank inner skin and the honeycomb core in testing. This tank had completed its third successful cryogenic and loads testing at MSFC. Replacement liquid hydrogen tanks have completed design and are in fabrication. The resulting delay from this change of design for the liquid hydrogen tank will be approximately two years.

Austin, Robert E.↗

NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗

NASA NTRS2017

Agile: From Software to Mission Systems

To maximize efficiency and flexibility in Mission Operations System (MOS) design, we are evolving principles from agile and lean methods for software, to the complete mission system. This allows for reduced operational risk at reduced cost, and achieves a more effective design through early integration of operations into mission system engineering and flight system design. The core principles are assessment of capability through demonstration, risk reduction through targeted experiments, early test and deployment, and maturation of processes and tools through use.

Trimble, Jay↗

NASA NTRS2019

Autonomous Operating System (AOS)

The Autonomy Operating System (AOS) is a software system that enables core capabilities for the autonomous operations for an unmanned aircraft. It is based on the NASA cFS system and provides a higher-level layer of infrastructure and applications for the execution of flight plans, natural-language communication with Air Traffic Control, Diagnostics, Prognostics, and contingency planning.

Lowry, Michael R.↗

NASA NTRS2014

Simulation Technology at NASA

NASA Ames Research Center is home to several high-fidelity research flight and air-traffic control simulation facilities which, together with an experienced workforce, produce high-quality research data and findings that have proven to be applicable in the real world. These assets include the Vertical Motion Simulator (VMS), Crew Vehicle Systems Research Facility (CVSRF), Future Flight Central (FFC) air traffic control tower simulator, and several air-traffic control (ATC) simulators. The VMS combines a high-fidelity simulation capability with an adaptable simulation environment, enabling customization for numerous human-in-the-loop research applications. The distinctive feature of the VMS is its unparalleled large amplitude, high-fidelity motion capability. In over 30 years of continuous operation, the VMS has contributed significantly to the body of knowledge in a range of disciplines directly benefiting several aerospace programs and flight safety, including the design and development of flight control systems for the Joint Strike Fighter, Space Shuttle Orbiter, and rotorcraft. It continues to be used for researching new vehicle configurations, vehicle control and safety, transfer-of-training, etc., by NASA, other government agencies, and Industry.The CVSRF includes two motion-based flight simulators: a Boeing 747-400 full flight simulator and the reconfigurable Advanced Concepts Flight Simulator (ACFS). These simulators are primarily used to research air-traffic management concepts and procedures, advanced navigation and avionics concepts, and cockpit human factors. FFC is a full-sized control tower simulator with a 360-degree external field-of-view display system and reconfigurable system architecture. FFC and the ATC simulators are used for testing air-traffic management automation and decision support tools and demonstrate their feasibility in a realistic environment prior to technology transfer for implementation in the National Airspace System (NAS).To support integrated simulations and flight-tests for NASA's Unmanned Aircraft Systems (UAS) in the National Airspace System (NAS) Project, NASA developed a distributed test environment incorporating Live, Virtual, Constructive, (LVC) concepts. Development of the software enabling the LVC is conducted primarily at the Distributed Simulation Research Lab (DSRL) at NASA Ames. The LVC components provide the core infrastructure supporting simulation of UAS operations by integrating live and virtual aircraft in a realistic air traffic environment. This provides the ability to conduct tests more efficiently by promoting the use of existing distributed assets. The LVC infrastructure was used in several human-in-the-loop simulations to evaluate acceptance of Detect and Avoid (DAA) advisories used by UAS pilots to maintain well clear of other virtual traffic and to negotiate maneuvers with air traffic control. It is currently being used to support testing of self-separation algorithms between unmanned and manned aircraft in live flight. Further simulations with more comprehensive air traffic scenarios mixing live and virtual aircraft is planned.In the current fiscal environment, maintaining and upgrading these high-fidelity simulation assets and retaining the skilled workforce necessary to meet future research needs is the primary non-technical challenge.

CVSRF↗

NASA NTRS2018

High-Performance Spaceflight Computing (HPSC) Project Overview

The High Performance Spaceflight Computing (HPSC) multi-core processor Chiplet will provide a nearly two orders-of-magnitude improvement above the current state of the art for spaceflight processors, while also providing an unprecedented flexibility to tailor performance, power consumption, and fault tolerance to meet widely varying mission needs. These advancements will provide game changing improvements in computing performance, power efficiency, and flexibility, which will significantly improve the onboard processing capabilities of future NASA and Air Force space missions. HPSC is funded by NASA's Space Technology Mission Directorate (STMD), Science Mission Directorate (SMD), and the United States Air Force. The HPSC project is managed by Jet Propulsion Laboratory, and the HPSC contract is managed by NASA Goddard Space Flight Center (GSFC). Within the HPSC project, Boeing is under contract to NASA to develop prototype Chiplets, system software, and evaluation boards. As another development within the project, NASA Goddard Space Flight Center (GSFC) and the Jet Propulsion Laboratory (JPL) are developing middleware that will simplify application development for HPSC-based onboard processors.

multi-core processor↗

NASA NTRS2018

GPM Mission's Best Practices: PERP

Similar to other missions, the Global Precipitation Measurement (GPM) Core Observatory's Command and Data Handling (C&DH) subsystem is critical for operations of the spacecraft. The onboard C&DH system comprises of two fully redundant boxes - a primary and a cold backup. Within each box, amongst other components, is a Single Board Computer (SBC) that hosts the flight software (FSW) system. In the event of an SBC reset, the Flight Operations Team (FOT) is poised with a lengthy task of restoring the SBC to nominal configuration. Due to the complexity of the C&DH system, this may take many days at a time to complete. The spacecraft's FSW applications are located in Electronically Erasable Programmable Read-Only Memory (EEPROM) and are copied into Random Access Memory (RAM) upon SBC initialization/reset. Each SBC has two banks of EEPROM, with each bank containing a copy of the FSW. Since launch, there have been many configuration changes to tables and applications that have been loaded into just RAM. Unfortunately, these changes are vulnerable to being wiped during a SBC initialization/reset, when the RAM is overwritten by the EEPROM. Although the EEPROM loads the default FSW configurations, the process to command non-default individual table and application changes is very cumbersome and time consuming. This consequentially increases the time until the spacecraft is back into nominal Mission Science Mode (MSM) drastically. The GPM Power-On Reset (POR) Expedited Recovery Process (PERP) Design introduces a method of consolidating commands into a single file load which the SBC can process independently of the ground - decreasing recovery time, the level of TDRS support reliance, and human error. This tested design can be implemented across many other missions that utilize a similar core Flight Executive (cFE) platform; hence providing an easy-to-follow, safe, and efficient process that can be applied across the board.

recovery↗

NASA NTRS1998

Flight Guidance System Validation Using SPIN

To verify the requirements for the mode control logic of a Flight Guidance System (FGS) we applied SPIN, a widely used software package that supports the formal verification of distributed systems. These requirements, collectively called the FGS specification, were developed at Rockwell Avionics & Communications and expressed in terms of the Consortium Requirements Engineering (CoRE) method. The properties to be verified are the invariants formulated in the FGS specification, along with the standard properties of consistency and completeness. The project had two stages. First, the FGS specification and the properties to be verified were reformulated in PROMELA, the input language of SPIN. This involved a semantics issue, as some constructs of the FGS specification do not have well-defined semantics in CoRE. Then we attempted to verify the requirements' properties using the automatic model checking facilities of SPIN. Due to the large size of the state space of the FGS specification an exhaustive state space analysis with SPIN turned out to be impossible. So we used the supertrace model checking procedure of SPIN that provides for a partial analysis of the state space. During this process, we found some subtle errors in the FGS specification.

Naydich, Dimitri↗

NASA NTRS1993

Mongoose: Creation of a Rad-Hard MIPS R3000

This paper describes the development of a 32 Bit, full MIPS R3000 code-compatible Rad-Hard CPU, code named Mongoose. Mongoose progressed from contract award, through the design cycle, to operational silicon in 12 months to meet a space mission for NASA. The goal was the creation of a fully static device capable of operation to the maximum Mil-883 derated speed, worst-case post-rad exposure with full operational integrity. This included consideration of features for functional enhancements relating to mission compatibility and removal of commercial practices not supported by Rad-Hard technology. 'Mongoose' developed from an evolution of LSI Logic's MIPS-I embedded processor, LR33000, code named Cobra, to its Rad-Hard 'equivalent', Mongoose. The term 'equivalent' is used to infer that the core of the processor is functionally identical, allowing the same use and optimizations of the MIPS-I Instruction Set software tool suite for compilation, software program trace, etc. This activity was started in September of 1991 under a contract from NASA-Goddard Space Flight Center (GSFC)-Flight Data Systems. The approach affected a teaming of NASA-GSFC for program development, LSI Logic for system and ASIC design coupled with the Rad-Hard process technology, and Harris (GASD) for Rad-Hard microprocessor design expertise. The program culminated with the generation of Rad-Hard Mongoose prototypes one year later.

Lincoln, Dan↗

NASA NTRS2015

NASA's Space Launch System Program Update

Hardware and software for the world's most powerful launch vehicle for exploration is being welded, assembled, and tested today in high bays, clean rooms and test stands across the United States. NASA's Space Launch System (SLS) continued to make significant progress in 2014 with more planned for 2015, including firing tests of both main propulsion elements and the program Critical Design Review (CDR). Developed with the goals of safety, affordability, and sustainability, SLS will still deliver unmatched capability for human and robotic exploration. The initial Block 1 configuration will deliver more than 70 metric tons of payload to low Earth orbit (LEO). The evolved Block 2 design will deliver some 130 metric tons to LEO. Both designs offer enormous opportunity and flexibility for larger payloads, simplifying payload design as well as ground and on-orbit operations, shortening interplanetary transit times, and decreasing overall mission risk. Over the past year, every vehicle element has manufactured or tested hardware. An RS-25 liquid propellant engine was hotfire-tested at NASA's Stennis Space Center, Miss. for the first time since 2009 exercising and validating the new engine controller, the renovated A-1 test stand, and the test teams. Four RS-25s will power the SLS core stage. A qualification five-segment solid rocket motor incorporating several design, material, and process changes was scheduled to be test-fired in March at the prime contractor's facility in Utah. The booster also successfully completed its Critical Design Review (CDR) validating the planned design. All six major manufacturing tools for the core stage are in place at the Michoud Assembly Facility in Louisiana, and have been used to build numerous pieces of confidence, qualification, and even flight hardware, including barrel sections, domes and rings used to assemble the world's largest rocket stage. SLS Systems Engineering accomplished several key tasks including vehicle avionics software and hardware build and testing, scale model acoustic and base heating tests. Construction of the Interim Cryogenic Propulsion Stage (ICPS) began. Advanced development provided a look into the future of SLS. Shell buckling knockdown factor testing refined decades-old design margins that added thousands of pounds to rocket payloads. Adaptive manufacturing and structured light scanning development promised to cut the cost and time associated with manufacturing and testing. This paper will provide an overview of the progress made over the past year and provide a glimpse of 2015 milestones and beyond on the way to the first launch in 2018.

May, Todd↗

NASA NTRS2015

NASA's Space Launch System Program Update

Hardware and software for the world's most powerful launch vehicle for exploration is being welded, assembled, and tested today in high bays, clean rooms and test stands across the United States. NASA's Space Launch System (SLS) continued to make significant progress in 2014 with more planned for 2015, including firing tests of both main propulsion elements and the program Critical Design Review (CDR). Developed with the goals of safety, affordability, and sustainability, SLS will still deliver unmatched capability for human and robotic exploration. The initial Block 1 configuration will deliver more than 70 metric tons of payload to low Earth orbit (LEO). The evolved Block 2 design will deliver some 130 metric tons to LEO. Both designs offer enormous opportunity and flexibility for larger payloads, simplifying payload design as well as ground and on-orbit operations, shortening interplanetary transit times, and decreasing overall mission risk. Over the past year, every vehicle element has manufactured or tested hardware. An RS-25 liquid propellant engine was hotfire-tested at NASA's Stennis Space Center, Miss. for the first time since 2009 exercising and validating the new engine controller, the renovated A-1 test stand, and the test teams. Four RS-25s will power the SLS core stage. A qualification five-segment solid rocket motor incorporating several design, material, and process changes was scheduled to be test-fired in March at the prime contractor's facility in Utah. The booster also successfully completed its Critical Design Review (CDR) validating the planned design. All six major manufacturing tools for the core stage are in place at the Michoud Assembly Facility in Louisiana, and have been used to build numerous pieces of confidence, qualification, and even flight hardware, including barrel sections, domes and rings used to assemble the world's largest rocket stage. SLS Systems Engineering accomplished several key tasks including vehicle avionics software and hardware build and testing, scale model acoustic and base heating tests. Construction of the Interim Cryogenic Propulsion Stage (ICPS) began. Advanced development provided a look into the future of SLS. Shell buckling knockdown factor testing refined decades-old design margins that added thousands of pounds to rocket payloads. Adaptive manufacturing and structured light scanning development promised to cut the cost and time associated with manufacturing and testing. This paper will provide an overview of the progress made over the past year and provide a glimpse of 2015 milestones and beyond on the way to the first launch in 2018.

May, Todd↗

DOE OSTI2021

White Rabbit Time Synchronization for Radiation Detector Readout Electronics

As radiation detector arrays in nuclear physics applications become larger and physically more separated, the time synchronization and trigger distribution between many channels of detector readout electronics become more challenging. Clocks and triggers are traditionally distributed through dedicated cabling, but newer methods such as the IEEE 1588 Precision Time Protocol and White Rabbit allow clock synchronization through the exchange of timing messages over Ethernet. Consequently, we report here the use of White Rabbit in a new detector readout module, the Pixie-Net XL. Herein, the White Rabbit core, data capture from multiple digitizing channels, and subsequent pulse processing for pulse height and constant fraction timing are implemented in a Kintex 7 FPGA. The detector data records include White Rabbit time stamps and are transmitted to storage through the White Rabbit core's gigabit Ethernet data path or a slower diagnostic/control link using an embedded Zynq processor. The performance is characterized by time-of-flight style measurements and by time correlation of high energy background events from cosmic showers in detectors separated by longer distances. Software for the Zynq processor can implement "software triggering", for example to limit recording of data to events where a minimum number of channels from multiple modules detect radiation at the same time.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

NASA NTRS1997

Managing Satellites

Integral Systems, Inc.'s EPOCH 2000 forms the core of NASA's Near Earth Asteroid Rendezvous (NEAR) mission's command and control center. EPOCH 2000, which allows ground operators to monitor and control satellites over a wide area network, owes part of its heritage from work completed to support Goddard Space Flight Center. The software automates telemetry processing, commanding, anomaly detection, and archiving collected data. The NEAR spacecraft, launched in February 1996, will rendezvous in early 1999 and orbit the Asteroid Eros for a year. Integral Systems also provided Low Earth Orbit Autonomous Ground Terminals (LEO-Ts) to NASA. The LEO-T is designed to make it easier and less expensive for principal investigators to obtain telemetry, tracking and control services for their science missions. The company products have supported well over 70 satellite missions aimed at scientific research, meteorology, or communications applications.

Source record↗

NASA NTRS2016

Approximation of Engine Casing Temperature Constraints for Casing Mounted Electronics

The performance of propulsion engine systems is sensitive to weight and volume considerations. This can severely constrain the configuration and complexity of the control system hardware. Distributed Engine Control technology is a response to these concerns by providing more flexibility in designing the control system, and by extension, more functionality leading to higher performing engine systems. Consequently, there can be a weight benefit to mounting modular electronic hardware on the engine core casing in a high temperature environment. This paper attempts to quantify the in-flight temperature constraints for engine casing mounted electronics. In addition, an attempt is made at studying heat soak back effects. The Commercial Modular Aero Propulsion System Simulation 40k (C-MAPSS40k) software is leveraged with real flight data as the inputs to the simulation. A two-dimensional (2-D) heat transfer model is integrated with the engine simulation to approximate the temperature along the length of the engine casing. This modification to the existing C-MAPSS40k software will provide tools and methodologies to develop a better understanding of the requirements for the embedded electronics hardware in future engine systems. Results of the simulations are presented and their implications on temperature constraints for engine casing mounted electronics is discussed.

Engine↗

NASA NTRS2017

Approximation of Engine Casing Temperature Constraints for Casing Mounted Electronics

The performance of propulsion engine systems is sensitive to weight and volume considerations. This can severely constrain the configuration and complexity of the control system hardware. Distributed Engine Control technology is a response to these concerns by providing more flexibility in designing the control system, and by extension, more functionality leading to higher performing engine systems. Consequently, there can be a weight benefit to mounting modular electronic hardware on the engine core casing in a high temperature environment. This paper attempts to quantify the in-flight temperature constraints for engine casing mounted electronics. In addition, an attempt is made at studying heat soak back effects. The Commercial Modular Aero Propulsion System Simulation 40k (C-MAPSS40k) software is leveraged with real flight data as the inputs to the simulation. A two-dimensional (2-D) heat transfer model is integrated with the engine simulation to approximate the temperature along the length of the engine casing. This modification to the existing C-MAPSS40k software will provide tools and methodologies to develop a better understanding of the requirements for the embedded electronics hardware in future engine systems. Results of the simulations are presented and their implications on temperature constraints for engine casing mounted electronics is discussed.

Engine↗

NASA NTRS2019

"Sensor Web Evolution - Webs of Webs for NASA Science - Focus on small Uninhabited Aerial Systems (sUAS)"

This paper will describe the evolution of information collection, derivation and delivery mechanisms in webs of NASA sensor webs, with a focus on recent advancements in small Uninhabited Aerial Systems (sUAS). I will discuss the movement to "Fog Computing", also known as Edge Computing. Fog Computing facilitates the distribution of common operations and networking between edge devices and cloud computing facilities, optimizing the production of actionable intelligence. Initially, sUASs utilized onboard data collection as standard, with minimal data downloaded directly. Information products were derived in conventional computational environments, generally desk top computers, and information products made available to the Science Community in weeks or months. With the increased availability, and increasingly lower costs, of beyond line of sight (BLOS) satellite based communication, transmission rates and data volumes increased, and processing migrated to Cloud based services. Contemporary sUASs are moving some of that information product derivation to on vehicle services, and are creating a distributed Cloud/Fog environment. I will describe the technological advances that have made this possible, including low power multi-core Central Processing Units (CPU), and, more recently, the availability of high end Graphical Processing Units (GPU) that consume only a few watts. Intelligent system software, leveraging these hardware advances, finally allows for information product generation on-board, rather than simple data collection. Additionally, intelligent flight control systems now support mutual vehicle to vehicle collaboration, allowing sUASs to create ad-hoc sensor webs on demand, as required. Also discussed will be the lessons learned by the Authors' development of data systems for NASA's large High Altitude Long Endurance (HALE) UASs like Predator and Global Hawk, and how those lessons are being applied to sUAS development. This paper will focus on application, rather a deep dive into the technology, and will highlight improving data management through these new technologies.

Sensor Web↗

NASA NTRSDate not supplied

UASs in the VOG/Edge/FOG Sensor Web Environment

This paper will describe the evolution of information collection, derivation and delivery mechanisms in sensor webs utilizing Uninhabited Aerial Systems (UAS).We will discuss the movement to "Fog Computing", also known as Edge Computing. Fog Computing facilitates the distribution of common operations and networking between edge devices and cloud computing facilities, optimizing the production of actionable intelligence. Initially, UASs utilized onboard data collection as standard, with minimal data downloaded directly. Information products were derived in conventional computational environments, generally desk top computers, and information products made available to the Science Community in weeks or months. With the increased availability, and increasingly lower costs, of beyond line of sight (BLOS) satellite based communication, transmission rates and data volumes increased, and processing migrated to Cloud based services. Contemporary UASs are moving some of that information product derivation to on vehicle services, and are creating a distributed Cloud/Fog environment. The Author will describe the technological advances that have made this possible, including low power multi-core Central Processing Units (CPU), and, more recently, the availability of high end Graphical Processing Units (GPU) that consume only a few watts. Intelligent system software, leveraging these hardware advances, finally allows for information product generation on-board, rather than simple data collection. Additionally, intelligent flight control systems now support mutual vehicle to vehicle collaboration, allowing UASs to create ad-hoc sensor webs on demand, as required. Also discussed will be the lessons learned by the Authors' development of data systems for NASA's large High Altitude Long Endurance (HALE) UASs like Predator and Global Hawk, and how those lessons are being applied to other UAS development This paper will focus on applications, rather a deep dive into the technology, and will highlight improving data management through these new technologies.

UAS↗