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 433 records · Page 24

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↗

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.↗

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↗

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 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↗

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↗

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↗

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’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↗

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↗

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.↗

Generic astronomy 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 1998, 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.↗

Spacecraft Onboard Software Maintenance: An Effective Approach which Reduces Costs and Increases Science Return

Flight software (FSW) is a mission critical element of spacecraft functionality and performance. When ground operations personnel interface to a spacecraft, they are dealing almost entirely with onboard software. This software, even more than ground/flight communications systems, is expected to perform perfectly at all times during all phases of on-orbit mission life. Due to the fact that FSW can be reconfigured and reprogrammed to accommodate new spacecraft conditions, the on-orbit FSW maintenance team is usually significantly responsible for the long-term success of a science mission. Failure of FSW can result in very expensive operations work-around costs and lost science opportunities. There are three basic approaches to staffing on-orbit software maintenance, namely: (1) using the original developers, (2) using mission operations personnel, or (3) assembling a Center of Excellence for multi-spacecraft on-orbit FSW support. This paper explains a National Aeronautics and Space Administration, Goddard Space Flight Center (NASA/GSFC) experience related to the roles of on-orbit FSW maintenance personnel. It identifies the advantages and disadvantages of each of the three approaches to staffing the FSW roles, and demonstrates how a cost efficient on-orbit FSW Maintenance Center of Excellence can be established and maintained with significant return on the investment.

Shell, Elaine M.↗

Mission Control Technologies: Empowering Users

Traditional software is developed as monolithic applications that are typed and create boundaries around their domains. ARC, working with JSC, developed an object oriented user interface that reduced domain boundaries in software. We used agile participatory design to develop a solution with our customer in mission control.

Software engineering↗

Space Station Mission Planning System (MPS) development study. Volume 1: Executive summary

The basic objective of the Space Station (SS) Mission Planning System (MPS) Development Study was to define a baseline Space Station mission plan and the associated hardware and software requirements for the system. A detailed definition of the Spacelab (SL) payload mission planning process and SL Mission Integration Planning System (MIPS) software was derived. A baseline concept was developed for performing SS manned base payload mission planning, and it was consistent with current Space Station design/operations concepts and philosophies. The SS MPS software requirements were defined. Also, requirements for new software include candidate programs for the application of artificial intelligence techniques to capture and make more effective use of mission planning expertise. A SS MPS Software Development Plan was developed which phases efforts for the development software to implement the SS mission planning concept.

Klus, W. J.↗

Ultraviolet spectrometer and polarimeter (UVSP) software development and hardware tests for the solar maximum mission

The Ultraviolet Spectrometer/Polarimeter Instrument (UVSP) for the Solar Maximum Mission (SMM) was based on the re-use of the engineering model of the high resolution ultraviolet spectrometer developed for the OSO-8 mission. Lockheed assumed four distinct responsibilities in the UVSP program: technical evaluation of the OSO-8 engineering model; technical consulting on the electronic, optical, and mechanical modifications to the OSO-8 engineering model hardware; design and development of the UVSP software system; and scientific participation in the operations and analysis phase of the mission. Lockheed also provided technical consulting and assistance with instrument hardware performance anomalies encountered during the post launch operation of the SMM observatory. An index to the quarterly reports delivered under the contract are contained, and serves as a useful capsule history of the program activity.

Bruner, M. E.↗

Using Virtual Reality for Science Mission Planning: A Mars Pathfinder Case

The Mars Pathfinder Project GDS Team has designed software that integrates virtual reality technology with existing JPL Navigational Ancillary Information Facilities (NAIF) and image processing capabilities. The result is an interactive, workstation-based application software that provides a high resolution 3-dimensional stereo display of Mars as if it were viewed through the lander camera. This paper describes the architecture and characteristics of this science mission planning software and discusses possible uses of this software by other planetary missions.

virtual↗

Lessons Learned from Seven Space Shuttle Missions

Much can be learned from well-written descriptions of the technical and organizational factors that lead to an accident. Subsequent analysis by third parties of investigation reports and associated evidence collected during the investigations can lead to additional insight. Much can also be learned from documented close calls that do not result in loss of life or a spacecraft, such as the Mars Exploration Rover Spirit software anomaly, the SOHO mission interruption, and the NEAR burn anomaly. Seven space shuttle incidents fall into the latter category: Rendezvous Target Failure On STS-41B; Rendezvous Radar Anomaly and Trajectory Dispersion-STS-32 ;Rendezvous Lambert Targeting Anomaly-STS-49; Rendezvous Lambert Targeting Anomaly-STS-51; Zero Doppler Steering Maneuver Anomaly-STS-59; Excessive Propellant Consumption During Rendezvous-STS-69; Global Positioning System Receiver and Associated Shuttle Flight Software Anomalies-STS-91 Procedural work-arounds or software changes prevented them from threatening mission success. Extensive investigations, which included the independent recreation of the anomalies by multiple Shuttle Program organizations, were the key to determining the cause, accurately assessing risk, and identifying software and software process improvements. Lessons learned from these incidents not only validated long-standing operational best practices, but serve to promote discussion and mentoring among Program personnel and are applicable to future space flight programs.

Goodman, John↗