Search NASA⌕ Search

SEARCH · Search NASA

Results for “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 505 records · Page 28

Agile Approach to Assuring the Safety-Critical Embedded Software for NASA's Orion Spacecraft

Human-rated missions like NASA's Exploration Mission - 1 (EM-1) and the Orion Multi-Purpose Crew Vehicle are becoming exceedingly complex in terms of software's contribution to achieving mission objectives. The increasing complexity and inherent safety critical nature of the embedded flight software imposes a unique resource challenge to assurance providers responsible for affirming that the mission is going to fly safely. Another challenge NASA and other Government agencies are facing is that more and more software is being developed using an agile development methodology, which is divergent from the typical waterfall, iterative, and incremental development methodologies assurance providers generally observe in the development of safety-critical embedded software. Orion Independent Verification and Validation (IV&V) has addressed these challenges by providing focused assurance results of critical mission capabilities prioritized by a dynamic assessment of risk level. Prior to this approach, Orion IV&V evaluated areas of risk in much broader, and more static, terms. Due to the agile software development life cycle that Orion follows, IV&V findings were often reported months out of phase with the developer thereby imposing increased rework costs. As a result of evolving the approach to adding assurance on Orion, IV&V is able to incrementally deliver high-priority assurance conclusions and more impactful issues more in phase with the developer activities, thereby increasing the value of the findings to the project. The agile IV&V approach employed by the Orion IV&V team strives to achieve a cadence of delivery that matches the pace of development. This agile approach provides increased flexibility for the assurance provider to become more efficient in reporting assurance conclusions and issues. This paper and presentation will discuss the principles which drive the design of our approach, results to date, and stimulate thinking for groups looking to add assurance to software being developed using an agile methodology.

Justin Smith↗

A ROS-based Simulator for Testing the Enhanced Autonomous Navigation of the Mars 2020 Rover

In order to achieve the ambitious objectives of the Mars 2020 (M2020) mission, in particular the ability to autonomously traverse more challenging terrains more efficiently, new surface mobility software was developed for Enhanced Navigation (ENav). That decision was made early in the project, before most of the new surface flight software (FSW) existed, which created a need for a separate framework where the new navigation algorithms could be quickly prototyped and tested, before more realistic FSW-based testbeds became available. The JPL robotics team chose the Robot Operating System [1] (ROS) as the environment in which to test the new ENav algorithms. This made it possible to write the algorithms in the C language required by the FSW, so they could be directly ported over to the flight module later on, while leveraging all the C++ libraries and tools provided by ROS for simulation and testing. The ENav algorithms were developed as a separate C library, and stubs were used to replace any FSW-specific code, such as Event Reporting (EVRs) and data products (DPs). A ROS simulator was developed to generate a rich set of varied 3D terrains representative of the candidate Mars landing sites and simulate the physics of the rover motion, the point cloud perceived by the rover’s stereo vision system, and the new thinking-while-driving (TWD) navigation logic which directs the rover to drive autonomously to user-specified waypoints. To simulate the rover motion and perception, a ROS node was developed that uses a software library called HyperDrive Sim (HDSim), which is a wrapper for the Rover Sequencing and Visualization Program [2] (RSVP). That library provides roverterrain settling, realistic slip modelling, and camera rendering capability based on the rover’s NavCam machine vision models. To simulate the navigation logic, a ROS node was created that initializes and runs the ENav algorithms in a way that mimics the FSW execution, while also providing the capability to load and replay data products, including re-running the recorded inputs through the ENav algorithms for testing. An engineering Graphical User Interface (GUI) was also developed to visualize various elements, such as the rover pose during the drive, the simulated and perceived terrain, the selected local and global paths to the goal, the evaluated candidate paths and the reasons why they were rejected, the keep-in and keep-out zones (KIOZs), etc. Finally, an advanced Monte Carlo (MC) framework that can run many simulations in parallel on the Cloud and automatically generate reports that capture the key ENav performance metrics was developed to evaluate the system in a statisticallymeaningful way. This paper provides an overview of the ROSbased simulator used for testing the M2020 ENav algorithms.

Toupet, Olivier↗

Mission planning and execution within the mission data system

