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 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Ground Data System Analysis Tools to Track Flight System State Parameters for the Mars Science Laboratory (MSL) and Beyond

Flight software parameters enable space mission operators fine-tuned control over flight system configurations, enabling rapid and dynamic changes to ongoing science activities in a much more flexible manner than can be accomplished with (otherwise broadly used) configuration file based approaches. The Mars Science Laboratory (MSL), Curiosity, makes extensive use of parameters to support complex, daily activities via commanded changes to said parameters in memory. However, as the loss of Mars Global Surveyor (MGS) in 2006 demonstrated, flight system management by parameters brings with it risks, including the possibility of losing track of the flight system configuration and the threat of invalid command executions. To mitigate this risk a growing number of missions have funded efforts to implement parameter tracking parameter state software tools and services including MSL and the Soil Moisture Active Passive (SMAP) mission. This paper will discuss the engineering challenges and resulting software architecture of MSL's onboard parameter state tracking software and discuss the road forward to make parameter management tools suitable for use on multiple missions.

Allard, Dan↗
NASA NTRS2011

The Planning Execution Monitoring Architecture

The Planning Execution Monitoring (PEM) architecture is a design concept for developing autonomous cockpit command and control software. The PEM architecture is designed to reduce the operations costs in the space transportation system through the use of automation while improving safety and operability of the system. Specifically, the PEM autonomous framework enables automatic performance of many vehicle operations that would typically be performed by a human. Also, this framework supports varying levels of autonomous control, ranging from fully automatic to fully manual control. The PEM autonomous framework interfaces with the core flight software to perform flight procedures. It can either assist human operators in performing procedures or autonomously execute routine cockpit procedures based on the operational context. Most importantly, the PEM autonomous framework promotes and simplifies the capture, verification, and validation of the flight operations knowledge. Through a hierarchical decomposition of the domain knowledge, the vehicle command and control capabilities are divided into manageable functional "chunks" that can be captured and verified separately. These functional units, each of which has the responsibility to manage part of the vehicle command and control, are modular, re-usable, and extensible. Also, the functional units are self-contained and have the ability to plan and execute the necessary steps for accomplishing a task based upon the current mission state and available resources. The PEM architecture has potential for application outside the realm of spaceflight, including management of complex industrial processes, nuclear control, and control of complex vehicles such as submarines or unmanned air vehicles.

Wang, Lui↗
NASA NTRS2009

Mars Science Laboratory Workstation Test Set

The Mars Science Laboratory developed the Workstation TestSet (WSTS) is a computer program that enables flight software development on virtual MSL avionics. The WSTS is the non-real-time flight avionics simulator that is designed to be completely software-based and run on a workstation class Linux PC.

Henriquez, David A.↗
NASA NTRS2022

Visualizing Multi-process CPU Utilization using CUSP

The CPU Utilization Statistics Plotter (CUSP) tool automates the interpretation of detailed CPU Utilization trace data and statistics. It puts you on the cusp of understanding how CPU resources are split among the many parallel components of a software system.CUSP combines time-sampled CPU utilization numbers and Event Log annotations to generate human-readable plots and tables. It automatically splits up large CPU usage log files around interesting events, determines and highlights just the tasks of primary relevance by evaluating their changing contribution to each plot's total CPU usage, automatically eliminates irrelevant tasks, provides context by labeling plots with names and durations of all active commands, and uses consistent color-coding to enable quick visual comparison across multiple plots.CUSP has been used to process CPU Utilization trace logs on the Mars Science Laboratory and the Mars 2020 Rover missions during flight software development and Flight Operations on the Martian surface since December 2013.

Maimone, Mark W↗
NASA NTRS1986

Applications software supporting the Spartan Attitude Control System

The native software supporting a single mission for the Spartan Attitude Control System can require up to 40,000 lines of code. Most of this must be rewritten for each mission. Control system engineers use an array of Applications Software Packages residing in ground computers to write each mission's flight software. These Applications Packages are written in the 'C' programming language and run under the UNIX Operating System. This paper discusses each of the Attitude Control Applications Software Packages, and describes the purpose and design of each.

Stone, R. W.↗
NASA NTRS2009

An Autonomous Onboard Targeting Algorithm Using Finite Thrust Maneuvers

