Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Flight Software”

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 1,045 records · Page 58

Support activities to maintain SUMS flight readiness, volume 9. Attachment C: Flight STS-40 report. Attachment D: SUMS software listing

The Shuttle Upper Atmosphere Mass Spectrometer (SUMS), a component experiment of the NASA Orbital Experiments Program (OEX), was flown aboard the shuttle Columbia (OV102) mounted at the forward end of the nose landing gear well with an atmospheric gas inlet system fitted to the lower fuselage (chin panel) surface. The SUMS was designed to provide atmospheric data in flow regimes inaccessible prior to the development of the Space Transportation System (STS). The experiment mission operation begins about 1 hour prior to shuttle de-orbit entry maneuver and continues until reaching 1.6 torr (about 86 km altitude). The SUMS flew a total of three missions, 61C, STS-35, STS-40. Between flights, the SUMS was maintained in flight ready status. The flight data has been analyzed by the NASA LaRC Aerothermodynamics Branch. Flight data spectrum plots and reports are presented in the Appendices to the Final Technical Report for NAS1-17399. This volume provides a software listing and graphical data gathered from flight STS-40.

Wright, Willie↗

The Dangers of Failure Masking in Fault-Tolerant Software: Aspects of a Recent In-Flight Upset Event

On 1 August 2005, a Boeing Company 777-200 aircraft, operating on an international passenger flight from Australia to Malaysia, was involved in a significant upset event while flying on autopilot. The Australian Transport Safety Bureau's investigation into the event discovered that an anomaly existed in the component software hierarchy that allowed inputs from a known faulty accelerometer to be processed by the air data inertial reference unit (ADIRU) and used by the primary flight computer, autopilot and other aircraft systems. This anomaly had existed in original ADIRU software, and had not been detected in the testing and certification process for the unit. This paper describes the software aspects of the incident in detail, and suggests possible implications concerning complex, safety-critical, fault-tolerant software.

Johnson, C. W.↗

Time Series Analysis in Flight Flutter Testing at the Air Force Flight Test Center: Concepts and Results

The Air Force Flight Test Center (AFFTC) flight flutter facility is described. Concepts of using a minicomputer-based time series analyzer and a modal analysis software package for flight flutter testing are examined. The results of several evaluations of the software package are given. The reasons for employing a minimum phase concept in analyzing response only signals are discussed. The use of a Laplace algorithm is shown to be effective for the modal analysis of time histories in flutter testing. Sample results from models and flight tests are provided. The limitations inherent in time series analysis methods are discussed, and the need for effective noise reduction techniques is noted. The use of digital time series analysis techniques in flutter testing is shown to be fast, accurate, and cost effective.

Lenz, R. W.↗

Integration Test and Evaluation (IT&E) Flight Test Series 6 Live Virtual Constructive - Distributed Environment (LVC-DE) Test Report

The goals of the Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) (also UAS-NAS) Project are to reduce the barriers for UAS access and its integration into the NAS. The UAS-NAS project and industry stakeholders conducted a series of flight tests integrating technologies from the Modeling & Simulation (M&S), Human Systems Integration (HSI), and Communication and Control (C2), and Integration, Test & Evaluation (IT&E) research areas. The last of the flight test series, Flight Test Series 6 (FT6) was conducted in late 2019 and focused on evaluating the interaction of the airborne non-cooperative surveillance system and the Detect and Avoid (DAA) technology. The DAA system generated conflict alert and guidance for pilots using a Research Ground Control System (RGCS) to avoid intruder aircraft. The conflict alerting and guidance information was presented on the RGCS’s display using symbology developed by the human factors team. The objective of FT6 was to investigate the interoperability of Low Size, Weight, and Power (Low SWaP) sensors with the DAA alerting, guidance, and display requirements. To support this goal, the distributed test environments (DTE) were developed at Ames Research Center (ARC) and Armstrong Flight Research Center (AFRC) and securely linked over a Virtual Private Network (VPN). These environments took advantage of existing Live Virtual Constructive (LVC) technologies to support research observation at both Centers with the insertion of live UAS and manned intruder aircraft into a simulated NAS environment with Air Traffic Control (ATC) and constructive manned aircraft. The experiment was distributed between AFRC flight operations and research facilities and the Distributed Simulation Research Laboratory (DSRL) and Software Development Laboratory (SDL) in building N243 at ARC. The Air Traffic Controller and pseudo pilots operated from the DSRL and SDL, respectively, using the Multi-Aircraft Control System (MACS). The test subject and researchers operated from the Research Ground Control Station (RGCS) at AFRC using the Vigilant Spirit Control Station (VSCS) and associated DAA software and displays. Flight Operation for the unmanned aircraft (UA) and manned intruder traffic was conducted at AFRC. Virtual traffic was managed by ARC. Voice distribution was accomplished using a combination of disparate communication systems at ARC and AFRC. The purpose of this document is to record the development, design, and execution of activities in support of the FT6 efforts from the perspective of the ARC IT&E team. Furthermore, the Armstrong IT&E team has published a thorough FT6 Test Report, with emphasis on flight test support, facilities and vehicle development; this report complements the Armstrong report. Analysis of collected FT6 data will be conducted and reported by the M&S and HSI teams and will be published in separate reports.

