SEARCH · Search NASA

Results for “flight software design”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records

All sources NASA NTRS DOE OSTI

NASA NTRS1999

Flight Software Design Choices Based on Criticality

This slide presentation reviews the rationale behind flight software design as a function of criticality. The requirements of human rated systems implies a high criticality for the flight support software. Human life is dependent on correct operation of the software. Flexibility should be permitted when the consequences of software failure are not life threatening. This is also relevant for selecting Commercial Off the Shelf (COTS) software.

Lee, Earl↗

NASA NTRS2007

Flight Software Design and On-orbit Maintenance

This viewgraph presentation discusses the maintenance of flight software (FSW) on-orbit and the design of that software to allow maintenance of programs while they are on orbit.

Calder, Alexander C.↗

NASA NTRS1979

Integrated testing and verification system for research flight software design document

The NASA Langley Research Center is developing the MUST (Multipurpose User-oriented Software Technology) program to cut the cost of producing research flight software through a system of software support tools. The HAL/S language is the primary subject of the design. Boeing Computer Services Company (BCS) has designed an integrated verification and testing capability as part of MUST. Documentation, verification and test options are provided with special attention on real time, multiprocessing issues. The needs of the entire software production cycle have been considered, with effective management and reduced lifecycle costs as foremost goals. Capabilities have been included in the design for static detection of data flow anomalies involving communicating concurrent processes. Some types of ill formed process synchronization and deadlock also are detected statically.

Taylor, R. N.↗

NASA NTRS1980

Development and implementation of Shuttle/IUS proximity operations flight design software

The High Fidelity Relative Motion Program (HFRMP), a trajectory/attitude numerical integration program, was developed and implemented on the MPAD HP-9825A desk top computer systems. A solar and a lunar ephemeris is included in the HFRMP along with models of the oblate Earth, a rotating atmosphere, the orbiter's OMS/RCS/DAP system, orbiter vents, rotor dynamics, and upper stage propulsion systems. Although designed primarily for the analysis of proximity operations, it is useful in other areas such as attitude/stability analysis, propulsive consumables estimation, and trajector perturbation studies. An unique identification was assigned to each of the various configurations of the HFRMP that were developed to test new techniques and algorithms are briefly described. These include the HFRMP Versions 03H, 03M, 03T, 03U, and 05D. Development of orbiter/upper stage separation techniques including flight design support for the TDRS-A and Galileo deployment flights and design of standard maneuver sequences is discussed. Also, the development and implementation of the Euler angle conversion program is briefly addressed.

Wilson, S. W.↗

NASA NTRS1982

SEPAC flight software detailed design specifications, volume 1

The detailed design specifications (as built) for the SEPAC Flight Software are defined. The design includes a description of the total software system and of each individual module within the system. The design specifications describe the decomposition of the software system into its major components. The system structure is expressed in the following forms: the control-flow hierarchy of the system, the data-flow structure of the system, the task hierarchy, the memory structure, and the software to hardware configuration mapping. The component design description includes details on the following elements: register conventions, module (subroutines) invocaton, module functions, interrupt servicing, data definitions, and database structure.

Source record↗

NASA NTRS1998

Development and Testing of Automatically Generated ACS Flight Software for the MAP Spacecraft

By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.

ODonnell, James R., Jr.↗

NASA NTRS1973

Digital flight control software design requirements

The objective of the integrated digital flight control system is to provide rotational and translational control of the space shuttle orbiter in all phases of flight: from launch ascent through orbit to entry and touchdown, and during powered horizontal flights. The program provides a versatile control system structure while maintaining uniform communications with other programs, sensors, and control effects by using an executive routine/function subroutine format. The program reads all external variables at a single point, copies them into its dedicated storage, and then calls the required subroutines in the proper sequence. As a result, the flight control program is largely independent of other programs in the GN and C computer complex and is equally insensitive to the characteristics of the processor configuration. The integrated structure of the control system and the DFCS executive routine which embodies that structure are described. The specific estimation and control algorithms used in the various mission phases are shown. Attitude maneuver routines that interface with the DFCS are also described.

Source record↗

NASA NTRS1980

Tools to aid the specification and design of flight software, appendix B

The tasks that are normally performed during the specification and architecture design stages of software development are identified. Ways that tools could perform, or aid the performance, of such tasks are also identified. Much of the verification and analysis that is suggested is currently rarely performed during these early stages, but it is believed that this analysis should be done as early as possible so as to detect errors as early as possible.

