Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software testing”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Landsat-7 Simulation and Testing Environments

A spacecraft Attitude Control and Determination Subsystem (ACDS) is heavily dependent upon simulation throughout its entire development, implementation and ground test cycle. Engineering simulation tools are typically developed to design and analyze control systems to validate the design and software simulation tools are required to qualify the flight software. However, the need for simulation does not end here. Operating the ACDS of a spacecraft on the ground requires the simulation of spacecraft dynamics, disturbance modeling and celestial body motion. Sensor data must also be simulated and substituted for actual sensor data on the ground so that the spacecraft will respond by sending commands to the actuators as they will on orbit. And finally, the simulators is the primary training tool and test-bed for the Flight Operations Team. In this paper various ACDS simulation, developed for or used by the Landsat 7 project will be described. The paper will include a description of each tool, its unique attributes, and its role in the overall development and testing of the ACDS. Finally, a section is included which discusses how the coordinated use of these simulation tools can maximize the probability of uncovering software, hardware and operations errors during the ground test process.

Holmes, E.↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
NASA NTRS1993

Specialized data analysis for the Space Shuttle Main Engine and diagnostic evaluation of advanced propulsion system components

The Marshall Space Flight Center is responsible for the development and management of advanced launch vehicle propulsion systems, including the Space Shuttle Main Engine (SSME), which is presently operational, and the Space Transportation Main Engine (STME) under development. The SSME's provide high performance within stringent constraints on size, weight, and reliability. Based on operational experience, continuous design improvement is in progress to enhance system durability and reliability. Specialized data analysis and interpretation is required in support of SSME and advanced propulsion system diagnostic evaluations. Comprehensive evaluation of the dynamic measurements obtained from test and flight operations is necessary to provide timely assessment of the vibrational characteristics indicating the operational status of turbomachinery and other critical engine components. Efficient performance of this effort is critical due to the significant impact of dynamic evaluation results on ground test and launch schedules, and requires direct familiarity with SSME and derivative systems, test data acquisition, and diagnostic software. Detailed analysis and evaluation of dynamic measurements obtained during SSME and advanced system ground test and flight operations was performed including analytical/statistical assessment of component dynamic behavior, and the development and implementation of analytical/statistical models to efficiently define nominal component dynamic characteristics, detect anomalous behavior, and assess machinery operational condition. In addition, the SSME and J-2 data will be applied to develop vibroacoustic environments for advanced propulsion system components, as required. This study will provide timely assessment of engine component operational status, identify probable causes of malfunction, and indicate feasible engineering solutions. This contract will be performed through accomplishment of negotiated task orders.

Source record↗
NASA NTRS2017

Radiation Hardening by Software Techniques on FPGAs: Flight Experiment Evaluation and Results

We present our work on implementing Radiation Hardening by Software (RHBSW) techniques on the Xilinx Virtex5 FPGAs PowerPC 440 processors on the SpaceCube 2.0 platform. The techniques have been matured and tested through simulation modeling, fault emulation, laser fault injection and now in a flight experiment, as part of the Space Test Program- Houston 4-ISS SpaceCube Experiment 2.0 (STP-H4-ISE 2.0). This work leverages concepts such as heartbeat monitoring, control flow assertions, and checkpointing, commonly used in the High Performance Computing industry, and adapts them for use in remote sensing embedded systems. These techniques are extremely low overhead (typically <1.3%), enabling a 3.3x gain in processing performance as compared to the equivalent traditionally radiation hardened processor. The recently concluded STP-H4 flight experiment was an opportunity to upgrade the RHBSW techniques for the Virtex5 FPGA and demonstrate them on-board the ISS to achieve TRL 7. This work details the implementation of the RHBSW techniques, that were previously developed for the Virtex4-based SpaceCube 1.0 platform, on the Virtex5-based SpaceCube 2.0 flight platform. The evaluation spans the development and integration with flight software, remotely uploading the new experiment to the ISS SpaceCube 2.0 platform, and conducting the experiment continuously for 16 days before the platform was decommissioned. The experiment was conducted on two PowerPCs embedded within the Virtex5 FPGA devices and the experiment collected 19,400 checkpoints, processed 253,482 status messages, and incurred 0 faults. These results are highly encouraging and future work is looking into longer duration testing as part of the STP-H5 flight experiment.

Hybrid Flight Architectures↗
NASA NTRS2009

Implementation of an Adaptive Controller System from Concept to Flight Test

The National Aeronautics and Space Administration Dryden Flight Research Center (Edwards, California) is conducting ongoing flight research using adaptive controller algorithms. A highly modified McDonnell-Douglas NF-15B airplane called the F-15 Intelligent Flight Control System (IFCS) was used for these algorithms. This airplane has been modified by the addition of canards and by changing the flight control systems to interface a single-string research controller processor for neural network algorithms. Research goals included demonstration of revolutionary control approaches that can efficiently optimize aircraft performance for both normal and failure conditions, and to advance neural-network-based flight control technology for new aerospace systems designs. Before the NF-15B IFCS airplane was certified for flight test, however, certain processes needed to be completed. This paper presents an overview of these processes, including a description of the initial adaptive controller concepts followed by a discussion of modeling formulation and performance testing. Upon design finalization, the next steps are: integration with the system interfaces, verification of the software, validation of the hardware to the requirements, design of failure detection, development of safety limiters to minimize the effect of erroneous neural network commands, and creation of flight test control room displays to maximize human situational awareness.