UAS-NAS↗

Medical Data Architecture (MDA) Project Status

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. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. 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 supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

Advanced Software Techniques for Data Management Systems. Volume 2: Space Shuttle Flight Executive System: Functional Design

A functional design of software executive system for the space shuttle avionics computer is presented. Three primary functions of the executive are emphasized in the design: task management, I/O management, and configuration management. The executive system organization is based on the applications software and configuration requirements established during the Phase B definition of the Space Shuttle program. Although the primary features of the executive system architecture were derived from Phase B requirements, it was specified for implementation with the IBM 4 Pi EP aerospace computer and is expected to be incorporated into a breadboard data management computer system at NASA Manned Spacecraft Center's Information system division. The executive system was structured for internal operation on the IBM 4 Pi EP system with its external configuration and applications software assumed to the characteristic of the centralized quad-redundant avionics systems defined in Phase B.

Pepe, J. T.↗

Software Management Environment (SME) concepts and architecture, revision 1

This document presents the concepts and architecture of the Software Management Environment (SME), developed for the Software Engineering Branch of the Flight Dynamic Division (FDD) of GSFC. The SME provides an integrated set of experience-based management tools that can assist software development managers in managing and planning flight dynamics software development projects. This document provides a high-level description of the types of information required to implement such an automated management tool.

Hendrick, Robert↗

A Low Cost Simulation System to Demonstrate Pilot Induced Oscillation Phenomenon

A flight simulation system with graphics and software on Silicon Graphics computer workstations has been installed in the Flight Vehicle Design Laboratory at Tuskegee University. The system has F-15E flight simulation software from NASA Dryden which uses the graphics of SGI flight simulation demos. On the system, thus installed, a study of pilot induced oscillations is planned for future work. Preliminary research is conducted by obtaining two sets of straight level flights with pilot in the loop. In one set of flights no additional delay is used between the stick input and the appearance of airplane response on the computer monitor. In another set of flights, a 500 ms additional delay is used. The flight data is analyzed to find cross correlations between deflections of control surfaces and response of the airplane. The pilot dynamics features depicted from cross correlations of straight level flights are discussed in this report. The correlations presented here will serve as reference material for the corresponding correlations in a future study of pitch attitude tracking tasks involving pilot induced oscillations.

Ali, Syed Firasat↗