Not only has the number of launched spacecraft per year exploded over the past few years, but also spacecraft are getting progressively more complex, as flyby missions give way to remote orbiters, which in turn give way to rovers and other in situ explorers. To address the software issues in this expanding mission set, JPL started the Mission Data System (MDS) project, an effort to make flight software engineering more straightforward and less prone to error through the eplicit modeling of spacecraft state. This paper presents how MDS performs mission planning and execution in the context of explicitly managing spacecraft state.

MDS↗

PDSS/IMC requirements and functional specifications

The system (software and hardware) requirements for the Payload Development Support System (PDSS)/Image Motion Compensator (IMC) are provided. The PDSS/IMC system provides the capability for performing Image Motion Compensator Electronics (IMCE) flight software test, checkout, and verification and provides the capability for monitoring the IMC flight computer system during qualification testing for fault detection and fault isolation.

Source record↗

Mars Pathfinder Atmospheric Entry Navigation Operations

On July 4, 1997, after traveling close to 500 million km, the Pathfinder spacecraft successfully completed entry, descent, and landing, coming to rest on the surface of Mars just 27 km from its target point. In the present paper, the atmospheric entry and approach navigation activities required in support of this mission are discussed. In particular, the flight software parameter update and landing site prediction analyses performed by the Pathfinder operations navigation team are described. A suite of simulation tools developed during Pathfinder's design cycle, but extendible to Pathfinder operations, are also presented. Data regarding the accuracy of the primary parachute deployment algorithm is extracted from the Pathfinder flight data, demonstrating that this algorithm performed as predicted. The increased probability of mission success through the software parameter update process is discussed. This paper also demonstrates the importance of modeling atmospheric flight uncertainties in the estimation of an accurate landing site. With these atmospheric effects included, the final landed ellipse prediction differs from the post-flight determined landing site by less then 0.5 km in downtrack.

Braun, R. D.↗

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗

NOS3: NASA Operational Simulator for Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.

Suder, Mark↗

Magellan attitude and articulation control subsystem closed loop testing

In the spring of 1989, the Magellan spacecraft will embark on a two-year mission to map the surface of the planet Venus. Guiding it there will be the Attitude and Articulation Control Subsystem (AACS). To ensure reliable operations the AACS is being put through a rigorous test program at Martin Marietta Denver Aerospace. Before Magellan ever leaves the Space Shuttle bay from which it is to be launched, its components will have flown a simulated spaceflight in a ground-based lab. The primary objectives of the test program are to verify form, fit, and function of the AACS, particularly subsystem external interfaces and functional operation of the flight software. This paper discusses the Magellan Closed Loop Test Systems which makes realistic tests possible by simulating the dynamic and 'visual' flight environment for AACS components in the lab.

Olschansky, David G.↗

Enhancing Science and Automating Operations using Onboard Autonomy

In this paper, we will describe the evolution of the software from prototype to full time operation onboard Earth Observing One (EO-1). We will quantify the increase in science, decrease in operations cost, and streamlining of operations procedures. Included will be a description of how this software was adapted post-launch to the EO-1 mission, which had very limited computing resources which constrained the autonomy flight software. We will discuss ongoing deployments of this software to the Mars Exploration Rovers and Mars Odyssey Missions as well as a discussion of lessons learned during this project. Finally, we will discuss how the onboard autonomy has been used in conjunction with other satellites and ground sensors to form an autonomous sensor-web to study volcanoes, floods, sea-ice topography, and wild fires. As demonstrated on EO-1, onboard autonomy is a revolutionary advance that will change the operations approach on future NASA missions...

Earth Observing One (EO-1)↗

Software Certification - Coding, Code, and Coders

We describe a certification approach for software development that has been adopted at our organization. JPL develops robotic spacecraft for the exploration of the solar system. The flight software that controls these spacecraft is considered to be mission critical. We argue that the goal of a software certification process cannot be the development of "perfect" software, i.e., software that can be formally proven to be correct under all imaginable and unimaginable circumstances. More realistically, the goal is to guarantee a software development process that is conducted by knowledgeable engineers, who follow generally accepted procedures to control known risks, while meeting agreed upon standards of workmanship. We target three specific issues that must be addressed in such a certification procedure: the coding process, the code that is developed, and the skills of the coders. The coding process is driven by standards (e.g., a coding standard) and tools. The code is mechanically checked against the standard with the help of state-of-the-art static source code analyzers. The coders, finally, are certified in on-site training courses that include formal exams.

