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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
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 NTRS2015

Flight Testing ALHAT Precision Landing Technologies Integrated Onboard the Morpheus Rocket Vehicle

A suite of prototype sensors, software, and avionics developed within the NASA Autonomous precision Landing and Hazard Avoidance Technology (ALHAT) project were terrestrially demonstrated onboard the NASA Morpheus rocket-propelled Vertical Testbed (VTB) in 2014. The sensors included a LIDAR-based Hazard Detection System (HDS), a Navigation Doppler LIDAR (NDL) velocimeter, and a long-range Laser Altimeter (LAlt) that enable autonomous and safe precision landing of robotic or human vehicles on solid solar system bodies under varying terrain lighting conditions. The flight test campaign with the Morpheus vehicle involved a detailed integration and functional verification process, followed by tether testing and six successful free flights, including one night flight. The ALHAT sensor measurements were integrated into a common navigation solution through a specialized ALHAT Navigation filter that was employed in closed-loop flight testing within the Morpheus Guidance, Navigation and Control (GN&C) subsystem. Flight testing on Morpheus utilized ALHAT for safe landing site identification and ranking, followed by precise surface-relative navigation to the selected landing site. The successful autonomous, closed-loop flight demonstrations of the prototype ALHAT system have laid the foundation for the infusion of safe, precision landing capabilities into future planetary exploration missions.

Carson, John M. III↗
NASA NTRS2021

Pointing Error Budget Development and Methodology on the Psyche Project

The Psyche mission was selected by NASA as the 14th mission in the Discovery Program in 2017. The Psyche spacecraft utilizes solar electric propulsion, and will journey to the asteroid (16) Psyche during a 3.5 year trajectory after its planned 2022 launch. The spacecraft instrument suite includes a magnetometer, a multispectral imager, a gamma ray neutron spectrometer, and an X-band radio telecommunications system. It also includes the Deep Space Optical Communication technical demonstration. These instruments along with other spacecraft components require pointing accuracy to meet their scientific and engineering performance requirements. Early on in the project development, the team established a methodology by which pointing accuracy (knowledge and control) is analyzed against the system requirements by means of pointing error budgets and requirement allocations. A margin policy was implemented to ensure the instrument and engineering component pointing accuracy requirements will be met during verification and in flight. Psyche’s pointing management framework defines detailed rationales for the system and subsystem error allocations of the top level pointing accuracy requirements, with sufficient project level pointing margin, and supports end-to-end pointing requirement verification. This paper will present an overview of the Psyche project’s pointing error budget development process, and discuss the rationale behind the methodology. Psyche’s pointing budget methodology integrates best practices and lessons learned from heritage missions, while focusing on the specific needs of the Psyche spacecraft and its science instruments. Key challenges in the pointing error budget development will be reviewed, and a deep dive into two key Psyche pointing budgets are presented. The systems engineering of Psyche’s pointing budget methodology outlined in this paper will serve as a resource for future deep space missions.

Lai, Peter↗
NASA NTRS1974

A computer simulation of Skylab dynamics and attitude control for performance verification and operational support

A simulation of the Skylab attitude and pointing control system (APCS) is outlined and discussed. Implementation is via a large hybrid computer and includes those factors affecting system momentum management, propellant consumption, and overall vehicle performance. The important features of the flight system are discussed; the mathematical models necessary for this treatment are outlined; and the decisions involved in implementation are discussed. A brief summary of the goals and capabilities of this tool is also included.

Buchanan, H.↗
NASA NTRS1990

Software safety - A user's practical perspective

Software safety assurance philosophy and practices at the NASA Ames are discussed. It is shown that, to be safe, software must be error-free. Software developments on two digital flight control systems and two ground facility systems are examined, including the overall system and software organization and function, the software-safety issues, and their resolution. The effectiveness of safety assurance methods is discussed, including conventional life-cycle practices, verification and validation testing, software safety analysis, and formal design methods. It is concluded (1) that a practical software safety technology does not yet exist, (2) that it is unlikely that a set of general-purpose analytical techniques can be developed for proving that software is safe, and (3) that successful software safety-assurance practices will have to take into account the detailed design processes employed and show that the software will execute correctly under all possible conditions.

Dunn, William R.↗
NASA NTRS2011

NEXT Propellant Management System Integration With Multiple Ion Thrusters

