SEARCH · Search NASA

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 361 records · Page 20

All sources NASA NTRS DOE OSTI

NASA NTRS2002

ISS Material Science Research Rack HWIL Interface Simulation

In this paper, the first Material Science Research Rack (MSRR-1) hardware-in-the-loop (HWIL) interface simulation is described. Dynamic Concepts developed this HWIL simulation system with funding and management provided by the Flight Software group (ED14) of NASA-MSFC's Avionics Department. The HWIL system has been used both as a flight software development environment and as a software qualification tool. To fulfill these roles, the HWIL simulator accurately models the system dynamics of many MSRR-1 subsystems and emulates most of the internal interface signals. The modeled subsystems include the Experiment Modules, the Thermal Environment Control System, the Vacuum Access System, the Solid State Power Controller Module, and the Active Rack Isolation Systems. The emulated signals reside on three separate MIL-STD-1553B digital communication buses, the ISS Medium Rate Data Link, and several analog controller and sensor signals. To enhance the range of testing, it was necessary to simulate several off-nominal conditions that may occur in the interfacing subsystems.

Williams, Philip J.↗

NASA NTRS1983

Distributed asynchronous microprocessor architectures in fault tolerant integrated flight systems

The paper discusses the implementation of fault tolerant digital flight control and navigation systems for rotorcraft application. It is shown that in implementing fault tolerance at the systems level using advanced LSI/VLSI technology, aircraft physical layout and flight systems requirements tend to define a system architecture of distributed, asynchronous microprocessors in which fault tolerance can be achieved locally through hardware redundancy and/or globally through application of analytical redundancy. The effects of asynchronism on the execution of dynamic flight software is discussed. It is shown that if the asynchronous microprocessors have knowledge of time, these errors can be significantly reduced through appropiate modifications of the flight software. Finally, the papear extends previous work to show that through the combined use of time referencing and stable flight algorithms, individual microprocessors can be configured to autonomously tolerate intermittent faults.

Dunn, W. R.↗

NASA NTRS1988

Fault-Tolerant Software For Flight Control

Report discusses design and testing of redundant control system for F-8 digital fly-by-wire airplane. Outstanding feature of system is fault-tolerant software (REBUS) residing in primary digital computers. Transition to operation on backup software smooth.

Deets, Dwain A.↗

NASA NTRS2016

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IV&V) Program, with Software Assurance Research Program support, extracted FM architectures across the IV&V portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IV&V projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management. The identification of particular FM architectures, visibility, and associated IV&V techniques provides a TR suite that enables greater assurance that critical software systems will adequately protect against faults and respond to adverse conditions. Additionally, the role FM has with regard to strengthened security requirements, with potential to advance overall asset protection of flight software systems, is being addressed with the development of an adverse conditions database encompassing flight software vulnerabilities. Capitalizing on the established framework, this TR suite provides assurance capability for a variety of FM architectures and varied development approaches. Research results are being disseminated across NASA, other agencies, and the software community. This paper discusses the findings and TR suite informing the FM domain in best practices for FM architectural design, visibility observations, and methods employed for IV&V and mission assurance.

Fitz, Rhonda↗

NASA NTRSDate not supplied

The State of NOS3

The NASA Operational Simulator for Small Satellites (NOS3) showcases some of the Jon McBride Software Testing and Research (JSTAR) laboratories technologies on an open-source platform. NOS3 is a software digital twin providing a virtualized platform inside which you have your traditional flight software, ground software, environmental simulators, and middleware to keep all pieces in sync. NOS3 leverages the core Flight System (cFS), OpenC3 COSMOS, and NASA GSFC’s 42 software as the baseline to which additional research technologies can be developed. Current technologies to be demonstrated include NOS3 Igniter, constellation support, NASA JPL’s SYNOPSIS integration, and NASA GSFC’s OnAir. NOS3 Igniter is a GUI in which you can configure, build, and run your simulation. This along with improvements to the documentation and training available open source aims to reduce the ramp up time with new users and improve accessibility. As constellations introduce another level of complexity, it is important to ensure the baseline design reference mission covers all the basics required and allows users to experiment, understand, and test at all levels of the system. The Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) is an open-source tool developed by NASA JPL to enable data prioritization and planning. GSFC’s Onboard Artificial Intelligence Research (OnAIR) enables custom algorithm development written in python to interface with the flight software allowing scientists to develop what they need for the next generation of missions and easily interface back to the traditional flight software. During the presentation, a review and demonstration of the above technologies is planned along with a roadmap.

NOS3↗

NASA NTRS1974

HAL/S language specification

