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 325 records · Page 18

All sources NASA NTRS DOE OSTI

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS1981

A method of testing attitude control systems during the development phase

A technique, utilized on the Space Telescope Program, and used for testing satellite attitude pointing and control systems during the engineering and development phases is presented. The technique verifies the hardware models used in design phase computer simulations, verifies the interface between the flight hardware and flight software, and uncovers hardware/software switching or mode logic problems. The testing is accomplished in two phases: a dynamic hardware simulator phase using hardware electronic simulators and an electronic vehicle motion simulator; and a second real hardware phase utilizing engineering model gyros and reaction wheels on an airbearing table. Both phases use an engineering model of the flight computer, flight algorithms and software, and a breadboard data management and computer hardware interface for timing simulations. The purpose of each test and the test phases are described, and examples of closed loop test results for both attitude hold and maneuvering models are given.

Besonis, A.↗

NASA NTRS1988

Development and flight test experiences with a flight-crucial digital control system

Engineers and scientists in the advanced fighter technology integration (AFTI) F-16 program investigated the integration of emerging technologies into an advanced fighter aircraft. AFTI's three major technologies included: flight-crucial digital control, decoupled aircraft flight control, and integration of avionics, flight control, and pilot displays. In addition to investigating improvements in fighter performance, researchers studied the generic problems confronting the designers of highly integrated flight-crucial digital control. An overview is provided of both the advantages and problems of integration digital control systems. Also, an examination of the specification, design, qualification, and flight test life-cycle phase is provided. An overview is given of the fault-tolerant design, multimoded decoupled flight control laws, and integrated avionics design. The approach to qualifying the software and system designs is discussed, and the effects of design choices on system qualification are highlighted.

Mackall, Dale A.↗

NASA NTRS1993

Mars rover mechanisms designed for Rocky 4

A Mars rover prototype vehicle named Rocky 4 was designed and built at JPL during the fall of 1991 and spring 1992. This vehicle is the fourth in a series of rovers designed to test vehicle mobility and navigation software. Rocky 4 was the first attempt to design a vehicle with 'flight like' mass and functionality. It was consequently necessary to develop highly efficient mechanisms and structures to meet the vehicles very tight mass limit of 3 Kg for the entire mobility system (7 Kg for the full system). This paper will discuss the key mechanisms developed for the rover's innovative drive and suspension system. These are the wheel drive and strut assembly, the rocker-bogie suspension mechanism and the differential pivot. The end-to-end design, analysis, fabrication and testing of these components will also be discussed as will their performance during field testing. The lessons learned from Rocky 4 are already proving invaluable for the design of Rocky 6. Rocky 6 is currently being designed to fly on NASA's MESUR mission to Mars scheduled to launch in 1996.

Rivellini, Tommaso P.↗

NASA NTRS1996

Performance Validation of Version 152.0 ANSER Control Laws for the F-18 HARV

The Actuated Nose Strakes for Enhanced Rolling (ANSER) Control Laws were modified as a result of Phase 3 F/A-18 High Alpha Research Vehicle (HARV) flight testing. The control law modifications for the next software release were designated version 152.0. The Ada implementation was tested in the Hardware-In-the-Loop (HIL) simulation and results were compared to those obtained with the NASA Langley batch Fortran implementation of the control laws which are considered the 'truth model.' This report documents the performance validation test results between these implementations for ANSER control law version 152.0.

Messina, Michael D.↗

NASA NTRS1996

The Impact of Ada and Object-Oriented Design in NASA Goddard's Flight Dynamics Division

This paper presents the highlights and key findings of 10 years of use and study of Ada and object-oriented design in NASA Goddard's Flight Dynamics Division (FDD). In 1985, the Software Engineering Laboratory (SEL) began investigating how the Ada language might apply to FDD software development projects. Although they began cautiously using Ada on only a few pilot projects, they expected that, if the Ada pilots showed promising results, the FDD would fully transition its entire development organization from FORTRAN to Ada within 10 years. However, 10 years later, the FDD still produced 80 percent of its software in FORTRAN and had begun using C and C++, despite positive results on Ada projects. This paper presents the final results of a SEL study to quantify the impact of Ada in the FDD, to determine why Ada has not flourished, and to recommend future directions regarding Ada. Project trends in both languages are examined as are external factors and cultural issues that affected the infusion of this technology. The detailed results of this study were published in a formal study report in March of 1995. This paper supersedes the preliminary results of this study that were presented at the Eighteenth Annual Software Engineering Workshop in 1993.

Waligora, Sharon↗

NASA NTRS1998

Spacecraft Autonomy and the Missions of Exploration

Practitioners of artificial intelligence are being engaged to help develop the next generation of flight software for NASA missions, in partnership with other computer scientists, mission designers, operations personnel, spacecraft engineers, systems engineers, software engineers, and scientists.

artificial intelligence spacecraft autonomy ground↗

NASA NTRS2011

Space Shuttle GN and C Development History and Evolution

