Search NASA⌕ Search

SEARCH · Search NASA

Results for “core Flight System”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Runtime Verification with Ogma

Ultra-critical systems require high-level assurance, which cannot always be guaranteed in compile time. The use of runtime verification (RV) enable monitoring these systems in runtime, to detect property violations early and limit their potential consequences. However, the introduction of monitors in ultra-critical systems poses a challenge, as failures and delays in the RV subsystem could affect other subsystems and threaten the mission as a whole. In this talk we discuss two systems: NASA's Ogma, a tool to transform high-level specifications into monitoring code, and Copilot, a runtime verification framework for real-time embedded systems. The toolchain can be used to translate structured natural language requirements into C code with static memory requirements, which can be compiled to run on embedded hardware.

Ogma↗
NASA NTRS2006

Implications of Responsive Space on the Flight Software Architecture

The Responsive Space initiative has several implications for flight software that need to be addressed not only within the run-time element, but the development infrastructure and software life-cycle process elements as well. The runtime element must at a minimum support Plug & Play, while the development and process elements need to incorporate methods to quickly generate the needed documentation, code, tests, and all of the artifacts required of flight quality software. Very rapid response times go even further, and imply little or no new software development, requiring instead, using only predeveloped and certified software modules that can be integrated and tested through automated methods. These elements have typically been addressed individually with significant benefits, but it is when they are combined that they can have the greatest impact to Responsive Space. The Flight Software Branch at NASA's Goddard Space Flight Center has been developing the runtime, infrastructure and process elements needed for rapid integration with the Core Flight software System (CFS) architecture. The CFS architecture consists of three main components; the core Flight Executive (cFE), the component catalog, and the Integrated Development Environment (DE). This paper will discuss the design of the components, how they facilitate rapid integration, and lessons learned as the architecture is utilized for an upcoming spacecraft.

Wilmot, Jonathan↗
NASA NTRSDate not supplied

Flight Performance and Stability of Space Launch System Core Stage Thrust Vector Control

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 Core Stage TVC shares vehicle control authority with the SLS 5-segment Solid Rocket Boosters (SRBs) during boost phase flight, and is the sole means of vehicle flight control during in exoatmospheric flight following SRB separation. TVC responses during Green Run Hot Fire (GRHF) testing revealed that the TVC did not meet its performance specifications. Step and frequency responses exhibited unexpected departures from prior laboratory data and modeled behavior. Post-test analysis determined that the characteristics of the structure and gimbal friction are significantly influenced by the thrust-loaded conditions, and the command avionics exhibited a small but important gain nonlinearity. Using the available test data, the design team augmented the flight control TVC models to bound the observed results and include the additional fidelity needed for vehicle flight control analysis so as to build sufficient rationale for flight certification. Prior to the Green Run tests, “simplex” linear models typically used for flight control analysis did not include gimbal friction and other nonlinearities owing to long-standing assumptions that these effects were negligible in the Shuttle Orbiter TVC system. Following the Green Run findings, simulation analysis of the flight dynamics in the time and frequency domain revealed the propensity for a flight control limit cycle oscillation (LCO) if friction and structural compliances fell near the edges of test-predicted bounds. While the “most probable” models did not predict an in-flight LCO, the SLS Program conservatively proceeded with a system-wide evaluation and ultimate acceptance of the possibility for a small amplitude, low-frequency TVC LCO in flight. A final validation of the extensive test and modeling effort occurred when the first flight of SLS successfully demonstrated the fully integrated performance of the vehicle’s TVC system This paper is the final 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 development of flight rationale in light of the TVC responses observed in Green Run is discussed, along with a review of the flight telemetry illustrating the correlation of the preflight predictions with the observed performance.

John H. Wall↗
NASA NTRS2015

Big Software for SmallSats: Adapting CFS to CubeSat Missions

