Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “core Flight Software”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2022

Testing Mars 2020 Flight Software and Hardware in the Surface System Development Environment

The Mars 2020 (M2020) Perseverance Rover is NASA's most advanced planetary rover mission to date. It includes a novel Sample Caching Subsystem (SCS) which will collect rock cores for possible future return to Earth, as well as an improved mobility system with enhanced autonomous navigation which will enable it to traverse faster and farther than prior rovers. The development of both systems required extensive flight software and flight hardware testing. To support this testing, we developed the Surface System Development Environment (SSDEV) and used it for a wide variety of testing. SSDEV is a bundled subset of M2020 Flight Software which runs on commercially available Linux computers and can be combined with multiple backend options for simulation and hardware control. The SSDEV architecture enabled our teams to perform much more testing of flight software and flight hardware than would have otherwise been possible. As a secondary benefit, the SSDEV-based test campaigns also helped our teams enter the operations phase of the mission with greater readiness of operations products and tools. In this paper, we summarize the motivation for SSDEV, provide an overview of the SSDEV architecture, list several examples of how SSDEV was used, and summarize lessons learned. SSDEV is not a substitute for integrated testing with flight-like avionics, but it enabled substantially more testing than would have otherwise been possible and also provided some unique benefits. We recommend architectures like SSDEV to future projects that need to perform extensive hardware and software testing using a limited set of flight-like avionics.

Wai, Dennis↗
NASA NTRS2021

Software Approach for the Regenerative Fuel Cell Project

The Regenerative Fuel Cell (RFC) project is developing a system that combines a fuel cell subsystem for energy production with an electrolysis subsystem for energy storage. The system is primarily being developed at the Glenn Research Center with support from Johnson Space Center under the Space Technology Mission Directorate / Game Changing Development Program. Currently, the intent is to operate the RFC system in an equivalent environment to a lunar equator location for a period of several lunar day/night cycles with minimal operator input. Demonstrating an automated RFC system in this environment is a step towards showing the extensibility to a flight system. This paper describes the RFC software team’s approach for development of the monitoring and control software that allows for the automated operation of the RFC system. We describe the rationale for the choice of Core Flight System architecture, as well as the plan for software/hardware integration.

Mathew J Mccaskey↗
NASA NTRS2007

NASA's Core Trajectory Sub-System Project: Using JBoss Enterprise Middleware for Building Software Systems Used to Support Spacecraft Trajectory Operations

NASA's Johnson Space Center (JSC) / Flight Design and Dynamics Division (DM) has prototyped the use of Open Source middleware technology for building its next generation spacecraft mission support system. This is part of a larger initiative to use open standards and open source software as building blocks for future mission and safety critical systems. JSC is hoping to leverage standardized enterprise architectures, such as Java EE, so that its internal software development efforts can be focused on the core aspects of their problem domain. This presentation will outline the design and implementation of the Trajectory system and the lessons learned during the exercise.

Stensrud, Kjell C.↗
NASA NTRS1993

Flight validation of a pulsed smoke flow visualization system

A flow visualization scheme, designed to measure vortex fluid dynamics on research aircraft, was validated in flight. Strake vortex trajectories and axial core velocities were determined using pulsed smoke, high-speed video images, and semiautomated image edge detection hardware and software. Smoke was pulsed by using a fast-acting three-way valve. After being redesigned because of repeatedly jamming in flight, the valve shuttle operated flawlessly during the last two tests. A 25-percent scale, Gothic strake was used to generate vortex over the wing of a GA-7 Cougar and was operated at a local angle of attack of 22 degrees and Reynolds number of approximately 7.8 x 10(exp 5)/ft. Maximum axial velocities measured in the vortex core were between 1.75 and 1.95 times the freestream velocity. Analysis of the pulsed smoke system's affect on forebody vortices indicates that the system may reorient the forebody vortex system; however, blowing momentum coefficients normally used will have no appreciable affect on the leading-edge extension vortex system. It is recommended that a similar pulsed smoke system be installed on the F/A-18 High Angle Research Vehicle and that this approach be used to analyze vortex core dynamics during the remainder of its high-angle-of-attack research flights.

Ward, Donald T.↗
NASA NTRSDate not supplied

Space ROS TOFU: Flying Space ROS with Containerized Hybrid Trust