Completion of the final Space Shuttle flight marks the end of a significant era in Human Spaceflight. Developed in the 1970 s, first launched in 1981, the Space Shuttle embodies many significant engineering achievements. One of these is the development and operation of the first extensive fly-by-wire human space transportation Guidance, Navigation and Control (GN&C) System. Development of the Space Shuttle GN&C represented first time inclusions of modern techniques for electronics, software, algorithms, systems and management in a complex system. Numerous technical design trades and lessons learned continue to drive current vehicle development. For example, the Space Shuttle GN&C system incorporated redundant systems, complex algorithms and flight software rigorously verified through integrated vehicle simulations and avionics integration testing techniques. Over the past thirty years, the Shuttle GN&C continued to go through a series of upgrades to improve safety, performance and to enable the complex flight operations required for assembly of the international space station. Upgrades to the GN&C ranged from the addition of nose wheel steering to modifications that extend capabilities to control of the large flexible configurations while being docked to the Space Station. This paper provides a history of the development and evolution of the Space Shuttle GN&C system. Emphasis is placed on key architecture decisions, design trades and the lessons learned for future complex space transportation system developments. Finally, some of the interesting flight operations experience is provided to inform future developers of flight experiences.

Zimpfer, Douglas↗

NASA NTRS1981

Space Shuttle progress report

A status report on the development of the Space Shuttle system is presented, with emphasis on the system capability, the major objectives accomplished during the development period, the Orbital Flight Test program, and the STS-1 mission profile. The system incorporates virtually all of the characteristics and requirements initially established as design goals over a decade ago: both the system and the solid rocket booster are reusable; the orbiter, a delta wing vehicle, is capable of aerodynamic cross-range in excess of 1,100 nautical miles and has an approximate 4,000 nautical mile down-range capability; the flight control system and software provide various abort modes, and the orbiter crew compartment is designed for a shirt-sleeve environment; the main liquid fuel engines provide 470,000 pounds of thrust at vacuum, and the payload lift capacity is 65,000 pounds to a 150 nautical mile orbit.

Thompson, R. F.↗

NASA NTRS1976

Reconfigurable redundancy management for aircraft flight control

A highly fault tolerant digital computer system has been configured based on extensive experience with flight proven, redundant digital flight control systems. The feasibility of minimizing hardware complexity is shown while maintaining high levels of fault tolerance. The emerging hardware design combines reconfiguration concepts with conventional hardware redundancy techniques and special operational software to provide dual fail operate performance with a basic triplex system. The design provides high reliability and flight safety, enhances maintainability, and reduces life cycle cost while offering improved performance for future aircraft.

Bosch, J. A.↗

NASA NTRSDate not supplied

Design and Testing of an Approach to Automated In-Flight Safety Risk Management for sUAS Operations

An onboard risk management automation design is presented based on run-time assurance principles, as well as the concept for In-Time Aviation Safety Management Systems (IASMS) as described by the National Academies. The automation is designed to operate independently of the autopilot and perform real-time risk assessment spanning multiple classes of hazards, predict constraint violations, and track autopilot states. In the event of elevated risk conditions or predicted constraint violations, the automation will select from a set of available contingencies and trigger autopilot mode changes if necessary to mitigate risk exposure. The onboard automation also informs the remote operator/pilot of what the independent monitor is observing and any contingency decisions or actions that may arise during flight. Details of an implementation of this design and results of verification and validation activities, as required to meet stringent NASA software and system assurance standards, are also presented. This includes simulation and flight testing using small unmanned aircraft systems.

Ersin Ancel↗

NASA NTRS2007

AIRSAR Web-Based Data Processing

The AIRSAR automated, Web-based data processing and distribution system is an integrated, end-to-end synthetic aperture radar (SAR) processing system. Designed to function under limited resources and rigorous demands, AIRSAR eliminates operational errors and provides for paperless archiving. Also, it provides a yearly tune-up of the processor on flight missions, as well as quality assurance with new radar modes and anomalous data compensation. The software fully integrates a Web-based SAR data-user request subsystem, a data processing system to automatically generate co-registered multi-frequency images from both polarimetric and interferometric data collection modes in 80/40/20 MHz bandwidth, an automated verification quality assurance subsystem, and an automatic data distribution system for use in the remote-sensor community. Features include Survey Automation Processing in which the software can automatically generate a quick-look image from an entire 90-GB SAR raw data 32-MB/s tape overnight without operator intervention. Also, the software allows product ordering and distribution via a Web-based user request system. To make AIRSAR more user friendly, it has been designed to let users search by entering the desired mission flight line (Missions Searching), or to search for any mission flight line by entering the desired latitude and longitude (Map Searching). For precision image automation processing, the software generates the products according to each data processing request stored in the database via a Queue management system. Users are able to have automatic generation of coregistered multi-frequency images as the software generates polarimetric and/or interferometric SAR data processing in ground and/or slant projection according to user processing requests for one of the 12 radar modes.

Chu, Anhua↗

NASA NTRS1999

GPS Ocean Reflection Experiment on Spartan 251