A programming language for the flight software of the NASA space shuttle program was developed and identified as HAL/S. The language is intended to satisfy virtually all of the flight software requirements of the space shuttle. The language incorporates a wide range of features, including applications-oriented data types and organizations, real time control mechanisms, and constructs for systems programming tasks.

Newbold, P. M.↗

NASA NTRS2005

James Webb Space Telescope XML Database: From the Beginning to Today

The James Webb Space Telescope (JWST) Project has been defining, developing, and exercising the use of a common eXtensible Markup Language (XML) for the command and telemetry (C&T) database structure. JWST is the first large NASA space mission to use XML for databases. The JWST project started developing the concepts for the C&T database in 2002. The database will need to last at least 20 years since it will be used beginning with flight software development, continuing through Observatory integration and test (I&T) and through operations. Also, a database tool kit has been provided to the 18 various flight software development laboratories located in the United States, Europe, and Canada that allows the local users to create their own databases. Recently the JWST Project has been working with the Jet Propulsion Laboratory (JPL) and Object Management Group (OMG) XML Telemetry and Command Exchange (XTCE) personnel to provide all the information needed by JWST and JPL for exchanging database information using a XML standard structure. The lack of standardization requires custom ingest scripts for each ground system segment, increasing the cost of the total system. Providing a non-proprietary standard of the telemetry and command database definition formation will allow dissimilar systems to communicate without the need for expensive mission specific database tools and testing of the systems after the database translation. The various ground system components that would benefit from a standardized database are the telemetry and command systems, archives, simulators, and trending tools. JWST has exchanged the XML database with the Eclipse, EPOCH, ASIST ground systems, Portable spacecraft simulator (PSS), a front-end system, and Integrated Trending and Plotting System (ITPS) successfully. This paper will discuss how JWST decided to use XML, the barriers to a new concept, experiences utilizing the XML structure, exchanging databases with other users, and issues that have been experienced in creating databases for the C&T system.

Gal-Edd, Jonathan↗

NASA NTRS1993

Evaluation of the efficiency and fault density of software generated by code generators

Flight computers and flight software are used for GN&C (guidance, navigation, and control), engine controllers, and avionics during missions. The software development requires the generation of a considerable amount of code. The engineers who generate the code make mistakes and the generation of a large body of code with high reliability requires considerable time. Computer-aided software engineering (CASE) tools are available which generates code automatically with inputs through graphical interfaces. These tools are referred to as code generators. In theory, code generators could write highly reliable code quickly and inexpensively. The various code generators offer different levels of reliability checking. Some check only the finished product while some allow checking of individual modules and combined sets of modules as well. Considering NASA's requirement for reliability, an in house manually generated code is needed. Furthermore, automatically generated code is reputed to be as efficient as the best manually generated code when executed. In house verification is warranted.

Schreur, Barbara↗

NASA NTRS2016

The Soil Moisture Acttive Passive Mission: Fault Protection Performance and Lessons Learned

Fault protection as a discipline involves a collection of flight software logic and operational processes for detecting unacceptable anomalous behavior, responding prior to reaching criticality, restricting the propagation of a failure beyond a fault containment region, and recovering the vehicle back to full or degraded functionality if possible. The System Fault Protection (SFP) design for the SMAP Earth orbiter was put to the test during its 90-day vehicle commissioning activities. During this time, the SFP software autonomously protected the vehicle from multiple faults to critical hardware, and the operations team successfully returned the observatory to its science state. The SFP also performed well in the presence of anomalous behavior below true safety limits by not taking unnecessary response actions, instead allowing the operations team time to monitor the behavior. Certain aspects of the SFP design were modified during operations via both parameter updates and a full flight software update in order to better match the vehicle behavior in the flight environment. An evaluation of the SMAP SFP performance during vehicle Commissioning will be provided in this paper, as well as a set of lessons learned largely focused on visibility, SFP mutability in operations, responses to peripheral device faults, and Safe Mode recovery and design. By capturing some of the knowledge gained during SMAP Commissioning, it is intended that this paper provide guidance for making future System Fault Protection designs more robust and supportive of operations.

Clark, Jessica↗

NASA NTRS2000

Formal Analysis of the Remote Agent Before and After Flight

