Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Flight Software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 829 records · Page 46
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Space Robot Operating System (Space ROS)

Space Robot Operating System (Space ROS) is an open-source software framework for flight-quality robotic and autonomous space systems. It combines the benefits of open-source software and flight software best-practices into a single framework. Space ROS is predicated on ROS2 and is therefore reusable, modular and adoptable. As an open-source framework, it is accessible to the global space community. Space ROS is intended to be compliant with NASA flight software engineering practices in order to facilitate meeting mission and safety standards. Space ROS has fault management and real-time capabilities at its core.

Will Chambers↗
NASA NTRS2016

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗
NASA NTRS1977

Backup flight control system functional evaluator software manual

The software for the Backup Flight Control System Functional Evaluator (BFCSFE) on a Data General Corporation Nova 1200 computer consists of three programs: the ground support program, the operational flight program (OFP), and the ground pulse code modulation (PCM) program. The Nova OFP software is structurally as close as possible to the AP101 code; therefore, this document highlights and describes only those areas of the Nova OFP that are significantly different from the AP101. Since the Ground Support Program was developed to meet BFCSFE requirements and differs considerably from the AP101 code, it is described in detail.

Helmke, C. A.↗
NASA NTRSDate not supplied

NASA GSFC SmallSats – A NOS 3 Case Study