In earlier investigations, the adaptation and implementation of a modified two-level corrections process as the onboard targeting algorithm for the Trans-Earth Injection phase of Orion is presented. The objective of that targeting algorithm is to generate the times of ignition and magnitudes of the required maneuvers such that the desired state at entry interface is achieved. In an actual onboard flight software implementation, these times of ignition and maneuvers are relayed onto Flight Control for command and execution. Although this process works well when the burn durations or burn arcs are small, this might not be the case during a contingency situation when lower thrust engines are employed to perform the maneuvers. Therefore, a new version of the modified two-level corrections process is formulated to handle the case of finite burn arcs. This paper presents the development and formulation of that finite burn modified two-level corrections process which can again be used as an onboard targeting algorithm for the Trans-Earth Injection phase of Orion. Additionally, performance results and a comparison between the two methods are presented. The finite burn two-level corrector formulation presented here ensures the entry constraints at entry interface are still met without violating the available fuel budget, while still accounting for much longer burn times in its design.

Scarritt, Sara K.↗
NASA NTRS2010

An Autonomous Onboard Targeting Algorithm Using Finite Thrust Maneuvers

In earlier investigations, the adaptation and implementation of a modified two-level corrections (or targeting) process as the onboard targeting algorithm for the Trans-Earth Injection phase of Orion is presented. The objective of that targeting algorithm is to generate the times of ignition and magnitudes of the required maneuvers such that the desired state at entry interface is achieved. In an actual onboard flight software implementation, these times of ignition and maneuvers are relayed onto Flight Control for command and execution. Although this process works well when the burn durations or burn arcs are small, this might not be the case during a contingency situation when lower thrust engines are employed to perform the maneuvers. Therefore, a new model for the two-level corrections process is formulated here to accommodate finite burn arcs. This paper presents the development and formulation of the finite burn two-level corrector, used as an onboard targeting algorithm for the Trans-Earth Injection phase of Orion. A performance comparison between the impulsive and finite burn models is also presented. The present formulation ensures all entry constraints are met, without violating the available fuel budget, while allowing for low-thrust scenarios with long burn durations.

Scarritt, Sara K.↗
NASA NTRS2010

Controlling Precision Stepper Motors in Flight Using (Almost) No Parts

This concept allows control of high-performance stepper motors with minimal parts count and minimal flight software complexity. Although it uses a small number of common flight-qualified parts and simple control algorithms, it is capable enough to meet demanding system requirements. Its programmable nature makes it trivial to implement changes to control algorithms both during integration & test and in flight. Enhancements such as microstepping, half stepping, back-emf compensation, and jitter reduction can be tailored to the requirements of a large variety of stepper motor based applications including filter wheels, focus mechanisms, antenna tracking subsystems, pointing and mobility. The hardware design (using an H-bridge motor controller IC) was adapted from JPL's MER mission, still operating on Mars. This concept has been fully developed and incorporated into the MCS instrument on MRO, currently operating in Mars orbit. It has been incorporated into the filter wheel mechanism and linear stage (focus) mechanism for the AMT instrument. On MCS/MRO, two of these circuits control the elevation and azimuth of the MCS telescope/radiometer assembly, allowing the instrument to continuously monitor the limb of the Martian atmosphere. Implementation on MCS/MRO resulted in a 4:1 reduction in the volume and mass required for the motor driver electronics (100:25 square inches of PCB space), producing a very compact instrument. In fact, all of the electronics for the MCS instrument are packaged within the movable instrument structure. It also saved approximately 3 Watts of power. Most importantly, the design enabled MCS to meet very its stringent maximum allowable torque disturbance requirements.

Randall, David↗
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 NTRS2007

Space-Shuttle Emulator Software

A package of software has been developed to execute a raw binary image of the space shuttle flight software for simulation of the computational effects of operation of space shuttle avionics. This software can be run on inexpensive computer workstations. Heretofore, it was necessary to use real flight computers to perform such tests and simulations. The package includes a program that emulates the space shuttle orbiter general- purpose computer [consisting of a central processing unit (CPU), input/output processor (IOP), master sequence controller, and buscontrol elements]; an emulator of the orbiter display electronics unit and models of the associated cathode-ray tubes, keyboards, and switch controls; computational models of the data-bus network; computational models of the multiplexer-demultiplexer components; an emulation of the pulse-code modulation master unit; an emulation of the payload data interleaver; a model of the master timing unit; a model of the mass memory unit; and a software component that ensures compatibility of telemetry and command services between the simulated space shuttle avionics and a mission control center. The software package is portable to several host platforms.