training↗

Runtime Analysis with R2U2: A Tool Exhibition Report

We present R2U2 (Realizable, Responsive, Unobtrusive Unit), a hardware- supported tool and framework for the continuous monitoring of safetycritical and embedded cyber-physical systems.With the widespread advent of autonomous systems such as Unmanned Aerial Systems (UAS), satellites, rovers, and cars, real-time, on-board decision making requires unobtrusive monitoring of properties for safety, performance, security, and system health. R2U2 models combine past-time and future-time Metric Temporal Logic, “mission time” Linear Temporal Logic, probabilistic reasoning with Bayesian Networks, and modelbased prognostics. The R2U2 monitoring engine can be instantiated as a hardware solution, running on an FPGA, or as a software component. The FPGA realization enables R2U2 to monitor complex cyber-physical systems without any overhead or instrumentation of the flight software. In this tool exhibition report, we present R2U2 and demonstrate applications on system runtime monitoring, diagnostics, software health management, and security monitoring for a UAS. Our tool demonstration uses a hardware-based processor-in-the-loop “iron-bird” configuration.

Johann Martin Schumann↗

Flight dynamics system software development environment (FDS/SDE) tutorial

A sample development scenario using the Flight Dynamics System Software Development Environment (FDS/SDE) is presented. The SDE uses a menu-driven, fill-in-the-blanks format that provides online help at all steps, thus eliminating lengthy training and allowing immediate use of this new software development tool.

Buell, John↗

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗

Onboard Autonomy on the Earth Observing One Mission

The Earth Observing One Spacecraft is currently flying The Autonomous Sciencecraft Experiment (ASE) - onboard autonomy software to improve science return. The ASE software enables the spacecraft to autonomously detect and respond to science events occurring on the Earth. ASE includes software systems that perform science data analysis, mission planning, and run-time robust execution. In this article we describe the autonomy flight software and how it enables a new paradigm of autonomous science and mission operations.

autonomy↗

Agile Approach to Assuring the Safety-Critical Embedded Software for NASA's Orion Spacecraft

Human-rated missions like those in NASA's Orion Program continue to grow in complexity. The role of software in achieving ambitious mission objectives has expanded dramatically in the last few decades. Assuring the safety and performance of the embedded flight software is quickly growing beyond the reach of traditional methods and resource levels. The methods used to build these software-dominant systems evolve in an on-going attempt to keep pace with the scope of our ambitions. Agile software development is now commonplace. The long timelines and large batches of work associated with traditional methods are being replaced by rapid delivery of small increments _ as system capabilities are realized in waves. Assurance of these critical software capabilities must therefore conquer an ever-expanding frontier of challenges, and do so with an approach matched to the evolving development methods. This paper recounts the journey of the Orion Independent Verification and Validation (IV&V) team as we addressed this dynamic environment. Widening our aperture to encompass a dramatically larger mission scope, while adjusting our cadence to synchronize with the rapid pace of agile software development, a new approach to IV&V is emerging. This approach is characterized by a sharper focus on mission capabilities, matched with a method to dynamically _follow the risk' as the IV&V team delivers more compelling assurance data in waves. Traditional methods prevalent in IV&V tend to scope the work using artifacts of the development process as they evolve from preliminary to final versions, and the pace of delivery was synchronized with the development timelines prevalent in the waterfall lifecycle. That more static approach is out of phase with the demands of the new environment. Scoping work according to the critical capabilities of the system (rather than artifacts of development) and synchronizing with the rapid pace of agile development, we are moving toward more effective parity with the demands of the environment. We explain the concrete steps we took, the principles that motivated our choices, and the results we have achieved to date.

Capability based assurance↗

Trust in Collaborative Automation in High Stakes Software Engineering Work

The amount of autonomy in software engineering tools is increasing as developers build increasingly complex systems. Research in other domains shows that too much or too little trust in autonomous tools can have negative consequences, but we are not aware of any study that has investigated trust in autonomous tools in the highly interactive context of a software engineering workplace. We present the results of a ten week ethnographic case study of engineers collaborating with autonomous tools to write flight software at a large national space exploration organization to support high stakes missions. We find that trust in an autonomous software engineering tool in this setting was influenced by four main factors: the tool’s transparency, social context, an organization’s associated processes, and its usability. We outline theoretical implications for future research into trust in autonomous software engineering tools, and practical implications for tool designers and organizations conducting high stakes work with autonomous tools.

