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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

HISPASAT launch and early operations phases: Computation and monitoring of geostationary satellite positioning

Since 1974, CNES, the French National Space Agency, has been involved in the geostationary launch and early operations phases (LEOP) of moving satellites from a transfer orbit delivered by a launcher to a geostationary point. During the operations and their preparation, the Flight Dynamics Center (FDC), part of CNES LEOP facilities, is in charge of the space mechanics aspects. What is noteworthy about the Spanish HISPASAT satellite positioning is that all the operations were performed on the customer's premises, and consequently the FDC was duplicated in Madrid, Spain. The first part of this paper is the FDC presentation: its role, its hardware configuration, and its space dynamics ground control system called MERCATOR. The second part of this paper details the preparation used by the FDC for the HISPASAT mission: hardware and software installation in Madrid, integration with the other entities, and technical and operational qualifications. The third part gives results concerning flight dynamics aspects and operational activities.

Brousse, Pascal↗
NASA NTRS1994

Shared virtual environments for aerospace training

Virtual environments have the potential to significantly enhance the training of NASA astronauts and ground-based personnel for a variety of activities. A critical requirement is the need to share virtual environments, in real or near real time, between remote sites. It has been hypothesized that the training of international astronaut crews could be done more cheaply and effectively by utilizing such shared virtual environments in the early stages of mission preparation. The Software Technology Branch at NASA's Johnson Space Center has developed the capability for multiple users to simultaneously share the same virtual environment. Each user generates the graphics needed to create the virtual environment. All changes of object position and state are communicated to all users so that each virtual environment maintains its 'currency.' Examples of these shared environments will be discussed and plans for the utilization of the Department of Defense's Distributed Interactive Simulation (DIS) protocols for shared virtual environments will be presented. Finally, the impact of this technology on training and education in general will be explored.

Loftin, R. Bowen↗
NASA NTRS1996

High speed simulator: A simulator for all seasons

The evolution of a high speed spacecraft simulator (HSS) is discussed from development and operations perspectives. The HSS is a series of simulators capable of modeling the spacecraft and its subsystems at different levels. The HSS was developed for the validation of the Galileo low gain antenna mission's flight software. Due to the successful performance of the HSS in assisting with the flight software validation, additional Galileo validation applications were identified. These applications include the modeling of other onboard data systems, such as the command and data subsystem and the attitude and articulation control subsystem. The HSS architecture, which consists of a number of components, is described and the operational use of the system is outlined.

Patel, K.↗
NASA NTRS1995

Technology for Manufacturing Efficiency

The Ground Processing Scheduling System (GPSS) was developed by Ames Research Center, Kennedy Space Center and divisions of the Lockheed Company to maintain the scheduling for preparing a Space Shuttle Orbiter for a mission. Red Pepper Software Company, now part of PeopleSoft, Inc., commercialized the software as their ResponseAgent product line. The software enables users to monitor manufacturing variables, report issues and develop solutions to existing problems.

Source record↗
NASA NTRS2003

Advantages of Brahms for Specifying and Implementing a Multiagent Human-Robotic Exploration System

We have developed a model-based, distributed architecture that integrates diverse components in a system designed for lunar and planetary surface operations: an astronaut's space suit, cameras, all-terrain vehicles, robotic assistant, crew in a local habitat, and mission support team. Software processes ('agents') implemented in the Brahms language, run on multiple, mobile platforms. These mobile agents interpret and transform available data to help people and robotic systems coordinate their actions to make operations more safe and efficient. The Brahms-based mobile agent architecture (MAA) uses a novel combination of agent types so the software agents may understand and facilitate communications between people and between system components. A state-of-the-art spoken dialogue interface is integrated with Brahms models, supporting a speech-driven field observation record and rover command system. An important aspect of the methodology involves first simulating the entire system in Brahms, then configuring the agents into a runtime system Thus, Brahms provides a language, engine, and system builder's toolkit for specifying and implementing multiagent systems.

Clancey, William J.↗
NASA NTRS2003

Mobile Agents: A Distributed Voice-Commanded Sensory and Robotic System for Surface EVA Assistance

