Search NASA⌕ Search

SEARCH · Search NASA

Results for “space 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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
NASA NTRS2007

Hierarchical Segmentation Enhances Diagnostic Imaging

Bartron Medical Imaging LLC (BMI), of New Haven, Connecticut, gained a nonexclusive license from Goddard Space Flight Center to use the RHSEG software in medical imaging. To manage image data, BMI then licensed two pattern-matching software programs from NASA's Jet Propulsion Laboratory that were used in image analysis and three data-mining and edge-detection programs from Kennedy Space Center. More recently, BMI made NASA history by being the first company to partner with the Space Agency through a Cooperative Research and Development Agreement to develop a 3-D version of RHSEG. With U.S. Food and Drug Administration clearance, BMI will sell its Med-Seg imaging system with the 2-D version of the RHSEG software to analyze medical imagery from CAT and PET scans, MRI, ultrasound, digitized X-rays, digitized mammographies, dental X-rays, soft tissue analyses, moving object analyses, and soft-tissue slides such as Pap smears for the diagnoses and management of diseases. Extending the software's capabilities to three dimensions will eventually enable production of pixel-level views of a tumor or lesion, early identification of plaque build-up in arteries, and identification of density levels of microcalcification in mammographies.

Source record↗
NASA NTRS2013

Reducing Pointing Errors During Cassini Reaction Control System Orbit Trim Maneuvers

The effect of altering a gain parameter in the Cassini reaction control system (RCS) delta-V controller on the maneuver execution errors during orbit trim maneuvers (OTMs) is explored. Cassini consists of two reaction control thruster branches (A & B) each with eight thrusters. Currently, the B-branch is operational while the A-branch serves as a back-up. The four Z-thrusters control the X and Y-axes, while the four Y-thrusters control the Z-axis. During an OTM, the Z-thrusters fire to maintain the X and Y-axes pointing within an attitude control dead-zone (-10 to 10 milliradians). The errors do not remain at zero due to pointing error sources such as spacecraft center of mass offset from the geometric center of the Z-facing thrusters, and variability in the thruster forces due to the thruster hardware differences. The delta-V reaction control system (RCS) controller ensures that the attitude error remains within this dead-zone. Gain parameters within the RCS delta-V controller affect the maneuver execution errors. Different parameter values are used to explore effect on these errors. It is found that pointing error decreases and magnitude error increases rapidly for gain parameters 10 times greater than the current parameter values used in the flight software.

European Space Agency (ESA)↗
NASA NTRS2017

Key Differences in Operating a Rover on the Moon vs. Mars

The command and control model for spacecraft operations, as well as the distribution of tasks between ground assets and in space assets, whether with a crew or solely robotic, is fundamentally constrained by the round trip light time between the space asset and the control facility (presumably on Earth, though not required). For an asset on Mars, the round trip light time varies, from roughly fourteen minutes to up to forty minutes. For a Lunar asset the round-trip light time is measured in only a few seconds, but current communications systems may more than double the latency with system overhead. For a Lunar Asset the total command latency may range from six seconds to more than forty, depending on communications overhead and data rates. Further, these variables are not always predictable, thus complicating operations. There are several differentiating factors for Lunar vs. Mars operations, Round trip light time/Atmosphere/Lighting and ShadowsTerrain type and knowledge/Round trip light time has implications for the distribution of tasks between ground and in space assets. Even at Lunar Distances, the combination of round trip light time plus communications systems overhead does not enable joy stick driving of a rover. The best that can be done, if driving from Earth, is near real time command and control. By 2030, driving from in space may be possible. Productivity on Mars requires either long operational sequences of commands, as is done for current rovers such as Curiosity, significant autonomous capability or, as may be possible by 2030, command and control support from space. Another implication of the long round trip light time from Earth to Mars, is that flight software functions must be resident on the in space asset. On the Moon, there is considerably more flexibility, enabling processing functions, to be resident on Earth or in space. This provides the opportunity to take advantage of the considerable processing power available on the ground, but may be constrained by data rates. On the Moon, for practical operational purposes, there is no atmosphere. Hence there is no scattering of light in the shadows. This has implications for image interpretation and driving near the poles. The Moon has permanently shadowed regions (PSR), unique terrain with unknown surface properties. With no scattering of light in shadows, driving on the Moon, particularly at the poles, where we have strong evidence of water, may prove to be hazardous and complex, requiring non-optical sensors, such as LIDAR.

Trimble, Jay↗
NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗
NASA NTRS1973

GOAL-to-HAL translation study

This report deals with the feasibility, problems, solutions, and mapping of a GOAL language to HAL language translator. Ground Operations Aerospace Language, or GOAL, is a test-oriented higher order language developed by the John F. Kennedy Space Center to be used in checkout and launch of the space shuttle. HAL is a structured higher order language developed by the Johnson Space Center to be used in writing the flight software for the onboard shuttle computers. Since the onboard computers will extensively support ground checkout of the space shuttle, and since these computers and the software development facilities on the ground use the HAL language as baseline, the translation of GOAL to HAL becomes significant. The issue of feasibility was examined and it was found that a GOAL to HAL translator is feasible. Special problems are identified and solutions proposed. Finally, examples of translation are provided for each category of complete GOAL statement.