Expanding capabilities and mission objectives for SmallSats and CubeSats is driving the need for reliable, reusable, and robust flight software. While missions are becoming more complicated and the scientific goals more ambitious, the level of acceptable risk has decreased. Design challenges are further compounded by budget and schedule constraints that have not kept pace. NASA's Core Flight Software System (cFS) is an open source solution which enables teams to build flagship satellite level flight software within a CubeSat schedule and budget. NASA originally developed cFS to reduce mission and schedule risk for flagship satellite missions by increasing code reuse and reliability. The Lunar Reconnaissance Orbiter, which launched in 2009, was the first of a growing list of Class B rated missions to use cFS. Large parts of cFS are now open source, which has spurred adoption outside of NASA. This paper reports on the experiences of two teams using cFS for current CubeSat missions. The performance overheads of cFS are quantified, and the reusability of code between missions is discussed. The analysis shows that cFS is well suited to use on CubeSats and demonstrates the portability and modularity of cFS code.

Open Source↗
NASA NTRS2015

Big Software for SmallSats: Adapting cFS to CubeSat Missions

Expanding capabilities and mission objectives for SmallSats and CubeSats is driving the need for reliable, reusable, and robust flight software. While missions are becoming more complicated and the scientific goals more ambitious, the level of acceptable risk has decreased. Design challenges are further compounded by budget and schedule constraints that have not kept pace. NASA's Core Flight Software System (cFS) is an open source solution which enables teams to build flagship satellite level flight software within a CubeSat schedule and budget. NASA originally developed cFS to reduce mission and schedule risk for flagship satellite missions by increasing code reuse and reliability. The Lunar Reconnaissance Orbiter, which launched in 2009, was the first of a growing list of Class B rated missions to use cFS.

Flight Software↗
NASA NTRSDate not supplied

Space Launch System Core Stage Green Run Base Heating: Anomaly, Mitigation and Flight Redesign

The NASA Space Launch System (SLS) vehicle is composed of four RS-25 liquid oxygen and hydrogen rocket engines in the Core Stage (CS). The SLS Core Stage went through Green Run hot-fire testing at NASA Stennis Space Center’s B-2 test facility in 2021. The main goal of this testing was to confirm Core Stage tanking, propulsion and thrust vector control systems operations and performance to verify with predicted models. Two hot-fire (HF) test sequences were performed with the first one (HF1) in January for a test duration of 70 seconds and the second (HF2) testing completed in March for a test duration of 500 seconds. This paper focuses on the base heating anomalies observed during HF1 and HF2 where an extensive fire was observed along the Core Stage base heat shield during test operations. This environment was not anticipated and led to extensive unplanned damage to the thermal protection system which was augmented for flight. Green Run observations also led to a reassessment of flight environments for Artemis I. This paper discusses the potential cause of the anomalies, the flow physics, the reconstructed base environments, and mitigation plans for HF2 and flight.

aerothermodynamics↗
NASA NTRSDate not supplied

Space Launch System Core Stage Green Run Base Heating: Anomaly, Mitigation and Flight Redesign

The NASA Space Launch System (SLS) vehicle is composed of four RS-25 liquid oxygen and hydrogen rocket engines in the Core Stage (CS). The SLS Core Stage went through Green Run hotfire testing at NASA Stennis Space Center’s B-2 test facility in 2021. The main goal of this testing was to confirm Core Stage tanking, propulsion and thrust vector control systems operations and performance to verify with predicted models. Two hot-fire (HF) test sequences were performed with the first one (HF1) in January for a test duration of 70 seconds and the second (HF2) testing completed in March for a test duration of 500 seconds. This paper focuses on the base heating anomalies observed during HF1 and HF2 where an extensive fire was observed along the Core Stage base heat shield during test operations. This environment was not anticipated and led to extensive unplanned damage to the thermal protection system which was augmented for flight. Green Run observations also led to a reassessment of flight environments for Artemis I. This paper discusses the potential cause of the anomalies, the flow physics, the reconstructed base environments, and mitigation plans for HF2 and flight.

aerothermodynamics↗
NASA NTRS2019

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗
NASA NTRS2006

A Core Plug and Play Architecture for Reusable Flight Software Systems

The Flight Software Branch, at Goddard Space Flight Center (GSFC), has been working on a run-time approach to facilitate a formal software reuse process. The reuse process is designed to enable rapid development and integration of high-quality software systems and to more accurately predict development costs and schedule. Previous reuse practices have been somewhat successful when the same teams are moved from project to project. But this typically requires taking the software system in an all-or-nothing approach where useful components cannot be easily extracted from the whole. As a result, the system is less flexible and scalable with limited applicability to new projects. This paper will focus on the rationale behind, and implementation of the run-time executive. This executive is the core for the component-based flight software commonality and reuse process adopted at Goddard.

