Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission 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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Advanced Reference Counting Pointers for Better Performance

A computer program implements reference counting pointers (RCPs) that are lock-free, thread-safe, async-safe, and operational on a multiprocessor computer. RCPs are powerful and convenient means of managing heap memory in C++ software. Most prior RCP programs use locks to ensure thread safety and manage concurrency. The present program was developed in a continuing effort to explore ways of using the C++ programming language to develop safety-critical and mission- critical software. This effort includes exploration of lock-free algorithms because they offer potential to avoid some costly and difficult verification problems. Unlike previously published RCP software, the present program does not use locks (meaning that no thread can block progress on another thread): Instead, this program implements algorithms that exploit capabilities of central-processing- unit hardware so as to avoid locks. Once locks are eliminated, it becomes possible to realize the other attributes mentioned in the first sentence. In addition to the abovementioned attributes, this program offers several advantages over other RCP programs that use locks: It is smaller (and, hence, is faster and uses less memory), it is immune to priority inversion, and there is no way for it to cause a C++ exception.

Reinholtz, William↗
NASA NTRS2002

Optimization Shield Materials Trade Study for Lunar/Gateway Mission

The great cost of added radiation shielding is a potential limiting factor in many deep space missions. For this enabling technology, we are developing tools for optimized shield design over multi-segmented missions involving multiple work and living areas in the transport and duty phase of various space missions. The total shield mass over all pieces of equipment and habitats is optimized subject to career dose and dose rate constraints. Preliminary studies of deep space missions indicate that for long duration space missions, improved shield materials will be required. The details of this new method and its impact on space missions and other technologies will be discussed. This study will provide a vital tool for evaluating Gateway designs in their usage context. Providing protection against the hazards of space radiation is one of the challenges to the Gateway infrastructure designs. We will use the mission optimization software to scope the impact of Gateway operations on human exposures and the effectiveness of alternate shielding materials on Gateway infrastructure designs. It is being proposed to use Moon and the Lagrange points as the hub for deep space missions. This study will provide a guide to the effectiveness of multifunctional materials in preparation to more detailed geometry studies in progress.

Tripathi, R. K.↗
NASA NTRS2022

VIPRE: A Tool Aiding the Design for Entry Probe Missions

Exploring planetary atmospheres uncovers important information for how our solar system formed and evolved. While remote sensing is extensively used, some crucial observations require in-situ measurements by an atmospheric probe. Given their scientific importance, probe missions to Saturn, Uranus and Neptune are considered for the coming decades. In anticipation of future probe missions, the software tool VIPRE was developed as proof-of-concept to facilitate selection of probe entry locations. Currently, there is no analytical way to identify which interplanetary trajectory from thousands of feasible launch opportunities is optimal for a considered mission concept. The search and decision process for that solution is complex and relies on the intuition of mission designers, who focus on a subset of trajectories to make the trade space manageable. The idea of VIPRE is to (1) generate a multi-dimensional data cube showing relevant engineering and science parameters simultaneously for thousands of trajectories, and (2) visualize the data for all entry sites over the body's envelope. VIPRE lays the foundation to make the data available for browsing in a 3-D visualization to identify the best family of solutions for a given mission. The paper introduces the validated and verified core algorithms of VIPRE, published on GitHub. VIPRE serves as a basic framework to be used and extended for different purposes. The paper presents the motivation for the development and algorithms. It explains the computation and data visualization strategy, and gives a list of suggested functionalities to extend and further develop VIPRE to fully leverage its potential.

Ice Giants↗
NASA NTRS2011

Global Precipitation Mission Visualization Tool

