Search NASA⌕ Search

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.

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

At least 487 records · Page 27
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Designing a priority driven multi-frame rate flight executive

The Advanced Transport Operating System (ATOPS) project is a NASA operational research flight project which is concerned with upgrading the new generation of flight computers. In connection with this work, it becomes also necessary to reassess the adequacy of the flight executive and flight software. In the present discussion, attention is given to the ATOPS project upgrade, the operating flight system, the design criteria for the new flight executive, the implementation of the executive, a sample real-time execution, a real-time debug and test tool, and several experiences which could be useful to others considering a similar exercise.

Smith-Taylor, R.↗
NASA NTRS1990

Universal Lambert and Kepler algorithms for autonomous rendezvous

This paper describes Lambert and Kepler algorithms designed to be the core of an autonomous rendezvous guidance system for an onboard computer. Applications include robotic and piloted missions to the moon and planets. Flight software must be compact, fast, and totally reliable. Although high accuracy is not essential for flight, in double precision these algorithms are accurate to at least 14 places almost everywhere. Both are universal; they apply to elliptic, parabolic, hyperbolic, and even rectilinear trajectories. The algorithms are improvements to those published by Battin (1987).

Klumpp, Allan R.↗
NASA NTRS2002

Fielding An Amphibious UAV: Development, Results, and Lessons Learned

This report summarizes the work completed on the design and flight-testing of a small, unmanned, amphibious demonstrator aircraft that flies autonomously. The aircraft named ACAT (Autonomous Cargo Amphibious Transport) is intended to be a large cargo carrying unmanned aircraft that operates from water to avoid airspace and airfield conflict issues between manned and unmanned aircraft. To demonstrate the feasibility of this concept, a demonstrator ACAT was designed, built, and flown that has a six-foot wingspan and can fly autonomously from land or water airfield. The demonstrator was designed for a 1-hour duration and 1-mile telemetry range. A sizing code was used to design the smallest demonstrator UAV to achieve these goals. The final design was a six-foot wingspan, twin hull configuration that distributes the cargo weight across the span, reducing the wing structural weight. The demonstrator airframe was constructed from balsa wood, fiberglass, and plywood. A 4-stroke model airplane engine powered by methanol fuel was mounted in a pylon above the wing and powers the ACAT UAV. Initial flight tests from land and water were conducted under manual radio control and confirmed the amphibious capability of the design. Flight avionics that were developed by MLB for production UAVs were installed in the ACAT demonstrator. The flight software was also enhanced to permit autonomous takeoff and landing from water. A complete autonomous flight from ahard runway was successfully completed on July 5, 2001 and consisted of a take-off, rectangular flight pattern, and landing under complete computer control. A completely autonomous flight that featured a water takeoff and landing was completed on October 4, 2001. This report describes these activities in detail and highlights the challenges encountered and solved during the development of the ACAT demonstrator. hard runway was successfully completed on July 5, 2001 and consisted of a take-off, rectangular flight pattern, and landing under complete computer control. A completely autonomous flight that featured a water takeoff and landing was completed on October 4, 2001. This report describes these activities in detail and highlights the challenges encountered and solved during the development of the ACAT demonstrator.

Pisanich, Greg↗
NASA NTRS2004

The HiVy tool set

Our aim is to validate mission-specific components of spacecraft flight software designs that are specified using state-charts and translated automatically to the final flight code for the mission. We established an automatic translation tool set from state-charts to SPIN for the validation of such mission-specific components.

translation↗
NASA NTRS2012

LogScope

LogScope is a software package for analyzing log files. The intended use is for offline post-processing of such logs, after the execution of the system under test. LogScope can, however, in principle, also be used to monitor systems online during their execution. Logs are checked against requirements formulated as monitors expressed in a rule-based specification language. This language has similarities to a state machine language, but is more expressive, for example, in its handling of data parameters. The specification language is user friendly, simple, and yet expressive enough for many practical scenarios. The LogScope software was initially developed to specifically assist in testing JPL s Mars Science Laboratory (MSL) flight software, but it is very generic in nature and can be applied to any application that produces some form of logging information (which almost any software does).