As a critical part of the NEXT test validation process, a multiple-string integration test was performed on the NEXT propellant management system and ion thrusters. The objectives of this test were to verify that the PMS is capable of providing stable flow control to multiple thrusters operating over the NEXT system throttling range and to demonstrate to potential users that the NEXT PMS is ready for transition to flight. A test plan was developed for the sub-system integration test for verification of PMS and thruster system performance and functionality requirements. Propellant management system calibrations were checked during the single and multi-thruster testing. The low pressure assembly total flow rates to the thruster(s) were within 1.4 percent of the calibrated support equipment flow rates. The inlet pressures to the main, cathode, and neutralizer ports of Thruster PM1R were measured as the PMS operated in 1-thruster, 2-thruster, and 3-thruster configurations. It was found that the inlet pressures to Thruster PM1R for 2-thruster and 3-thruster operation as well as single thruster operation with the PMS compare very favorably indicating that flow rates to Thruster PM1R were similar in all cases. Characterizations of discharge losses, accelerator grid current, and neutralizer performance were performed as more operating thrusters were added to the PMS. There were no variations in these parameters as thrusters were throttled and single and multiple thruster operations were conducted. The propellant management system power consumption was at a fixed voltage to the DCIU and a fixed thermal throttle temperature of 75 C. The total power consumed by the PMS was 10.0, 17.9, and 25.2 W, respectively, for single, 2-thruster, and 3-thruster operation with the PMS. These sub-system integration tests of the PMS, the DCIU Simulator, and multiple thrusters addressed, in part, the NEXT PMS and propulsion system performance and functionality requirements.

Sovey, James S.↗
NASA NTRS2018

SLS Navigation Model-Based Design Approach

The SLS Program chose to implement a Model-based Design and Model-based Requirements approach for managing component design information and system requirements. This approach differs from previous large-scale design efforts at Marshall Space Flight Center where design documentation alone conveyed information required for vehicle design and analysis and where extensive requirements sets were used to scope and constrain the design. The SLS Navigation Team has been responsible for the Program-controlled Design Math Models (DMMs) which describe and represent the performance of the Inertial Navigation System (INS) and the Rate Gyro Assemblies (RGAs) used by Guidance, Navigation, and Controls (GN&C). The SLS Navigation Team is also responsible for the navigation algorithms. The navigation algorithms are delivered for implementation on the flight hardware as a DMM. For the SLS Block 1-B design, the additional GPS Receiver hardware is managed as a DMM at the vehicle design level. This paper provides a discussion of the processes and methods used to engineer, design, and coordinate engineering trades and performance assessments using SLS practices as applied to the GN&C system, with a particular focus on the Navigation components. These include composing system requirements, requirements verification, model development, model verification and validation, and modeling and analysis approaches. The Model-based Design and Requirements approach does not reduce the effort associated with the design process versus previous processes used at Marshall Space Flight Center. Instead, the approach takes advantage of overlap between the requirements development and management process, and the design and analysis process by efficiently combining the control (i.e. the requirement) and the design mechanisms. The design mechanism is the representation of the component behavior and performance in design and analysis tools. The focus in the early design process shifts from the development and management of design requirements to the development of usable models, model requirements, and model verification and validation efforts. The models themselves are represented in C/C++ code and accompanying data files. Under the idealized process, potential ambiguity in specification is reduced because the model must be implementable versus a requirement which is not necessarily subject to this constraint. Further, the models are shown to emulate the hardware during validation. For models developed by the Navigation Team, a common interface/standalone environment was developed. The common environment allows for easy implementation in design and analysis tools. Mechanisms such as unit test cases ensure implementation as the developer intended. The model verification and validation process provides a very high level of component design insight. The origin and implementation of the SLS variant of Model-based Design is described from the perspective of the SLS Navigation Team. The format of the models and the requirements are described. The Model-based Design approach has many benefits but is not without potential complications. Key lessons learned associated with the implementation of the Model Based Design approach and process from infancy to verification and certification are discussed

Oliver, T. Emerson↗
NASA NTRS1993

Concept report: Experimental vector magnetograph (EXVM) operational configuration balloon flight assembly

The observational limitations of earth bound solar studies has prompted a great deal of interest in recent months in being able to gain new scientific perspectives through, what should prove to be, relatively low cost flight of the magnetograph system. The ground work done by TBE for the solar balloon missions (originally planned for SOUP and GRID) as well as the rather advanced state of assembly of the EXVM has allowed the quick formulation of a mission concept for the 30 cm system currently being assembled. The flight system operational configuration will be discussed as it is proposed for short duration flight (on the order of one day) over the continental United States. Balloon hardware design requirements used in formulation of the concept are those set by the National Science Balloon Facility (NSBF), the support agency under NASA contract for flight services. The concept assumes that the flight hardware assembly would come together from three development sources: the scientific investigator package, the integration contractor package, and the NSBF support system. The majority of these three separate packages can be independently developed; however, the computer control interfaces and telemetry links would require extensive preplanning and coordination. A special section of this study deals with definition of a dedicated telemetry link to be provided by the integration contractor for video image data for pointing system performance verification. In this study the approach has been to capitalize to the maximum extent possible on existing hardware and system design. This is the most prudent step that can be taken to reduce eventual program cost for long duration flights. By fielding the existing EXVM as quickly as possible, experience could be gained from several short duration flight tests before it became necessary to commit to major upgrades for long duration flights of this system or of the larger 60 cm version being considered for eventual development.