Arnold, Scott↗
NASA NTRS2006

Software Engineering Improvement Plan

In performance of this task order, bd Systems personnel provided support to the Flight Software Branch and the Software Working Group through multiple tasks related to software engineering improvement and to activities of the independent Technical Authority (iTA) Discipline Technical Warrant Holder (DTWH) for software engineering. To ensure that the products, comments, and recommendations complied with customer requirements and the statement of work, bd Systems personnel maintained close coordination with the customer. These personnel performed work in areas such as update of agency requirements and directives database, software effort estimation, software problem reports, a web-based process asset library, miscellaneous documentation review, software system requirements, issue tracking software survey, systems engineering NPR, and project-related reviews. This report contains a summary of the work performed and the accomplishments in each of these areas.

Source record↗
NASA NTRS2005

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗
NASA NTRS1980

Mission planning and analysis division development plan for STS-2 through STS-4

The baseline products, schedules, and resource requirements for the Mission Planning and Analysis Division's support of Space Transportation System flights 2, 3, and 4 are presented. Major functions addressed are: orbiter software, Mission Control Center software, flight design, flight operations support, simulation tools, and postflight analysis.

Source record↗
NASA NTRS1990

Software verification plan for GCS

This verification plan is written as part of an experiment designed to study the fundamental characteristics of the software failure process. The experiment will be conducted using several implementations of software that were produced according to industry-standard guidelines, namely the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, Software Consideration in Airborne Systems and Equipment Certification, for the development of flight software. This plan fulfills the DO-178A requirements for providing instructions on the testing of each implementation of software. The plan details the verification activities to be performed at each phase in the development process, contains a step by step description of the testing procedures, and discusses all of the tools used throughout the verification process.

Dent, Leslie A.↗
NASA NTRS2003

Developing Generic Software for Spacecraft Avionics

A proposed approach to the development of software for spacecraft avionics is based partly on a concept of generic software that could be tailored to satisfy requirements for specific missions. The proposed approach would stand in contrast to the conventional approach of first defining avionics requirements for a specific mission, then developing software specific to those requirements. The proposed approach might also be adaptable to programming computers that control and monitor other complex equipment systems that range in scale from automobiles to factories. The concept of a spacecraft avionics functional model (SAFM) is a major element of the proposed approach. An SAFM would be, essentially, a systematic and hierarchical description of the functionality required of the avionics software (and hardware) for a given mission. Although the initial input information used to start the construction of an SAFM would typically amount to a high-level description, the SAFM would thereafter be decomposed to a low level. The resulting low-level version of the model would be used to develop a set of generic requirements that could be expected to include a large fraction of all requirements for a large fraction of all missions. The generic requirements would be used to develop software modules that could be included in, or excluded from, the final flight software to satisfy the requirements of a specific mission.

Smith, Joseph↗
NASA NTRS2012

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗
NASA NTRS2013

Simple Sensitivity Analysis for Orion Guidance Navigation and Control

The performance of Orion flight software, especially its GNC software, is being analyzed by running Monte Carlo simulations of Orion spacecraft flights. The simulated performance is analyzed for conformance with flight requirements, expressed as performance constraints. Flight requirements include guidance (e.g. touchdown distance from target) and control (e.g., control saturation) as well as performance (e.g., heat load constraints). The Monte Carlo simulations disperse hundreds of simulation input variables, for everything from mass properties to date of launch. We describe in this paper a sensitivity analysis tool ("Critical Factors Tool" or CFT) developed to find the input variables or pairs of variables which by themselves significantly influence satisfaction of requirements or significantly affect key performance metrics (e.g., touchdown distance from target). Knowing these factors can inform robustness analysis, can inform where engineering resources are most needed, and could even affect operations. The contributions of this paper include the introduction of novel sensitivity measures, such as estimating success probability, and a technique for determining whether pairs of factors are interacting dependently or independently. The tool found that input variables such as moments, mass, thrust dispersions, and date of launch were found to be significant factors for success of various requirements. Examples are shown in this paper as well as a summary and physics discussion of EFT-1 driving factors that the tool found.

Pressburger, Tom↗