Flanders, J. H.↗
NASA NTRS1992

Data collection procedures for the Software Engineering Laboratory (SEL) database

This document is a guidebook to collecting software engineering data on software development and maintenance efforts, as practiced in the Software Engineering Laboratory (SEL). It supersedes the document entitled Data Collection Procedures for the Rehosted SEL Database, number SEL-87-008 in the SEL series, which was published in October 1987. It presents procedures to be followed on software development and maintenance projects in the Flight Dynamics Division (FDD) of Goddard Space Flight Center (GSFC) for collecting data in support of SEL software engineering research activities. These procedures include detailed instructions for the completion and submission of SEL data collection forms.

Heller, Gerard↗
NASA NTRS2004

A Preliminary ZEUS Lightning Location Error Analysis Using a Modified Retrieval Theory

The ZEUS long-range VLF arrival time difference lightning detection network now covers both Europe and Africa, and there are plans for further expansion into the western hemisphere. In order to fully optimize and assess ZEUS lightning location retrieval errors and to determine the best placement of future receivers expected to be added to the network, a software package is being developed jointly between the NASA Marshall Space Flight Center (MSFC) and the University of Nevada Las Vegas (UNLV). The software package, called the ZEUS Error Analysis for Lightning (ZEAL), will be used to obtain global scale lightning location retrieval error maps using both a Monte Carlo approach and chi-squared curvature matrix theory. At the core of ZEAL will be an implementation of an Iterative Oblate (IO) lightning location retrieval method recently developed at MSFC. The IO method will be appropriately modified to account for variable wave propagation speed, and the new retrieval results will be compared with the current ZEUS retrieval algorithm to assess potential improvements. In this preliminary ZEAL work effort, we defined 5000 source locations evenly distributed across the Earth. We then used the existing (as well as potential future ZEUS sites) to simulate arrival time data between source and ZEUS site. A total of 100 sources were considered at each of the 5000 locations, and timing errors were selected from a normal distribution having a mean of 0 seconds and a standard deviation of 20 microseconds. This simulated "noisy" dataset was analyzed using the IO algorithm to estimate source locations. The exact locations were compared with the retrieved locations, and the results are summarized via several color-coded "error maps."

Elander, Valjean↗
NASA NTRS1994

Software Process Assessment (SPA)

NASA's environment mirrors the changes taking place in the nation at large, i.e. workers are being asked to do more work with fewer resources. For software developers at NASA's Goddard Space Flight Center (GSFC), the effects of this change are that we must continue to produce quality code that is maintainable and reusable, but we must learn to produce it more efficiently and less expensively. To accomplish this goal, the Data Systems Technology Division (DSTD) at GSFC is trying a variety of both proven and state-of-the-art techniques for software development (e.g., object-oriented design, prototyping, designing for reuse, etc.). In order to evaluate the effectiveness of these techniques, the Software Process Assessment (SPA) program was initiated. SPA was begun under the assumption that the effects of different software development processes, techniques, and tools, on the resulting product must be evaluated in an objective manner in order to assess any benefits that may have accrued. SPA involves the collection and analysis of software product and process data. These data include metrics such as effort, code changes, size, complexity, and code readability. This paper describes the SPA data collection and analysis methodology and presents examples of benefits realized thus far by DSTD's software developers and managers.

Rosenberg, Linda H.↗
NASA NTRS2005

VERSE - Virtual Equivalent Real-time Simulation

Distributed real-time simulations provide important timing validation and hardware in the- loop results for the spacecraft flight software development cycle. Occasionally, the need for higher fidelity modeling and more comprehensive debugging capabilities - combined with a limited amount of computational resources - calls for a non real-time simulation environment that mimics the real-time environment. By creating a non real-time environment that accommodates simulations and flight software designed for a multi-CPU real-time system, we can save development time, cut mission costs, and reduce the likelihood of errors. This paper presents such a solution: Virtual Equivalent Real-time Simulation Environment (VERSE). VERSE turns the real-time operating system RTAI (Real-time Application Interface) into an event driven simulator that runs in virtual real time. Designed to keep the original RTAI architecture as intact as possible, and therefore inheriting RTAI's many capabilities, VERSE was implemented with remarkably little change to the RTAI source code. This small footprint together with use of the same API allows users to easily run the same application in both real-time and virtual time environments. VERSE has been used to build a workstation testbed for NASA's Space Interferometry Mission (SIM PlanetQuest) instrument flight software. With its flexible simulation controls and inexpensive setup and replication costs, VERSE will become an invaluable tool in future mission development.

virtual real time↗
NASA NTRS2015

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗
NASA NTRS1985

Measuring the impact of computer resource quality on the software development process and product