Space ROS is a distribution of Robot Operating System 2 (ROS2) targeting the specific requirements of flight software and spaceborne robotics while maintaining the flexibility that has made ROS indispensible for robotics research and industrial system integration. With Space ROS, a project can leverage the existing ROS2 ecosystem to reduce redundant development while tackling increasingly complex demands for on-device intelligence; however, there is no substitute for flight heritage to combat the risk-aversion common to spaceflight projects, and Space ROS has yet to fly. To break the collective-action standoff and gain valuable flight experience, the Distributed Spacecraft Autonomy (DSA) team at NASA Ames Research Center developed Opportunistic Software Experiments for Spacecraft Autonomy Testbeds (OSE-SAT) architecture, utilizing containerization to execute lower-trust software under traditionally verified heritage flight software for demonstration on-orbit. OSE-SAT leverages a hybrid-trust model where flexible, complex components like Space ROS can run without risk to the host spacecraft while providing validated feedback to a highly scrutinized, trusted core. We leverage this testbed to demonstrate Space ROS in flight, building heritage, and experience for projects with "Trust On First Use" (TOFU) requirements for flight heritage. We present a Space ROS component for OSE-SAT, lessons learned integrating Space ROS into a flight software stack, and the results of the first known use of Space ROS in orbit.

small satellites↗
NASA NTRS2017

NASA's Space Launch System: Progress Report

NASA and its commercial industry team achieved significant progress in 2016 in manufacturing and testing of the Block 1 vehicle for the first launch of the Space Launch System (SLS). Test and flight article hardware for the liquid hydrogen fuel tank as well as the engine section for the core stage were completed at Michoud Assembly Facility (MAF) in New Orleans. Test stands neared completion at Marshall Space Flight Center for the propellant tanks, engine section, intertank and payload section. Stennis Space Center completed major structural renovations on the B2 test stand, where the core stage "green run" test program will be conducted. The SLS team completed a hotfire test series at Stennis to successfully demonstrate the ability of the RS-25 engine to operate under SLS environments and performance conditions. The team also test fired the second qualification five-segment solid rocket motor and cast the first six motor segments for the first SLS mission. The Interim Cryogenic Propulsion Stage (ICPS) test article was delivered to Marshall for structural tests, and work is nearly finished on the flight stage. Flight software testing completed at Marshall included power quality and command and data handling. In 2017, that work continues. SLS completed Preliminary Design Review (PDR) on the Exploration Upper Stage (EUS), a powerful, human-rated spacecraft that will propel explorers to cis-lunar space. In 2017, hardware will continue to be integrated at MAF for core stage structural test articles and the first two operational flights. RS-25 hotfire testing will continue to explore engine performance, as well as test flight-like software and four new Engine Controller Units (ECUs) for the first mission. Production of development components for a more affordable RS-25 design is underway. Core stage structural test articles have begun arriving at Marshall. While engineering challenges typical of a new development are possible, SLS is working toward launch readiness in late 2018. 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 first flight

Cook, Jerry↗
NASA NTRS2017

Mars 2020 Sampling and Caching Subsystem Environmental Development Testing and Preliminary Results

The Environmental Development Testing program supported the development test efforts of the Mars 2020 Sampling and Caching Subsystem from May to November 2015. The engineering prototype Brassboard Corer was attached to a five degree-of-freedom robotic arm to execute a 96-test matrix of ambient and low pressure tests in the 10 ft. thermal vacuum chamber at the NASA Jet Propulsion Laboratory, California Institute of Technology. The Pretest, Test, and Post Test procedures are described, and some preliminary results are discussed. Data and observations from this test campaign inform the future development of the software and hardware toward the Mars 2020 flight design, including the next iteration of the rock coring drill, the Engineering Development Unit Corer.

Kriechbaum, Kristo↗
NASA NTRS2017

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.

Software↗
NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗
NASA NTRS2014

UAS-Systems Integration, Validation, and Diagnostics Simulation Capability

