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.

SourceResearch connectionFrom yearThrough year

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

At least 1,657 records · Page 92

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Software Management System

A software management system, originally developed for Goddard Space Flight Center (GSFC) by Century Computing, Inc. has evolved from a menu and command oriented system to a state-of-the art user interface development system supporting high resolution graphics workstations. Transportable Applications Environment (TAE) was initially distributed through COSMIC and backed by a TAE support office at GSFC. In 1993, Century Computing assumed the support and distribution functions and began marketing TAE Plus, the system's latest version. The software is easy to use and does not require programming experience.

Source record↗

NASA NTRS1981

A Loran-C prototype navigation receiver for general aviation

Prototype equipment was developed for flight evaluation which provides enroute navigation in both latitude-longitude and rho-theta coordinates. The nonprecision approach capabilities of this equipment was evaluated. The antenna/preamplifier coupler, the RF processor, tracking loop hardware, tracking loop software, and the video output are discussed. Laboratory and flight test results are evaluated.

Lilley, R. W.↗

NASA NTRS1983

Digital Instrumentation Analysis and Navigation System (DIANS) for system identification

Hardware, software, and performance features of the Digital Instrumentation and Navigation System (DIANS) designed for NASA research to collect flight data as a strap-down system are detailed. The support software for the system has a cross compiler, a linkage editor, and cross assembler, extended communication capabilities, postflight processing applications, and compilers for PASCAL, FORTRAN, CBASIC and MT. The DIANS microcomputer has a 1 Mbyte RAM module, a fast floating point processor board, a 68000 monoboard computer with 64 RAM, a 128 Kbyte bubble memory card, and a navigation radio. The system also carries a battery for full system operation for over an hour. The support software is also stored on a host mainframe computer, which has a CP/M operating system. Pitch, roll, and heading data are gathered from the on-board system, and communication is possible between the airborne and ground-based computer.

Smyth, R. K.↗

NASA NTRS1994

High performance real-time flight simulation at NASA Langley

In order to meet the stringent time-critical requirements for real-time man-in-the-loop flight simulation, computer processing operations must be deterministic and be completed in as short a time as possible. This includes simulation mathematical model computational and data input/output to the simulators. In 1986, in response to increased demands for flight simulation performance, personnel at NASA's Langley Research Center (LaRC), working with the contractor, developed extensions to a standard input/output system to provide for high bandwidth, low latency data acquisition and distribution. The Computer Automated Measurement and Control technology (IEEE standard 595) was extended to meet the performance requirements for real-time simulation. This technology extension increased the effective bandwidth by a factor of ten and increased the performance of modules necessary for simulator communications. This technology is being used by more than 80 leading technological developers in the United States, Canada, and Europe. Included among the commercial applications of this technology are nuclear process control, power grid analysis, process monitoring, real-time simulation, and radar data acquisition. Personnel at LaRC have completed the development of the use of supercomputers for simulation mathematical model computational to support real-time flight simulation. This includes the development of a real-time operating system and the development of specialized software and hardware for the CAMAC simulator network. This work, coupled with the use of an open systems software architecture, has advanced the state of the art in real time flight simulation. The data acquisition technology innovation and experience with recent developments in this technology are described.

Cleveland, Jeff I., II↗

NASA NTRS2005

Trusted Autonomy for Space Flight Systems

NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.

Freed, Michael↗

NASA NTRS1984

Software modifications to the Demonstration Advanced Avionics Systems (DAAS)

Critical information required for the design of integrated avionics suitable for generation aviation is applied towards software modifications for the Demonstration Advanced Avionics System (DAAS). The program emphasizes the use of data busing, distributed microprocessors, shared electronic displays and data entry devices, and improved functional capability. A demonstration advanced avionics system (DAAS) is designed, built, and flight tested in a Cessna 402, twin engine, general aviation aircraft. Software modifications are made to DAAS at Ames concurrent with the flight test program. The changes are the result of the experience obtained with the system at Ames, and the comments of the pilots who evaluated the system.