It has recently been demonstrated that the GPS signal which has reflected from the ocean surface contains useful geophysical data from which the sea surface wind speed and other parameters can be extracted. This can be used for remote sensing, similar to present day use of radar altimeters or scatterometers, but with significantly smaller instrumentation because of the utilization of the existing GPS broadcast signal for illumination. Several campaigns of aircraft experimentation have been completed demonstrating this technique and reflected GPS data has been reliably collected from 25 km altitude on a balloon. However, there has not yet been a demonstration that the reflected GPS signal can be detected from orbit with sufficient signal to noise ratio (SNR) to make useful remote sensing measurements. A technology demonstration experiment was planned for a Space Shuttle flight in the late 2000 using the Spartan 251 recoverable carrier. This experiment would also have been the first flight validation of the PiVoT GPS receiver developed in house at the Goddard Space Flight Center. The "open-architecture" design of this receiver would allow the software modifications to be made which control code-correlator spacing to map out the shape of the reflected signal waveform, which is the most basic data product generated by this instrumentation. A moderate gain left-hand circularly polarized antenna, constructed from an array of off-the-shelf hemispherical antennas was to be used to give approximately 3 to 6 dB of additional gain. Preliminary SNR predictions have been done indicating that this antenna would offer sufficient gain to record waveform measurements. A system level description of the experiment instrumentation, including the receiver, antenna and data storage and retrieval will be given. The visibility of GPS reflections over the mission duration of several hours will be studied, including the effects of the limited beamwidth of the antenna. Spartan 251 has now been postponed with the earliest opportunity in the year 2002. The results of this study however, have been 2 used to further the define the requirements and expected performance of reflected GPS receivers in orbit. Several other space flight opportunities are being considered based upon this new information.

Garrison, James L↗

NASA NTRSDate not supplied

Rover Flight Software for the VIPER Mission

The VIPER mission exhibits a unique set of operational and environmental constraints, which provide opportunities as well as impose unique challenges for a robotic surface mission.VIPER Rover Software architecture and design targets these constraints in innovative ways to meet the mission’s technical and operational requirements.In this presentation we describe the design of VIPER’s rover software and present early results from its realization.

Flight Software↗

NASA NTRSDate not supplied

Rover Flight Software for the VIPER Mission

Flight Software↗

NASA NTRS1999

Automated Flight Dynamics Product Generation for the EOS AM-1 Spacecraft

As part of NASA's Earth Science Enterprise, the Earth Observing System (EOS) AM-1 spacecraft is designed to monitor long-term, global, environmental changes. Because of the complexity of the AM-1 spacecraft, the mission operations center requires more than 80 distinct flight dynamics products (reports). To create these products, the AM-1 Flight Dynamics Team (FDT) will use a combination of modified commercial software packages (e.g., Analytical Graphic's Satellite ToolKit) and NASA-developed software applications. While providing the most cost-effective solution to meeting the mission requirements, the integration of these software applications raises several operational concerns: (1) Routine product generation requires knowledge of multiple applications executing on variety of hardware platforms. (2) Generating products is a highly interactive process requiring a user to interact with each application multiple times to generate each product. (3) Routine product generation requires several hours to complete. (4) User interaction with each application introduces the potential for errors, since users are required to manually enter filenames and input parameters as well as run applications in the correct sequence. Generating products requires some level of flight dynamics expertise to determine the appropriate inputs and sequencing. To address these issues, the FDT developed an automation software tool called AutoProducts, which runs on a single hardware platform and provides all necessary coordination and communication among the various flight dynamics software applications. AutoProducts, autonomously retrieves necessary files, sequences and executes applications with correct input parameters, and deliver the final flight dynamics products to the appropriate customers. Although AutoProducts will normally generate pre-programmed sets of routine products, its graphical interface allows for easy configuration of customized and one-of-a-kind products. Additionally, AutoProducts has been designed as a mission-independent tool, and can be easily reconfigured to support other missions or incorporate new flight dynamics software packages. After the AM-1 launch, AutoProducts will run automatically at pre-determined time intervals . The AutoProducts tool reduces many of the concerns associated with the flight dynamics product generation. Although AutoProducts required a significant effort to develop because of the complexity of the interfaces involved, its use will provide significant cost savings through reduced operator time and maximum product reliability. In addition, user satisfaction is significantly improved and flight dynamics experts have more time to perform valuable analysis work. This paper will describe the evolution of the AutoProducts tool, highlighting the cost savings and customer satisfaction resulting from its development. It will also provide details about the tool including its graphical interface and operational capabilities.

Matusow, Carla↗

NASA NTRS2008

Automatic Code Generation for Instrument Flight Software

Automatic code generation can be used to convert software state diagrams into executable code, enabling a model- based approach to software design and development. The primary benefits of this process are reduced development time and continuous consistency between the system design (statechart) and its implementation. We used model-based design and code generation to produce software for the Electra UHF radios that is functionally equivalent to software that will be used by the Mars Reconnaissance Orbiter (MRO) and the Mars Science Laboratory to communicate with each other. The resulting software passed all of the relevant MRO flight software tests, and the project provides a useful case study for future work in model-based software development for flight software systems.

state charts↗