Search NASA⌕ Search

SEARCH · Search NASA

Results for “Flight Control System Verification”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

Verification and Validation of Adaptive and Intelligent Systems with Flight Test Results

F-15 IFCS project goals are: a) Demonstrate Control Approaches that can Efficiently Optimize Aircraft Performance in both Normal and Failure Conditions [A] & [B] failures. b) Advance Neural Network-Based Flight Control Technology for New Aerospace Systems Designs with a Pilot in the Loop. Gen II objectives include; a) Implement and Fly a Direct Adaptive Neural Network Based Flight Controller; b) Demonstrate the Ability of the System to Adapt to Simulated System Failures: 1) Suppress Transients Associated with Failure; 2) Re-Establish Sufficient Control and Handling of Vehicle for Safe Recovery. c) Provide Flight Experience for Development of Verification and Validation Processes for Flight Critical Neural Network Software.

Burken, John J.↗
NASA NTRS2009

Node 3 Relocation Environmental Control and Life Support System Modification Kit Verification and Updated Status

Node 1 (Unity) flew to International Space Station (ISS) on Flight 2A. Node 1 was the first module of the United States On-Orbit Segment (USOS) launched to ISS. The Node 1 ISS Environmental Control and Life Support (ECLS) design featured limited ECLS capability. The main purpose of Node 1 was to provide internal storage by providing four stowage rack locations within the module and to allow docking of multiple modules and a truss segment to it. The ECLS subsystems inside Node 1 were routed through the element prior to launch to allow for easy integration of the attached future elements, particularly the Habitation Module which was planned to be located at the nadir docking port of Node 1. After Node 1 was on-orbit, the Program decided not to launch the Habitation Module and instead, to replace it with Node 3 (Tranquility). In 2007, the Program became concerned with a potential Russian docking port approach issue for the Russian FGB nadir docking port after Node 3 is attached to Node 1. To solve this concern the Program decided to relocate Node 3 from Node 1 nadir to Node 1 port. To support the movement of Node 3 the Program decided to build a modification kit for Node 1, an on-orbit feedthrough leak test device, and new vestibule jumpers to support the ECLS part of the relocation. This paper provides a design overview of the modification kit, a summary of the Node 1 ECLS re-verification to support the Node 3 relocation from Node 1 nadir to Node 1 port, and a status of the ECLS modification kit installation into Node 1.

Williams, David E.↗
NASA NTRS2010

Node 3 Relocation Environmental Control and Life Support System Modification Kit Verification and Updated Status

Node 1 (Unity) flew to International Space Station (ISS) on Flight 2A. Node 1 was the first module of the United States On-Orbit Segment (USOS) launched to ISS. The Node 1 ISS Environmental Control and Life Support (ECLS) design featured limited ECLS capability. The main purpose of Node 1 was to provide internal storage by providing four stowage rack locations within the module and to allow docking of multiple modules and a truss segment to it. The ECLS subsystems inside Node 1 were routed through the element prior to launch to allow for easy integration of the attached future elements, particularly the Habitation Module which was planned to be located at the nadir docking port of Node 1. After Node I was on-orbit, the Program decided not to launch the Habitation Module and instead, to replace it with Node 3 (Tranquility). In 2007, the Program became concerned with a potential Russian docking port approach issue for the Russian FGB nadir docking port after Node 3 is attached to Node 1. To solve this concern the Program decided to relocate Node 3 from Node I nadir to Node 1 port. To support the movement of Node 3 the Program decided to build a modification kit for Node 1, an on-orbit feedthrough leak test device, and new vestibule jumpers to support the ECLS part of the relocation. This paper provides a design overview of the modification kit for Node 1, a summary of the Node 1 ECLS re-verification to support the Node 3 relocation from Node 1 nadir to Node 1 port, and a status of the ECLS modification kit installation into Node 1.

Williams, David E.↗
NASA NTRS1983

Graphics enhanced computer emulation for improved timing-race and fault tolerance control system analysis

