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 739 records · Page 41

Libration Orbit Mission Design: Applications of Numerical & Dynamical Methods

Sun-Earth libration point orbits serve as excellent locations for scientific investigations. These orbits are often selected to minimize environmental disturbances and maximize observing efficiency. Trajectory design in support of libration orbits is ever more challenging as more complex missions are envisioned in the next decade. Trajectory design software must be further enabled to incorporate better understanding of the libration orbit solution space and thus improve the efficiency and expand the capabilities of current approaches. The Goddard Space Flight Center (GSFC) is currently supporting multiple libration missions. This end-to-end support consists of mission operations, trajectory design, and control. It also includes algorithm and software development. The recently launched Microwave Anisotropy Probe (MAP) and upcoming James Webb Space Telescope (JWST) and Constellation-X missions are examples of the use of improved numerical methods for attaining constrained orbital parameters and controlling their dynamical evolution at the collinear libration points. This paper presents a history of libration point missions, a brief description of the numerical and dynamical design techniques including software used, and a sample of future GSFC mission designs.

Bauer, Frank↗

Space Missions and Information Technology: Some Thoughts and Highlights

A viewgraph presentation about information technology and its role in space missions is shown. The topics include: 1) Where is the IT on Space Missions? 2) Winners of the NASA Software of the Year Award; 3) Space Networking Roadmap; and 4) 10 (7) -Year Vision for IT in Space.

space missions↗

DEMO: the Autonomous Sciencecraft Experiment onboard the EO-1 spacecraft

The Autonomous Sciencececraft Experiment (ASE), currently flying onboard the Earth Observing-1 (EO-1) spacecraft, integrates several autnomoy software technologies enabling autnomous science analysis and mission planning. The experiment demonstrates the potential for future space missions to use onboard decision-making to respond autonomously to capture short-lived science phenomena. The AAAI software demonstration will consist of two sections: a real-time display of an ASE-commanded ground contact from the EO-1 spacecraft, and a simulation of the full ASE autonomous science-response scenario.

EO-1 spacecraft↗

The autonomous sciencecraft experiment onboard the EO-1 spacecraft

The Autonomous Sciencecraft Experiment (ASE), currently flying onboard the Earth Observing-1 (EO-I) spacecraft, integrates several autonomy software technologies enabling autonomous science analysis and mission planning. The experiment demonstrates the potential for future space missions to use onboard decision-making to respond autonomously to capture short-lived science phenomena. The AAAI software demonstration will consist of two sections: a real-time display of an ASE-commanded ground contact from the EO-1 spacecraft, and a simulation of the full ASE autonomous science-response scenario.

Earth Observatory (EO)↗

Software Engineering for Human Spaceflight

The Spacecraft Software Engineering Branch of NASA Johnson Space Center (JSC) provides world‐class products, leadership, and technical expertise in software engineering, processes, technology, and systems management for human spaceflight. The branch contributes to major NASA programs (e.g. ISS, MPCV/Orion) with in‐house software development and prime contractor oversight, and maintains the JSC Engineering Directorate CMMI rating for flight software development. Software engineering teams work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements. They seek to infuse automation and autonomy into missions, and apply new technologies to flight processor and computational architectures. This presentation will provide an overview of key software‐related projects, software methodologies and tools, and technology pursuits of interest to the JSC Spacecraft Software Engineering Branch.

Fredrickson, Steven E.↗

Scheduling the Mapping of a planet under geometrical constraints

Scheduling the coverage of a planet by scientific instruments on board spacecrafts under observational constraints is central in a significant number of current and future missions for the exploration of the solar system. In this paper, we describe the components and algorithms of a software used to study early-phase mission design or to schedule daily operations of currently in-flight spacecraft. The scheduling problem at hand is usually a large combinatorial problem. A discretization process is described and several ordering algorithms are designed and compared. Experiments show that high-quality schedules can be produced by approaches combining reasoning about rolling, coverage and priorities.

Wells, Christopher↗

The Use of Modeling for Flight Software Engineering on SMAP

