Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software design”

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 127 records · Page 7

Planning Orbiter Flights

Shuttle Mission Design and Operations Software (SMDOS) assists in design and operation of missions involving spacecraft in low orbits around Earth by providing orbital and graphics information. SMDOS performs following five functions: display two world and two polar maps or any user-defined window 5 degrees high in latitude by 5 degrees wide in longitude in one of eight standard projections; designate Earth sites by points or polygon shapes; plot spacecraft ground track with 1-min demarcation lines; display, by means of different colors, availability of Tracking and Data Relay Satellite to Shuttle; and calculate available times and orbits to view particular site, and corresponding look angles. SMDOS written in Laboratory Micro-systems FORTH (1979 standard)

Harris, H. M.↗

Constellation Program DOLILU Operational Concepts

Day of launch I-load uplink (DOLILU) and a corresponding day of launch trajectory and loads evaluation are being considered for the Constellation Program. Abort effectiveness, controllability, and ascent structural loads all improve with some of the flight software I-loads designed using current measured atmospheric conditions. While a generalized DOLILU framework has been assumed, specific implementation details have not yet been discussed in depth nor documented. Operational improvements can be leveraged from Space Shuttle experience to create a more cost-effective and streamlined process while maintaining the integrity of the results. A preliminary discussion of DOLILU design methodology is presented followed by some suggestions and implementation details for Constellation Program DOLILU operations

Puperi, Daniel S.↗

Orion Backup Flight Software

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

Orion↗

Orion Backup Flight Software (BFS)

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

CFS↗

Computer Software Configuration Item-Specific Flight Software Image Transfer Script Generator

A K-shell UNIX script enables the International Space Station (ISS) Flight Control Team (FCT) operators in NASA s Mission Control Center (MCC) in Houston to transfer an entire or partial computer software configuration item (CSCI) from a flight software compact disk (CD) to the onboard Portable Computer System (PCS). The tool is designed to read the content stored on a flight software CD and generate individual CSCI transfer scripts that are capable of transferring the flight software content in a given subdirectory on the CD to the scratch directory on the PCS. The flight control team can then transfer the flight software from the PCS scratch directory to the Electronically Erasable Programmable Read Only Memory (EEPROM) of an ISS Multiplexer/ Demultiplexer (MDM) via the Indirect File Transfer capability. The individual CSCI scripts and the CSCI Specific Flight Software Image Transfer Script Generator (CFITSG), when executed a second time, will remove all components from their original execution. The tool will identify errors in the transfer process and create logs of the transferred software for the purposes of configuration management.

Bolen, Kenny↗

Design and operational features of the Ultraviolet Imaging Telescope flight and ground software

The NASA Office of Space Sciences and Applications is sponsoring a series of Space Shuttle missions named Astro-n which are dedicated to a variety of astronomical projects. These missions will be the first in which the Space Shuttle crew will be interactively operating an astronomical observatory which is fixed in the payload bay. The operation of an instrument in such an environment requires a considerable amount of software both on board and on the ground. The Spacelab Experiment Computer provides generalized interactive telemetry display and command processing services through the Experiment Computer Operating System. The experimenter must then design a software package for his Dedicated Experiment Processor which can provide complete control of his instrument as well as communicate with the Experiment Computer. This paper describes the design considerations and operational features of the Ultraviolet Imaging Telescope Dedicated Experiment Processor and Instrument Ground Support Equipment software.

Parise, R. A.↗

NASA Tech Briefs, January 2014