Wilmot, Jonathan↗
NASA NTRS1993

Design and pilot evaluation of the RAH-66 Comanche Core AFCS

This paper addresses the design and pilot evaluation of the Core Automatic Flight Control System (AFCS) for the Reconnaissance/Attack Helicopter (RAH-66) Comanche. During the period from November 1991 through February 1992, the RAH-66 Comanche control laws were evaluated through a structured pilot acceptance test using a motion base simulator. Design requirements, descriptions of the control law design, and handling qualities data collected from ADS-33 maneuvers are presented.

Fogler, Donald L., Jr.↗
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 NTRS1981

Manned orbit transfer vehicles and their missions

From a study that identified over 100 possible geosynchronous orbit-related applications for manned orbit transfer vehicles (MOTV), a group of 20 are chosen for consideration. These generic missions can be grouped into five categories: (1) inspection service and repair, (2) operation of large systems, (3) debris removal, (4) construction, and (5) unmanned cargo. Among the findings of this study is that space basing permits more efficient use of Space Shuttle flights, since the core propulsion system, crew cabin and general purpose mission hardware need not be launched into space each time. A conservative traffic model shows that $600 million may be saved over five years by space basing, due to the decreased number of Shuttle flights needed to support the space-based MOTV. Crew information, payloads, characteristics of the vehicle, and mission requirements are covered in detail.

Boyland, R. E.↗
NASA NTRS2012

NASA's Robotic Lunar Lander Development Project

Since early 2005, NASA's Robotic Lunar Lander Development (RLLD) office at NASA MSFC, in partnership with the Applied Physics Laboratory (APL), has developed mission concepts and preformed risk-reduction activities to address planetary science and exploration objectives uniquely met with landed missions. The RLLD team developed several concepts for lunar human-exploration precursor missions to demonstrate precision landing and in-situ resource utilization, a multi-node lunar geophysical network mission, either as a stand-alone mission, or as part of the International Lunar Network (ILN), a Lunar Polar Volatiles Explorer and a Mercury lander mission for the Planetary Science decadal survey, and an asteroid rendezvous and landing mission for the Exploration Precursor Robotics Mission (xPRM) office. The RLLD team has conducted an extensive number of risk-reduction activities in areas common to all lander concepts, including thruster testing, propulsion thermal control demonstration, composite deck design and fabrication, and landing leg stability and vibration. In parallel, the team has developed two robotic lander testbeds providing closed-loop, autonomous hover and descent activities for integration and testing of flight-like components and algorithms. A compressed-air test article had its first flight in September 2009 and completed over 150 successful flights. This small test article (107 kg dry/146 kg wet) uses a central throttleable thruster to offset gravity, plus 3 descent thrusters (~37lbf ea) and 6 attitude-control thrusters (~12lbf ea) to emulate the flight system with pulsed operation over approximately 10s of flight time. The test article uses carbon composite honeycomb decks, custom avionics (COTS components assembled in-house), and custom flight and ground software. A larger (206 kg dry/322 kg wet), hydrogen peroxide-propelled vehicle began flight tests in spring 2011 and fly over 30 successful flights to a maximum altitude of 30m. The monoprop testbed also uses a central gravity-canceling thruster and 3 descent thrusters, but has 12 attitude-control thrusters and a maximum flight time of over a minute. The testbed uses aluminum ortho-grid decks, an LN200-1 IMU, Roke Manor Radar Altimeter, Illunis optical cameras, Novatel Pro-Pak GPS truth data system, Pressure transducers & thermocouples for housekeeping, "In-Control" ground system software, and the core Flight Executive (cFE) modular software environment. The peroxide lander testbed is able to accept other sensors and algorithms for testing, both from within NASA and from other customers. Through these activities, the RLLD team has significantly reduced technical risks for all small and medium class robotic landers for the Moon and other airless planetary bodies.

Cohen, Barbara A.↗