Larson, Richard R.↗
NASA NTRS1987

Verifying shuttle onboard software using expert systems

The Space Shuttle uses a complex set of software to guide, navigate, and control it through all phases of flight. Adding to the complexity is the fact that the software is reconfigured for each flight, i.e., thousands of constants in the software are changed to reflect the unique properties of a given mission. In the last level of tests, the software is flown through end to end nominal and abort scenarios taking the shuttle from liftoff to landing. The analysis of the results of the testing is experience and labor intensive. A set of pass/fail criteria were defined for each test case and in parallel with the knowledge acquisition, tools were developed which allowed the automation of the knowledge being gathered on paper. A prototype of the Analysis Criteria Expert System (ACES) was put into production in the verification of the reconfigured onboard flight software.

Wingert, William B.↗
NASA NTRS1976

Flight experience with a digital integrated propulsion control system on an F-111E airplane

A digital integrated propulsion control system (IPCS) installed in the left side of an F-111 E aircraft was tested in flight. The F-111 aircraft was selected for the IPCS program because it incorporated a variable geometry inlet and an afterburning turbofan engine and had two engines, one of which could remain in the normal configuration to ensure flight safety. Flight data were compared with results of tests run in an altitude test chamber. The digital system was found to be capable of duplicating the standard engine and inlet control systems. Instabilities such as inlet buzz and afterburner rumble were detected and controlled. The usefulness of an altitude chamber for developing a software and testing hardware was proven. The flexibility of IPCS was demonstrated when an autothrottle, an in-flight thrust calculation, and a coannular noise study capability were added at the end of the flight tests.

Burcham, F. W., Jr.↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the validation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aerospace Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and ascent. The GLASS framework utilizes the off-the-shelf Mathworks (R) Simscape (TM) Multibody (TM) toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparison demonstrates that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check-cases and verify the GLASS core framework dynamics and the implementation of the check case scenario models.

6-Dof↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink (R)

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the vali-dation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aero-space Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and as-cent. The GLASS framework utilizes the off-the-shelf Mathworks ® Simscape Multibody® toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparisons demonstrate that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check cases and verifies the GLASS core framework dynamics and the correct implementation of the check case scenario models.

6-Dof↗
NASA NTRSDate not supplied

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗
NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗
NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for A Medical Data System for Exploration Missions

Minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions.In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗
NASA NTRS2009

Ares I-X: On the Threshold of Exploration

Ares I-X, the first flight of the Ares I crew launch vehicle, is less than a year from launch. Ares I-X will test the flight characteristics of Ares I from liftoff to first stage separation and recovery. The flight also will demonstrate the computer hardware and software (avionics) needed to control the vehicle; deploy the parachutes that allow the first stage booster to land in the ocean safely; measure and control how much the rocket rolls during flight; test and measure the effects of first stage separation; and develop and try out new ground handling and rocket stacking procedures in the Vehicle Assembly Building (VAB) and first stage recovery procedures at Kennedy Space Center (KSC) in Florida. All Ares I-X major elements have completed their critical design reviews, and are nearing final fabrication. The first stage--four-segment solid rocket booster from the Space Shuttle inventory--incorporates new simulated forward structures to match the Ares I five-segment booster. The upper stage, Orion crew module, and launch abort system will comprise simulator hardware that incorporates developmental flight instrumentation for essential data collection during the mission. The upper stage simulator consists of smaller cylindrical segments, which were transported to KSC in fall 2008. The crew module and launch abort system simulator were shipped in December 2008. The first stage hardware, active roll control system (RoCS), and avionics components will be delivered to KSC in 2009. This paper will provide detailed statuses of the Ares I-X hardware elements as NASA's Constellation Program prepares for this first flight of a new exploration era in the summer of 2009.

Davis, Stephan R.↗
NASA NTRS2014