The Soil Moisture Active Passive (SMAP) mission proposes to deploy an Earth-orbiting satellite with the goal of obtaining global maps of soil moisture content at regular intervals. Launch is currently planned in 2014. The spacecraft bus would be built at the Jet Propulsion Laboratory (JPL), incorporating both new avionics as well as hardware and software heritage from other JPL projects. [4] provides a comprehensive overview of the proposed mission

Software architecture↗

MOS 2.0: The Next Generation in Mission Operations Systems

A Mission Operations System (MOS) or Ground System constitutes that portion of an overall space mission Enterprise that resides here on Earth. Over the past two decades, technological innovations in computing and software technologies have allowed an MOS to support ever more complex missions while consuming a decreasing fraction of Project development budgets. Despite (or perhaps, because of) such successes, it is routine to hear concerns about the cost of MOS development. At the same time, demand continues for Ground Systems which will plan more spacecraft activities with fewer commanding errors, provide scientists and engineers with more autonomous functionality, process and manage larger and more complex data more quickly, all while requiring fewer people to develop, deploy, operate and maintain them. One successful approach to such concerns over this period is a multimission approach, based on the reuse of portions (most often software) developed and used in previous missions. The Advanced Multi-Mission Operations System (AMMOS), developed for deep-space science missions, is one successful example of such an approach. Like many computing-intensive systems, it has grown up in a near-organic fashion from a relatively simple set of tools into a complexly interrelated set of capabilities. Such systems, like a city lacking any concept of urban planning, can and will grow in ways that are neither efficient nor particularly easy to sustain. To meet the growing demands and unyielding constraints placed on ground systems, a new approach is necessary. Under the aegis of a multi-year effort to revitalize the AMMOS's multimission operations capabilities, we are utilizing modern practices in systems architecting and model-based engineering to create the next step in Ground Systems: MOS 2.0. In this paper we outline our work (ongoing and planned) to architect and design a multimission MOS 2.0, describe our goals and measureable objectives, and discuss some of the benefits that this top-down, architectural approach holds for creating a more flexible and capable MOS for Missions while holding the line on cost.

ground systems↗

3D Visualization for Phoenix Mars Lander Science Operations

Planetary surface exploration missions present considerable operational challenges in the form of substantial communication delays, limited communication windows, and limited communication bandwidth. A 3D visualization software was developed and delivered to the 2008 Phoenix Mars Lander (PML) mission. The components of the system include an interactive 3D visualization environment called Mercator, terrain reconstruction software called the Ames Stereo Pipeline, and a server providing distributed access to terrain models. The software was successfully utilized during the mission for science analysis, site understanding, and science operations activity planning. A terrain server was implemented that provided distribution of terrain models from a central repository to clients running the Mercator software. The Ames Stereo Pipeline generates accurate, high-resolution, texture-mapped, 3D terrain models from stereo image pairs. These terrain models can then be visualized within the Mercator environment. The central cross-cutting goal for these tools is to provide an easy-to-use, high-quality, full-featured visualization environment that enhances the mission science team s ability to develop low-risk productive science activity plans. In addition, for the Mercator and Viz visualization environments, extensibility and adaptability to different missions and application areas are key design goals.

Edwards, Laurence↗

Voyager Interstellar Mission: Challenges of Flying a Very Old Spacecraft on a Very Long Mission