Nedell, B. F.↗

NASA NTRS2015

Superboom Caustic Analysis and Measurement Program (SCAMP) Final Report

The objectives of the Superboom Caustic Analysis and Measurement (SCAMP) Program were to develop and validate, via flight-test measurements, analytical models for sonic boom signatures in and around focal zones as they are expected to occur during commercial aircraft transition from subsonic to supersonic flight, and to apply these models to focus boom prediction of low-boom aircraft designs. The SCAMP program has successfully investigated sonic boom focusing both analytically and experimentally, while gathering a comprehensive empirical flight test and acoustic dataset, and developing a suite of focused sonic boom prediction tools. An experimental flight and acoustic measurement test was designed during the initial year of the SCAMP program, with execution of the SCAMP flight test occurring in May 2011. The current SCAMP team, led by Wyle, includes partners from the Boeing Company, Pennsylvania State University, Gulfstream Aerospace, Eagle Aeronautics, and Central Washington University. Numerous collaborators have also participated by supporting the experiment with human and equipment resources at their own expense. The experiment involved precision flight of a McDonnell Douglas (now Boeing) F-18B executing different maneuvers that created focused sonic booms. The maneuvers were designed to center on the flight regime expected for commercial supersonic aircraft transonic transition, and also span a range of caustic curvatures in order to provide a variety of conditions for code validations. The SCAMP experiment was designed to capture concurrent F-18B on-board flight instrumentation data, high-fidelity ground-based and airborne acoustic data, and surface and upper air meteorological data. Close coordination with NASA Dryden resulted in the development of new experimental instrumentation and techniques to facilitate the SCAMP flight-test execution, including the development of an F-18B Mach rate cockpit display, TG-14 powered glider in-flight sonic boom measurement instrumentation and "Where's the Focus?" (WTF) software for near-real time way-point computation accounting for local atmospherics. In May 2011, 13 F-18B flights were conducted during 5 flying days over a 2 week period. A densely populated 10,000 ft-long ground acoustic array with 125-ft microphone spacing was designed to capture pre-, focus, and post-focus regions. The ground-based acoustic array was placed in a nominally east-west orientation in the remote Cuddeback lakebed region, north of Edwards AFB. This area was carefully selected to avoid placing focused booms on populated areas or solar power facilities. For the SCAMP measurement campaign, approvals were obtained to temporarily extend the Black Mountain supersonic corridor northward by three miles. The SCAMP flight tests successfully captured 70 boom events, with 61 focus passes, and 9 calibration passes. Seventeen of the focus passes and three of the calibration passes were laterally offset; with the others being centerline flights. Airborne incoming sonic boom wave measurements were measured by the TG-14 for 10 of the F-18B flight passes including one maximum focus signature, several N-u combinations, several overlapped N-u signatures, and several evanescent waves. During the 27-month program, the SCAMP team developed a suite of integrated computer codes with sonic boom focusing predictive capabilities: PCBoom, Lossy Nonlinear Tricomi Equation Method (LNTE) and the Nonlinear Progressive wave Equation (NPE) method. PCBoom propagates the rays through the atmosphere and, in addition to legacy focus signature prediction based on the Gill-Seebass method, provides input source characteristics and propagation parameters to LNTE and NPE. LNTE, a Tricomi solver that incorporates atmospheric losses, computes the focus signature at the focus, and computes the focus signature in the vicinity of the focal zone, including the evanescent and post-focus zones. LNTE signature auralization from low-boom vehicle designs has been demonstrated in the NASA Langley Interior Effects Room (IER). The NPE has also been validated for use in prediction of focused ground boom signatures in sonic boom focal zones. The NPE formulation has the capability to incorporate atmospheric turbulence in the predictions. This has been applied to sonic boom propagation in the past. Prediction of turbulence effects on focal zone signatures was not, however, explored during the SCAMP program.

Page, Juliet↗

NASA NTRS2008

Generating Safety-Critical PLC Code From a High-Level Application Software Specification