Havelund, Klaus↗
NASA NTRS2014

Adaptive Augmenting Control Flight Characterization Experiment on an F/A-18

The NASA Marshall Space Flight Center (MSFC) Flight Mechanics and Analysis Division developed an Adaptive Augmenting Control (AAC) algorithm for launch vehicles that improves robustness and performance by adapting an otherwise welltuned classical control algorithm to unexpected environments or variations in vehicle dynamics. This AAC algorithm is currently part of the baseline design for the SLS Flight Control System (FCS), but prior to this series of research flights it was the only component of the autopilot design that had not been flight tested. The Space Launch System (SLS) flight software prototype, including the adaptive component, was recently tested on a piloted aircraft at Dryden Flight Research Center (DFRC) which has the capability to achieve a high level of dynamic similarity to a launch vehicle. Scenarios for the flight test campaign were designed specifically to evaluate the AAC algorithm to ensure that it is able to achieve the expected performance improvements with no adverse impacts in nominal or nearnominal scenarios. Having completed the recent series of flight characterization experiments on DFRC's F/A-18, the AAC algorithm's capability, robustness, and reproducibility, have been successfully demonstrated. Thus, the entire SLS control architecture has been successfully flight tested in a relevant environment. This has increased NASA's confidence that the autopilot design is ready to fly on the SLS Block I vehicle and will exceed the performance of previous architectures.

VanZwieten, Tannen S.↗
NASA NTRS2019

Benefits and Challenges of Model-based Software Engineering: Lessons Learned based on Qualitative and Quantitative Findings

Even though Model-based Software Engineering (MBSwE) techniques and Autogenerated Code (AGC) have been increasingly used to produce complex software systems, there is only anecdotal knowledge about the state-of-thepractice. Furthermore, there is a lack of empirical studies that explore the potential quality improvements due to the use of these techniques. This paper presents in-depth qualitative findings about development and Software Assurance (SWA) practices and detailed quantitative analysis of software bug reports of a NASA mission that used MBSwE and AGC. The mission’s flight software is a combination of handwritten code and AGC developed by two different approaches: one based on state chart models (AGC-M) and another on specification dictionaries (AGC-D). The empirical analysis of fault proneness is based on 380 closed bug reports created by software developers. Our main findings include: (1) MBSwE and AGC provide some benefits, but also impose challenges. (2) SWA done only at a model level is not sufficient. AGC code should also be tested and the models and AGC should always be kept in-sync. AGC must not be changed manually. (3) Fixes made to address an individual bug report were spread both across multiple modules and across multiple files. On average, for each bug report 1.4 modules, that is, 3.4 files were fixed. (4) Most bug reports led to changes in more than one type of file. The majority of changes to auto-generated source code files were made in conjunction to changes in either file with state chart models or XML files derived from dictionaries. (5) For newly developed files, AGC-M and handwritten code were of similar quality, while AGC-D files were the least fault prone.

Goseva-Popstojanova, Katerina↗
NASA NTRS2013

Space Data Systems Applications in the iPAS Pathfinder Laboratory

The iPAS is an integrated hardware/software test and evaluation environment, in support of current and future spacecraft development The iPAS has two main elements. A common avionics, hardware, and software architecture that can be applied over various missions. A common testbed framework that supports integrated hardware/software testing for a variety of applications. The iPAS includes the following (non-flight qualified) components: Core Flight Software (from GSFC). Commercially available Proton and S950 Flight Computer boards. Power and propulsion systems based on representative flight hardware. A realistic flight deck based on the Multi-Purpose Crew Vehicle (MPCV), including realistic flight controls and displays. A Space Data System based on CCSDS protocols.

Rich, Tom↗
NASA NTRS1982

A real-time dynamic spacecraft simulator for the LANDSAT-D mission

A real time dynamic simulator for LANDSAT D was developed and has played an integral role in the development and validation of both the ground control system and of the on-board flight software. The simulator utilized an electronic replica of the spacecraft on-board computer and data handling hardware interfaced to a VAX 11/780 computer and simulation software. Key features of the simulator design are a modular software architecture tailored to the VAX/VMS real time capabilities, a microprocessor controlled interface between the VAX and the flight hardware replica, complete simulation of the spacecraft and NASA network communication links, and a flexible and powerful scenario structuring and operator control capability. The design goals and trade-offs, software, and hardware design are summarized. The application of the simulator to the validation of both the ground systems and on-board software is reviewed in detail.