A model-based, distributed architecture integrates diverse components in a system designed for lunar and planetary surface operations: spacesuit biosensors, cameras, GPS, and a robotic assistant. The system transmits data and assists communication between the extra-vehicular activity (EVA) astronauts, the crew in a local habitat, and a remote mission support team. Software processes ("agents"), implemented in a system called Brahms, run on multiple, mobile platforms, including the spacesuit backpacks, all-terrain vehicles, and robot. These "mobile agents" interpret and transform available data to help people and robotic systems coordinate their actions to make operations more safe and efficient. Different types of agents relate platforms to each other ("proxy agents"), devices to software ("comm agents"), and people to the system ("personal agents"). A state-of-the-art spoken dialogue interface enables people to communicate with their personal agents, supporting a speech-driven navigation and scheduling tool, field observation record, and rover command system. An important aspect of the engineering methodology involves first simulating the entire hardware and software system in Brahms, and then configuring the agents into a runtime system. Design of mobile agent functionality has been based on ethnographic observation of scientists working in Mars analog settings in the High Canadian Arctic on Devon Island and the southeast Utah desert. The Mobile Agents system is developed iteratively in the context of use, with people doing authentic work. This paper provides a brief introduction to the architecture and emphasizes the method of empirical requirements analysis, through which observation, modeling, design, and testing are integrated in simulated EVA operations.

Clancey, William J.↗
NASA NTRS2005

Virtual Machine Language

Virtual Machine Language (VML) is a mission-independent, reusable software system for programming for spacecraft operations. Features of VML include a rich set of data types, named functions, parameters, IF and WHILE control structures, polymorphism, and on-the-fly creation of spacecraft commands from calculated values. Spacecraft functions can be abstracted into named blocks that reside in files aboard the spacecraft. These named blocks accept parameters and execute in a repeatable fashion. The sizes of uplink products are minimized by the ability to call blocks that implement most of the command steps. This block approach also enables some autonomous operations aboard the spacecraft, such as aerobraking, telemetry conditional monitoring, and anomaly response, without developing autonomous flight software. Operators on the ground write blocks and command sequences in a concise, high-level, human-readable programming language (also called VML ). A compiler translates the human-readable blocks and command sequences into binary files (the operations products). The flight portion of VML interprets the uplinked binary files. The ground subsystem of VML also includes an interactive sequence- execution tool hosted on workstations, which runs sequences at several thousand times real-time speed, affords debugging, and generates reports. This tool enables iterative development of blocks and sequences within times of the order of seconds.

Grasso, Christopher↗
NASA NTRS2004

MER SPICE Interface

MER SPICE Interface is a software module for use in conjunction with the Mars Exploration Rover (MER) mission and the SPICE software system of the Navigation and Ancillary Information Facility (NAIF) at NASA's Jet Propulsion Laboratory. (SPICE is used to acquire, record, and disseminate engineering, navigational, and other ancillary data describing circumstances under which data were acquired by spaceborne scientific instruments.) Given a Spacecraft Clock value, MER SPICE Interface extracts MER-specific data from SPICE kernels (essentially, raw data files) and calculates values for Planet Day Number, Local Solar Longitude, Local Solar Elevation, Local Solar Azimuth, and Local Solar Time (UTC). MER SPICE Interface was adapted from a subroutine, denoted m98SpiceIF written by Payam Zamani, that was intended to calculate SPICE values for the Mars Polar Lander. The main difference between MER SPICE Interface and m98SpiceIf is that MER SPICE Interface does not explicitly call CHRONOS, a time-conversion program that is part of a library of utility subprograms within SPICE. Instead, MER SPICE Interface mimics some portions of the CHRONOS code, the advantage being that it executes much faster and can efficiently be called from a pipeline of events in a parallel processing environment.

Sayfi, Elias↗
NASA NTRS2011

Towards a Standard for Provenance and Context for Preservation of Data for Earth System Science