As part of the Phase 1 efforts of NASA's UAS-in-the-NAS Project a task was initiated to explore the merits of developing a system simulation capability for UAS to address airworthiness certification requirements. The core of the capability would be a software representation of an unmanned vehicle, including all of the relevant avionics and flight control system components. The specific system elements could be replaced with hardware representations to provide Hardware-in-the-Loop (HWITL) test and evaluation capability. The UAS Systems Integration and Validation Laboratory (UAS-SIVL) was created to provide a UAS-systems integration, validation, and diagnostics hardware-in-the-loop simulation capability. This paper discusses how SIVL provides a robust and flexible simulation framework that permits the study of failure modes, effects, propagation paths, criticality, and mitigation strategies to help develop safety, reliability, and design data that can assist with the development of certification standards, means of compliance, and design best practices for civil UAS.

Buttrill, Catherine W.↗
NASA NTRS2012

Certification of COTS Software in NASA Human Rated Flight Systems

Adoption of commercial off-the-shelf (COTS) products in safety critical systems has been seen as a promising acquisition strategy to improve mission affordability and, yet, has come with significant barriers and challenges. Attempts to integrate COTS software components into NASA human rated flight systems have been, for the most part, complicated by verification and validation (V&V) requirements necessary for flight certification per NASA s own standards. For software that is from COTS sources, and, in general from 3rd party sources, either commercial, government, modified or open source, the expectation is that it meets the same certification criteria as those used for in-house and that it does so as if it were built in-house. The latter is a critical and hidden issue. This paper examines the longstanding barriers and challenges in the use of 3rd party software in safety critical systems and cover recent efforts to use COTS software in NASA s Multi-Purpose Crew Vehicle (MPCV) project. It identifies some core artifacts that without them, the use of COTS and 3rd party software is, for all practical purposes, a nonstarter for affordable and timely insertion into flight critical systems. The paper covers the first use in a flight critical system by NASA of COTS software that has prior FAA certification heritage, which was shown to meet the RTCA-DO-178B standard, and how this certification may, in some cases, be leveraged to allow the use of analysis in lieu of testing. Finally, the paper proposes the establishment of an open source forum for development of safety critical 3rd party software.

Goforth, Andre↗
NASA NTRS2007

[Interview Questions]

The Goddard Mission Services Evolution Center, or GMSEC, was started in 2001 to create a new standard approach for managing GSFC missions. Standardized approaches in the past involved selecting and then integrating the most appropriate set of functional tools. Assumptions were made that "one size fits all" and that tool changes would not be necessary for many years. GMSEC took a very different approach and has proven to be very successful. The core of the GMSEC architecture consists of a publish/subscribe message bus, standardized message formats, and an Applications Programming Interface (API). The API supports multiple operating systems, programming languages and messaging middleware products. We use a GMSEC-developed free middleware for low-cost development. A high capacity, robust middleware is used for operations and a messaging system with a very small memory footprint is used for on-board flight software. Software components can use the standard message formats or develop adapters to convert from their native formats to the GMSEC formats. We do not want vendors to modify their core products. Over 50 software components are now available for use with the GMSEC architecture. Most available commercial telemetry and command systems, including the GMV hifly Satellite Control System, have been adapted to run in the GMSEC labs.

Smith, Dan↗
NASA NTRS1990

Universal Lambert and Kepler algorithms for autonomous rendezvous

This paper describes Lambert and Kepler algorithms designed to be the core of an autonomous rendezvous guidance system for an onboard computer. Applications include robotic and piloted missions to the moon and planets. Flight software must be compact, fast, and totally reliable. Although high accuracy is not essential for flight, in double precision these algorithms are accurate to at least 14 places almost everywhere. Both are universal; they apply to elliptic, parabolic, hyperbolic, and even rectilinear trajectories. The algorithms are improvements to those published by Battin (1987).

Klumpp, Allan R.↗
NASA NTRS2017

NASA's Space Launch System Takes Shape