The benefits of automatic-application code generation are widely accepted within the software engineering community. These benefits include raised abstraction level of application programming, shorter product development time, lower maintenance costs, and increased code quality and consistency. Surprisingly, code generation concepts have not yet found wide acceptance and use in the field of programmable logic controller (PLC) software development. Software engineers at Kennedy Space Center recognized the need for PLC code generation while developing the new ground checkout and launch processing system, called the Launch Control System (LCS). Engineers developed a process and a prototype software tool that automatically translates a high-level representation or specification of application software into ladder logic that executes on a PLC. All the computer hardware in the LCS is planned to be commercial off the shelf (COTS), including industrial controllers or PLCs that are connected to the sensors and end items out in the field. Most of the software in LCS is also planned to be COTS, with only small adapter software modules that must be developed in order to interface between the various COTS software products. A domain-specific language (DSL) is a programming language designed to perform tasks and to solve problems in a particular domain, such as ground processing of launch vehicles. The LCS engineers created a DSL for developing test sequences of ground checkout and launch operations of future launch vehicle and spacecraft elements, and they are developing a tabular specification format that uses the DSL keywords and functions familiar to the ground and flight system users. The tabular specification format, or tabular spec, allows most ground and flight system users to document how the application software is intended to function and requires little or no software programming knowledge or experience. A small sample from a prototype tabular spec application is shown.

Source record↗

NASA NTRS2017

Security Vulnerability Profiles of NASA Mission Software: Empirical Analysis of Security Related Bug Reports

NASA develops, runs, and maintains software systems for which security is of vital importance. Therefore, it is becoming an imperative to develop secure systems and extend the current software assurance capabilities to cover information assurance and cybersecurity concerns of NASA missions. The results presented in this report are based on the information provided in the issue tracking systems of one ground mission and one flight mission. The extracted data were used to create three datasets: Ground mission IVV issues, Flight mission IVV issues, and Flight mission Developers issues. In each dataset, we identified the software bugs that are security related and classified them in specific security classes. This information was then used to create the security vulnerability profiles (i.e., to determine how, why, where, and when the security vulnerabilities were introduced) and explore the existence of common trends. The main findings of our work include:- Code related security issues dominated both the Ground and Flight mission IVV security issues, with 95 and 92, respectively. Therefore, enforcing secure coding practices and verification and validation focused on coding errors would be cost effective ways to improve mission's security. (Flight mission Developers issues dataset did not contain data in the Issue Category.)- In both the Ground and Flight mission IVV issues datasets, the majority of security issues (i.e., 91 and 85, respectively) were introduced in the Implementation phase. In most cases, the phase in which the issues were found was the same as the phase in which they were introduced. The most security related issues of the Flight mission Developers issues dataset were found during Code Implementation, Build Integration, and Build Verification; the data on the phase in which these issues were introduced were not available for this dataset.- The location of security related issues, as the location of software issues in general, followed the Pareto principle. Specifically, for all three datasets, from 86 to 88 the security related issues were located in two to four subsystems.- The severity levels of most security issues were moderate, in all three datasets.- Out of 21 primary security classes, five dominated: Exception Management, Memory Access, Other, Risky Values, and Unused Entities. Together, these classes contributed from around 80 to 90 of all security issues in each dataset. This again proves the Pareto principle of uneven distribution of security issues, in this case across CWE classes, and supports the fact that addressing these dominant security classes provides the most cost efficient way to improve missions' security. The findings presented in this report uncovered the security vulnerability profiles and identified the common trends and dominant classes of security issues, which in turn can be used to select the most efficient secure design and coding best practices compiled by the part of the SARP project team associated with the NASA's Johnson Space Center. In addition, these findings provide valuable input to the NASA IVV initiative aimed at identification of the two 25 CWEs of ground and flight missions.

vulnerability↗

NASA NTRS2013

Robotics On-Board Trainer (ROBoT)