Two Voyager spacecraft were launched in 1977. After the successful flybys of Jupiter and Saturn by both Voyagers and Uranus and Neptune by Voyager 2, the mission has been extended for another 30 years in search of the transition region between the dominance of the solar energy and interstellar energy. The Voyager Interstellar Mission (VIM) started on January 1, 1990. It can be characterized by several factors including extremely long communication distances, aging hardware, reduced staffing levels and difficulty in obtaining Deep Space Network (DSN) resources necessitated by the increasing distance between the spacecraft and Earth. The mission was redesigned to compensate for such factors while maximizing the science return. After 25 years of VIM and several significant science discoveries, both Voyager spacecraft are still functioning well and the Voyager flight team is preparing for an even longer mission - until the year 2025 and beyond. In order to work around the challenges and to continue the mission even further, the team has been implementing numerous changes, mainly through flight software modifications and hardware reconfiguration. The major drivers for the changes are two-fold: resource constraints (such as decreasing power output and difficulty in obtaining the necessary DSN coverage) and anomalies due to the aging hardware. The majority of changes occur through flight software modifications so the state of the on-board responses is appropriate for the changing space environment and mission phase, and the flight software is compatible in allowing the maximum data gathering. The on-board flight software routines such as baseline sequence, fault protection routines, the High Gain Antenna POINTing to Earth (HPOINT) table, and long-term events table need to be maintained through flight software updates. The changes also occur through hardware reconfiguration such as selecting the backup Hybrid Buffer Interface Circuits (HYBIC) or attitude propulsion thrusters. This paper will describe the challenges of VIM and what has been done to overcome or mitigate those challenges. The primary focus will be the major flight software changes made during VIM and the changes that are in store for the near future in preparation for continuing the extended mission, from the originally projected year of 2020 out to the year 2025 and possibly beyond.

Matsumoto, Sun Kang↗

Software-implemented Fault Tolerance for Supercomputing in Space

The NASA Jet Propulsion Laboratory Remote Exploration and Experimentaion (REE) Project is a large multi-year technology demonstration project which will develop low-power, scalable, fault-tolerant, high- performance computing for use in space and will demonstrate that significant onboard processing capability enables a new class of science missions.

software fault tolerance supercomputing space remo↗

Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems

NASA is developing an architecture standard for software-defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer. This paper presents the initial Space Telecommunications Radio System (STRS) Architecture for NASA missions to provide the desired software abstraction and flexibility while minimizing the resources necessary to support the architecture.

Reinhart, Richard C.↗

GMI-IPS: Python Processing Software for Aircraft Campaigns

NASA's Atmospheric Tomography Mission (ATom) seeks to understand the impact of anthropogenic air pollution on gases in the Earth's atmosphere. Four flight campaigns are being deployed on a seasonal basis to establish a continuous global-scale data set intended to improve the representation of chemically reactive gases in global atmospheric chemistry models. The Global Modeling Initiative (GMI), is creating chemical transport simulations on a global scale for each of the ATom flight campaigns. To meet the computational demands required to translate the GMI simulation data to grids associated with the flights from the ATom campaigns, the GMI ICARTT Processing Software (GMI-IPS) has been developed and is providing key functionality for data processing and analysis in this ongoing effort. The GMI-IPS is written in Python and provides computational kernels for data interpolation and visualization tasks on GMI simulation data. A key feature of the GMI-IPS, is its ability to read ICARTT files, a text-based file format for airborne instrument data, and extract the required flight information that defines regional and temporal grid parameters associated with an ATom flight. Perhaps most importantly, the GMI-IPS creates ICARTT files containing GMI simulated data, which are used in collaboration with ATom instrument teams and other modeling groups. The initial main task of the GMI-IPS is to interpolate GMI model data to the finer temporal resolution (1-10 seconds) of a given flight. The model data includes basic fields such as temperature and pressure, but the main focus of this effort is to provide species concentrations of chemical gases for ATom flights. The software, which uses parallel computation techniques for data intensive tasks, linearly interpolates each of the model fields to the time resolution of the flight. The temporally interpolated data is then saved to disk, and is used to create additional derived quantities. In order to translate the GMI model data to the spatial grid of the flight path as defined by the pressure, latitude, and longitude points at each flight time record, a weighted average is then calculated from the nearest neighbors in two dimensions (latitude, longitude). Using SciPya's Regular Grid Interpolator, interpolation functions are generated for the GMI model grid and the calculated weighted averages. The flight path points are then extracted from the ATom ICARTT instrument file, and are sent to the multi-dimensional interpolating functions to generate GMI field quantities along the spatial path of the flight. The interpolated field quantities are then written to a ICARTT data file, which is stored for further manipulation. The GMI-IPS is aware of a generic ATom ICARTT header format, containing basic information for all flight campaigns. The GMI-IPS includes logic to edit metadata for the derived field quantities, as well as modify the generic header data such as processing dates and associated instrument files. The ICARTT interpolated data is then appended to the modified header data, and the ICARTT processing is complete for the given flight and ready for collaboration. The output ICARTT data adheres to the ICARTT file format standards V1.1. The visualization component of the GMI-IPS uses Matplotlib extensively and has several functions ranging in complexity. First, it creates a model background curtain for the flight (time versus model eta levels) with the interpolated flight data superimposed on the curtain. Secondly, it creates a time-series plot of the interpolated flight data. Lastly, the visualization component creates averaged 2D model slices (longitude versus latitude) with overlaid flight track circles at key pressure levels. The GMI-IPS consists of a handful of classes and supporting functionality that have been generalized to be compatible with any ICARTT file that adheres to the base class definition. The base class represents a generic ICARTT entry, only defining a single time entry and 3D spatial positioning parameters. Other classes inherit from this base class; several classes for input ICARTT instrument files, which contain the necessary flight positioning information as a basis for data processing, as well as other classes for output ICARTT files, which contain the interpolated model data. Utility classes provide functionality for routine procedures such as: comparing field names among ICARTT files, reading ICARTT entries from a data file and storing them in data structures, and returning a reduced spatial grid based on a collection of ICARTT entries. Although the GMI-IPS is compatible with GMI model data, it can be adapted with reasonable effort for any simulation that creates Hierarchical Data Format (HDF) files. The same can be said of its adaptability to ICARTT files outside of the context of the ATom mission. The GMI-IPS contains just under 30,000 lines of code, eight classes, and a dozen drivers and utility programs. It is maintained with GIT source code management and has been used to deliver processed GMI model data for the ATom campaigns that have taken place to date.

