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,027 records · Page 57

Simulation-To-Flight (STF-1): A Mission to Enable CubeSat Software-Based Validation and Verification

The Simulation-to-Flight 1 (STF-1) CubeSat mission aims to demonstrate how legacy simulation technologies may be adapted for flexible and effective use on missions using the CubeSat platform. These technologies, named NASA Operational Simulator (NOS), have demonstrated significant value on several missions such as James Webb Space Telescope, Global Precipitation Measurement, Juno, and Deep Space Climate Observatory in the areas of software development, mission operations/training, verification and validation (V&V), test procedure development and software systems check-out. STF-1 will demonstrate a highly portable simulation and test platform that allows seamless transition of mission development artifacts to flight products. This environment will decrease development time of future CubeSat missions by lessening the dependency on hardware resources. In addition, through a partnership between NASA GSFC, the West Virginia Space Grant Consortium and West Virginia University, the STF-1 CubeSat will hosts payloads for three secondary objectives that aim to advance engineering and physical-science research in the areas of navigation systems of small satellites, provide useful data for understanding magnetosphere-ionosphere coupling and space weather, and verify the performance and durability of III-V Nitride-based materials.

navigation↗

IPCS implications for future supersonic transport aircraft

The Integrated Propulsion Control System (IPCS) demonstrates control of an entire supersonic propulsion module - inlet, engine afterburner, and nozzle - with an HDC 601 digital computer. The program encompasses the design, build, qualification, and flight testing of control modes, software, and hardware. The flight test vehicle is an F-111E airplane. The L.H. inlet and engine will be operated under control of a digital computer mounted in the weapons bay. A general description and the current status of the IPCS program are given.

Billig, L. O.↗

Prototype software reuse environment at Goddard Space Flight Center

The Goddard Space Flight Center (GSFC) work is organized into four phases and includes participation by a contractor, CTA, Inc. The first phase was an automation study, which began with a comprehensive survey of software development automation technologies. Eight technical areas were analyzed for goals, current capabilities, and obstacles. The study documented current software development practice in GSFC Mission Operations and Data Systems Directorate, and presented short- and long-term recommendations that included focus on reuse and object-oriented development. The second phase, which has been completed, developed a prototype reuse environment with tools supporting object-oriented requirements analysis and design. This phase addressed the operational concept of software reuse, i.e., it attempted to understand how software can be reused. This environment has two semantic networks: object and keywords, and includes automated search, interactive browsing and a graphical display of database contents. Phase 3 was a domain analysis of Payload Operations Control Center (POCC) software. The goal in this phase was to create an initial repository of reusable components and techniques. Seven existing Operations Control Centers at GSFC were studied, but the domain analysis proved to be very slow. A lesson learned from this was that senior people who understand the environment and the functionality of the area are needed to perform successful domain analyses.

Truszkowski, Walt↗

The Package-Based Development Process in the Flight Dynamics Division

The Software Engineering Laboratory (SEL) has been operating for more than two decades in the Flight Dynamics Division (FDD) and has adapted to the constant movement of the software development environment. The SEL's Improvement Paradigm shows that process improvement is an iterative process. Understanding, Assessing and Packaging are the three steps that are followed in this cyclical paradigm. As the improvement process cycles back to the first step, after having packaged some experience, the level of understanding will be greater. In the past, products resulting from the packaging step have been large process documents, guidebooks, and training programs. As the technical world moves toward more modularized software, we have made a move toward more modularized software development process documentation, as such the products of the packaging step are becoming smaller and more frequent. In this manner, the QIP takes on a more spiral approach rather than a waterfall. This paper describes the state of the FDD in the area of software development processes, as revealed through the understanding and assessing activities conducted by the COTS study team. The insights presented include: (1) a characterization of a typical FDD Commercial Off the Shelf (COTS) intensive software development life-cycle process, (2) lessons learned through the COTS study interviews, and (3) a description of changes in the SEL due to the changing and accelerating nature of software development in the FDD.

Parra, Amalia↗

Obtaining the Greatest Scientific Benefit from Observational Platforms by Consideration of the Relative Benefit of Observations

One of the current trends in spacecraft software design is to increase the autonomy of onboard flight and science software. This is especially true when real-time observations may affect the observation schedule of a mission. For many science missions, such as those conducted by the Swift Burst Alert Telescope, the ability of the spacecraft to autonomously respond in real-time to unpredicted science events is crucial for mission success. We apply utility theory within resource management middleware to optimize the real-time performance of application software and achieve maximum system level benefit. We then explore how this methodology can be extended to manage both software and observational resources onboard a spacecraft to achieve the best possible observations.