A computer simulation system has been developed for the Space Shuttle's advanced Centaur liquid fuel booster rocket, in order to conduct systems safety verification and flight operations training. This simulation utility is designed to analyze functional system behavior by integrating control avionics with mechanical and fluid elements, and is able to emulate any system operation, from simple relay logic to complex VLSI components, with wire-by-wire detail. A novel graphics data entry system offers a pseudo-wire wrap data base that can be easily updated. Visual subsystem operations can be selected and displayed in color on a six-monitor graphics processor. System timing and fault verification analyses are conducted by injecting component fault modes and min/max timing delays, and then observing system operation through a red line monitor.

Szatkowski, G. P.↗
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 NTRS1994

Formal design and verification of a reliable computing platform for real-time control (phase 3 results)

In this paper the design and formal verification of the lower levels of the Reliable Computing Platform (RCP), a fault-tolerant computing system for digital flight control applications, are presented. The RCP uses NMR-style redundancy to mask faults and internal majority voting to flush the effects of transient faults. Two new layers of the RCP hierarchy are introduced: the Minimal Voting refinement (DA_minv) of the Distributed Asynchronous (DA) model and the Local Executive (LE) Model. Both the DA_minv model and the LE model are specified formally and have been verified using the Ehdm verification system. All specifications and proofs are available electronically via the Internet using anonymous FTP or World Wide Web (WWW) access.

Butler, Ricky W.↗
NASA NTRS1980

STS-1 operational flight profile. Volume 5: Descent, cycle 3

The trajectory data presented are to be used for orbiter systems and subsystems evalation, flight and mission control center software verification, flight techniques and timeline development, crew training, and evaluation of operational mission suitability. The entry profile is very similar to cycle 2, however, elevon and body flap temperature margins have increased and the elevon schedule was changed. The terminal area energy management (TAEM) profile was completely reshaped to conform with new angle of attack constraints and left hand turn around the heading alignment cylinder. Also, the entry/TAEM interface was adjusted to minimize guidance induced angle of attack transients across the interface. The approach and landing phase was reshaped for a 20 deg glideslope and reduced velocity at touchdown. The definition of the runway threshold was standardized for all landing sites. This results in a shift at Edwards Air Force Base in aim points and touchdown relative to the threshold of 1000 feet. The rollout remains essentially unchanged with the exception of the speedbrake, which is now deployed to 50 percent at touchdown.

Moore, R.↗
NASA NTRS2012

Design of Low Complexity Model Reference Adaptive Controllers

Flight research experiments have demonstrated that adaptive flight controls can be an effective technology for improving aircraft safety in the event of failures or damage. However, the nonlinear, timevarying nature of adaptive algorithms continues to challenge traditional methods for the verification and validation testing of safety-critical flight control systems. Increasingly complex adaptive control theories and designs are emerging, but only make testing challenges more difficult. A potential first step toward the acceptance of adaptive flight controllers by aircraft manufacturers, operators, and certification authorities is a very simple design that operates as an augmentation to a non-adaptive baseline controller. Three such controllers were developed as part of a National Aeronautics and Space Administration flight research experiment to determine the appropriate level of complexity required to restore acceptable handling qualities to an aircraft that has suffered failures or damage. The controllers consist of the same basic design, but incorporate incrementally-increasing levels of complexity. Derivations of the controllers and their adaptive parameter update laws are presented along with details of the controllers implementations.

Hanson, Curt↗
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 NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

GPS↗
NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

Galileo↗
NASA NTRS1994

Using formal specification in the Guidance and Control Software (GCS) experiment. Formal design and verification technology for life critical systems

The goal of this task was to investigate how formal methods could be incorporated into a software engineering process for flight-control systems under DO-178B and to demonstrate that process by developing a formal specification for NASA's Guidance and Controls Software (GCS) Experiment. GCS is software to control the descent of a spacecraft onto a planet's surface. The GCS example is simplified from a real example spacecraft, but exhibits the characteristics of realistic spacecraft control software. The formal specification is written in Larch.