Topics include: Multi-Source Autonomous Response for Targeting and Monitoring of Volcanic Activity; Software Suite to Support In-Flight Characterization of Remote Sensing Systems; Visual Image Sensor Organ Replacement; Ultra-Wideband, Dual-Polarized, Beam-Steering P-Band Array Antenna; Centering a DDR Strobe in the Middle of a Data Packet; Using a Commercial Ethernet PHY Device in a Radiation Environment; Submerged AUV Charging Station; Habitat Demonstration Unit (HDU) Vertical Cylinder Habitat; Origami-Inspired Folding of Thick, Rigid Panels; A Novel Protocol for Decoating and Permeabilizing Bacterial Spores for Epifluorescent Microscopy; Method and Apparatus for Automated Isolation of Nucleic Acids from Small Cell Samples; Enabling Microliquid Chromatography by Microbead Packing of Microchannels; On-Command Force and Torque Impeding Devices (OC-FTID) Using ERF; Deployable Fresnel Rings; Transition-Edge Hot-Electron Microbolometers for Millimeter and Submillimeter Astrophysics; Spacecraft Trajectory Analysis and Mission Planning Simulation (STAMPS) Software; Cross Support Transfer Service (CSTS) Framework Library; Arbitrary Shape Deformation in CFD Design; Range Safety Flight Elevation Limit Calculation Software; Frequency-Modulated, Continuous-Wave Laser Ranging Using Photon-Counting Detectors; Calculation of Operations Efficiency Factors for Mars Surface Missions; GPU Lossless Hyperspectral Data Compression System; Robust, Optimal Subsonic Airfoil Shapes; Protograph-Based Raptor-Like Codes; Fuzzy Neuron: Method and Hardware Realization; Kalman Filter Input Processor for Boresight Calibration; Organizing Compression of Hyperspectral Imagery to Allow Efficient Parallel Decompression; and Temperature Dependences of Mechanisms Responsible for the Water-Vapor Continuum Absorption.

Source record↗

Plume Impingement Software Module for Real-Time Proximity Operations

Successfully executing proximity operations in space, such as docking or in-orbit servicing, requires sophisticated spacecraft design that accounts for induced environments. As a chaser vehicle’s attitude control thrusters fire, they create rarefied plumes that can impact the target vehicle, with the potential to overload components, exceed thermal limits, and spin the target vehicle out of control. High-fidelity simulations of the thruster plume impingement environment require the direct simulation Monte Carlo (DSMC) method, but DSMC is too computationally expensive to simulate proximity operations that involve thousands of thruster firings. For this analysis to be tractable, engineering models of the plume flowfield and impingement events are used to simulate these trajectories [1]. Currently, on-orbit plume impingement environments are modeled through an inefficient open-loop analysis cycle where the vehicle’s flight controller and plume impingement teams iterate on the trajectories until they pass the target vehicle’s plume requirements. As complex on-orbit missions evolve and become more frequent, lengthy design cycles will become operational bottlenecks. To address this gap, this work develops an advanced plume impingement module capable of operating at real-time scale that can be integrated with existing mission planning tools and onboard flight systems. The plume module leverages state-of-the-art plume simulation techniques [2] to deliver fast, physics-based impingement predictions in a software architecture that can be tailored to diverse proximity operations scenarios. A prototype of this plume impingement module is built to demonstrate the feasibility of real-time performance. This prototype completes plume impingement calculations in microseconds per target geometry mesh point. The software serves as a foundational capability for plume-aware trajectory design, operational risk assessment, and future autonomous decision-making systems.

Plume Impingement↗

The development of a multi-target compiler-writing system for flight software development

A wide variety of systems designed to assist the user in the task of writing compilers has been developed. A survey of these systems reveals that none is entirely appropriate to the purposes of the MUST project, which involves the compilation of one or at most a small set of higher-order languages to a wide variety of target machines offering little or no software support. This requirement dictates that any compiler writing system employed must provide maximal support in the areas of semantics specification and code generation, the areas in which existing compiler writing systems as well as theoretical underpinnings are weakest. This paper describes an ongoing research and development effort to create a compiler writing system which will overcome these difficulties, thus providing a software system which makes possible the fast, trouble-free creation of reliable compilers for a wide variety of target computers.

Feyock, S.↗

Orbital flight simulation utility software unit specifications, revision 1