The Global Precipitation Mission (GPM) software provides graphic visualization tools that enable easy comparison of ground- and space-based radar observations. It was initially designed to compare ground radar reflectivity from operational, ground-based, S- and C-band meteorological radars with comparable measurements from the Tropical Rainfall Measuring Mission (TRMM) satellite's precipitation radar instrument. This design is also applicable to other groundbased and space-based radars, and allows both ground- and space-based radar data to be compared for validation purposes. The tool creates an operational system that routinely performs several steps. It ingests satellite radar data (precipitation radar data from TRMM) and groundbased meteorological radar data from a number of sources. Principally, the ground radar data comes from national networks of weather radars (see figure). The data ingested by the visualization tool must conform to the data formats used in GPM Validation Network Geometry-matched data product generation. The software also performs match-ups of the radar volume data for the ground- and space-based data, as well as statistical and graphical analysis (including two-dimensional graphical displays) on the match-up data. The visualization tool software is written in IDL, and can be operated either in the IDL development environment or as a stand-alone executable function.

Schwaller, Mathew↗
NASA NTRS1994

Taking advantage of ground data systems attributes to achieve quality results in testing software

During the software development life cycle process, basic testing starts with the development team. At the end of the development process, an acceptance test is performed for the user to ensure that the deliverable is acceptable. Ideally, the delivery is an operational product with zero defects. However, the goal of zero defects is normally not achieved but is successful to various degrees. With the emphasis on building low cost ground support systems while maintaining a quality product, a key element in the test process is simulator capability. This paper reviews the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) test tool that is used in the acceptance test process for unmanned satellite operations control centers. The TASS is designed to support the development, test and operational environments of the Goddard Space Flight Center (GSFC) operations control centers. The TASS uses the same basic architecture as the operations control center. This architecture is characterized by its use of distributed processing, industry standards, commercial off-the-shelf (COTS) hardware and software components, and reusable software. The TASS uses much of the same TPOCC architecture and reusable software that the operations control center developer uses. The TASS also makes use of reusable simulator software in the mission specific versions of the TASS. Very little new software needs to be developed, mainly mission specific telemetry communication and command processing software. By taking advantage of the ground data system attributes, successful software reuse for operational systems provides the opportunity to extend the reuse concept into the test area. Consistency in test approach is a major step in achieving quality results.

Sigman, Clayton B.↗
NASA NTRS1999

Spacecraft Software Maintenance: An Effective Approach to Reducing Costs and Increasing Science Return

Flight software is a mission critical element of spacecraft functionality and performance. When ground operations personnel interface to a spacecraft, they are typically dealing almost entirely with the capabilities of onboard software. This software, even more than critical ground/flight communications systems, is expected to perform perfectly during all phases of spacecraft life. Due to the fact that it can be reprogrammed on-orbit to accommodate degradations or failures in flight hardware, new insights into spacecraft characteristics, new control options which permit enhanced science options, etc., the on- orbit flight software maintenance team is usually significantly responsible for the long term success of a science mission. Failure of flight software to perform as needed can result in very expensive operations work-around costs and lost science opportunities. There are three basic approaches to maintaining spacecraft software--namely using the original developers, using the mission operations personnel, or assembling a center of excellence for multi-spacecraft software maintenance. Not planning properly for flight software maintenance can lead to unnecessarily high on-orbit costs and/or unacceptably long delays, or errors, in patch installations. A common approach for flight software maintenance is to access the original development staff. The argument for utilizing the development staff is that the people who developed the software will be the best people to modify the software on-orbit. However, it can quickly becomes a challenge to obtain the services of these key people. They may no longer be available to the organization. They may have a more urgent job to perform, quite likely on another project under different project management. If they havn't worked on the software for a long time, they may need precious time for refamiliarization to the software, testbeds and tools. Further, a lack of insight into issues related to flight software in its on-orbit environment, may find the developer unprepared for the challenges. The second approach is to train a member of the flight operations team to maintain the spacecraft software. This can prove to be a costly and inflexible solution. The person assigned to this duty may not have enough work to do during a problem free period and may have too much to do when a problem arises. If the person is a talented software engineer, he/she may not enjoy the limited software opportunities available in this position; and may eventually leave for newer technology computer science opportunities. Training replacement flight software personnel can be a difficult and lengthy process. The third approach is to assemble a center of excellence for on-orbit spacecraft software maintenance. Personnel in this specialty center can be managed to support flight software of multiple missions at once. The variety of challenges among a set of on-orbit missions, can result in a dedicated, talented staff which is fully trained and available to support each mission's needs. Such staff are not software developers but are rather spacecraft software systems engineers. The cost to any one mission is extremely low because the software staff works and charges, minimally on missions with no current operations issues; and their professional insight into on-orbit software troubleshooting and maintenance methods ensures low risk, effective and minimal-cost solutions to on-orbit issues.