Streamlining GNC Architecture Development and FSW Integration forthe Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface ofanother atmospheric planetary body outside of the Earth-Moon system. Significant light-time delayrequires complete autonomy of flight throughout ascent, and naturally a high level of reliability isdesired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls(GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiencyof algorithm integration onto the MAV flight processor, and to increase confidence that said integrationis successful and without human error. An interface architecture is proposed for the GNC suite thatallows both the guidance and navigation subsystems to provide code algorithms directly in C++, and thecontrols subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code fromthe GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendlywrapper which abstracts the integration of the GNC algorithm code into an interface-level API that iscompatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSWteam’s partnership, and this strong interface between these two teams have allowed the GNC/FSWteams to greatly increase confidence of efficient and error-free implementation of the GNC code ontoMAV for a successful flight.

GNC↗

Knowledge based and interactive control for the Superfluid Helium On-orbit Transfer Project

NASA's Superfluid Helium On-Orbit Transfer (SHOOT) project is a Shuttle-based experiment designed to acquire data on the properties of superfluid helium in micro-gravity. Aft Flight Deck Computer Software for the SHOOT experiment is comprised of several monitoring programs which give the astronaut crew visibility into SHOOT systems and a rule based system which will provide process control, diagnosis and error recovery for a helium transfer without ground intervention. Given present Shuttle manifests, this software will become the first expert system to be used in space. The SHOOT Command and Monitoring System (CMS) software will provide a near real time highly interactive interface for the SHOOT principal investigator to control the experiment and to analyze and display its telemetry. The CMS software is targeted for all phases of the SHOOT project: hardware development, pre-flight pad servicing, in-flight operations, and post-flight data analysis.

Castellano, Timothy P.↗

Data systems and computer science programs: Overview

An external review of the Integrated Technology Plan for the Civil Space Program is presented. The topics are presented in viewgraph form and include the following: onboard memory and storage technology; advanced flight computers; special purpose flight processors; onboard networking and testbeds; information archive, access, and retrieval; visualization; neural networks; software engineering; and flight control and operations.

Smith, Paul H.↗

Efficient Low-Speed Flight in a Wind Field

A new software tool was needed for flight planning of a high altitude, low speed unmanned aerial vehicle which would be flying in winds close to the actual airspeed of the vehicle. An energy modeled NLP (non-linear programming) formulation was used to obtain results for a variety of missions and wind profiles. The energy constraint derived included terms due to the wind field and the performance index was a weighted combination of the amount of fuel used and the final time. With no emphasis on time and with no winds the vehicle was found to fly at maximum lift to drag velocity, V(sub md). When flying in tail winds the velocity was less than V(sub md), while flying in head winds the velocity was higher than V(sub md). A family of solutions was found with varying times of flight and varying fuel amounts consumed which will aid the operator in choosing a flight plan depending on a desired landing time. At certain parts of the flight, the turning terms in the energy constraint equation were found to be significant. An analysis of a simpler vertical plane cruise optimal control problem was used to explain some of the characteristics of the vertical plane NLP results.

Feldman, Michael A.↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

A representational basis for the development of a distributed expert system for Space Shuttle flight control

A new representation of malfunction procedure logic which permits the automation of these procedures using Boolean normal forms is presented. This representation is discussed in the context of the development of an expert system for space shuttle flight control including software and hardware implementation modes, and a distributed architecture. The roles and responsibility of the flight control team as well as previous work toward the development of expert systems for flight control support at Johnson Space Center are discussed. The notion of malfunction procedures as graphs is introduced as well as the concept of hardware-equivalence.

Helly, J. J., Jr.↗

Streamlining GNC Architecture Development and FSW Integration for the Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface of another atmospheric planetary body outside of the Earth-Moon system. Significant light-time delay requires complete autonomy of flight throughout ascent, and naturally a high level of reliability is desired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls (GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiency of algorithm integration onto the MAV flight processor, and to increase confidence that said integration is successful and without human error. An interface architecture is proposed for the GNC suite that allows both the guidance and navigation subsystems to provide code algorithms directly in C++, and the controls subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code from the GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendly wrapper which abstracts the integration of the GNC algorithm code into an interface-level API that is compatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSW team’s partnership, and this strong interface between these two teams have allowed the GNC/FSW teams to greatly increase confidence of efficient and error-free implementation of the GNC code onto MAV for a successful flight.

Engineering↗

Point-Mass Aircraft Trajectory Prediction Using a Hierarchical, Highly-Adaptable Software Design

A highly adaptable and extensible method for predicting four-dimensional trajectories of civil aircraft has been developed. This method, Behavior-Based Trajectory Prediction, is based on taxonomic concepts developed for the description and comparison of trajectory prediction software. A hierarchical approach to the "behavioral" layer of a point-mass model of aircraft flight, a clear separation between the "behavioral" and "mathematical" layers of the model, and an abstraction of the methods of integrating differential equations in the "mathematical" layer have been demonstrated to support aircraft models of different types (in particular, turbojet vs. turboprop aircraft) using performance models at different levels of detail and in different formats, and promise to be easily extensible to other aircraft types and sources of data. The resulting trajectories predict location, altitude, lateral and vertical speeds, and fuel consumption along the flight path of the subject aircraft accurately and quickly, accounting for local conditions of wind and outside air temperature. The Behavior-Based Trajectory Prediction concept was implemented in NASA's Traffic Aware Planner (TAP) flight-optimizing cockpit software application.

Karr, David A.↗

Onboard rendezvous navigation for the Space Shuttle

The onboard rendezvous navigation software for Shuttle flight 41-C are described. Particular attention is given to the inputs, models, and outputs of the software. The performance of the rendezvous navigation system is compared to predicted performance profiles in connection with the relative vehicle geometry, as well as the location of the navigation sensor tracking arcs. The methods used to process navigational sensor measurements in order to update the state vector are also summarized. A table listing the sources of maneuver targeting errors is provided.

Wylie, A. D.↗

Guidance, Navigation, and Control Program

The Rendezvous and Proximity Operations Program (RPOP) is real-time guidance, navigation, and control (GN&C) domain piloting-aid software that provides 3D Orbiter graphics and runs on the Space Shuttle's Criticality-3 Payload and General Support Computer (PGSC) in the crew cockpit. This software provides the crew with Situational Awareness during the rendezvous and proximity operations phases of flight. RPOP can be configured from flight to flight, accounting for mission-specific flight scenarios and target vehicles, via initialization load (I-load) data files. The software provides real-time, automated, closed-loop guidance recommendations and the capability to integrate the crew s manual backup techniques. The software can bring all relative navigation sensor data, including the Orbiter's GPC (general purpose computer) data, into one central application to provide comprehensive situational awareness of the rendezvous and proximity operations trajectory. RPOP also can separately maintain trajectory estimates (past, current, and predicted) based on certain data types and co-plot them, in order to show how the various navigation solutions compare. RPOP s best estimate of the relative trajectory is determined by a relative Kalman filter processing data provided by the sensor suite s most accurate sensor, the trajectory control sensor (TCS). Integrated with the Kalman filter is an algorithm that identifies the reflector that the TCS is tracking. Because RPOP runs on PC laptop computers, the development and certification lifecycles are more agile, flexible, and cheaper than those that govern the Orbiter FSW (flight software) that runs in the GPC. New releases of RPOP can be turned around on a 3- to 6-month template, from new Change Request (CR) to certification, depending on the complexity of the changes.

Hinkel, Heather↗