Source record↗
NASA NTRS1988

NASA Shuttle Training Aircraft flight simulation overview

The Shuttle Training Aircraft (STA) is a variable stability, variable control law flying simulator used by NASA/JSC to train astronauts in the final landing phase of a Space Shuttle Orbiter. A general outline is given for the STA flight simulation system. An overview is given of the software generation and verification process through the Advanced Validation System (AVAS). The flight test techniques for software verification will be reviewed and the process for releasing the software for flight training will be covered. The astronaut STA training syllabus is examined. Parameter matching with the Orbiter in the final approach phase of de-orbit and landing is briefly examined. Simulation performance will be assessed against flight data, performance measurement, and cue synchronization.

Justiz, Charles R.↗
NASA NTRS1997

Experimental Verification of the Pulse Shepherding Concept in Dispersion-Shifted Single-Mode Fiber for Bit-Parallel Wavelength Links

A new way to dynamically control in-flight pulses by a co-propagating shepherd pulse in a wavelength divsion multiplexed (WDM) single-mode fiber system was proposed at the MPPOI '96 Conference. That system functionally resembles an optical fiber ribbon cable, except that all the bits pass on one fiber optic waveguide.

Pulse Shepherding Bit-Parallel Wavelength Links↗
NASA NTRS2002

Verification and Validation of Neural Networks for Aerospace Systems

The Dryden Flight Research Center V&V working group and NASA Ames Research Center Automated Software Engineering (ASE) group collaborated to prepare this report. The purpose is to describe V&V processes and methods for certification of neural networks for aerospace applications, particularly adaptive flight control systems like Intelligent Flight Control Systems (IFCS) that use neural networks. This report is divided into the following two sections: Overview of Adaptive Systems and V&V Processes/Methods.

Mackall, Dale↗
NASA NTRS2002

Verification and Validation of Neural Networks for Aerospace Systems

The Dryden Flight Research Center V&V working group and NASA Ames Research Center Automated Software Engineering (ASE) group collaborated to prepare this report. The purpose is to describe V&V processes and methods for certification of neural networks for aerospace applications, particularly adaptive flight control systems like Intelligent Flight Control Systems (IFCS) that use neural networks. This report is divided into the following two sections: 1) Overview of Adaptive Systems; and 2) V&V Processes/Methods.

Mackall, Dale↗
NASA NTRS1992

ONAV - An Expert System for the Space Shuttle Mission Control Center

The ONAV (Onboard Navigation) Expert System is being developed as a real-time console assistant to the ONAV flight controller for use in the Mission Control Center at the Johnson Space Center. Currently, Oct. 1991, the entry and ascent systems have been certified for use on console as support tools, and were used for STS-48. The rendezvous system is in verification with the goal to have the system certified for STS-49, Intelsat retrieval. To arrive at this stage, from a prototype to real-world application, the ONAV project has had to deal with not only Al issues but operating environment issues. The Al issues included the maturity of Al languages and the debugging tools, verification, and availability, stability and size of the expert pool. The environmental issues included real time data acquisition, hardware suitability, and how to achieve acceptance by users and management.

Mills, Malise↗
NASA NTRS1998

Development and Testing of a High Stability Engine Control (HISTEC) System

Flight tests were recently completed to demonstrate an inlet-distortion-tolerant engine control system. These flight tests were part of NASA's High Stability Engine Control (HISTEC) program. The objective of the HISTEC program was to design, develop, and flight demonstrate an advanced integrated engine control system that uses measurement-based, real-time estimates of inlet airflow distortion to enhance engine stability. With improved stability and tolerance of inlet airflow distortion, future engine designs may benefit from a reduction in design stall-margin requirements and enhanced reliability, with a corresponding increase in performance and decrease in fuel consumption. This paper describes the HISTEC methodology, presents an aircraft test bed description (including HISTEC-specific modifications) and verification and validation ground tests. Additionally, flight test safety considerations, test plan and technique design and approach, and flight operations are addressed. Some illustrative results are presented to demonstrate the type of analysis and results produced from the flight test program.

Orme, John S.↗
NASA NTRS2008

SDO FlatSat Facility