Shell, Elaine M.↗
NASA NTRS2004

OTIS 3.2 Software Released

Trajectory, mission, and vehicle engineers concern themselves with finding the best way for an object to get from one place to another. These engineers rely upon special software to assist them in this. For a number of years, many engineers have used the OTIS program for this assistance. With OTIS, an engineer can fully optimize trajectories for airplanes, launch vehicles like the space shuttle, interplanetary spacecraft, and orbital transfer vehicles. OTIS provides four modes of operation, with each mode providing successively stronger optimization capability. The most powerful mode uses a mathematical method called implicit integration to solve what engineers and mathematicians call the optimal control problem. OTIS 3.2, which was developed at the NASA Glenn Research Center, is the latest release of this industry workhorse and features new capabilities for parameter optimization and mission design. OTIS stands for Optimal Control by Implicit Simulation, and it is implicit integration that makes OTIS so powerful at solving trajectory optimization problems. Why is this so important? The optimization process not only determines how to get from point A to point B, but it can also determine how to do this with the least amount of propellant, with the lightest starting weight, or in the fastest time possible while avoiding certain obstacles along the way. There are numerous conditions that engineers can use to define optimal, or best. OTIS provides a framework for defining the starting and ending points of the trajectory (point A and point B), the constraints on the trajectory (requirements like "avoid these regions where obstacles occur"), and what is being optimized (e.g., minimize propellant). The implicit integration method can find solutions to very complicated problems when there is not a lot of information available about what the optimal trajectory might be. The method was first developed for solving two-point boundary value problems and was adapted for use in OTIS. Implicit integration usually allows OTIS to find solutions to problems much faster than programs that use explicit integration and parametric methods. Consequently, OTIS is best suited to solving very complicated and highly constrained problems.

Riehl, John P.↗
NASA NTRS2016

Extended Bright Bodies - Flight and Ground Software Challenges on the Cassini Mission at Saturn

Extended bright bodies in the Saturn environment such as Saturn's rings, the planet itself, and Saturn's satellites near the Cassini spacecraft may interfere with the star tracker's ability to find stars. These interferences can create faulty spacecraft attitude knowledge, which would decrease the pointing accuracy or even trip a fault protection response on board the spacecraft. The effects of the extended bright body interference were observed in December of 2000 when Cassini flew by Jupiter. Based on this flight experience and expected star tracker behavior at Saturn, the Cassini AACS operations team defined flight rules to suspend the star tracker during predicted interference windows. The flight rules are also implemented in the existing ground software called Kinematic Predictor Tool to create star identification suspend commands to be uplinked to the spacecraft for future predicted interferences. This paper discusses the details of how extended bright bodies impact Cassini's acquisition of attitude knowledge, how the observed data helped the ground engineers in developing flight rules, and how automated methods are used in the flight and ground software to ensure the spacecraft is continuously operated within these flight rules. This paper also discusses how these established procedures will continue to be used to overcome new bright body challenges that Cassini will encounter during its dips inside the rings of Saturn for its final orbits of a remarkable 20-year mission at Saturn.

Sung, Tina S.↗
NASA NTRS2003

Developing Generic Software for Spacecraft Avionics

