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.
This paper reports on a simple, low-cost effort to streamline the configuration of the uplink software tools. Even though the existing ground system consisted of JPL and custom Cassini software rather than COTS, we chose a glueware approach--reintegrating with wrappers and bridges and adding minimal new functionality.
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 object of this project was to develop and calibrate quantitative models for predicting the quality of software. Reliable flight and supporting ground software is a highly important factor in the successful operation of the space shuttle program. The models used in the present study consisted of SMERFS (Statistical Modeling and Estimation of Reliability Functions for Software). There are ten models in SMERFS. For a first run, the results obtained in modeling the cumulative number of failures versus execution time showed fairly good results for our data. Plots of cumulative software failures versus calendar weeks were made and the model results were compared with the historical data on the same graph. If the model agrees with actual historical behavior for a set of data then there is confidence in future predictions for this data. Considering the quality of the data, the models have given some significant results, even at this early stage. With better care in data collection, data analysis, recording of the fixing of failures and CPU execution times, the models should prove extremely helpful in making predictions regarding the future pattern of failures, including an estimate of the number of errors remaining in the software and the additional testing time required for the software quality to reach acceptable levels. It appears that there is no one 'best' model for all cases. It is for this reason that the aim of this project was to test several models. One of the recommendations resulting from this study is that great care must be taken in the collection of data. When using a model, the data should satisfy the model assumptions.
The Ground Software Maintenance Facility (GSMF) is designed to support development and maintenance of spacelab ground support software. THE GSMF consists of a Perkin Elmer 3250 (Host computer) and a MITRA 125s (ATE computer), with appropriate interface devices and software to simulate the Electrical Ground Support Equipment (EGSE). This document is presented in three sections: (1) GSMF Overview; (2) Software Structure; and (3) Fault Isolation Capability. The overview contains information on hardware and software organization along with their corresponding block diagrams. The Software Structure section describes the modes of software structure including source files, link information, and database files. The Fault Isolation section describes the capabilities of the Ground Computer Interface Device, Perkin Elmer host, and MITRA ATE.
Instructions for the Ground Software Maintenance Facility (GSMF) system user is provided to operate the GSMF in all modes. The GSMF provides the resources for the Automatic Test Equipment (ATE) computer program maintenance (GCOS and GOAL). Applicable reference documents are listed. An operational overview and descriptions of the modes in terms of operator interface, options, equipment, material utilization, and operational procedures are contained. Test restart procedures are described. The GSMF documentation tree is presented including the user manual.
Extended bright bodies in the Saturn environment such as Saturn's rings, the planet itself, and Saturn's satellites near the Cassini spacecraft may interfere with the star tracker's ability to find stars. These interferences can create faulty spacecraft attitude knowledge, which would decrease the pointing accuracy or even trip a fault protection response on board the spacecraft. The effects of the extended bright body interference were observed in December of 2000 when Cassini flew by Jupiter. Based on this flight experience and expected star tracker behavior at Saturn, the Cassini AACS operations team defined flight rules to suspend the star tracker during predicted interference windows. The flight rules are also implemented in the existing ground software called Kinematic Predictor Tool to create star identification suspend commands to be uplinked to the spacecraft for future predicted interferences. This paper discusses the details of how extended bright bodies impact Cassini's acquisition of attitude knowledge, how the observed data helped the ground engineers in developing flight rules, and how automated methods are used in the flight and ground software to ensure the spacecraft is continuously operated within these flight rules. This paper also discusses how these established procedures will continue to be used to overcome new bright body challenges that Cassini will encounter during its dips inside the rings of Saturn for its final orbits of a remarkable 20-year mission at Saturn.
The NASA Office of Space Sciences and Applications is sponsoring a series of Space Shuttle missions named Astro-n which are dedicated to a variety of astronomical projects. These missions will be the first in which the Space Shuttle crew will be interactively operating an astronomical observatory which is fixed in the payload bay. The operation of an instrument in such an environment requires a considerable amount of software both on board and on the ground. The Spacelab Experiment Computer provides generalized interactive telemetry display and command processing services through the Experiment Computer Operating System. The experimenter must then design a software package for his Dedicated Experiment Processor which can provide complete control of his instrument as well as communicate with the Experiment Computer. This paper describes the design considerations and operational features of the Ultraviolet Imaging Telescope Dedicated Experiment Processor and Instrument Ground Support Equipment software.
This paper reports on a simple, low-cost effort to streamline the configuration of the uplink software tools.
Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.
SEDSAT-1 is designed to be a low cost scientific satellite which is to be used to perform a minimum of five tasks which include: (1) the acquisition of a number of important parameters associated with the tethering processes from the payloads perspective (such as accelerations incurred and imaging data of the tether during deployment), (2) to act as a remote sensing platform for making measurements of the Earth's Atmosphere (allowing research to be performed in such areas as vertical lightning observation, visible light spectrography, and cloud cover studies, (3) to act as a general purpose amateur radio communication satellite relaying information back to earth, (4) to demonstrate the feasibility of the deployment in low earth orbit of advanced technology such as the Gallium Arsenide Solar Cells, Nickel Metal Hydride batteries, and multi-chip module technology and, (5) to support student's active participation in applying the disciplines of engineering and science to space-based hardware platforms. The project includes the Three-axis Accelerometer System, TAS, Experiment which is designed to report the accelerations that the satellite undergoes during the tethering operations and during the second phase of the mission when the free floating satellite comes in contact with orbit debris. The SEASIS (SEDS Earth, Atmosphere, and Space Imaging System) is another SEDSAT experiment designed to provide images of the tether during its deployment and the earth during the second phase of the mission. To control these experiments and virtually all other satellite operations the Command Data System, CDS is employed. This system utilizes a moderate complexity micro-controller controlled by tasks operating under a real-time operating system to dynamically monitor and control the satellite. The scope of this researchers efforts has been in the general area of coordinating and assisting the student researchers with the development of the CDS and ground station interfaces. This included the low level CDS hardware design and the formulization of a general software plan and schedule for both the CDS and ground station portions of the project.
The Delta-T Processor (DTP) computes the instantaneous downtrack error in a specified orbiter onboard navigation state vector recovered via downlink telemetry. The downtrack error, expressed in units of time, is computed based on current incoming Earth based range and Doppler navigation tracking data and the ground selected onboard navigation state vector. The computed time difference when used to modify the timetag of the vector used for onboard navigation reduces the instantaneous downtrack error in this vector to within the threshold of the DTP, the input data, and the onboard software. This threshold is currently estimated to be approximately 2 to 4 nautical miles. The DTP is not restricted to using only onboard vectors. Any vector, either input via the manual entry device or accessible via the vector administration table, may be used. The DTP does not require that both data types be available.
Procedures are presented that allow the user to assemble tasks, link, compile, backup the system, generate/establish/print display pages, cancel tasks in memory, and to TET an assembly task without having to enter the commands every time. A list of acronyms is provided. Software identification, payload checkout unit operating system services, data base generation, and MITRA operating procedures are also discussed.
Explore the source record for details and available documents.
No abstract available
This paper is concerned with methods of measuring and developing quality software. Reliable flight and ground support software is a highly important factor in the successful operation of the space shuttle program. Reliability is probably the most important of the characteristics inherent in the concept of 'software quality'. It is the probability of failure free operation of a computer program for a specified time and environment.
This poster presents the coordinated efforts of the Mars Ascent Vehicle (MAV) software development teams, encompassing Flight Software, Ground Software, and Hardware-in-the-Loop Labs. This collaborative approach, which stems from the Artemis program, ensures efficiency in preparing for the Mars Sample Return (MSR) mission, focusing on the critical role of software integration for mission success.
The NASA Operational Simulator for Small Satellites (NOS3) showcases some of the Jon McBride Software Testing and Research (JSTAR) laboratories technologies on an open-source platform. NOS3 is a software digital twin providing a virtualized platform inside which you have your traditional flight software, ground software, environmental simulators, and middleware to keep all pieces in sync. NOS3 leverages the core Flight System (cFS), OpenC3 COSMOS, and NASA GSFC’s 42 software as the baseline to which additional research technologies can be developed. Current technologies to be demonstrated include NOS3 Igniter, constellation support, NASA JPL’s SYNOPSIS integration, and NASA GSFC’s OnAir. NOS3 Igniter is a GUI in which you can configure, build, and run your simulation. This along with improvements to the documentation and training available open source aims to reduce the ramp up time with new users and improve accessibility. As constellations introduce another level of complexity, it is important to ensure the baseline design reference mission covers all the basics required and allows users to experiment, understand, and test at all levels of the system. The Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) is an open-source tool developed by NASA JPL to enable data prioritization and planning. GSFC’s Onboard Artificial Intelligence Research (OnAIR) enables custom algorithm development written in python to interface with the flight software allowing scientists to develop what they need for the next generation of missions and easily interface back to the traditional flight software. During the presentation, a review and demonstration of the above technologies is planned along with a roadmap.