Communications Technology Assessment for the Unmanned Aircraft System (UAS) Control and Non-Payload Communications (CNPC) Link

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) is performing communications systems research for the Unmanned Aircraft System (UAS) in the National Airspace System (NAS) Project. One of the goals of the communications element is to select and test a communications technology for the UAS Control and Non-Payload Communications (CNPC) link. The GRC UAS Modeling and Simulation (M/S) Sub Team will evaluate the performance of several potential technologies for the CNPC link through detailed software simulations. In parallel, an industry partner will implement a technology in hardware to be used for flight testing. The task necessitated a technical assessment of existing Radio Frequency (RF) communications technologies to identify the best candidate systems for use as the UAS CNPC link. The assessment provides a basis for selecting the technologies for the M/S effort and the hardware radio design. The process developed for the technical assessments for the Future Communications Study1 (FCS) was used as an initial starting point for this assessment. The FCS is a joint Federal Aviation Administration (FAA) and Eurocontrol study on technologies for use as a future aeronautical communications link. The FCS technology assessment process methodology can be applied to the UAS CNPC link; however the findings of the FCS are not directly applicable because of different requirements between a CNPC link and a general aeronautical data link. Additional technologies were added to the potential technologies list from the State of the Art Unmanned Aircraft System Communication Assessment developed by NASA GRC2. This document investigates the state of the art of communications as related to UAS. A portion of the document examines potential communications systems for a UAS communication architecture. Like the FCS, the state of the art assessment surveyed existing communications technologies. It did not, however, perform a detailed assessment of the technology necessary to recommend a technology for the UAS CNPC link. The technical assessment process, as shown in Figure 1, consists of the following steps. First, candidate RF communications technologies are identified. An initial review of each of these technologies is then performed to determine if the technology appears to be a good candidate and requires further review. Any technology that can be shown to be inadequate at that point is removed from consideration to allow for more detailed analysis of the remaining technologies. Criteria for the detailed assessments are defined and a scoring methodology is devised. This is followed by the detailed review and scoring of each technology. The least favorable technologies are removed during the process until only the few best candidates remain.

Aircraft Command and Control↗
NASA NTRS2000

Automation and Upgrade of Thermal System for Large 38-Year-Young Test Facility

The Goddard Space Flight Center's Space Environment Simulator (SES) facility has been improved by the upgrade of its thermal control hardware and software. This paper describes the preliminary design process, funding constraints, and the proposed enhancements as well as the installation details, the testing difficulties, and the overall benefits realized from this upgrade. The preliminary design process was discussed in a paper presented in October 1996 and will be recapped in this paper to provide background and comparison to actual product. Structuring the procurement process to match the funding constraints allowed Goddard to enhance its capabilities in an environment of reduced budgets. The installation of the new system into a location that has been occupied for over 38 years was one of the driving design factors for the size of the equipment. The installation was completed on time and under budget. The tuning of the automatic sequences for the new thermal system to the existing shroud system required more time and ultimately presented some setbacks to the vendor and the final completion of the system. However, the end product and its benefits to Goddard's thermal vacuum test portfolio will carry the usefulness of this facility well into the next century.

Webb, Andrew T.↗
NASA NTRS2000

Automation and Upgrade of Thermal System for Large 38-Year Young Test Facility

The Goddard Space Flight Center's Space Environment Simulator (SES) facility has been improved by the upgrade of its thermal control hardware and software. This paper describes the preliminary design process, funding constraints, and the proposed enhancements as well as the installation details, the testing difficulties, and the overall benefits realized from this upgrade. The preliminary design process was discussed in a paper presented in October 1996 and will be recapped in this paper to provide background and comparison to actual product. Structuring the procurement process to match the funding constraints allowed Goddard to enhance its capabilities in an environment of reduced budgets. The installation of the new system into a location that has been occupied for over 38-years was one of the driving design factors for the size of the equipment. The installation was completed on-time and under budget. The tuning of the automatic sequences for the new thermal system to the existing shroud system required more time and ultimately presented some setbacks to the vendor and the final completion of the system. However, the end product and its benefits to Goddard's thermal vacuum test portfolio will carry the usefulness of this facility well into the next century.

Webb, Andrew↗
NASA NTRS1975

Description and Flight Test Results of the NASA F-8 Digital Fly-by-Wire Control System

A NASA program to develop digital fly-by-wire (DFBW) technology for aircraft applications is discussed. Phase I of the program demonstrated the feasibility of using a digital fly-by-wire system for aircraft control through developing and flight testing a single channel system, which used Apollo hardware, in an F-8C airplane. The objective of Phase II of the program is to establish a technology base for designing practical DFBW systems. It will involve developing and flight testing a triplex digital fly-by-wire system using state-of-the-art airborne computers, system hardware, software, and redundancy concepts. The papers included in this report describe the Phase I system and its development and present results from the flight program. Man-rated flight software and the effects of lightning on digital flight control systems are also discussed.

Source record↗
NASA NTRS1976

Payload specialist station study. Volume 3: Program study cost estimates. Part 1: Work breakdown structure

The work breakdown structure (WBS) for the Payload Specialist Station (PSS) is presented. The WBS is divided into two elements--PSS contractor and mission unique requirements. In accordance with the study ground rules, it is assumed that a single contractor, hereafter referred to as PSS Contractor will perform the following: (1) provide C and D hardware (MFDS and elements of MMSE), except for GFE; (2) identify software requirements; (3) provide GSE and ground test software; and (4) perform systems engineering and integration in support of the Aft Flight Deck (AFD) C and D concept. The PSS Contractor WBS element encompasses a core or standardized PSS concept. Payload peculiar C and D requirements identified by users will originate as a part of the WBS element mission unique requirements; these requirements will be provided to the PSS Contractor for implementation.

Source record↗