Weber, Doug↗
NASA NTRS1992

Rapid development of the X-31 simulation to support flight-testing

The X-31 Enhanced Fighter Maneuverability Program has been recognized to form the International Test Organization, with the NASA Dryden Flight Research Facility (NASA-Dryden) as the responsible test organization. The two X-31 research aircraft and engineering support personnel were colocated at NASA-Dryden, with flight test operations beginning in Apr. 1992. Therefore, rapid development of a hardware-in-the-loop simulation was needed to support the flight test operations at NASA-Dryden, and to perform verification and validation of flight control software. The X-31 simulation system requirements, distributed simulation system architecture, simulation components math models to the visual system, and the advanced capabilities the X-31 simulation provides. In addition, unique software tools and the methods used to rapidly develop this simulation system will be highlighted.

Mackall, Dale↗
NASA NTRS1992

Rapid development of the X-31 simulation to support flight-testing

The X-31 Enhanced Fighter Maneuverability Program has been recognized to form the International Test Organization, with the NASA Dryden Flight Research Facility (NASA-Dryden) as the responsible test organization. The two X-31 research aircraft and engineering support personnel were colocated at NASA-Dryden, with flight test operations beginning in Apr. 1992. Therefore, rapid development of a hardware-in-the-loop simulation was needed to support the flight test operations at NASA-Dryden, and to perform verification and validation of flight control software. The X-31 simulation system requirements, distributed simulation system architecture, simulation components math models to the visual system, and the advanced capabilities the X-31 simulation provides. In addition, unique software tools and the methods used to rapidly develop this simulation system will be highlighted.

Mackall, Dale↗
NASA NTRS1981

Verification of the Space Shuttle entry GN&C system

The certification procedures for the initial Shuttle flight are discussed. Particular attention is paid to the entry guidance, navigation, and control (GNC) verification, comprising tests, analysis, demonstration, inspection, and simulation. Flow diagrams for the verification and operational flight sequences are provided, along with a block diagram of the GNC circuitry interfaces. The development of the test matrix software for the GNC is outlined, noting the constant interplay between software verification and spacecraft reconfiguration to meet simulated performance requirements. Comparison of GNC performance predictions with actual entry flight data showed a good match in all performance areas except for sideslip excursions, bank overshoots, an area of transonic buffet, and an increased lift/drag ratio in the preflare to landing flight phase.

Van Hoften, J. D. A.↗
NASA NTRS1984

Software control and system configuration management: A systems-wide approach

A comprehensive software control and system configuration management process for flight-crucial digital control systems of advanced aircraft has been developed and refined to insure efficient flight system development and safe flight operations. Because of the highly complex interactions among the hardware, software, and system elements of state-of-the-art digital flight control system designs, a systems-wide approach to configuration control and management has been used. Specific procedures are implemented to govern discrepancy reporting and reconciliation, software and hardware change control, systems verification and validation testing, and formal documentation requirements. An active and knowledgeable configuration control board reviews and approves all flight system configuration modifications and revalidation tests. This flexible process has proved effective during the development and flight testing of several research aircraft and remotely piloted research vehicles with digital flight control systems that ranged from relatively simple to highly complex, integrated mechanizations.

Petersen, K. L.↗
NASA NTRS1983

Software control and system configuration management - A process that works

A comprehensive software control and system configuration management process for flight-crucial digital control systems of advanced aircraft has been developed and refined to insure efficient flight system development and safe flight operations. Because of the highly complex interactions among the hardware, software, and system elements of state-of-the-art digital flight control system designs, a systems-wide approach to configuration control and management has been used. Specific procedures are implemented to govern discrepancy reporting and reconciliation, software and hardware change control, systems verification and validation testing, and formal documentation requirements. An active and knowledgeable configuration control board reviews and approves all flight system configuration modifications and revalidation tests. This flexible process has proved effective during the development and flight testing of several research aircraft and remotely piloted research vehicles with digital flight control systems that ranged from relatively simple to highly complex, integrated mechanizations.

Petersen, K. L.↗