This paper describes two separate efforts that used the SPIN model checker to verify deep space autonomy flight software. The first effort occurred at the beginning of a spiral development process and found five concurrency errors early in the design cycle that the developers acknowledge would not have been found through testing. This effort required a substantial manual modeling effort involving both abstraction and translation from the prototype LISP code to the PROMELA language used by SPIN. This experience and others led to research to address the gap between formal method tools and the development cycle used by software developers. The Java PathFinder tool which directly translates from Java to PROMELA was developed as part of this research, as well as automatic abstraction tools. In 1999 the flight software flew on a space mission, and a deadlock occurred in a sibling subsystem to the one which was the focus of the first verification effort. A second quick-response "cleanroom" verification effort found the concurrency error in a short amount of time. The error was isomorphic to one of the concurrency errors found during the first verification effort. The paper demonstrates that formal methods tools can find concurrency errors that indeed lead to loss of spacecraft functions, even for the complex software required for autonomy. Second, it describes progress in automatic translation and abstraction that eventually will enable formal methods tools to be inserted directly into the aerospace software development cycle.

Havelund, Klaus↗

NASA NTRS2011

Space Shuttle Ascent Flight Design Process: Evolution and Lessons Learned

The Space Shuttle Ascent Flight Design team is responsible for defining a launch to orbit trajectory profile that satisfies all programmatic mission objectives and defines the ground and onboard reconfiguration requirements for this high-speed and demanding flight phase. This design, verification and reconfiguration process ensures that all applicable mission scenarios are enveloped within integrated vehicle and spacecraft certification constraints and criteria, and includes the design of the nominal ascent profile and trajectory profiles for both uphill and ground-to-ground aborts. The team also develops a wide array of associated training, avionics flight software verification, onboard crew and operations facility products. These key ground and onboard products provide the ultimate users and operators the necessary insight and situational awareness for trajectory dynamics, performance and event sequences, abort mode boundaries and moding, flight performance and impact predictions for launch vehicle stages for use in range safety, and flight software performance. These products also provide the necessary insight to or reconfiguration of communications and tracking systems, launch collision avoidance requirements, and day of launch crew targeting and onboard guidance, navigation and flight control updates that incorporate the final vehicle configuration and environment conditions for the mission. Over the course of the Space Shuttle Program, ascent trajectory design and mission planning has evolved in order to improve program flexibility and reduce cost, while maintaining outstanding data quality. Along the way, the team has implemented innovative solutions and technologies in order to overcome significant challenges. A number of these solutions may have applicability to future human spaceflight programs.

Picka, Bret A.↗

NASA NTRS1990

A sun gate for Galileo spacecraft attitude control

The combination of a sun sensor called a sun gate (SG) and a digital programmable signal processor on the Galileo spacecraft attitude and articulation control subsystem (AACS) will orient the rotation axis of the spacecraft toward the sun to satisfy a new requirement imposed by the new spacecraft trajectory. The combination will continuously monitor the pointing direction of the rotation axis, and any off-sun excursions of more than a preset threshold will be detected, triggering appropriate actions by the flight software to prevent off-sun cone angles of more than 14 deg. The design of the SG is described in detail, its principle of operation is given, and the flight software processing of the SG output is discussed.

Mobasser, Sohrab↗

NASA NTRS1989

Shuttle relative navigation of a tethered satellite mission with current on board software

A Shuttle mission planned in 1991 will test the feasibility of tethers in space. This mission, a joint effort between Italy and the United States, will connect a satellite (built by the Italians) to the Shuttle with a 20 km long tether. This mission poses unique navigation problems. The flight software on the Shuttle was never designed to account for the low level acceleration that is generated by the gravity gradient. IMUs on the Shuttle was never designed to account for the low level acceleration that is generated by the gravity gradient. Inertial Maneuvering Units on the shuttle will sense the acceleration of the tether but it turns out that incorporating the continuous accelerometer noise also generates large error growth. Relative navigation is another important issue since the majority of the mission will be conducted while the satellite is out of the visual range of the crew. Some kind of feedback on the motion of the satellite will be desirable. Feedback of the satellite motion can be generated by using the rendezvous radar. To process the radar measurements, the flight software uses a 13 state Kalman Filter, but unfortunately with the filter currently tuned as it is, valid measurements tend to be ignored. This is due to the constraint of the tether on the satellite, which is an unmodeled force. Analysis shows that with proper tuning, relative navigation is possible.

Lee, Kevin A.↗

NASA NTRS2017

Autonomy Operating System for UAVs: Pilot-in-a-Box

The Autonomy Operating System (AOS) is an open flight software platform with Artificial Intelligence for smart UAVs. It is built to be extendable with new apps, similar to smartphones, to enable an expanding set of missions and capabilities. AOS has as its foundations NASAs core flight executive and core flight software (cFEcFS). Pilot-in-a-Box (PIB) is an expanding collection of interacting AOS apps that provide the knowledge and intelligence onboard a UAV to safely and autonomously fly in the National Air Space, eventually without a remote human ground crew. Longer-term, the goal of PIB is to provide the capability for pilotless air vehicles such as air taxis that will be key for new transportation concepts such as mobility-on-demand. PIB provides the procedural knowledge, situational awareness, and anticipatory planning (thinking ahead of the plane) that comprises pilot competencies. These competencies together with a natural language interface will enable Pilot-in-a-Box to dialogue directly with Air Traffic Management from takeoff through landing. This paper describes the overall AOS architecture, Artificial Intelligence reasoning engines, Pilot-in-a-box competencies, and selected experimental flight tests to date.