Major hardware and software for NASA's Space Launch System (SLS) began rolling off assembly lines in 2016, setting the stage for critical testing in 2017 and the launch of a major new capability for deep space human exploration. SLS continues to pursue a 2018 first launch of Exploration Mission 1 (EM-1). At NASA's Michoud Assembly Facility near New Orleans, LA, Boeing completed welding of structural test and flight liquid hydrogen tanks, and engine sections. Test stands for core stage structural tests at NASA's Marshall Space Flight Center, Huntsville, AL. neared completion. The B2 test stand at NASA's Stennis Space Center, MS, completed major structural renovation to support core stage green run testing in 2018. Orbital ATK successfully test fired its second qualification solid rocket motor in the Utah desert and began casting the motor segments for EM-1. Aerojet Rocketdyne completed its series of test firings to adapt the heritage RS-25 engine to SLS performance requirements. Production is under way on the first five new engine controllers. NASA also signed a contract with Aerojet Rocketdyne for propulsion of the RL10 engines for the Exploration Upper Stage. United Launch Alliance delivered the structural test article for the Interim Cryogenic Propulsion Stage to MSFC for tests and construction was under way on the flight stage. Flight software testing at MSFC, including power quality and command and data handling, was completed. Substantial progress is planned for 2017. Liquid oxygen tank production will be completed at Michoud. Structural testing at Marshall will get under way. RS-25 hotfire testing will verify the new engine controllers. Core stage horizontal integration will begin. The core stage pathfinder mockup will arrive at the B2 test stand for fit checks and tests. EUS will complete preliminary design review. This paper will discuss the technical and programmatic successes and challenges of 2016 and look ahead to plans for 2017.

Askins, Bruce↗
NASA NTRS1987

Advanced fighter technology integration (AFTI)/F-16 Automated Maneuvering Attack System final flight test results

The AFTI F-16 Automated Maneuvering Attack System has undergone developmental and demonstration flight testing over a total of 347.3 flying hours in 237 sorties. The emphasis of this phase of the flight test program was on the development of automated guidance and control systems for air-to-air and air-to-ground weapons delivery, using a digital flight control system, dual avionics multiplex buses, an advanced FLIR sensor with laser ranger, integrated flight/fire-control software, advanced cockpit display and controls, and modified core Multinational Stage Improvement Program avionics.

Dowden, Donald J.↗
NASA NTRS2005

MSAP Hardware Verification: Testing Multi-Mission System Architecture Platform Hardware Using Simulation and Bench Test Equipment

The Multi-Mission System Architecture Platform (MSAP) project aims to develop a system of hardware and software that will provide the core functionality necessary in many JPL missions and can be tailored to accommodate mission-specific requirements. The MSAP flight hardware is being developed in the Verilog hardware description language, allowing developers to simulate their design before releasing it to a field programmable gate array (FPGA). FPGAs can be updated in a matter of minutes, drastically reducing the time and expense required to produce traditional application-specific integrated circuits. Bench test equipment connected to the FPGAs can then probe and run Tcl scripts on the hardware. The Verilog and Tcl code can be reused or modified with each design. These steps are effective in confirming that the design operates according specifications.

Crossin, Kent R.↗
NASA NTRSDate not supplied

Design, Instrumentation, and Data Analysis for the SLS Core Stage Green Run Test Series

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. The actuators are powered by a Shuttle-derived hydraulic Core Auxiliary Power Unit (CAPU), and integrated with an all-new Core Stage thrust structure. The actuators are interfaced to the SLS Vehicle Management (VM) software via an all-new TVC Actuator Control (TAC) avionics subsystem. Despite the significant test and flight experience of the Shuttle hardware, the SLS Green Run ambient and hot fire test activities revealed a number of new findings associated with the dynamic response of the TVC integrated system. Test responses suggested that the TVC system did not meet its performance specifications and its step and frequency responses exhibited unexpected departures from prior lab tests and modeled behavior. This paper is the fifth installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the design of the TVC analyses conducted during the Core Stage Green Run test series are discussed in detail. Throughout the course of the test activities, the SLS flight control team worked diligently with the Core Stage contractor to revise test command profiles and ensure sufficient instrumentation was available to collect data. Post-test analysis combined the Green Run modal, ambient, and hot fire test data, MSFC 2- axis Core Stage TVC Inertial Load Simulator (ILS) data, Hardware-In-the-Loop (HWIL) Systems Integration Lab (SIL) results, and actuator Acceptance Testing Procedure (ATP) responses. These data were used to characterize the response, validate critical math models of the TVC subsystem, and isolate the probable cause of the unexpected responses. Through comprehensive analysis of the available test data sources, the integrated team identified the dominant contributors to the observed response and developed test-correlated rationale for vehicle flight control system performance, ultimately leading to a confident posture for the Artemis I mission.

John H. Wall↗