ROBoT is an on-orbit version of the ground-based Dynamics Skills Trainer (DST) that astronauts use for training on a frequent basis. This software consists of two primary software groups. The first series of components is responsible for displaying the graphical scenes. The remaining components are responsible for simulating the Mobile Servicing System (MSS), the Japanese Experiment Module Remote Manipulator System (JEMRMS), and the H-II Transfer Vehicle (HTV) Free Flyer Robotics Operations. The MSS simulation software includes: Robotic Workstation (RWS) simulation, a simulation of the Space Station Remote Manipulator System (SSRMS), a simulation of the ISS Command and Control System (CCS), and a portion of the Portable Computer System (PCS) software necessary for MSS operations. These components all run under the CentOS4.5 Linux operating system. The JEMRMS simulation software includes real-time, HIL, dynamics, manipulator multi-body dynamics, and a moving object contact model with Tricks discrete time scheduling. The JEMRMS DST will be used as a functional proficiency and skills trainer for flight crews. The HTV Free Flyer Robotics Operations simulation software adds a functional simulation of HTV vehicle controllers, sensors, and data to the MSS simulation software. These components are intended to support HTV ISS visiting vehicle analysis and training. The scene generation software will use DOUG (Dynamic On-orbit Ubiquitous Graphics) to render the graphical scenes. DOUG runs on a laptop running the CentOS4.5 Linux operating system. DOUG is an Open GL-based 3D computer graphics rendering package. It uses pre-built three-dimensional models of on-orbit ISS and space shuttle systems elements, and provides realtime views of various station and shuttle configurations.

Johnson, Genevieve↗

NASA NTRS1972

Vehicle management and mission planning systems with shuttle applications

A preliminary definition of a concept for an automated system is presented that will support the effective management and planning of space shuttle operations. It is called the Vehicle Management and Mission Planning System (VMMPS). In addition to defining the system and its functions, some of the software requirements of the system are identified and a phased and evolutionary method is recommended for software design, development, and implementation. The concept is composed of eight software subsystems supervised by an executive system. These subsystems are mission design and analysis, flight scheduler, launch operations, vehicle operations, payload support operations, crew support, information management, and flight operations support. In addition to presenting the proposed system, a discussion of the evolutionary software development philosophy that the Mission Planning and Analysis Division (MPAD) would propose to use in developing the required supporting software is included. A preliminary software development schedule is also included.

Source record↗

NASA NTRS2005

The Small Aircraft Transportation System (SATS), Higher Volume Operations (HVO) Off-Nominal Operations

The ability to conduct concurrent, multiple aircraft operations in poor weather, at virtually any airport, offers an important opportunity for a significant increase in the rate of flight operations, a major improvement in passenger convenience, and the potential to foster growth of charter operations at small airports. The Small Aircraft Transportation System, (SATS) Higher Volume Operations (HVO) concept is designed to increase traffic flow at any of the 3400 nonradar, non-towered airports in the United States where operations are currently restricted to one-in/one-out procedural separation during Instrument Meteorological Conditions (IMC). The concept's key feature is pilots maintain their own separation from other aircraft using procedures, aircraft flight data sent via air-to-air datalink, cockpit displays, and on-board software. This is done within the Self-Controlled Area (SCA), an area of flight operations established during poor visibility or low ceilings around an airport without Air Traffic Control (ATC) services. The research described in this paper expands the HVO concept to include most off-nominal situations that could be expected to occur in a future SATS environment. The situations were categorized into routine off-nominal operations, procedural deviations, equipment malfunctions, and aircraft emergencies. The combination of normal and off-nominal HVO procedures provides evidence for an operational concept that is safe, requires little ground infrastructure, and enables concurrent flight operations in poor weather.

Baxley, B.↗

NASA NTRS2015

The Evolution of On-Board Emergency Training for the International Space Station Crew