Damon, M. R.↗

SLS-PLAN-IT: A knowledge-based blackboard scheduling system for Spacelab life sciences missions

The primary scheduling tool in use during the Spacelab Life Science (SLS-1) planning phase was the operations research (OR) based, tabular form Experiment Scheduling System (ESS) developed by NASA Marshall. PLAN-IT is an artificial intelligence based interactive graphic timeline editor for ESS developed by JPL. The PLAN-IT software was enhanced for use in the scheduling of Spacelab experiments to support the SLS missions. The enhanced software SLS-PLAN-IT System was used to support the real-time reactive scheduling task during the SLS-1 mission. SLS-PLAN-IT is a frame-based blackboard scheduling shell which, from scheduling input, creates resource-requiring event duration objects and resource-usage duration objects. The blackboard structure is to keep track of the effects of event duration objects on the resource usage objects. Various scheduling heuristics are coded in procedural form and can be invoked any time at the user's request. The system architecture is described along with what has been learned with the SLS-PLAN-IT project.

Kao, Cheng-Yan↗

Navigation/Prop Software Suite

Navigation (Nav)/Prop software is used to support shuttle mission analysis, production, and some operations tasks. The Nav/Prop suite containing configuration items (CIs) resides on IPS/Linux workstations. It features lifecycle documents, and data files used for shuttle navigation and propellant analysis for all flight segments. This suite also includes trajectory server, archive server, and RAT software residing on MCC/Linux workstations. Navigation/Prop represents tool versions established during or after IPS Equipment Rehost-3 or after the MCC Rehost.

Bruchmiller, Tomas↗

Wake Cycle Robustness of the Mars Science Laboratory Flight Software

The Mars Science Laboratory (MSL) is a spacecraft being developed by the Jet Propulsion Laboratory (JPL) for the purpose of in-situ exploration on the surface of Mars. The objective of MSL is to explore and quantitatively assess a local region on the Martian surface as a habitat for microbial life, past or present. This objective will be accomplished through the assessment of the biological potential of at least one target environment, the characterization of the geology and geochemistry of the landing region, an investigation of the planetary process relevant to past habitability, and a characterization of surface radiation. For this purpose, MSL incorporates a total of ten scientific instruments for which functions are to include, among others, atmospheric and descent imaging, chemical composition analysis, and radiation measurement. The Flight Software (FSW) system is responsible for all mission phases, including launch, cruise, entry-descent-landing, and surface operation of the rover. Because of the essential nature of flight software to project success, each of the software modules is undergoing extensive testing to identify and correct errors.

Whitehill, Robert↗