Long-term data sets with data from many missions are needed to study trends and validate model results that are typical in Earth System Science research. Data and derived products originate from multiple missions (spaceborne, airborne and/or in situ) and from multiple organizations. During the missions as well as well past their termination, it is essential to preserve the data and products to support future studies. Key aspects of preservation are: preserving bits and ensuring data are uncorrupted, preserving understandability with appropriate documentation, and preserving reproducibility of science with appropriate documentation and other artifacts. Computer technology provides adequate standards to ensure that, with proper engineering, bits are preserved as hardware evolves. However, to ensure understandability and reproducibility, it is essential to plan ahead to preserve all the relevant data and information. There are currently no standards to identify the content that needs to be preserved, leading to non-uniformity in content and users not being sure of whether preserved content is comprehensive. Each project, program or agency can specify the items to be preserved as a part of its data management requirements. However, broader community consensus that cuts across organizational or national boundaries would be needed to ensure comprehensiveness, uniformity and long-term utility of archived data. The Federation of Earth Science Information Partners (ESIP), a diverse network of scientists, data stewards and technology developers, has a forum for ESIP members to collaborate on data preservation issues. During early 2011, members discussed the importance of developing a Provenance and Context Content Standard (PCCS) and developed an initial list of content items. This list is based on the outcome of a NASA and NOAA meeting held in 1998 under the auspices of the USGCRP, documentation requirements from NOAA and our experience with some of the NASA Earth science missions. The items are categorized into the following 8 high level categories: Preflight/Pre-Operations, Products (Data), Product Documentation, Mission Calibration, Product Software, Algorithm Input, Validation, Software Tools.

Ramaprian, Hampapuram K.↗
NASA NTRS2012

Optical and Scanning Electron Microscopy of the Materials International Space Station Experiment (MISSE) Spacecraft Silicone Experiment

Under a microscope, atomic oxygen (AO) exposed silicone surfaces are crazed and seen as "islands" separated by numerous crack lines, much analogous to mud-tile cracks. This research characterized and compared the degree of AO degradation of silicones by analyzing optical microscope images of samples exposed to low Earth orbit (LEO) AO as part of the Spacecraft Silicone Experiment. The Spacecraft Silicone Experiment consisted of eight DC 93-500 silicone samples exposed to eight different AO fluence levels (ranged from 1.46 to 8.43 10(exp 21) atoms/sq cm) during two different Materials International Space Station Experiment (MISSE) missions. Image analysis software was used to analyze images taken using a digital camera. To describe the morphological degradation of each AO exposed flight sample, three different parameters were selected and estimated: (1) average area of islands was determined and found to be in the 1000 to 3100 sq mm range; (2) total length of crack lines per unit area of the sample surface were determined and found to be in the range of 27 to 59 mm of crack length per sq mm of sample surface; and (3) the fraction of sample surface area that is occupied by crack lines was determined and found to be in the 25 to 56 percent range. In addition, average crack width can be estimated from crack length and crack area measurements and was calculated to be about 10 mm. Among the parameters studied, the fraction of sample surface area that is occupied by crack lines is believed to be most useful in characterizing the degree of silicone conversion to silicates by AO because its value steadily increases with increasing fluence over the entire fluence range. A series of SEM images from the eight samples exposed to different AO fluences suggest a complex sequence of surface stress due to surface shrinkage and crack formation, followed by re-distribution of stress and shrinking rate on the sample surface. Energy dispersive spectra (EDS) indicated that upon AO exposure, carbon content on the surface decreased relatively quickly at the beginning, to 32 percent of the pristine value for the least exposed sample in this set of experiments (1.46 10(exp 21) atoms/sq cm), but then decreased slowly, to 22 percent of the pristine value for the most exposed sample in this set of experiment (8.43 10(exp 21) atoms/sq cm). The oxygen content appears to increase at a slower rate. The least and most AO exposed samples were, respectively, 52 and 150 percent above the pristine values. The silicone samples with the greater AO exposure (7.75 10(exp 21) atoms/sq cm and higher) appear to have a surface layer which contains SiO2 with perhaps small amounts of unreacted silicone, CO and CO2 sealed inside.

Hung, Ching-cheh↗
NASA NTRSDate not supplied

Demonstration of Rapid Development Through Containerization: OSE-SAT