Chelberg, David↗

Fault Detection and Diagnosis in Spacecraft Electrical Power Systems

The ability to accurately identify and isolate failures in the electrical power system (EPS) is critical to ensure the reliability of spacecraft. This paper proposes a novel solution to the problem of fault detection and diagnosis in direct current (DC) electric power systems for spacecraft. Autonomous operation becomes essential during deep space missions that lack the ability to monitor and control the spacecraft from ground locations. The current state of EPS fault supervision is insufficient to guarantee highly reliable operation. To solve this issue, a combination of model-based and knowledge-based techniques are used in a hierarchical framework to improve the diagnostic performance of the system. Noise, disturbances, and modeling errors are considered in the design of the fault detection system. Practical considerations related to spacecraft flight hardware and software are accounted for in the system design for flight applications. To assess the functionality of the design, a wide array of failures are simulated in a series of experiments. The experiments showed that the technique improved the capability of the autonomous system by increasing the number of fault types diagnosed. The significance of this study is to provide a framework capable of advanced diagnostics of an EPS with little to no interaction from human operators.

Autonomous Power Systems↗

Experimenting with an Evolving Ground/Space-based Software Architecture to Enable Sensor Webs

A series of ongoing experiments are being conducted at the NASA Goddard Space Flight Center to explore integrated ground and space-based software architectures enabling sensor webs. A sensor web, as defined by Steve Talabac at NASA Goddard Space Flight Center(GSFC), is a coherent set of distributed nodes interconnected by a communications fabric, that collectively behave as a single, dynamically adaptive, observing system. The nodes can be comprised of satellites, ground instruments, computing nodes etc. Sensor web capability requires autonomous management of constellation resources. This becomes progressively more important as more and more satellites share resource, such as communication channels and ground station,s while automatically coordinating their activities. There have been five ongoing activities which include an effort to standardize a set of middleware. This paper will describe one set of activities using the Earth Observing 1 satellite, which used a variety of ground and flight software along with other satellites and ground sensors to prototype a sensor web. This activity allowed us to explore where the difficulties that occur in the assembly of sensor webs given today s technology. We will present an overview of the software system architecture, some key experiments and lessons learned to facilitate better sensor webs in the future.

mandl, Daniel↗

NASA TSRV essential flight control system requirements via object oriented analysis

The objective was to analyze the baseline flight control system of the Transport Systems Research Vehicle (TSRV) and to develop a system specification that offers high visibility of the essential system requirements in order to facilitate the future development of alternate, more advanced software architectures. The flight control system is defined to be the baseline software for the TSRV research flight deck, including all navigation, guidance, and control functions, and primary pilot displays. The Object Oriented Analysis (OOA) methodology developed is used to develop a system requirement definition. The scope of the requirements definition contained herein is limited to a portion of the Flight Management/Flight Control computer functionality. The development of a partial system requirements definition is documented, and includes a discussion of the tasks required to increase the scope of the requirements definition and recommendations for follow-on research.

Duffy, Keith S.↗

NASA Langley Research Center's Simulation-To-Flight Concept Accomplished through the Integration Laboratories of the Transport Research Facility

The Flight Simulation and Software Branch (FSSB) at NASA Langley Research Center (LaRC) maintains the unique national asset identified as the Transport Research Facility (TRF). The TRF is a group of facilities and integration laboratories utilized to support the LaRC's simulation-to-flight concept. This concept incorporates common software, hardware, and processes for both groundbased flight simulators and LaRC s B-757-200 flying laboratory identified as the Airborne Research Integrated Experiments System (ARIES). These assets provide Government, industry, and academia with an efficient way to develop and test new technology concepts to enhance the capacity, safety, and operational needs of the ever-changing national airspace system. The integration of the TRF enables a smooth continuous flow of the research from simulation to actual flight test.

Martinez, Debbie↗

Low cost programmable multisimulator facility

A prototype, low cost multisimulator facility consisting of a DEC LSI-11 host computer and multiple desk top simulators is reported. The facility includes a main-frame system, a voice system, and a multi-cab system which consists of a flight panel, a host subsystem, and a flight simulator system. Software components are described, and the simulator computer, which provides flight dynamics, a path predictor, and navigation and data communications is discussed. The system may be computationally upgraded by specification of the DEC LSI-11/23, thus obtaining at least a two-fold increase in real-time computational power.

Kreifeldt, J. G.↗

Assessment of the State of the Art of Flight Control Technologies as Applicable to Adverse Conditions