Coffin, A. R.↗
NASA NTRS1997

Bantam System Technology Project Ground System Requirements Document

The Low Cost Booster Project (LCBP), also known as Bantam, is an element of the Advanced Space Transportation Program focused on Low Cost Booster Technologies. During FY 99 flight demonstrations are planned to demonstrate the feasibility of producing a booster capable of inserting a 150 kg payload into low earth orbit. The ground support system is an element of the full launch system. The ground support system provides for integration of the payload with the launch vehicle, preparation of the vehicle for launch (including maintenance, integration and test of the vehicle flight software), monitor and control of the launch sequence, range safety during launch, and collection of telemetry during the flight up to payload release. The ground support system is intended to make the maximum possible use of Government Off-the-Shelf (GOTS) or Commercial Off-the-Shelf (COTS) hardware and software to obtain the best value in terms of development operations support and ultimate life cycle cost for the launch system.

Moon, J. M.↗
NASA NTRS2012

Replacing the CCSDS Telecommand Protocol with the Next Generation Uplink (NGU)

The current CCSDS Telecommand (TC) Recommendations 1-3 have essentially been in use since the early 1960s. The purpose of this paper is to propose a successor protocol to TC. The current CCSDS recommendations can only accommodate telecommand rates up to approximately 1 mbit/s. However today's spacecraft are storehouses for software including software for Field Programmable Gate Arrays (FPGA) which are rapidly replacing unique hardware systems. Changes to flight software occasionally require uplinks to deliver very large volumes of data. In the opposite direction, high rate downlink missions that use acknowledged CCSDS File Delivery Protocol (CFDP)4 will increase the uplink data rate requirements. It is calculated that a 5 mbits/s downlink could saturate a 4 kbits/s uplink with CFDP downlink responses: negative acknowledgements (NAKs), FINISHs, End-of-File (EOF), Acknowledgements (ACKs). Moreover, it is anticipated that uplink rates of 10 to 20 mbits/s will be required to support manned missions. The current TC recommendations cannot meet these new demands. Specifically, they are very tightly coupled to the Bose-Chaudhuri-Hocquenghem (BCH) code in Ref. 2. This protocol requires that an uncorrectable BCH codeword delimit the TC frame and terminate the randomization process. This method greatly limits telecom performance since only the BCH code can support the protocol. More modern techniques such as the CCSDS Low Density Parity Check (LDPC)5 codes can provide a minimum performance gain of up to 6 times higher command data rates as long as sufficient power is available in the data. This paper will describe the proposed protocol format, trade-offs, and advantages offered, along with a discussion of how reliable communications takes place at higher nominal rates.