The goal of the Solar Dynamics Observatory (SDO) is to understand and, ideally, predict the solar variations that influence life and society. It's instruments will measure the properties of the Sun and will take hifh definition images of the Sun every few seconds, all day every day. The FlatSat is a high fidelity electrical and functional representation of the SDO spacecraft bus. It is a high fidelity test bed for Integration & Test (I & T), flight software, and flight operations. For I & T purposes FlatSat will be a driver to development and dry run electrical integration procedures, STOL test procedures, page displays, and the command and telemetry database. FlatSat will also serve as a platform for flight software acceptance and systems testing for the flight software system component including the spacecraft main processors, power supply electronics, attitude control electronic, gimbal control electrons and the S-band communications card. FlatSat will also benefit the flight operations team through post-launch flight software code and table update development and verification and verification of new and updated flight operations products. This document highlights the benefits of FlatSat; describes the building of FlatSat; provides FlatSat facility requirements, access roles and responsibilities; and, and discusses FlatSat mechanical and electrical integration and functional testing.

Amason, David L.↗
NASA NTRS2010

ISS and Shuttle Payload Research Development and Processing

NASA's ISS and Spacecraft Processing Directorate (UB) is charged with the performance of payload development for research originating through NASA, ISS international partners, and the National Laboratory. The Payload Development sector of the Directorate takes biological research approved for on orbit experimentation from its infancy stage and finds a way to integrate and implement that research into a payload on either a Shuttle sortie or Space Station increment. From solicitation and selection, to definition, to verification, to integration and finally to operations and analysis, Payload Development is there every step of the way. My specific work as an intern this summer has consisted of investigating data received by separate flight and ground control Advanced Biological Research Systems (ABRS) units for Advanced Plant Experiments (APEX) and Cambium research. By correlation and analysis of this data and specific logbook information I have been working to explain changes in environmental conditions on both the flight and ground control unit. I have then, compiled all of that information into a form that can be presentable to the Principal Investigator (PI). This compilation allows that PI scientist to support their findings and add merit to their research. It also allows us, as the Payload Developers, to further inspect the ABRS unit and its performance

Calhoun, Kyle A.↗
NASA NTRS2017

Human Reliability Assessments: Using the Past (Shuttle) to Predict the Future (ORION)

NASA uses two HRA assessment methodologies. The first is a simplified method which is based on how much time is available to complete the action, with consideration included for environmental and personal factors that could influence the human's reliability. This method is expected to provide a conservative value or placeholder as a preliminary estimate. This preliminary estimate is used to determine which placeholder needs a more detailed assessment. The second methodology is used to develop a more detailed human reliability assessment on the performance of critical human actions. This assessment needs to consider more than the time available, this would include factors such as: the importance of the action, the context, environmental factors, potential human stresses, previous experience, training, physical design interfaces, available procedures/checklists and internal human stresses. The more detailed assessment is still expected to be more realistic than that based primarily on time available. When performing an HRA on a system or process that has an operational history, we have information specific to the task based on this history and experience. In the case of a PRA model that is based on a new design and has no operational history, providing a "reasonable" assessment of potential crew actions becomes more problematic. In order to determine what is expected of future operational parameters, the experience from individuals who had relevant experience and were familiar with the system and process previously implemented by NASA was used to provide the "best" available data. Personnel from Flight Operations, Flight Directors, Launch Test Directors, Control Room Console Operators and Astronauts were all interviewed to provide a comprehensive picture of previous NASA operations. Verification of the assumptions and expectations expressed in the assessments will be needed when the procedures, flight rules and operational requirements are developed and then finalized.

DeMott, Diana L.↗
NASA NTRS2016

Human Reliability Assessments: Using the Past (Shuttle) to Predict the Future (Orion)

NASA (National Aeronautics and Space Administration) Johnson Space Center (JSC) Safety and Mission Assurance (S&MA) uses two human reliability analysis (HRA) methodologies. The first is a simplified method which is based on how much time is available to complete the action, with consideration included for environmental and personal factors that could influence the human's reliability. This method is expected to provide a conservative value or placeholder as a preliminary estimate. This preliminary estimate or screening value is used to determine which placeholder needs a more detailed assessment. The second methodology is used to develop a more detailed human reliability assessment on the performance of critical human actions. This assessment needs to consider more than the time available, this would include factors such as: the importance of the action, the context, environmental factors, potential human stresses, previous experience, training, physical design interfaces, available procedures/checklists and internal human stresses. The more detailed assessment is expected to be more realistic than that based primarily on time available. When performing an HRA on a system or process that has an operational history, we have information specific to the task based on this history and experience. In the case of a Probabilistic Risk Assessment (PRA) that is based on a new design and has no operational history, providing a "reasonable" assessment of potential crew actions becomes more challenging. In order to determine what is expected of future operational parameters, the experience from individuals who had relevant experience and were familiar with the system and process previously implemented by NASA was used to provide the "best" available data. Personnel from Flight Operations, Flight Directors, Launch Test Directors, Control Room Console Operators and Astronauts were all interviewed to provide a comprehensive picture of previous NASA operations. Verification of the assumptions and expectations expressed in the assessments will be needed when the procedures, flight rules and operational requirements are developed and then finalized.

DeMott, Diana↗