Literature from academia, industry, and other Government agencies was surveyed to assess the state of the art in current Integrated Resilient Aircraft Control (IRAC) aircraft technologies. Over 100 papers from 25 conferences from the time period 2004 to 2009 were reviewed. An assessment of the general state of the art in adaptive flight control is summarized first, followed by an assessment of the state of the art as applicable to 13 identified adverse conditions. Specific areas addressed in the general assessment include flight control when compensating for damage or reduced performance, retrofit software upgrades to flight controllers, flight control through engine response, and finally test and validation of new adaptive controllers. The state-of-the-art assessment applicable to the adverse conditions include technologies not specifically related to flight control, but may serve as inputs to a future flight control algorithm. This study illustrates existing gaps and opportunities for additional research by the NASA IRAC Project

Reveley, Mary s.↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

The development and flight test of an electronic integrated propulsion control system

Advanced technical features of the electronic integrated propulsion control system (IPCS) and flight evaluation tests of IPCS (F-111E with TF30-P-9 engines as test vehicle) are described. Nine baseline flight tests and 15 IPCS flight tests were conducted. Instrumentation, data acquisition and data processing systems, software maintenance procedures, flight test procedures, flight safety criteria, flight test results, and ground and flight testing of the aircraft system are described. Advantages conferred by IPCS include: faster accelerations (both gas generator and afterburner performance), better thrust and flight control, reduced flight idle thrust, reduced engine ground trim, extended service ceiling, automatic stall detection, and stall recovery detection.

Johnson, H. J.↗

2nd Generation QUATARA Flight Computer Project

Single core flight computer boards have been designed, developed, and tested (DD&T) to be flown in small satellites for the last few years. In this project, a prototype flight computer will be designed as a distributed multi-core system containing four microprocessors running code in parallel. This flight computer will be capable of performing multiple computationally intensive tasks such as processing digital and/or analog data, controlling actuator systems, managing cameras, operating robotic manipulators and transmitting/receiving from/to a ground station. In addition, this flight computer will be designed to be fault tolerant by creating both a robust physical hardware connection and by using a software voting scheme to determine the processor's performance. This voting scheme will leverage on the work done for the Space Launch System (SLS) flight software. The prototype flight computer will be constructed with Commercial Off-The-Shelf (COTS) components which are estimated to survive for two years in a low-Earth orbit.

Falker, Jay↗

Evaluation of the Shuttle GN&C during powered ascent flight phase

An overview of the ascent trajectory and GN&C (guidance, navigation, and control) system design is followed by a summary of flight test results for the ascent phase of STS-1. The most notable variance from nominal pre-flight predictions was the lofted trajectory observed in first stage due to an unanticipated shift in pitch aerodynamic characteristics from those predicted by wind tunnel tests. The GN&C systems performed as expected on STS-1 throughout powered flight. Following a discussion of the software constants changed for Flight 2 to provide adequate performance margin, a summary of test results from STS-2 and STS-3 is presented. Vehicle trajectory response and GN&C system behavior were very similar to STS-1. Ascent aerodynamic characteristics extracted from the first two test flights were included in the data base used to design the first stage steering and pitch trim profiles for STS-3.

Olson, L.↗

A preliminary design for flight testing the FINDS algorithm

This report presents a preliminary design for flight testing the FINDS (Fault Inferring Nonlinear Detection System) algorithm on a target flight computer. The FINDS software was ported onto the target flight computer by reducing the code size by 65%. Several modifications were made to the computational algorithms resulting in a near real-time execution speed. Finally, a new failure detection strategy was developed resulting in a significant improvement in the detection time performance. In particular, low level MLS, IMU and IAS sensor failures are detected instantaneously with the new detection strategy, while accelerometer and the rate gyro failures are detected within the minimum time allowed by the information generated in the sensor residuals based on the point mass equations of motion. All of the results have been demonstrated by using five minutes of sensor flight data for the NASA ATOPS B-737 aircraft in a Microwave Landing System (MLS) environment.

Caglayan, A. K.↗

Results of software error-data experiments

In order to evaluate existing software reliability models and proposed modeling approaches, a search was conducted for data on the software failure process. This search revealed that the data necessary for this evaluation were not available. As a result, a research effort was initiated by NASA to generate data on which to base the development of credible methods for assessing the reliability of software targeted for flight-crucial applications. Two sets of software error-data experiments were conducted by different research groups. The results of the experiments were consistent: errors caused by different faults in a program occurred at widely varying rates; program failure rates exhibited a log-linear trend with respect to the number of faults corrected; some faults were found to interact in either concealing or revealing ways; and contiguous regions of the input space which cause a program to generate errors, called error crystals, were found and characterized for some faults. Collectively, these experiments have produced information on software failure which must be accounted for in software reliability modeling approaches.

Finelli, George B.↗