The HP PASCAL source code defines the specifications for a Utility Software Unit (USU) designed to support orbital flight simulators such as MANHANDLE and GREAS (General Research and Engineering Analysis Simulator). Besides providing basic input/output, mathematical, matrix, quaternion, and statistical routines for such simulators, one of the primary functions of the USU is to isolate all system-dependent codes in one well-defined compartment, thereby facilitating transportation of the simulations from one computer to another. Directives are given for the PASCAL compilers of the HP-9000 Series 200 Pascal 3.0 and the HP-9000 Series 500 HP-UX 5.0 operating systems that produce a single file of relocatable code from four separate files of source code. Three of the source code files are common to both operating systems. The fourth source code file (utilspif.I) contains all of the system-dependent PASCAL code for the USU. A fifth file of source code written in C is required to interface utilspif.I with the HP-UX I/O package. The Pascal 3.0 compiler directives and the driver source code for a unit rest program and counterparts for the HP-UX 5.0 operating system are given. The major portion of the unit test program source code is common to both operating systems. Unit test results from the Pascal 3.0 operating system and results from the HP-UX operating system are given.

Wilson, S. W.↗

Design and Analysis of Morpheus Lander Flight Control System

The Morpheus Lander is a vertical takeoff and landing test bed vehicle developed to demonstrate the system performance of the Guidance, Navigation and Control (GN&C) system capability for the integrated autonomous landing and hazard avoidance system hardware and software. The Morpheus flight control system design must be robust to various mission profiles. This paper presents a design methodology for employing numerical optimization to develop the Morpheus flight control system. The design objectives include attitude tracking accuracy and robust stability with respect to rigid body dynamics and propellant slosh. Under the assumption that the Morpheus time-varying dynamics and control system can be frozen over a short period of time, the flight controllers are designed to stabilize all selected frozen-time control systems in the presence of parametric uncertainty. Both control gains in the inner attitude control loop and guidance gains in the outer position control loop are designed to maximize the vehicle performance while ensuring robustness. The flight control system designs provided herein have been demonstrated to provide stable control systems in both Draper Ares Stability Analysis Tool (ASAT) and the NASA/JSC Trick-based Morpheus time domain simulation.

Jang, Jiann-Woei↗

Flight Test of an Adaptive Controller and Simulated Failure/Damage on the NASA NF-15B

The method of flight-testing the Intelligent Flight Control System (IFCS) Second Generation (Gen-2) project on the NASA NF-15B is herein described. The Gen-2 project objective includes flight-testing a dynamic inversion controller augmented by a direct adaptive neural network to demonstrate performance improvements in the presence of simulated failure/damage. The Gen-2 objectives as implemented on the NASA NF-15B created challenges for software design, structural loading limitations, and flight test operations. Simulated failure/damage is introduced by modifying control surface commands, therefore requiring structural loads measurements. Flight-testing began with the validation of a structural loads model. Flight-testing of the Gen-2 controller continued, using test maneuvers designed in a sequenced approach. Success would clear the new controller with respect to dynamic response, simulated failure/damage, and with adaptation on and off. A handling qualities evaluation was conducted on the capability of the Gen-2 controller to restore aircraft response in the presence of a simulated failure/damage. Control room monitoring of loads sensors, flight dynamics, and controller adaptation, in addition to postflight data comparison to the simulation, ensured a safe methodology of buildup testing. Flight-testing continued without major incident to accomplish the project objectives, successfully uncovering strengths and weaknesses of the Gen-2 control approach in flight.

Buschbacher, Mark↗

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↗

Incorporating Manual and Autonomous Code Generation