Consultative Committee for Space Data Systems (CCS↗
NASA NTRS2015

Software Innovation in a Mission Critical Environment

Operating in mission-critical environments requires trusted solutions, and the preference for "tried and true" approaches presents a potential barrier to infusing innovation into mission-critical systems. This presentation explores opportunities to overcome this barrier in the software domain. It outlines specific areas of innovation in software development achieved by the Johnson Space Center (JSC) Engineering Directorate in support of NASA's major human spaceflight programs, including International Space Station, Multi-Purpose Crew Vehicle (Orion), and Commercial Crew Programs. Software engineering teams at JSC work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements for genuinely mission critical applications. The innovations described, including the use of NASA Core Flight Software and its associated software tool chain, can lead to software that is more affordable, more reliable, better modelled, more flexible, more easily maintained, better tested, and enabling of automation.

Fredrickson, Steven↗
NASA NTRS2022

Cross-Cutting Flight Infrastructure Improvements on M2020

Mars2020 (M2020) was formulated as a mission that leveraged as much Mars Science Laboratory (MSL) heritage as possible, while focusing major new development efforts on the original and unique elements needed to accomplish the different mission objectives. Well publicized examples of high profile new developments include precision landing, the sampling and caching system, the specific instrument suite, improved mobility via Autonomous Navigation, and later the addition of the Ingenuity helicopter. Less well known are the refinements to the core flight infrastructure, primarily in the cross-cutting functions of Telecom, Avionics, Data Management, Communications Behaviors, and Parameter Management. These enhancements are introduced predominately via flight software, and represent increases in capability that justified their inclusion in an otherwise heritage-focused project environment.Perseverance’s cross-cutting flight infrastructure improvements fall into and across the following five categories. First is a trimming of the software footprint of infrastructure modules, in order to make room for memory demands elsewhere in the system. Second is the minimization of data volume to be downlinked, through various methods such as the incorporation of new compression options. Third is the maximization of the available downlink bandwidth for data, by curtailing content-less data (fill) and introducing an improved UHF proximity link protocol. Fourth is a reduction in vulnerabilities, through increased file system redundancy, robustness, and software process monitoring. Fifth is an increase in operations efficiency by lowering file system mount times, improving parallelism between simultaneous events, minimizing the time to recover from file system errors, streamlining the purging of obsolete data, and reducing the number of commands to service parameters by a factor of 100.Individually, none of the cross-cutting infrastructure improvements are likely to garner headlines, but collectively they appreciably improve the safety and operability of Perseverance over its predecessor. This paper will describe the improvements, their promise, and where applicable, their actual impact in operations.

Bohannon, Emily↗
NASA NTRS2003

Experimental Evaluation of Verification and Validation Tools on Martian Rover Software

We report on a study to determine the maturity of different verification and validation technologies (V&V) on a representative example of NASA flight software. The study consisted of a controlled experiment where three technologies (static analysis, runtime analysis and model checking) were compared to traditional testing with respect to their ability to find seeded errors in a prototype Mars Rover. What makes this study unique is that it is the first (to the best of our knowledge) to do a controlled experiment to compare formal methods based tools to testing on a realistic industrial-size example where the emphasis was on collecting as much data on the performance of the tools and the participants as possible. The paper includes a description of the Rover code that was analyzed, the tools used as well as a detailed description of the experimental setup and the results. Due to the complexity of setting up the experiment, our results can not be generalized, but we believe it can still serve as a valuable point of reference for future studies of this kind. It did confirm the belief we had that advanced tools can outperform testing when trying to locate concurrency errors. Furthermore the results of the experiment inspired a novel framework for testing the next generation of the Rover.

Brat, Guillaume↗
NASA NTRS1984

The role of simulation in the development and flight test of the HiMAT vehicle

Real time simulations have been essential in the flight test program of the highly maneuverable aircraft technology (HiMAT) remotely piloted research vehicle at NASA Ames Research Center's Dryden Flight Research Facility. The HiMAT project makes extensive use of simulations in design, development, and qualification for flight, pilot training, and flight planning. Four distinct simulations, each with varying amounts of hardware in the loop, were developed for the HiMAT project. The use of simulations in detecting anomalous behavior of the flight software and hardware at the various stages of development, verification, and validation has been the key to flight qualification of the HiMAT vehicle.

Evans, M. B.↗
NASA NTRSDate not supplied

Astrobee: Improving Capabilities for Free Flying Robotic Technology Demonstrations

The Astrobee Project has completed three years operating inside the ISS. Three Astrobee Free Flyers reached the ISS in April 2019 and are currently hosting a variety of users. During this time, Astrobee has advanced the state of the art in free-flying robots on ISS, operated over 100 sessions, logged over 750 hours of free-flyer operation, and made several capability improvements. Astrobee’s primary objective is to provide a highly flexible and capable free-flying robotic research platform to enable future guest scientist investigations. However, Astrobee is also demonstrating the feasibility of intra-vehicular robots (IVR) for performing key caretaking functions within exploration vehicles as part of NASA’s Moon-to-Mars exploration strategy. IVR capabilities will be especially vital during uncrewed mission phases. For example, current plans call for the lunar Gateway to be uncrewed >85% of the time. Astrobee’s baseline implementation supports free-flying camera and sensor survey use cases. Astrobee guest scientists can deploy software updates and hardware payloads to extend its capabilities. Astrobee is continuously improving its navigation robustness, general flight software maturity, and ISS interior maps, both through the baseline Astrobee operations and with the help of the ISAAC project. Astrobee began with mapping, localization, and operations in the Japanese Experiment Module (JEM), and has expanded to mapping in Node 2 and the US Lab. Astrobee has improved localization and operational robustness through improved mapping processes, algorithm updates (Soussan 2022) that reduce the occurrences of lost localization as well as developed recovery techniques to return to a good localization fix when loss of localization does occur. Future guest science experiments currently in development could demonstrate cargo transfer, fault isolation, free flyer and stationary robot collaboration, microgravity fluid transfer, and new docking mechanisms, among others. This presentation will focus on 1) Astrobee technical capabilities 2) What Astrobee can provide to a guest science experiment 3) Astrobee’s recent improvements 4) Possibilities for using Astrobee for future investigations. Soussan, R., Kumar, V., Coltin, B. and Smith, T. (2022) AstroLoc: An Efficient and Robust Localizer for a Free-flying Robot, Proc. Int. Conf. Rob. Autom. (ICRA) [to appear]