A proposed approach to the development of software for spacecraft avionics is based partly on a concept of generic software that could be tailored to satisfy requirements for specific missions. The proposed approach would stand in contrast to the conventional approach of first defining avionics requirements for a specific mission, then developing software specific to those requirements. The proposed approach might also be adaptable to programming computers that control and monitor other complex equipment systems that range in scale from automobiles to factories. The concept of a spacecraft avionics functional model (SAFM) is a major element of the proposed approach. An SAFM would be, essentially, a systematic and hierarchical description of the functionality required of the avionics software (and hardware) for a given mission. Although the initial input information used to start the construction of an SAFM would typically amount to a high-level description, the SAFM would thereafter be decomposed to a low level. The resulting low-level version of the model would be used to develop a set of generic requirements that could be expected to include a large fraction of all requirements for a large fraction of all missions. The generic requirements would be used to develop software modules that could be included in, or excluded from, the final flight software to satisfy the requirements of a specific mission.

Smith, Joseph↗
NASA NTRS2018

Software System for the Mars 2020 Mission Sampling and Caching Testbeds

The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.

Vieira, Peter↗
NASA NTRS2009

Flashline Mars Arctic Research Station (FMARS) 2009 Expedition Crew Perspectives

The Flashline Mars Arctic Research Station (FMARS), located on the rim of the Haughton Crater on Devon Island in the Canadian Arctic, is a simulated Mars habitat that provides operational constraints similar to those which will be faced by future human explorers on Mars. In July 2009, a six-member crew inhabited the isolated habitation module and conducted the twelfth FMARS mission. The crew members conducted frequent EVA operations wearing mock space suits to conduct field experiments under realistic Mars-like conditions. Their scientific campaign spanned a wide range of disciplines and included many firsts for Mars analog research. Among these are the first use of a Class IV medical laser during a Mars simulation, helping to relieve crew stress injuries during the mission. Also employed for the first time in a Mars simulation at FMARS, a UAV (Unmanned Aerial Vehicle) was used by the space-suited explorers, aiding them in their search for mineral resources. Sites identified by the UAV were then visited by geologists who conducted physical geologic sampling. For the first time, explorers in spacesuits deployed passive seismic equipment to monitor earthquake activity and characterize the planet's interior. They also conducted the first geophysical electromagnetic survey as analog Mars pioneers to search for water and characterize geological features under the surface. The crew collected hydrated minerals and attempted to produce drinkable water from the rocks. A variety of equipment was field tested as well, including new cameras that automatically geotag photos, data-recording GPS units, a tele-presence rover (operated from Florida), as well as MIT-developed mission planning software. As plans develop to return to the Moon and go on to Mars, analog facilities like FMARS can provide significant benefit to NASA and other organizations as they prepare for robust human space exploration. The authors will present preliminary results from these studies as well as their perspectives on topics including human factors, logistics, EVA operations, and the use of social media throughout the mission.

Cusack, Stacy↗
NASA NTRS2016

Station Program Note Pull Automation

Upon commencement of my internship, I was in charge of maintaining the CoFR (Certificate of Flight Readiness) Tool. The tool acquires data from existing Excel workbooks on NASA's and Boeing's databases to create a new spreadsheet listing out all the potential safety concerns for upcoming flights and software transitions. Since the application was written in Visual Basic, I had to learn a new programming language and prepare to handle any malfunctions within the program. Shortly afterwards, I was given the assignment to automate the Station Program Note (SPN) Pull process. I developed an application, in Python, that generated a GUI (Graphical User Interface) that will be used by the International Space Station Safety & Mission Assurance team here at Johnson Space Center. The application will allow its users to download online files with the click of a button, import SPN's based on three different pulls, instantly manipulate and filter spreadsheets, and compare the three sources to determine which active SPN's (Station Program Notes) must be reviewed for any upcoming flights, missions, and/or software transitions. Initially, to perform the NASA SPN pull (one of three), I had created the program to allow the user to login to a secure webpage that stores data, input specific parameters, and retrieve the desired SPN's based on their inputs. However, to avoid any conflicts with sustainment, I altered it so that the user may login and download the NASA file independently. After the user has downloaded the file with the click of a button, I defined the program to check for any outdated or pre-existing files, for successful downloads, to acquire the spreadsheet, convert it from a text file to a comma separated file and finally into an Excel spreadsheet to be filtered and later scrutinized for specific SPN numbers. Once this file has been automatically manipulated to provide only the SPN numbers that are desired, they are stored in a global variable, shown on the GUI, and transferred over to a new Excel worksheet for comparison. I managed to get my application to acquire the CSWG (Computer Safety Working Group) and the SPNWG (Space Station Working Group) SPN's with just two mouse clicks for each pull, as opposed to several from the original process. When all three pulls are performed, an Excel sheet containing all three different results will be generated for the user to compare and determine which SPN's will be presented or reviewed the following month. The experience from this internship has been spectacular. As a high school senior who will begin attending college in the fall, this internship has been both educationally and occupationally beneficial. The internship has allowed me the opportunities to learn new programming languages, effectively network with NASA personnel from a variety of departments at JSC, and allowed me to learn new professional skills and etiquette. My internship at NASA's Johnson Space Center has further motivated me to pursue a Master's degree in Software Engineering and strive for a prosperous career with NASA as a civil servant.