Lowry, Michael↗

NASA NTRS1993

Performance assessment of the TDRSS Onboard Navigation System (TONS) experiment on EP/EUVE

The National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC) is currently developing an operational Tracking and Data Relay Satellite (TDRS) System (TDRSS) Onboard Navigation System (TONS) to provide onboard knowledge of high-accuracy navigation products autonomously to users of TDRSS and its successor, TDRS-2. A TONS experiment has been implemented on the Explorer Platform/Extreme Ultraviolet Explorer (EP/EUVE) spacecraft, launched June 7, 1992, to flight qualify the TONS operational system using TDRSS forward-link communications services. This paper assesses the performance of the TONS flight hardware, an ultrastable oscillator (USO) and Doppler extractor (DE) card in one of the TDRSS user transponders, and the protoype flight software, based on the TONS experiment results. An overview of onboard navigation via TDRSS is also presented for both the EP/EUVE experiment and for future users of TONS. USO and DE short-term and long-term stability performance has been excellent. TONS Flight Software analysis indicates that position accuracies of better than 25 meters root-mean-square are achievable with tracking every one to two orbits, for the EP/EUVE 525-kilometer altitudes, 28.5-degree inclination orbit. The success of the TONS experiment demonstrates the flight readiness of TONS, which is scheduled to provide autonomous navigation for the Earth Observing System (EOS)-AM mission.

Gramling, C. J.↗

NASA NTRS2010

Orion Entry Display Feeder and Interactions with the Entry Monitor System

The Orion spacecraft is designed to return astronauts to a landing within 10 km of the intended landing target from low Earth orbit, lunar direct-entry, and lunar skip-entry trajectories. Al pile the landing is nominally controlled autonomously, the crew can fly precision entries manually in the event of an anomaly. The onboard entry displays will be used by the crew to monitor and manually fly the entry, descent, and landing, while the Entry Monitor System (EMS) will be used to monitor the health and status of the onboard guidance and the trajectory. The entry displays are driven by the entry display feeder, part of the Entry Monitor System (EMS). The entry re-targeting module, also part of the EMS, provides all the data required to generate the capability footprint of the vehicle at any point in the trajectory, which is shown on the Primary Flight Display (PFD). It also provides caution and warning data and recommends the safest possible re-designated landing site when the nominal landing site is no longer within the capability of the vehicle. The PFD and the EMS allow the crew to manually fly an entry trajectory profile from entry interface until parachute deploy having the flexibility to manually steer the vehicle to a selected landing site that best satisfies the priorities of the crew. The entry display feeder provides data from the ENIS and other components of the GNC flight software to the displays at the proper rate and in the proper units. It also performs calculations that are specific to the entry displays and which are not made in any other component of the flight software. In some instances, it performs calculations identical to those performed by the onboard primary guidance algorithm to protect against a guidance system failure. These functions and the interactions between the entry display feeder and the other components of the EMS are described.

Baird, Darren↗

NASA NTRS2018

Radio-hosted Flight / Ground Interface for Operations Standardization

The interface between a spacecraft and its ground operations segment includes the flow of commands, configuration, and sequencing elements to the spacecraft, and the flow of telemetry and data products from the spacecraft. Creating and implementing a complete definition of this interface simplifies and standardizes mission operations, allowing easy sharing of operations personnel across missions. Early spacecraft featured a simple flight / ground interface (FGI) using hardware command decoding in the radio, driven by technological limitations of the time. Modern spacecraft use command and data handling (CDH) avionics on which flight software executes, which in turn controls and configures the mission, executes subsystem and instrument instructions, and implements critical fault protection actions. Deep space missions feature advanced operations software for running sequenced activities over a period of weeks, which allows them to function with only infrequent ground contact. This approach comes at the cost of increased complexity in the FGI, requiring expensive modifications to heritage flight software and ground systems. By hosting the interface in the radio instead of the CDH avionics, modern missions can approximate the FGI design simplicity of early spacecraft, with significant advantages for vendor competition, lowered costs, standardization of operations, and reduction of implementation risk.

Lock, Patricia D.↗

NASA NTRS1998

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↗