Bristow, G.↗

NASA NTRS1995

TIMED Doppler Interferometer

The Timed Doppler Interferometer (TIDI) will accurately and precisely determine the global vector MLTI (Mesosphere and Lower Thermosphere) wind, temperature, and density profiles. It will measure characteristics of the gravity wave and planetary wave spectra. The tidal characteristics of temperature, density, and wind in the MLTI will be determined. The neutral and ion winds will be measured to characterize the electrodynamical behavior of the MLTI. Oxygen and O2 abundances and nocticulent cloud activity will be measured. This review goes into the calibration and error sources, optical design, mechanisms design, detector design, electronics design, microprocessor and flight software design, and quality assurance and parts.

Killeen, Timothy L.↗

NASA NTRS1978

Preliminary design of an Orbiter/IUS separation sequence

An orbiter/IUS separation sequence to satisfy the assumed requirements of Shuttle Flight 8 was defined for the purpose of gaining an insight into the flight design software requirements. The key to economical and effective flight design for orbiter/IUS proximity operations is considered to be the capability for rapid and accurate generation of graphical displays that will facilitate not only decision making on the part of the designer, but also lucid documentation of rationale and the resulting design features. The data indicate that (1) an OMS burn is required to attain the necessary velocity without subjecting the IUS and its payload to undue plume impingement, and (2) a departure trajectory that places the orbiter above and behind the IUS at SRM ignition time is preferred over the alternative which would place it below and ahead.

Wilson, S. W.↗

NASA NTRS2005

Expecting the Unexpected: Radiation Hardened Software

Radiation induced Single Event Effects (SEEs) are a serious problem for spacecraft flight software, potentially leading to a complete loss of mission. Conventional risk mitigation has been focused on hardware, leading to slow, expensive and outdated on-board computing devices, increased power consumption and launch mass. Our approach is to look at SEEs from a software perspective, and to explicitly design flight software so that it can detect and correct the majority of SEES. Radiation hardened flight software will reduce the significant residual residual risk for critical missions and flight phases, and enable more use of inexpensive and fast COTS hardware.

Penix, John↗

NASA NTRS1993

The Cassini spacecraft: Object oriented flight control software

The Cassini Attitude and Articulation Control Subsystem (AACS) is responsible for determining and controlling the spacecraft attitude including instrument pointing, antenna pointing, and thrust vector pointing during velocity change maneuvers. The 12 year mission life, long round-trip light time, and extended periods of coast without continuous ground control drive the AACS flight software design in the directions of autonomy, fault tolerance, and modularity to accommodate planned upgrades in flight. The Cassini AACS Flight Software is depicted in increasing levels of detail using a Context Diagram, Architecture Diagrams (i.e., Dependency Diagrams), an Object Diagram for each object, and a Statechart (i.e., State Transition Diagram) for each object. The detail contained in the diagrams is enhanced and refined during the Requirements and Design Phases of both Subsystem and Software Development. Examples of all the diagrams as well as the criteria for object selection, the advantages of statecharts, and the ease of modifying the design to accommodate changes in scope are described.

Hackney, John C.↗

NASA NTRS2011

Orion Relative Navigation Flight Software Analysis and Design

The Orion relative Navigation System has sought to take advantage of the latest developments in sensor and algorithm technology while living under the constraints of mass, power, volume, and throughput. In particular, the only sensor specifically designed for relative navigation is the Vision Navigation System (VNS), a lidar-based sensor. But it uses the Star Trackers, GPS (when available) and IMUs, which are part of the overall Orion navigation sensor suite, to produce a relative state accurate enough to dock with the ISS. The Orion Relative Navigation System has significantly matured as the program has evolved from the design phase to the flight software implementation phase. With the development of the VNS system and the STORRM flight test of the Orion Relative Navigation hardware, much of the performance of the system will be characterized before the first flight. However challenges abound, not the least of which is the elimination of the RF range and range-rate system, along with the development of the FSW in the Matlab/Simulink/Stateflow environment. This paper will address the features and the rationale for the Orion Relative Navigation design as well as the performance of the FSW in a 6-DOF environment as well as the initial results of the hardware performance from the STORRM flight.

D'Souza, Chris↗

NASA NTRS2004

The HiVY Tool Set