The crew of the International Space Station (ISS) receives extensive ground‐training in order to safely and effectively respond to any potential emergency event while on‐orbit, but few people realize that their training is not concluded when they launch into space. The evolution of the emergency On‐ Board Training events (OBTs) has recently moved from paper "scripts" to an intranet‐based software simulation that allows for the crew, as well as the flight control teams in Mission Control Centers across the world, to share in an improved and more realistic training event. This emergency OBT simulator ensures that the participants experience the training event as it unfolds, completely unaware of the type, location, or severity of the simulated emergency until the scenario begins. The crew interfaces with the simulation software via iPads that they keep with them as they translate through the ISS modules, receiving prompts and information as they proceed through the response. Personnel in the control centers bring up the simulation via an intranet browser at their console workstations, and can view additional telemetry signatures in simulated ground displays in order to assist the crew and communicate vital information to them as applicable. The Chief Training Officers and emergency instructors set the simulation in motion, choosing the type of emergency (rapid depressurization, fire, or toxic atmosphere) and specific initial conditions to emphasize the desired training objectives. Project development, testing, and implementation was a collaborative effort between ISS emergency instructors, Chief Training Officers, Flight Directors, and the Crew Office using commercial off the shelf (COTS) hardware along with simulation software created in‐house. Due to the success of the Emergency OBT simulator, the already‐developed software has been leveraged and repurposed to develop a new emulator used during fire response ground‐training to deliver data that the crew receives from the handheld Compound Specific Analyzer for Combustion Products (CSA‐CP). This CSA‐CP emulator makes use of a portion of codebase from the Emergency OBT simulator dealing with atmospheric contamination during fire scenarios, and feeds various data signatures to crew via an iPod Touch with a flight‐like CSA‐CP display. These innovative simulations, which make use of COTS hardware with custom in‐house software, have yielded drastic improvements to emergency training effectiveness and risk reduction for ISS crew and flight control teams during on‐orbit and ground training events.

LaBuff, Skyler↗

NASA NTRS2006

NASA Tech Briefs, September 2006