Modern advancements in spacecraft technology have enabled engineers to develop radically smaller and lighter spacecraft, which has drastically reduced the cost of putting spacecraft into space. Despite these advancements and the shrinking cost to get spacecraft into space, space exploration is still prohibitively expensive. So much so that many space missions prefer to err on the side of caution than take on additional risk by trying newer, unproven technologies. This risk-averse mission design, while very reasonable from a program management point of view, significantly impacts engineers’ ability to solve newer, more complicated problems and limits scientists’ ability to develop more complex experiments that rely on newer technology. Often these new technologies remain stuck at lower technology readiness levels for many years due to the space community's reluctance to take on the additional risks of proving out unproven technology. The Distributed Spacecraft Autonomy (DSA) team at NASA Ames Research Center is developing a containerized solution to enable the rapid development of newer space technologies and accelerate their adoption into space missions. The Opportunistic Software Experiments for Spacecraft Autonomy Testbeds (OSE-SAT) is an on-orbit test bed that aims to reduce the amount of risk associated with newer, unproven space technologies by containerizing each experiment in its own isolated environment and providing a safe, robust, and controlled interface to access spacecraft host resources that is monitored in real time by thoroughly tested Trusted Container developed by DSA. This paper will describe DSA’s implementation of OSE-SAT and discuss the benefits, as well as challenges, of on-orbit containerization.

Aaron J Woodard↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
NASA NTRS1994

A proven approach for more effective software development and maintenance

Modern space flight mission operations and associated ground data systems are increasingly dependent upon reliable, quality software. Critical functions such as command load preparation, health and status monitoring, communications link scheduling and conflict resolution, and transparent gateway protocol conversion are routinely performed by software. Given budget constraints and the ever increasing capabilities of processor technology, the next generation of control centers and data systems will be even more dependent upon software across all aspects of performance. A key challenge now is to implement improved engineering, management, and assurance processes for the development and maintenance of that software; processes that cost less, yield higher quality products, and that self-correct for continual improvement evolution. The NASA Goddard Space Flight Center has a unique experience base that can be readily tapped to help solve the software challenge. Over the past eighteen years, the Software Engineering Laboratory within the code 500 Flight Dynamics Division has evolved a software development and maintenance methodology that accommodates the unique characteristics of an organization while optimizing and continually improving the organization's software capabilities. This methodology relies upon measurement, analysis, and feedback much analogous to that of control loop systems. It is an approach with a time-tested track record proven through repeated applications across a broad range of operational software development and maintenance projects. This paper describes the software improvement methodology employed by the Software Engineering Laboratory, and how it has been exploited within the Flight Dynamics Division with GSFC Code 500. Examples of specific improvement in the software itself and its processes are presented to illustrate the effectiveness of the methodology. Finally, the initial findings are given when this methodology was applied across the mission operations and ground data systems software domains throughout Code 500.

Pajerski, Rose↗
NASA NTRS2003

Autonomous Science on the EO-1 Mission

In mid-2003, we will fly software to detect science events that will drive autonomous scene selectionon board the New Millennium Earth Observing 1 (EO-1) spacecraft. This software will demonstrate the potential for future space missions to use onboard decision-making to detect science events and respond autonomously to capture short-lived science events and to downlink only the highest value science data.

autonomous systems robust execution↗
NASA NTRSDate not supplied

Advancing Autonomy in Distributed Space Systems: Insights From on-Orbit Testing with the Starling 1.0 Mission

Autonomous decision-making is crucial for enhancing mission effectiveness in Distributed Space Systems (DSS), particularly in multi-spacecraft operations where communication constraints and mission complexity pose challenges. The Distributed Spacecraft Autonomy (DSA) team at NASA’s Ames Research Center is advancing autonomy in DSS through five key technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. The DSA experiment onboard the Starling 1.0 Mission showcases collaborative resource allocation for multi-point science data collection with four small spacecraft. Autonomy in decision-making is highlighted as a crucial factor for multi-spacecraft missions, enabling spacecraft to operate independently, reducing reliance on ground control. This capability is particularly significant for future deep-space missions, where communication delays and limited data transmission capacity make traditional command and control approaches impractical. This demonstration focuses on a GPS Channel Selection Experiment, leveraging emergent capabilities like "shared sampling" and "simultaneous sampling" to optimize channel selection across the spacecraft swarm. The experiment aims to capture ionospheric phenomena such as the Equatorial Ionization Anomaly and Polar Patches. The DSA system's autonomous reconfiguration ability is showcased, emphasizing its adaptability to natural phenomena without significant integration efforts. The GPS Channel Selection Experiment utilizes a dual-band GPS receiver to estimate plasma density in the ionosphere. Explorative and exploitative channel selections are employed based on the nature of observed phenomena. The performance of DSA algorithms is evaluated in terms of optimal channel allocations and responsiveness to changes in observed features. The DSA Flight Software utilizes the Core Flight System (cFS) framework, ensuring compatibility with the Starling 1.0 flight mission software. DSA showcases results from RTI’s Connext DDS Micro communication middleware, enabling message routing over the Ad-Hoc Network of Starling 1.0. This paper provides a comprehensive overview of the DSA experiment's initial results, emphasizing the advancements in autonomy for Distributed Space Systems and the successful collaboration with the Starling 1.0 mission.