The availability and quality of computer resources during the software development process was speculated to have measurable, significant impact on the efficiency of the development process and the quality of the resulting product. Environment components such as the types of tools, machine responsiveness, and quantity of direct access storage may play a major role in the effort to produce the product and in its subsequent quality as measured by factors such as reliability and ease of maintenance. During the past six years, the NASA Goddard Space Flight Center has conducted experiments with software projects in an attempt to better understand the impact of software development methodologies, environments, and general technologies on the software process and product. Data was extracted and examined from nearly 50 software development projects. All were related to support of satellite flight dynamics ground-based computations. The relationship between computer resources and the software development process and product as exemplified by the subject NASA data was examined. Based upon the results, a number of computer resource-related implications are provided.

Mcgarry, Frank↗
NASA NTRS2003

The VISAR Process

The Video Image Stabilization And Registration (VISAR) process is an award winning video image processing software developed at NASA's Marshall Space Flight Center. VISAR has a wide variety of application areas where the refinement of digital video is needed. It is used to correct jitter, rotation, and zoom effects by registering and processing on individual image captures that are a part of normal video capturing. Its most prominent uses were the 1996 Olympic Bombing case and in identifying Saddam Hussein during the Iraq war. Based on first-hand knowledge, this paper describes the VISAR process, which consists of several steps designed to refine digital video using VISAR software. The process determines the differences between two video images so that one, or both, of the images can be changed in ways that make them match as well as possible. Corrections include changes in position (horizontal and vertical image shifts), changes in orientation (image rotation), and changes in magnification (image zoom). While much of the VISAR process is automated, in its current embodiment it requires the user to initially identify the area of interest and to reset a threshold parameter if the default gives unacceptable results. The basic process that is used is an old tried and true method that determines how well the two images match. This process is called cross-correlation. It gives a single number, the correlation coefficient, that is equal to 1.0 if the images are perfectly matched, is equal to 0.0 if the images have nothing in common, and is equal to -1.0 if one image is the negative of the other. This basic process is used by many image stabilization methods. With VISAR we use it in a manner that provides statistical information needed to best determine orientation and magnification.

Hathaway, David↗
NASA NTRS1986

Towards a general object-oriented software development methodology

An object is an abstract software model of a problem domain entity. Objects are packages of both data and operations of that data (Goldberg 83, Booch 83). The Ada (tm) package construct is representative of this general notion of an object. Object-oriented design is the technique of using objects as the basic unit of modularity in systems design. The Software Engineering Laboratory at the Goddard Space Flight Center is currently involved in a pilot program to develop a flight dynamics simulator in Ada (approximately 40,000 statements) using object-oriented methods. Several authors have applied object-oriented concepts to Ada (e.g., Booch 83, Cherry 85). It was found that these methodologies are limited. As a result a more general approach was synthesized with allows a designer to apply powerful object-oriented principles to a wide range of applications and at all stages of design. An overview is provided of this approach. Further, how object-oriented design fits into the overall software life-cycle is considered.

Seidewitz, ED↗
NASA NTRS1994

Building an experience factory for maintenance

This paper reports the preliminary results of a study of the software maintenance process in the Flight Dynamics Division (FDD) of the National Aeronautics and Space Administration/Goddard Space Flight Center (NASA/GSFC). This study is being conducted by the Software Engineering Laboratory (SEL), a research organization sponsored by the Software Engineering Branch of the FDD, which investigates the effectiveness of software engineering technologies when applied to the development of applications software. This software maintenance study began in October 1993 and is being conducted using the Quality Improvement Paradigm (QIP), a process improvement strategy based on three iterative steps: understanding, assessing, and packaging. The preliminary results represent the outcome of the understanding phase, during which SEL researchers characterized the maintenance environment, product, and process. Findings indicate that a combination of quantitative and qualitative analysis is effective for studying the software maintenance process, that additional measures should be collected for maintenance (as opposed to new development), and that characteristics such as effort, error rate, and productivity are best considered on a 'release' basis rather than on a project basis. The research thus far has documented some basic differences between new development and software maintenance. It lays the foundation for further application of the QIP to investigate means of improving the maintenance process and product in the FDD.

Valett, Jon D.↗
NASA NTRS2010

GSFC Technology Thrusts and Partnership Opportunities

This slide presentation reviews the technology thrusts and the opportunities to partner in developing software in support of the technological advances at the Goddard Space Flight Center (GSFC). There are thrusts in development of end-to-end software systems for mission data systems in areas of flight software, ground data systems, flight dynamic systems and science data systems. The required technical expertise is reviewed, and the supported missions are shown for the various areas given.

Le Moigne, Jacqueline↗
NASA NTRS1989

ASTEC: Controls analysis for personal computers

The ASTEC (Analysis and Simulation Tools for Engineering Controls) software is under development at Goddard Space Flight Center (GSFC). The design goal is to provide a wide selection of controls analysis tools at the personal computer level, as well as the capability to upload compute-intensive jobs to a mainframe or supercomputer. The project is a follow-on to the INCA (INteractive Controls Analysis) program that has been developed at GSFC over the past five years. While ASTEC makes use of the algorithms and expertise developed for the INCA program, the user interface was redesigned to take advantage of the capabilities of the personal computer. The design philosophy and the current capabilities of the ASTEC software are described.

Downing, John P.↗