The NASA Operational Simulator for Small Satellites (NOS 3 ) has now been in existence since 2016. It was originally developed as one of the main goals of the Simulation-To-Flight 1 CubeSat effort. Subsequently, portions of NOS 3 were released as open source (https://github.com/nasa/nos3) in 2018. Beginning in 2019, NOS 3 was used for the development of a number of NASA CubeSats. This presentation will describe the use of NOS 3 in that development. It will describe how NOS 3 was used to develop and test numerous components for the CubeSats including the development of hardware component simulators. It will describe the benefits of using NOS 3 for component development. It will also describe how NOS 3 was used for integrating attitude control system software with flight software. This included executing closed loop attitude control for the CubeSats using simulated hardware sensors and actuators. The benefits of using NOS 3 for this integration will also be described.

NOS3↗
NASA NTRS1989

Detection and avoidance of errors in computer software

The acceptance test errors of a computer software project to determine if the errors could be detected or avoided in earlier phases of development. GROAGSS (Gamma Ray Observatory Attitude Ground Support System) was selected as the software project to be examined. The development of the software followed the standard Flight Dynamics Software Development methods. GROAGSS was developed between August 1985 and April 1989. The project is approximately 250,000 lines of code of which approximately 43,000 lines are reused from previous projects. GROAGSS had a total of 1715 Change Report Forms (CRFs) submitted during the entire development and testing. These changes contained 936 errors. Of these 936 errors, 374 were found during the acceptance testing. These acceptance test errors were first categorized into methods of avoidance including: more clearly written requirements; detail review; code reading; structural unit testing; and functional system integration testing. The errors were later broken down in terms of effort to detect and correct, class of error, and probability that the prescribed detection method would be successful. These determinations were based on Software Engineering Laboratory (SEL) documents and interviews with the project programmers. A summary of the results of the categorizations is presented. The number of programming errors at the beginning of acceptance testing can be significantly reduced. The results of the existing development methodology are examined for ways of improvements. A basis is provided for the definition is a new development/testing paradigm. Monitoring of the new scheme will objectively determine its effectiveness on avoiding and detecting errors.

Kinsler, Les↗
NASA NTRS1981

LANDSAT-D flight segment operations manual. Appendix B: OBC software operations

The LANDSAT 4 satellite contains two NASA standard spacecraft computers and 65,536 words of memory. Onboard computer software is divided into flight executive and applications processors. Both applications processors and the flight executive use one or more of 67 system tables to obtain variables, constants, and software flags. Output from the software for monitoring operation is via 49 OBC telemetry reports subcommutated in the spacecraft telemetry. Information is provided about the flight software as it is used to control the various spacecraft operations and interpret operational OBC telemetry. Processor function descriptions, processor operation, software constraints, processor system tables, processor telemetry, and processor flow charts are presented.

Talipsky, R.↗
NASA NTRS2014

Range Safety Flight Elevation Limit Calculation Software

This program was developed to fill a need within the Wallops Flight Facility workflow for automation of the development of vertical plan limit lines used by flight safety officers during the conduct of expendable launch vehicle missions. Vertical plane present-position-based destruct lines have been used by range safety organizations at numerous launch ranges to mitigate launch vehicle risks during the early phase of flight. Various ranges have implemented data submittal and processing workflows to develop these destruct lines. As such, there is significant prior art in this field. The ElLimits program was developed at NASA's Wallops Flight Facility to automate the process for developing vertical plane limit lines using current computing technologies. The ElLimits program is used to configure launch-phase range safety flight control lines for guided missiles. The name of the program derives itself from the fundamental quantity that is computed - flight elevation limits. The user specifies the extent and resolution of a grid in the vertical plane oriented along the launch azimuth. At each grid point, the program computes the maximum velocity vector flight elevation that can be permitted without endangering a specified back-range location. Vertical plane x-y limit lines that can be utilized on a present position display are derived from the flight elevation limit data by numerically propagating 'streamlines' through the grid. The failure turn and debris propagation simulation technique used by the application is common to all of its analysis options. A simulation is initialized at a vertical plane grid point chosen by the program. A powered flight failure turn is then propagated in the plane for the duration of the so-called RSO reaction time. At the end of the turn, a delta-velocity is imparted, and a ballistic trajectory is propagated to impact. While the program possesses capability for powered flight failure turn modeling, it does not require extensive user inputs of vehicle characteristics (e.g., thrust and aerodynamic data), nor does it require reams of turn data after the traditional fashion of the Air Force ranges. The program requires a nominal trajectory table (time, altitude, range, velocity, and flight elevation) and makes heavy use of it to initialize and model a failure turn.

Lanzi, Raymond J↗
NASA NTRS2004

STK/Lifetime as a Replacement for Heritage Orbital Lifetime Software

The Flight Dynamics Analysis Branch (FDAB) of NASNGSFC is tasked with determining the orbital lifetime of several developmental and operational satellites, which include the Hubble Space Telescope. A DOS based program developed by the FDAB many years ago, called PC Lifetime, is used to determine a satellite s lifetime and could soon be in need of a replacement. STK s Lifetime Object Tool is a possible candidate. Due to the reduced support of the PC Lifetime program, and the growing incompatibility of older programs with new operating systems, a comparative analysis was done to determine if STWLifetime could meet the stringent requirements that were laid before it. The use of highly accurate numerical propagators such as STK s High Precision Orbit Propagator ( OP) and the Goddard Trajectory Determination System (GTDS) provided a basis on which to compare STWLifetime s results. Several test cases were run, but the main four test cases would determine whether or not STWLifetime could be PC- Lifetime s replacement. These four cases include a geotransfer orbit, two circular LEOS, and a Poiar LEO. Following rigorous testmg procedures, a conclusion will be determined. STK has proved to be a versatile program on many satellite missions and the FDAB has high hopes that it can pass FDAB s requirements for orbital lifetime prediction.

Dove, Edwin↗
NASA NTRS2007

Imaging Sensor Flight and Test Equipment Software

The Lightning Imaging Sensor (LIS) is one of the components onboard the Tropical Rainfall Measuring Mission (TRMM) satellite, and was designed to detect and locate lightning over the tropics. The LIS flight code was developed to run on a single onboard digital signal processor, and has operated the LIS instrument since 1997 when the TRMM satellite was launched. The software provides controller functions to the LIS Real-Time Event Processor (RTEP) and onboard heaters, collects the lightning event data from the RTEP, compresses and formats the data for downlink to the satellite, collects housekeeping data and formats the data for downlink to the satellite, provides command processing and interface to the spacecraft communications and data bus, and provides watchdog functions for error detection. The Special Test Equipment (STE) software was designed to operate specific test equipment used to support the LIS hardware through development, calibration, qualification, and integration with the TRMM spacecraft. The STE software provides the capability to control instrument activation, commanding (including both data formatting and user interfacing), data collection, decompression, and display and image simulation. The LIS STE code was developed for the DOS operating system in the C programming language. Because of the many unique data formats implemented by the flight instrument, the STE software was required to comprehend the same formats, and translate them for the test operator. The hardware interfaces to the LIS instrument using both commercial and custom computer boards, requiring that the STE code integrate this variety into a working system. In addition, the requirement to provide RTEP test capability dictated the need to provide simulations of background image data with short-duration lightning transients superimposed. This led to the development of unique code used to control the location, intensity, and variation above background for simulated lightning strikes at user-selected locations.

Freestone, Kathleen↗
NASA NTRSDate not supplied

Rapid Lightweight Firmware Architecture of the Mobile Metamaterial Internal Co-Integrator Robot

The Mobile Metamaterial Internal Co-Integrator (MMIC-I) is a structure assembly and servicing robot for in-space servicing, assembly, and manufacturing of primary structures and infrastructure. MMIC-I is a battery-powered crawling robot that can travel through periodic structures such as trusses and open framework mechanical metamaterials. It does this through sequences of component extension, contraction, and gripping. This paper provides a detailed discussion of MMIC-I’s lightweight and rapidly developed firmware architecture, to enable demonstration of robot locomotion, secondary operations, and communications with a central command source. The rationale for the lightweight rapid development approach is to allow for assessment of long term system requirements in parallel with the mechatronics development, including optimization of system and subsystem power densities, to inform a future choice of flight ready software frameworks. MMIC-I system computing and I/O requirements are much lower than what is provided by proven baseline computing hardware for existing flight ready software frameworks such as the core Flight System, F prime, and the Robot Operating System. Development of earth gravity ground demonstration of the robotic systems is greatly benefited by limited power and mass factors for computing hardware. Here, we implement inter-process communication, commanding, and telemetry with the Espressif ESP32 module running the Arduino OS.

Damiana Catanoso↗
NASA NTRS1980

STS-1 operational flight profile. Volume 5: Descent, cycle 3

The trajectory data presented are to be used for orbiter systems and subsystems evalation, flight and mission control center software verification, flight techniques and timeline development, crew training, and evaluation of operational mission suitability. The entry profile is very similar to cycle 2, however, elevon and body flap temperature margins have increased and the elevon schedule was changed. The terminal area energy management (TAEM) profile was completely reshaped to conform with new angle of attack constraints and left hand turn around the heading alignment cylinder. Also, the entry/TAEM interface was adjusted to minimize guidance induced angle of attack transients across the interface. The approach and landing phase was reshaped for a 20 deg glideslope and reduced velocity at touchdown. The definition of the runway threshold was standardized for all landing sites. This results in a shift at Edwards Air Force Base in aim points and touchdown relative to the threshold of 1000 feet. The rollout remains essentially unchanged with the exception of the speedbrake, which is now deployed to 50 percent at touchdown.

Moore, R.↗
NASA NTRS1984

Software conversion history of the Flight Dynamics System (FDS)

This report summarizes the overall history of the Flight Dynamics System (FDS) applications software conversion project. It describes the background and nature of the project; traces the actual course of conversion; assesses the process, product, and personnel involved; and offers suggestions for future projects. It also contains lists of pertinent reference material and examples of supporting data.

Liu, K.↗
NASA NTRS1990

Manager's handbook for software development, revision 1

Methods and aids for the management of software development projects are presented. The recommendations are based on analyses and experiences of the Software Engineering Laboratory (SEL) with flight dynamics software development. The management aspects of the following subjects are described: organizing the project, producing a development plan, estimating costs, scheduling, staffing, preparing deliverable documents, using management tools, monitoring the project, conducting reviews, auditing, testing, and certifying.

Source record↗
NASA NTRS1980

Orbit determination software development for microprocessor based systems: Evaluation and recommendations

A guide is presented for National Aeronautics and Space Administration management personnel who stand to benefit from the lessons learned in developing microprocessor-based flight dynamics software systems. The essential functional characteristics of microprocessors are presented. The relevant areas of system support software are examined, as are the distinguishing characteristics of flight dynamics software. Design examples are provided to illustrate the major points presented, and actual development experience obtained in this area is provided as evidence to support the conclusions reached.

Shenitz, C. M.↗
NASA NTRS1986

Software reliability - Measures and effects in flight critical digital avionics systems

The paper discusses software reliability as it applies particularly to design and evaluation of flight-critical digital avionics systems. Measures of software reliability, measurement methods and reliability (macro-) models are discussed. Recent work assessing their accuracy in predicting software errors in 'fly-by-wire' Newtonian applications is presented. Additional, detailed topics are discussed including software error distributions (e.g. catastrophic vs. noncatastrophic) and the effects of system growth/maturity on reliability improvement. In practical flight-critical digital applications, software reliability improvement is sought through use of parallel, redundant software (i.e. N-version programming) or backup software that can be invoked in the event of (primary) software failure. Achievable reliability levels are however highly sensitive to common-mode specification and programming errors. Recent data correlating these errors with net software reliability are discussed.

Dunn, William R.↗