Astrobee↗
NASA NTRS2018

Orion Optical Navigation Progress Toward Exploration: Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. It shares a history with the "method of lunar distances" that was used in the 18th century and gained some notoriety after its use by Captain James Cook during his 1768 Pacific voyage of the HMS Endeavor. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is being worked as a Government Furnished Equipment (GFE) project delivered as an application within the Core Flight Software of the Orion camera controller module. The mathematical formulation behind the initial ellipse fit in the image processing is detailed in Christian. The non-linear least squares refinement then follows the technique of Mortari as an estimation process of the planetary limb using the sigmoid function. The Orion optical navigation system uses a body fixed camera, a decision that was driven by mass and mechanism constraints. The general concept of operations involves a 2-hour pass once every 24 hours, with passes specifically placed before all maneuvers to supply accurate navigation information to guidance and targeting. The pass lengths are limited by thermal constraints on the vehicle since the OpNav attitude generally deviates from the thermally stable tail-to-sun attitude maintained during the rest of the orbit coast phase. Calibration is scheduled prior to every pass due to the unknown nature of thermal effects on the lens distortion and the mounting platform deformations between the camera and star trackers. The calibration technique is described in detail by Christian, et al. and simultaneously estimates the Brown-Conrady coefficients and the Star Tracker/Camera interlock angles. Accurate attitude information is provided by the star trackers during each pass. Figure 1 shows the various phases of lunar return navigation when the vehicle is in autonomous operation with lost ground communication. The midcourse maneuvers are placed to control the entry interface conditions to the desired corridor for safe landing. The general form of optical navigation on Orion is where still images of the Moon or Earth are processed to find the apparent angular diameter and centroid in the camera focal plane. This raw data is transformed into range and bearing angle measurements using planetary data and precise star tracker inertial attitude. The measurements are then sent to the main flight computer's Kalman filter to update the onboard state vector. The images are, of course, collected over an arc to converge the state and estimate velocity. The same basic technique was used by Apollo to satisfy loss-of-comm, but Apollo used manual crew sightings with a vehicle-integral sextant instead of autonomously processing optical imagery. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. In support of this, a hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. Figure 2 shows the rig, which the test team has dubbed OCILOT (Orion Camera In the Loop Optical Testbed). Analysis performed to date shows a delivery that satisfies an allowable entry corridor as shown in Figure 3.

Holt, Greg N.↗
NASA NTRS1983

Galileo attitude and articulation control subsystem closed loop testing

In order to ensure the reliable operation of the Attitude and Articulation Control Subsystem (AACS) which will guide the Galileo spacecraft on its two and one-half year journey to Jupiter, the AACS is being rigorously tested. The primary objectives of the test program are the verification of the AACS's form, fit, and function, especially with regard to subsystem external interfaces and the functional operation of the flight software. Attention is presently given to the Galileo Closed Loop Test System, which simulates the dynamic and 'visual' flight environment for AACS components in the laboratory.

Lembeck, M. F.↗