Delgado, Ivan↗
NASA NTRS2006

Spitzer Space Telescope Sequencing Operations Software, Strategies, and Lessons Learned

The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.

missions operations↗
NASA NTRS1988

Ion propulsion system design and throttling strategies for planetary missions

This paper describes recent advances in ion propulsion system design which promise to increase the propulsion system reliability by reducing the overall system complexity. The greatest simplification in the overall propulsion system operation is accomplished through a change in the ion engine throttling strategy. By using three grid optics it is possible to effect engine throttling at a constant beam curent over at least a 3.8 to 1 variation in input power. Throttling at a constant beam current results in a single discharge chamber operating point and eliminates the need for active propellant flow controllers and complex engine throttling software. Detailed mission analysis calculations for a CNSR mission performed using this constant beam current throttling strategy indicate only a small reduction in delivered payload and increase in required propellant relative to a conventional throttling profile based on varying the beam curent.

Garner, Charles E.↗
NASA NTRS2018

An Open Avionics and Software Architecture to Support Future NASA Exploration Missions

Final Document is attached. The presentation describes an avionics and software architecture that has been developed through NASAs Advanced Exploration Systems (AES) division. The architecture is open-source, highly reliable with fault tolerance, and utilizes standard capabilities and interfaces, which are scalable and customizable to support future exploration missions. Specific focus areas of discussion will include command and data handling, software, human interfaces, communication and wireless systems, and systems engineering and integration. Final Paper, not the Abstract, is attached.

Avionics↗
NASA NTRS1991

Issues associated with establishing control zones for international space operations

Cooperative missions in Earth orbit can be facilitated by developing a strategy to regulate the manner in which vehicles interact in orbit. One means of implementing such a strategy is to utilize a control zones technique that assigns different types of orbital operations to specific regions of space surrounding a vehicle. Considered here are issues associated with developing a control zones technique to regulate the interactions of spacecraft in proximity to a manned vehicle. Technical and planning issues, flight hardware and software issues, mission management parameter, and other constraints are discussed. Also covered are manned and unmanned vehicle operations, and manual versus automated flight control. A review of the strategies utilized by the Apollo Soyuz Test Project and the Space Station Freedom Program is also presented.

Nader, Blair A.↗
NASA NTRS1992

Issues in developing control zones for international space operations

Cooperative missions in earth orbit can be facilitated by developing a strategy to regulate the manner in which vehicles interact in orbit. One means of implementing such a strategy is to utilize a control zones technique that assigns different types of orbital operations to specific regions of space surrounding a vehicle. Considered here are issues associated with developing a control zones technique to regulate the interactions of spacecraft in proximity to a manned vehicle. Technical and planning issues, flight hardware and software issues, mission management parameter, and other constraints are discussed. Also covered are manned and unmanned vehicle operations, and manual versus automated flight control. A review of the strategies utilized by the Apollo Soyuz Test Project and the Space Station Freedom Program is also presented.

Nader, Blair A.↗