Topics covered include: Improving Thermomechanical Properties of SiC/SiC Composites; Aerogel/Particle Composites for Thermoelectric Devices; Patches for Repairing Ceramics and Ceramic- Matrix Composites; Lower-Conductivity Ceramic Materials for Thermal-Barrier Coatings; An Alternative for Emergency Preemption of Traffic Lights; Vehicle Transponder for Preemption of Traffic Lights; Automated Announcements of Approaching Emergency Vehicles; Intersection Monitor for Traffic-Light-Preemption System; Full-Duplex Digital Communication on a Single Laser Beam; Stabilizing Microwave Frequency of a Photonic Oscillator; Microwave Oscillators Based on Nonlinear WGM Resonators; Pointing Reference Scheme for Free-Space Optical Communications Systems; High-Level Performance Modeling of SAR Systems; Spectral Analysis Tool 6.2 for Windows; Multi-Platform Avionics Simulator; Silicon-Based Optical Modulator with Ferroelectric Layer; Multiplexing Transducers Based on Tunnel-Diode Oscillators; Scheduling with Automated Resolution of Conflicts; Symbolic Constraint Maintenance Grid; Discerning Trends in Performance Across Multiple Events; Magnetic Field Solver; Computing for Aiming a Spaceborne Bistatic- Radar Transmitter; 4-Vinyl-1,3-Dioxolane-2-One as an Additive for Li-Ion Cells; Probabilistic Prediction of Lifetimes of Ceramic Parts; STRANAL-PMC Version 2.0; Micromechanics and Piezo Enhancements of HyperSizer; Single-Phase Rare-Earth Oxide/Aluminum Oxide Glasses; Tilt/Tip/Piston Manipulator with Base-Mounted Actuators; Measurement of Model Noise in a Hard-Wall Wind Tunnel; Loci-STREAM Version 0.9; The Synergistic Engineering Environment; Reconfigurable Software for Controlling Formation Flying; More About the Tetrahedral Unstructured Software System; Computing Flows Using Chimera and Unstructured Grids; Avoiding Obstructions in Aiming a High-Gain Antenna; Analyzing Aeroelastic Stability of a Tilt-Rotor Aircraft; Tracking Positions and Attitudes of Mars Rovers; Stochastic Evolutionary Algorithms for Planning Robot Paths; Compressible Flow Toolbox; Rapid Aeroelastic Analysis of Blade Flutter in Turbomachines; General Flow-Solver Code for Turbomachinery Applications; Code for Multiblock CFD and Heat-Transfer Computations; Rotating-Pump Design Code; Covering a Crucible with Metal Containing Channels; Repairing Fractured Bones by Use of Bioabsorbable Composites; Kalman Filter for Calibrating a Telescope Focal Plane; Electronic Absolute Cartesian Autocollimator; Fiber-Optic Gratings for Lidar Measurements of Water Vapor; Simulating Responses of Gravitational-Wave Instrumentation; SOFTC: A Software Correlator for VLBI; Progress in Computational Simulation of Earthquakes; Database of Properties of Meteors; Computing Spacecraft Solar-Cell Damage by Charged Particles; Thermal Model of a Current-Carrying Wire in a Vacuum; Program for Analyzing Flows in a Complex Network; Program Predicts Performance of Optical Parametric Oscillators; Processing TES Level-1B Data; Automated Camera Calibration; Tracking the Martian CO2 Polar Ice Caps in Infrared Images; Processing TES Level-2 Data; SmaggIce Version 1.8; Solving the Swath Segment Selection Problem; The Spatial Standard Observer; Less-Complex Method of Classifying MPSK; Improvement in Recursive Hierarchical Segmentation of Data; Using Heaps in Recursive Hierarchical Segmentation of Data; Tool for Statistical Analysis and Display of Landing Sites; Automated Assignment of Proposals to Reviewers; Array-Pattern-Match Compiler for Opportunistic Data Analysis; Pre-Processor for Compression of Multispectral Image Data; Compressing Image Data While Limiting the Effects of Data Losses; Flight Operations Analysis Tool; Improvement in Visual Target Tracking for a Mobile Robot; Software for Simulating Air Traffic; Automated Vectorization of Decision-Based Algorithms; Grayscale Optical Correlator Workbench; "One-Stop Shopping" for Ocean Remote-Sensing and Model Data; State Analysis Database Tool; Generating CAHV and CAHVOmages with Shadows in ROAMS; Improving UDP/IP Transmission Without Increasing Congestion; FORTRAN Versions of Reformulated HFGMC Codes; Program for Editing Spacecraft Command Sequences; Flight-Tested Prototype of BEAM Software; Mission Scenario Development Workbench; Marsviewer; Tool for Analysis and Reduction of Scientific Data; ASPEN Version 3.0; Secure Display of Space-Exploration Images; Digital Front End for Wide-Band VLBI Science Receiver; Multifunctional Tanks for Spacecraft; Lightweight, Segmented, Mostly Silicon Telescope Mirror; Assistant for Analyzing Tropical-Rain-Mapping Radar Data; and Anion-Intercalating Cathodes for High-Energy- Density Cells.

Source record↗

DOE OSTI2021

SSRS (Stochastic Soaring Raptor Simulator)

SSRS (Stochastic Soaring Raptor Simulator) is a generalizable, probabilistic, and predictive tool for wind energy developers, ecologists, wildlife managers and industry consultants to estimate the potential for soaring raptors to interact with operating wind turbines, without the need for site-specific data collection. Rapid expansion of wind energy development across the world has exposed the risk of turbine collisions for birds and bats. The risk to obligate soaring raptors such as golden eagles is of particular concern due to their small population and influence on ecological balance. Golden eagles rely heavily on updrafts to subsidize their flight, putting them in direct conflict with operational wind turbines that utilize the same wind resource. Understanding the behavior of soaring raptors with varying atmospheric conditions is crucial for predicting and mitigating the risk of turbine collision. This software contains a predictive movement model that simulates individual flight paths of golden eagles during updraft-subsidized long-distance flight, including migration. For a given set of atmospheric conditions, the model simulates thousands of eagles at turbine-scale spatial resolution (50m) to produce a relative presence density map. The simulated eagles rely on updrafts to pursue uninterrupted directional flight with minimal energy expenditure, following fluid-flow principles. The simulator includes a stochastic model of eagle behavior and a systematic method of accounting for spatiotemporal variations in atmospheric conditions. This framework only requires publicly available atmospheric data to estimate orographic and thermal updrafts, ensuring general usability.

