Experiences in adopting real-time Java for flight-like software
This work involves developing representative mission-critical spacecraft software using the Real-Time Specification for Java.
Java flight software design patterns real-time Jav↗
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.
Operational concepts for selected Sortie missions: Executive summary
An executive summary is presented of a Spacelab concept study conducted from August 1973 to June 1974. Background information and a summary of study conclusions are given. Specific data are reported for the quick-reaction carrier concept, software and mission integration, configuration management, documentation, equipment pool, and integration alternatives. A forecast of the impact of a second launch site, mission feasibility, and space availability for the Spacelab are also discussed.
Dulock, V. A., Jr.↗
Automated Code Standard Checker 2002
Coding standards are typically levied on flight software in order to help ensure that the code is testable, maintainable, and modifiable. Visually checking software source against a set of coding standards is time consuming and may be prone to error. Software inspection is typically costly and may require large amounts of highly skilled labor. The objective of this center initiative is to develop an automated method to ensure that mission critical software follows the required coding practices and standards.
Trevino, Luis↗
Resource Prospector Instrumentation for Lunar Volatiles Prospecting, Sample Acquisition and Processing
Data gathered from lunar missions within the last two decades have significantly enhanced our understanding of the volatile resources available on the lunar surface, specifically focusing on the polar regions. Several orbiting missions such as Clementine and Lunar Prospector have suggested the presence of volatile ices and enhanced hydrogen concentrations in the permanently shadowed regions of the moon. The Lunar Crater Observation and Sensing Satellite (LCROSS) mission was the first to provide direct measurement of water ice in a permanently shadowed region. These missions with other orbiting assets have laid the groundwork for the next step in the exploration of the lunar surface; providing ground truth data of the volatiles by mapping the distribution and processing lunar regolith for resource extraction. This next step is the robotic mission Resource Prospector (RP). Resource Prospector is a lunar mission to investigate 'strategic knowledge gaps' (SKGs) for in-situ resource utilization (ISRU). The mission is proposed to land in the lunar south pole near a permanently shadowed crater. The landing site will be determined by the science team with input from broader international community as being near traversable landscape that has a high potential of containing elevated concentrations of volatiles such as water while maximizing mission duration. A rover will host the Regolith & Environment Science and Oxygen & Lunar Volatile Extraction (RESOLVE) payload for resource mapping and processing. The science instruments on the payload include a 1-meter drill, neutron spectrometer, a near infrared spectrometer, an operations camera, and a reactor with a gas chromatograph-mass spectrometer for volatile analysis. After the RP lander safely delivers the rover to the lunar surface, the science team will guide the rover team on the first traverse plan. The neutron spectrometer (NS) and near infrared (NIR) spectrometer instruments will be used as prospecting tools to guide the traverse path. The NS will map the water-equivalent hydrogen concentration as low as 0.5% by weight to an 80 centimeter depth as the rover traverses the lunar landscape. The NIR spectrometer will measure surficial H2O/OH as well as general mineralogy. When the prospecting instruments identify a potential volatile-rich area during the course of a traverse, the prospect is then mapped out and the most promising location identified. An augering drill capable of sampling to a depth of 100 centimeters will excavate regolith for analysis. A quick assay of the drill cuttings will be made using an operations camera and NIR spectrometer. With the water depth confirmed by this first auguring activity, a regolith sample may be extracted for processing. The drill will deliver the regolith sample to a crucible that will be sealed and heated. Evolved volatiles will be measured by a gas chromatograph-mass spectrometer and the water will be captured and photographed. RP is a solar powered mission, which given the polar location translates to a relatively short mission duration on the order of 4-15 days. This short mission duration drives the concept of operations, instrumentation, and data analysis towards critical real time analysis and decision support. Previous payload field tests have increased the fidelity of the hardware, software, and mission operations. Current activities include a mission level field test to optimize interfaces between the payload and rover as well as better understand the interaction of the science and rover teams during the mission timeline. This paper will include the current status of the science instruments on the payload as well as the integrated field test occurring in fall of 2015. The concept of operations will be discussed, including the real time science and engineering decision-making process based on the critical data from the instrumentation. The path to flight will be discussed with the approach to this ambitious low cost mission.
ISRU↗
Enabling a Voice Management System for Space Applications
The sustainable missions beyond Low Earth Orbit (LEO) envisioned for NASA’s Artemis program will require autonomous capabilities. Moreover, Artemis mission crews will need a means to efficiently interact with a spacecraft’s autonomous systems. This interaction can be facilitated by voice and speech communications because voice-based controls enable users to interact hands- and eyes-free, allowing the user to better focus on critical tasks. The goal of our project was to explore the knowledge and technology needed to successfully design effective Voice User Interfaces (VUIs) for autonomous systems utilizing Human Centered Design (HCD) principles. The focus of the human factors’ aspect of engineering, pays close attention to psychological and physiological principles in the development of autonomous crew operation systems. A main objective was to understand how a crew member, through voice interaction, could efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project was a part of the NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The work from the BLiSS Team, at the University of Michigan, resulted in the design of a system persona, Diego, to which an astronaut may quickly build trust with autonomous systems, to alleviate known stressors on mental health expected during long duration space missions. Optimal software to facilitate integration of the system persona into a reference Lunar orbiting Gateway station was defined. Additionally, a Speech to Text (STT) system and a Graphical User Interface (GUI) that could be implemented in future missions was developed on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2020 project leveraged previous technology developed by the BLiSS team to incorporate a voice-based interface into NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the spacecraft background noise environment was assessed, a noise mitigation technique was developed, and a relatable personality for the autonomous system was developed in order to facilitate human-like conversations. The success of our effort was largely due to the diversity of the team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The diverse perspectives fostered elaborate discussions, resulting in the conception of three main subsystems: (1) User-System, (2) NPAS-System, and (3) Environment-System. The VUI was unique and had to be efficient and intuitive. For this project, 5 subteams were formed, each with a separate objective, Voice Design team, Background Noise Mitigation team, Software Integration team and Graphical User Interface team. The BLiSS team crafted a personality for the VUI to enable human-like conversation and drive user adoption and trust. User surveys were completed and used to help determine the required VUI system personality traits by capturing perspectives and expectations of prospective “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS platform for quick and reliable information transfer. The outcomes of our research were: (1) a working prototype user interface, that is compatible with NASA’s NPAS platform; (2) software that demonstrates the ability of the VUI system to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate in a noisy environment. Our research has laid the foundation for the development of VUI’s for autonomy, and provides a baseline for future VUI developments.
Voice user interface↗
Survey of Software Assurance Techniques for Highly Reliable Systems
This document provides a survey of software assurance techniques for highly reliable systems including a discussion of relevant safety standards for various industries in the United States and Europe, as well as examples of methods used during software development projects. It contains one section for each industry surveyed: Aerospace, Defense, Nuclear Power, Medical Devices and Transportation. Each section provides an overview of applicable standards and examples of a mission or software development project, software assurance techniques used and reliability achieved.
Nelson, Stacy↗
Software Construction and Analysis Tools for Future Space Missions
NASA and its international partners will increasingly depend on software-based systems to implement advanced functions for future space missions, such as Martian rovers that autonomously navigate long distances exploring geographic features formed by surface water early in the planet's history. The software-based functions for these missions will need to be robust and highly reliable, raising significant challenges in the context of recent Mars mission failures attributed to software faults. After reviewing these challenges, this paper describes tools that have been developed at NASA Ames that could contribute to meeting these challenges; 1) Program synthesis tools based on automated inference that generate documentation for manual review and annotations for automated certification. 2) Model-checking tools for concurrent object-oriented software that achieve memorability through synergy with program abstraction and static analysis tools.
Lowry, Michael R.↗
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↗
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.↗
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↗
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↗
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.↗
Trajectory Design Software for Low-Cost Planetary Mission Feasibility Studies
Explore the source record for details and available documents.
Trajectory Design Software Cost↗
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.↗
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.↗
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.↗
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↗
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↗