Code can be generated manually or using code-generated software tools, but how do you interpret the two? This article looks at a design methodology that combines object-oriented design with autonomic code generation for attitude control flight software. Recent improvements in space flight computers are allowing software engineers to spend more time engineering the applications software. The application developed was the attitude control flight software for an astronomical satellite called the Microwave Anisotropy Probe (MAP). The MAP flight system is being designed, developed, and integrated at NASA's Goddard Space Flight Center. The MAP controls engineers are using Integrated Systems Inc.'s MATRIXx for their controls analysis. In addition to providing a graphical analysis for an environment, MATRIXx includes an autonomic code generation facility called AutoCode. This article examines the forces that shaped the final design and describes three highlights of the design process: (1) Defining the manual to autonomic code interface; (2) Applying object-oriented design to the manual flight code; (3) Implementing the object-oriented design in C.

McComas, David↗

LADEE Multi-Domain Simulation

The Lunar Atmosphere Dust Environment Explorer (LADEE) was a small explorer class spacecraft that was launched on Sept 7, 2013 and that was de-orbited and successfully impacted the Moons surface on April 17, 2014 after completing all of the mission objectives. The low-cost rapidly prototyped hardware design used for the spacecraft was extend to the development of the software base. To achieve this goal, a Model Based Design approach was utilized to develop the onboard flight software, and out of this development a model based multipurpose simulator was created of the LADEE spacecraft and its mission environment. This simulator extended the traditional function of propagating the vehicle's kinematic and rotational states and included the electrical and thermal states propagation. Traditionally, these domains are handled by domain specific high fidelity simulations that use the states histories from other domains as input. By reducing the fidelity and abstracting the relevant features being monitored and controlled by the flight software, it was possible to model the coupling across these domains resulting in more accurate overall system behavior. A faster than real-time workstation (WSIM) version of the LADEE simulator was used to develop and test the software control algorithms in the Simulink environment. To maximize the performance of the simulation, modeling knobs were introduced to reduce the resolution of the some of the domains models when the effects of that domain were not significant for the scope of that simulation. The automatic code generation feature in Simulink was used to port the simulation to several real-time environments to support Processor-in-the-Loop (PIL) and Hardware-in-the-Loop (HIL) testing, verification and validation. The real-time environment required that the design of each of the domain models be deterministic as possible in the time required to perform all of the calculations to update its states. The simulation interface was designed to be compatible with the command interface employed by the LADEE mission operation team. The WSIM, PIL, and HIL simulators thus used a common interface and thus were used for flight software testing, for mission operations personnel training (nominal and off-nominal operations) prior to the mission and to perform command sequence verification during the mission. This presentation will look at the modeling strategies used to create a common interface to the simulator and to model and couple multiple domains within the simulation, the results of those strategies, and the lessons learned.

Multi-Domain↗

Flight test trajectory control analysis

Recent extensions to optimal control theory applied to meaningful linear models with sufficiently flexible software tools provide powerful techniques for designing flight test trajectory controllers (FTTCs). This report describes the principal steps for systematic development of flight trajectory controllers, which can be summarized as planning, modeling, designing, and validating a trajectory controller. The techniques have been kept as general as possible and should apply to a wide range of problems where quantities must be computed and displayed to a pilot to improve pilot effectiveness and to reduce workload and fatigue. To illustrate the approach, a detailed trajectory guidance law is developed and demonstrated for the F-15 aircraft flying the zoom-and-pushover maneuver.

Walker, R.↗

ATM Technology Demonstration-1 Phase II Boeing Configurable Graphical Display (CGD) Software Design Description

This Software Description Document (SDD) captures the design for developing the Flight Interval Management (FIM) system Configurable Graphics Display (CGD) software. Specifically this SDD describes aspects of the Boeing CGD software and the surrounding context and interfaces. It does not describe the Honeywell components of the CGD system. The SDD provides the system overview, architectural design, and detailed design with all the necessary information to implement the Boeing components of the CGD software and integrate them into the CGD subsystem within the larger FIM system. Overall system and CGD system-level requirements are derived from the CGD SRS (in turn derived from the Boeing System Requirements Design Document (SRDD)). Display and look-and-feel requirements are derived from Human Machine Interface (HMI) design documents and working group recommendations. This Boeing CGD SDD is required to support the upcoming Critical Design Review (CDR).

Wilber, George F.↗