Sandhu, Rimple↗

NASA NTRS1983

Area navigation implementation for a microcomputer-based LORAN-C receiver

Engineering performed to make LORAN-C a more useful and practical navigation system for general aviation is described. Development of new software, and implementation of this software on a (MOS6502) microcomputer to provide high quality practical area navigation information directly to the pilot and considered. Flight tests were performed specifically to examine the efficacy of this new software. Final results were exceptionally good and clearly demonstrate the merits of this new LORAN-C area navigation system.

Oguri, F.↗

NASA NTRS2010

The Role and Quality of Software Safety in the NASA Constellation Program

In this study, we examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Obtaining an accurate, program-wide picture of software safety risk is difficult across multiple, independently-developing systems. We leverage one source of safety information, hazard analysis, to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. The goal of this research is two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to quantify the level of risk presented by software in the hazard analysis. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. To quantify the importance of software, we collected metrics based on the number of software-related causes and controls of hazardous conditions. To quantify the level of risk presented by software, we created a metric scheme to measure the specificity of these software causes. We found that from 49-70% of hazardous conditions in the three systems could be caused by software or software was involved in the prevention of the hazardous condition. We also found that 12-17% of the 2013 hazard causes involved software, and that 23-29% of all causes had a software control. Furthermore, 10-12% of all controls were software-based. There is potential for inaccuracy in these counts, however, as software causes are not consistently scoped, and the presence of software in a cause or control is not always clear. The application of our software specificity metrics also identified risks in the hazard reporting process. In particular, we found a number of traceability risks in the hazard reports may impede verification of software and system safety.

Layman, Lucas↗

NASA NTRS2009

Real-Time Simulation of Ares I Launch Vehicle

The Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) has been developed for use by the Ares I launch vehicle System Integration Laboratory (SIL) at the Marshall Space Flight Center (MSFC). The primary purpose of the Ares SIL is to test the vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment to certify that the integrated system is prepared for flight. ARTEMIS has been designed to be the real-time software backbone to stimulate all required Ares components through high-fidelity simulation. ARTEMIS has been designed to take full advantage of the advances in underlying computational power now available to support HWIL testing. A modular real-time design relying on a fully distributed computing architecture has been achieved. Two fundamental requirements drove ARTEMIS to pursue the use of high-fidelity simulation models in a real-time environment. First, ARTEMIS must be used to test a man-rated integrated avionics hardware and software system, thus requiring a wide variety of nominal and off-nominal simulation capabilities to certify system robustness. The second driving requirement - derived from a nationwide review of current state-of-the-art HWIL facilities - was that preserving digital model fidelity significantly reduced overall vehicle lifecycle cost by reducing testing time for certification runs and increasing flight tempo through an expanded operational envelope. These two driving requirements necessitated the use of high-fidelity models throughout the ARTEMIS simulation. The nature of the Ares mission profile imposed a variety of additional requirements on the ARTEMIS simulation. The Ares I vehicle is composed of multiple elements, including the First Stage Solid Rocket Booster (SRB), the Upper Stage powered by the J- 2X engine, the Orion Crew Exploration Vehicle (CEV) which houses the crew, the Launch Abort System (LAS), and various secondary elements that separate from the vehicle. At launch, the integrated vehicle stack is composed of these stages, and throughout the mission, various elements separate from the integrated stack and tumble back towards the earth. ARTEMIS must be capable of simulating the integrated stack through the flight as well as propagating each individual element after separation. In addition, abort sequences can lead to other unique configurations of the integrated stack as the timing and sequence of the stage separations are altered.

Tobbe, Patrick↗