Our aim is to validate mission-specific components of spacecraft flight software designs that are specified using state-charts and translated automatically to the final flight code for the mission. We established an automatic translation tool set from state-charts to SPIN for the validation of such mission-specific components. To guarantee compliance with autogenerated flight code, our translation tool set preserves the StateFlow@ semantics. We are now able to specify and validate portions of mission-critical software design and implementation using the exhaustive exploration techniques of model checking.

stateflow↗

NASA NTRS2011

Safety-Critical Partitioned Software Architecture: A Partitioned Software Architecture for Robotic

The flight software on virtually every mission currently managed by JPL has several major flaws that make it vulnerable to potentially fatal software defects. Many of these problems can be addressed by recently developed partitioned operating systems (OS). JPL has avoided adopting a partitioned operating system on its flight missions, primarily because doing so would require significant changes in flight software design, and the risks associated with changes of that magnitude cannot be accepted by an active flight project. The choice of a partitioned OS can have a dramatic effect on the overall system and software architecture, allowing for realization of benefits far beyond the concerns typically associated with the choice of OS. Specifically, we believe that a partitioned operating system, when coupled with an appropriate architecture, can provide a strong infrastructure for developing systems for which reusability, modifiability, testability, and reliability are essential qualities. By adopting a partitioned OS, projects can gain benefits throughout the entire development lifecycle, from requirements and design, all the way to implementation, testing, and operations.

(Avionics Application Standard Software Interface ↗

NASA NTRS2004

The HiVy tool set

translation↗

NASA NTRS1980

Flight software requirements and design support system

The desirability and feasibility of computer-augmented support for the pre-implementation activities occurring during the development of flight control software was investigated. The specific topics to be investigated were the capabilities to be included in a pre-implementation support system for flight control software system development, and the specification of a preliminary design for such a system. Further, the pre-implementation support system was to be characterized and specified under the constraints that it: (1) support both description and assessment of flight control software requirements definitions and design specification; (2) account for known software description and assessment techniques; (3) be compatible with existing and planned NASA flight control software development support system; and (4) does not impose, but may encourage, specific development technologies. An overview of the results is given.

Riddle, W. E.↗

NASA NTRS2018

6DOF Testing of the SLS Inertial Navigation Unit

The Navigation System on the NASA Space Launch System (SLS) Block 1 vehicle performs initial alignment of the Inertial Navigation System (INS) navigation frame through gyrocompass alignment (GCA). Because the navigation architecture for the SLS Block 1 vehicle is a purely inertial system, the accuracy of the achieved orbit relative to mission requirements is very sensitive to initial alignment accuracy. The assessment of this sensitivity and many others via simulation is a part of the SLS Model-Based Design and Model-Based Requirements approach. As a part of the aforementioned, 6DOF Monte Carlo simulation is used in large part to develop and demonstrate verification of program requirements. To facilitate this and the GN&C flight software design process, an SLS-Program-controlled Design Math Model (DMM) of the SLS INS was developed by the SLS Navigation Team. The SLS INS model implements all of the key functions of the hardware-namely, GCA, inertial navigation, and FDIR (Fault Detection, Isolation, and Recovery)-in support of SLS GN&C design requirements verification. Despite the strong sensitivity to initial alignment, GCA accuracy requirements were not verified by test due to program cost and schedule constraints. Instead, the system relies upon assessments performed using the SLS INS model. In order to verify SLS program requirements by analysis, the SLS INS model is verified and validated against flight hardware. In lieu of direct testing of GCA accuracy in support of requirement verification, the SLS Navigation Team proposed and conducted an engineering test to, among other things, validate the GCA performance and overall behavior of the SLS INS model through comparison with test data. This paper will detail dynamic hardware testing of the SLS INS, conducted by the SLS Navigation Team at Marshall Space Flight Center's 6DOF Table Facility, in support of GCA performance characterization and INS model validation. A 6-DOF motion platform was used to produce 6DOF pad twist and sway dynamics while a simulated SLS flight computer communicated with the INS. Tests conducted include an evaluation of GCA algorithm robustness to increasingly dynamic pad environments, an examination of GCA algorithm stability and accuracy over long durations, and a long-duration static test to gather enough data for Allan Variance analysis. Test setup, execution, and data analysis will be discussed, including analysis performed in support of SLS INS model validation.

Geohagan, Kevin↗