SEARCH · Search NASA
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.
The arduous task of tracking multiple flight software images, across redundant on-board processors, recorders and across time, has been automated and systematized via the use of a unified Flight Software Memory Tracker (FMT) Tool.
Tracking the resources of the two redundant Solid State Recorders (SSR) is a necessary routine for Cassini spacecraft mission operations. Instead of relying on a full-fledged spacecraft hardware/software simulator to track and predict the SSR recording and playback pointer positions, a stand-alone SSR Pointer Tracker tool was developed as part of JPL's Multimission Spacecraft Analysis system.
The software engineering design of the Flight Software Memory Tracker (FMT) Tool is discussed in this paper. FMT is a ground analysis software set, consisting of utilities and procedures, designed to track the flight software, i.e., images of memory load and updatable parameters of the computers on-board Cassini spacecraft. FMT is implemented in Java.
In a brief evaluation of software-related considerations, it is found that suitable approaches for software development depend to a large degree on the characteristics of the particular project involved. An analysis is conducted of development problems in an environment in which ground support software is produced for spacecraft control. The amount of work involved is in the range from 6 to 10 man-years. Attention is given to a general project summary, a programmer/analyst survey, a component summary, a component status report, a resource summary, a change report, a computer program run analysis, aspects of data collection on a smaller scale, progress forecasting, problems of overhead, and error analysis.
Mission operations for the Mars Observer (MO) Project at the Jet Propulsion Laboratory were supported by a variety of ground data processing software and analysis tools. Some of these tools were generic to multimission spacecraft mission operations, some were specific to the MO spacecraft, and others were custom tailored to the operation and control of the Attitude and Articulation Control Subsystem (AACS). The focus of this paper is on the data analysis tools for the AACS. Four different categories of analysis tools are presented; with details offered for specific tools. Valuable experience was gained from the use of these tools and through their development. These tools formed the backbone and enhanced the efficiency of the AACS Unit in the Mission Operations Spacecraft Team. These same tools, and extensions thereof, have been adopted by the Galileo mission operations, and are being designed into Cassini and other future spacecraft mission operations.
Missions have been proposed that will use multiple spacecraft to perform scientific or commercial tasks. Indeed, in the commercial world, some spacecraft constellations already exist. Aside from the technical challenges of constructing and flying these missions, there is also the financial challenge presented by the tradition model of the flight operations team (FOT) when it is applied to a constellation mission. Proposed constellation missions range in size from three spacecraft to more than 50. If the current ratio of three-to-five FOT personnel per spacecraft is maintained, the size of the FOT becomes cost prohibitive. The Advanced Architectures and Automation Branch at the Goddard Space Flight Center (GSFC Code 588) saw the potential to reduce the cost of these missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a smaller FOT to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads a real-time stream of data from the ground system and displays it to the FOT such that anomalies are easy to pick out and investigate. Data visualization has been used in ground system operations for many years. To provide a unique visualization tool, we developed a unique source of data to visualize: the REACH Health Model Engine. The Health Model Engine is rule-based software that receives real-time telemetry information and outputs "health" information related to the subsystems and spacecraft that the telemetry belong to. The Health Engine can run out-of-the-box or can be tailored with a scripting language. Out of the box, it uses limit violations to determine the health of subsystems and spacecraft; when tailored, it determines health using equations combining the values and limits of any telemetry in the spacecraft. The REACH visualizations then "roll up" the information from the Health Engine into high level, summary displays. These summary visualizations can be "zoomed" into for increasing levels of detail. Currently REACH is installed in the Small Explorer (SMEX) lab at GSFC, and is monitoring three of their five spacecraft. We are scheduled to install REACH in the Mid-sized Explorer (MIDEX) lab, which will allow us to monitor up to six more spacecraft. The process of installing and using our "research" software in an operational environment has provided many insights into which parts of REACH are a step forward and which of our ideas are missteps. Our paper explores both the new concepts in spacecraft health-and-safety visualization, the difficulties of such systems in the operational environment, and the cost and safety issues of multi-spacecraft missions.
NASA's Advanced Architectures and Automation Branch at the Goddard Space Flight Center (Code 588) saw the potential to reduce the cost of constellation missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a small Flight Operations Team (FOT) to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads numerous real-time streams of data from the ground system(s) and displays synthesized information to the FOT such that anomalies are easy to pick out and investigate.
Ground software systems at JPL must meet high assurance standards while remaining on schedule due to relatively immovable launch dates for spacecraft that will be controlled by such systems. Toward this end, the Software Quality Improvement (SQI) project's Measurement and Benchmarking (M&B) team is collecting and analyzing defect data of JPL ground system software projects to build software defect prediction models. The aim of these models is to improve predictability with regard to software quality activities. Predictive models will quantitatively define typical trends for JPL ground systems as well as Critical Discriminators (CDs) to provide explanations for atypical deviations from the norm at JPL. CDs are software characteristics that can be estimated or foreseen early in a software project's planning. Thus, these CDs will assist in planning for the predicted degree to which software quality activities for a project are likely to deviation from the normal JPL ground system based on pasted experience across the lab.
The most fundamental objective of all robotic planetary spacecraft is to return science data. To accomplish this, a spacecraft is fabricated and built, software is planned and coded, and a ground system is designed and implemented. However, the quantitative analysis required to determine how the collection of science data drives ground system capabilities has received very little attention. This paper defines a process by which science objectives can be quantitatively evaluated. By applying it to the Cassini Mission to Saturn, this paper further illustrates the power of this technique. The results show which science objectives drive specific ground system capabilities. In addition, this process can assist system engineers and scientists in the selection of the science payload during pre-project mission planning; ground system designers during ground system development and implementation; and operations personnel during mission operations.
We describe a software approach for simultaneous demodulation and decoding of multiple frequency- multiplexed spacecraft across multiple ground stations. The approach involves the use of a single ground antenna with wide enough aperture to receive multiple angularly adjacent spacecraft simultaneously. This technique uses a wide-band RF signal digitizer coupled with easily and cheaply duplicated software-receiver modules to independently process the frequency-channelized downlink signals from the spacecraft. This approach relaxes the need for realizable modems at each antenna, for example in the Deep-SpaceNetwork (DSN), and can also function as a delayed data retrieval method for cubesat missions with routine science data return. Thus, we hope that this solution can enable more efficient utilization of DSN assets. We concentrate on a simulation similar to the proposed Exploration Mission 1 (EM-1) mission from a geometric perspective. To that end, the simulated scenario involves ten secondary cubesats deployed and tracked for a span of four days (the modeled motion over the first four days of the mission does not include any Trajectory Correction Maneuvers (TCMs) that may be necessary as the cubesats approach the moon). Transmissions from the cubesats may be received through a combination of DSN ground sites based on visibility. The cubesats are assumed to utilize typical cubesat transmit powers and a waveform similar to that of the Iris radio. One cubesat is chosen as the “target” and is considered tracked by all ground-stations throughout the simulation (i.e., it is consistently at the center of the main lobe of each ground station antenna when the ground station is in view of the cubesat in terms of elevation angle). The simulation effort involves synthesizing a wideband signal that includes the ten cubesats across a large bandwidth due to each cubesat having its own center-frequency in X-band, near 8.4 GHz. Each signal is characterized by its own Doppler-frequency shift and free-space path-loss computed through the underlying geometry of the simulation as well as the cubesat transmit power. Finally, each cubesat signal experiences a unique antenna gain at each ground station due to the underlying antenna pattern and spacecraft-ground station geometry. We establish two interesting findings: First, the link-budget for the EM-1-like scenario is almost completely limited by the angle between the center of the antenna main beam and the cubesat, which means that the signal-to-noise ratio is wholly adequate for demodulation and decoding at the simulated bitrates unless the cubesat exits the main beam. Secondly, and fortunately due to the use of a software radio architecture, we show that it is possible to successfully receive signals from most cubesats for the entire 4-day simulation. Due to the signal-to-noise ratio being sufficient for demodulation even after the side-lobe’s 17dB reduction in SNR, the software radio can still demodulate such cubesats as long as the radio is capable of re-establishing carrier lock as the cubesats leave the main beam and enter the side-lobe. Considering that the target application utilizes offline processing, a loss of lock can be detected and lock can be re-established by iterating over the data. Extensive simulations demonstrate these results.
The Mission Planning and Sequencing (MPS) element of Multi-Mission Ground System and Services (MGSS) provides space missions with multi-purpose software to plan spacecraft activities, sequence spacecraft commands, and then integrate these products and execute them on spacecraft. Jet Propulsion Laboratory (JPL) is currently is flying many missions. The processes for building, integrating, and testing the multi-mission uplink software need to be improved to meet the needs of the missions and the operations teams that command the spacecraft. The Multi-Mission Sequencing Team is responsible for collecting and processing the observations, experiments and engineering activities that are to be performed on a selected spacecraft. The collection of these activities is called a sequence and ultimately a sequence becomes a sequence of spacecraft commands. The operations teams check the sequence to make sure that no constraints are violated. The workflow process involves sending a program start command, which activates the Automatic Sequence Processor (ASP). The ASP is currently a file-based system that is comprised of scripts written in perl, c-shell and awk. Once this start process is complete, the system checks for errors and aborts if there are any; otherwise the system converts the commands to binary, and then sends the resultant information to be radiated to the spacecraft.
The most fundamental objective of all planetary missions is to return data. To accomplish this, a spacecraft is fabricated and built, software is planned and coded, and a ground system is designed and implemented. However, a systems engineering approach to determine how the collection of data drives ground system capabilities has received little attention.This paper defines a technique by which science objectives can be quantitatively evaluated. For illustrative purposes, it will be applied to NASA's Cassini Mission. This mission, to be launched in 1997, is an international endeavor designed to orbit Saturn for four years.The results of this systems engineering approach will show which science objectives drive specific ground system capabilities. In addition, this technique can assist system engineers in the selection of the science payload during pre-project mission planning; ground system designers during ground system development and implementation; and operations personnel during the mission.
In this infusion experiment, the Livingstone 2 (L2) model-based diagnosis engine, developed by the Computational Sciences division at NASA Ames Research Center, has been uploaded to the Earth Observing One (EO-1) satellite. L2 is integrated with the Autonomous Sciencecraft Experiment (ASE) which provides an on-board planning capability and a software bridge to the spacecraft's 1773 data bus. Using a model of the spacecraft subsystems, L2 predicts nominal state transitions initiated by control commands, monitors the spacecraft sensors, and, in the case of failure, isolates the fault based on the discrepant observations. Fault detection and isolation is done by determining a set of component modes, including most likely failures, which satisfy the current observations. All mode transitions and diagnoses are telemetered to the ground for analysis. The initial L2 model is scoped to EO-1's imaging instruments and solid state recorder. Diagnostic scenarios for EO-1's nominal imaging timeline are demonstrated by injecting simulated faults on-board the spacecraft. The solid state recorder stores the science images and also hosts: the experiment software. The main objective of the experiment is to mature the L2 technology to Technology Readiness Level (TRL) 7. Experiment results are presented, as well as a discussion of the challenging technical issues encountered. Future extensions may explore coordination with the planner, and model-based ground operations.
Projected for launch in the latter part of 1998, the Advanced X-ray Astrophysics Facility (AXAF), the third satellite in the Great Observatory series, promises to dramatically open the x-ray sky as the Hubble and Compton observatories have done in their respective realms. Unlike its companions, however, AXAF will be placed in a high altitude, highly elliptical orbit (10,000 x 100,000 km), and will therefore be subject to its own unique environment, spacecraft and science instrument constraints and communication network interactions. In support of this mission, ground operations personnel have embarked on the development of the AXAF Offline System (OFLS), a body of software divided into four basic functional elements: (1) Mission Planning and Scheduling, (2) Command Management, (3) Altitude Determination and Sensor Calibration and (4) Spacecraft Support and Engineering Analysis. This paper presents an overview concept for one of these major elements, the Mission Planning and Scheduling subsystem (MPS). The derivation of this concept is described in terms of requirements driven by spacecraft and science instrument characteristics, orbital environment and ground system capabilities. The flowdown of these requirements through the systems analysis process and the definition of MPS interfaces has resulted in the modular grouping of functional subelements depicted in the design implementation approach. The rationale for this design solution is explained and capabilities for the initial prototype system are proposed from the user perspective.
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.
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.
The main theme of this edition of the annual Research and Technology Report is Mission Operations and Data Systems. Shifting from centralized to distributed mission operations, and from human interactive operations to highly automated operations is reported. The following aspects are addressed: Mission planning and operations; TDRSS, Positioning Systems, and orbit determination; hardware and software associated with Ground System and Networks; data processing and analysis; and World Wide Web. Flight projects are described along with the achievements in space sciences and earth sciences. Spacecraft subsystems, cryogenic developments, and new tools and capabilities are also discussed.
The Autonomous Sciencecraft Software (ASE) is currently flying onboard the Earth Observing One (EO-1) Spacecraft. This software enables the spacecraft to autonomously detect and respond to science events occurring on the Earth. The package includes software systems that perform science data analysis, deliberative planning, and runtime robust execution. Because of the deployment to the EO-1 spacecraft, the ASE software has stringent constraints of autonomy and limited computing resources. We describe these constraints and how they are reflected in our operations approach. A summary of the final results of the experiment is also included. This software has demonstrated the potential for space missions to use onboard decision-making to detect, analyze, and respond to science events, and to downlink only the highest value science data. As a result, ground-based mission planning and analysis functions have been greatly simplified, thus reducing operations cost.