Davidoff, Scott↗

Flow Boiling and Condensation Experiment: Flow Boiling in a Rectangular Channel with Subcooled Inlet Conditions in Microgravity

Two-phase thermal management subsystems that take advantage of both the sensible and latent heat of a working fluid can potentially yield significant enhancements in overall performance by adopting heat transfer processes that are based on phase transition like boiling and condensation. Performance of terrestrial two-phase flow systems may be predictable because the hydrodynamic and body forces are understood, however, in microgravity, which is predominant during planetary space travel, forces that are masked by the strong body force on Earth (gravitational or buoyancy force) reappear with different magnitude and influence. The need arose for a facility that provides for two-phase flow with phase transition testing in microgravity. The Flow Boiling and Condensation Experiment (FBCE) is a facility that was launched to the International Space Station in August of 2021 and is in operation since February of 2022. This facility enables investigators to perform two-phase flow and phase transition research in flow boiling and condensation. Along with the test module that is experiment specific, the FBCE system consists of the fluid, avionics, and software subsystems. Currently two test modules, namely, the Flow Boiling Module (FBM) and the Condensation Module for Heat Transfer (CM-HT) are available. A third module, the Transfer Line test Module (TL) is being developed. The fluid subsystem conditions and delivers the fluid at the desired thermodynamic state to the test module. It consists of two fluid modules and a heater module that are connected by flex hoses for fluid circulation and by data and electrical cables for control and data acquisition. Two avionics modules acquire pressure and temperature data from various sensors in the flow loop. For FBM, a high-speed camera is available to acquire images of the boiling process. Experiments are operated autonomously by software and are based on an Experiment Parameters Master Table (EPMT) that is uploaded to ISS and is executed by the FBCE flight software. This presentation briefly introduces the objectives of FBCE and provides a system description of the experiment onboard of the ISS/Fluid Integrated Rack (FIR). Results of the test campaign carried out using the FBM are presented. Specifically, microgravity flow boiling of n-perfluorohexane (test fluid) is discussed with subcooled inlet conditions in a single-side-heated rectangular channel of dimensions 114.6-mm heated length, 2.5-mm heated width, and 5.0-mm height. Key operating parameters investigated are mass velocity (199.90 – 3200.13 kg/m2s), inlet subcooling (0.10 – 45.76°C), and inlet pressure (113.30 – 164.29 kPa). Image sequences acquired via high-speed-video are shown to elucidate the interfacial flow physics. The effects of various parameters on flow boiling heat transfer in microgravity, from the onset of boiling to the critical heat flux are discussed. Heat transfer results are presented in terms of flow boiling curves, streamwise profiles of wall temperature and heat transfer coefficient, and parametric trends of local and averaged heat transfer coefficient, and the critical heat flux.

Two-phase flow and phase transition↗

Independent Orbiter Assessment (IOA): Analysis of the backup flight system

The results of the Independent Orbiter Assessment (IOA) of the Failure Modes and Effects Analysis (FMEA) and Critical Items List (CIL) are presented. The IOA approach features a top-down analysis of the hardware to determine failure modes, criticality, and potential critical items. To preserve independence, this analysis was accomplished without reliance upon the results contained within the NASA FMEA/CIL documentation. This report documents the analysis results corresponding to the Orbiter Backup Flight System (BFS) hardware. The BFS hardware consists of one General Purpose Computer (GPC) loaded with backup flight software and the components used to engage/disengage that unique GPC. Specifically, the BFS hardware includes the following: DDU (Display Driver Unit), BFC (Backup Flight Controller), GPC (General Purpose Computer), switches (engage, disengage, GPC, CRT), and circuit protectors (fuses, circuit breakers). The IOA analysis process utilized available BFS hardware drawings and schematics for defining hardware assemblies, components, and hardware items. Each level of hardware was evaluated and analyzed for possible failure modes and effects. Criticality was assigned based upon the severity of the effect for each failure mode. Of the failure modes analyzed, 19 could potentially result in a loss of life and/or loss of vehicle.

Prust, E. E.↗