Caleb Ashmore Adams↗
NASA NTRSDate not supplied

NASA’s Space Launch System Successfully Launches Artemis I Mission and Hardware Progress Continues for Next Artemis Missions

NASA’s Artemis I mission will be the first flight of the agency’s Space Launch System (SLS) rocket. It will launch an uncrewed Orion spacecraft to the Moon, where it will enter a highly elliptical retrograde orbit. In 2022, final tests, checkouts, and preparations were on schedule to be completed, including the vital wet dress rehearsal (WDR) at Kennedy Space Center’s (KSC) Launch Complex 39B. Following successful completion of WDR, which is expected in summer 2022, the Artemis I launch vehicle will be returned to the Vehicle Assembly Building (VAB) at KSC where it will be prepared for launch. Important data were collected during launch and will be shared as applicable. While the Artemis I hardware and mission took center stage in 2022, significant progress was made on hardware and software for future Artemis missions, including for the first crewed launch and the following SLS Block 1B and Block 2 variants of the rocket.

John Honeycutt↗
NASA NTRS2013

Validation and Verification of LADEE Models and Software

The Lunar Atmosphere Dust Environment Explorer (LADEE) mission will orbit the moon in order to measure the density, composition and time variability of the lunar dust environment. The ground-side and onboard flight software for the mission is being developed using a Model-Based Software methodology. In this technique, models of the spacecraft and flight software are developed in a graphical dynamics modeling package. Flight Software requirements are prototyped and refined using the simulated models. After the model is shown to work as desired in this simulation framework, C-code software is automatically generated from the models. The generated software is then tested in real time Processor-in-the-Loop and Hardware-in-the-Loop test beds. Travelling Road Show test beds were used for early integration tests with payloads and other subsystems. Traditional techniques for verifying computational sciences models are used to characterize the spacecraft simulation. A lightweight set of formal methods analysis, static analysis, formal inspection and code coverage analyses are utilized to further reduce defects in the onboard flight software artifacts. These techniques are applied early and often in the development process, iteratively increasing the capabilities of the software and the fidelity of the vehicle models and test beds.

Gundy-Burlet, Karen↗
NASA NTRS1994

Generic mission planning and scheduling: The AXAF solution

During SpaceOps 92 the idea of generic mission planning concepts for space astronomy missions, that could be applied to future missions in order to simplify software development, was introduced. It was proposed that mission planning systems could be decomposed into functional elements that could be standardized and then organized into optimal functional flows for each individual mission. In addition, it was further suggested that these flows themselves could be reduced to a small set of possibilities by describing them in terms of generic mission type, such as manned, unmanned, high orbit, low orbit, etc. The Advanced X-ray Astrophysics Facility (AXAF), planned for launch in the latter part of '98, represents the first application of this idea on an unmanned mission. This paper examines the AXAF Mission Planning and Scheduling concept in light of the generic system theory. Each functional element is evaluated according to AXAF characteristics and requirements and then compared to its generic counterpart. Functional flow considerations are then derived from the overall AXAF mission planning concept to determine the viability and sensitivity of the generic flow to actual requirements. The results of this analysis are then used to update the generic system concept and to define the level of commonality and core system components that are practical to achieve across multiple missions.

Guffin, O. T.↗