Search NASA⌕ Search

SEARCH · Search NASA

Results for “fault protection”

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 127 records · Page 7

Feature Acquisition with Imbalanced Training Data

This work considers cost-sensitive feature acquisition that attempts to classify a candidate datapoint from incomplete information. In this task, an agent acquires features of the datapoint using one or more costly diagnostic tests, and eventually ascribes a classification label. A cost function describes both the penalties for feature acquisition, as well as misclassification errors. A common solution is a Cost Sensitive Decision Tree (CSDT), a branching sequence of tests with features acquired at interior decision points and class assignment at the leaves. CSDT's can incorporate a wide range of diagnostic tests and can reflect arbitrary cost structures. They are particularly useful for online applications due to their low computational overhead. In this innovation, CSDT's are applied to cost-sensitive feature acquisition where the goal is to recognize very rare or unique phenomena in real time. Example applications from this domain include four areas. In stream processing, one seeks unique events in a real time data stream that is too large to store. In fault protection, a system must adapt quickly to react to anticipated errors by triggering repair activities or follow- up diagnostics. With real-time sensor networks, one seeks to classify unique, new events as they occur. With observational sciences, a new generation of instrumentation seeks unique events through online analysis of large observational datasets. This work presents a solution based on transfer learning principles that permits principled CSDT learning while exploiting any prior knowledge of the designer to correct both between-class and withinclass imbalance. Training examples are adaptively reweighted based on a decomposition of the data attributes. The result is a new, nonparametric representation that matches the anticipated attribute distribution for the target events.

Thompson, David R.↗

Aspect-Oriented Monitoring of C Programs

The paper presents current work on extending ASPECTC with state machines, resulting in a framework for aspect-oriented monitoring of C programs. Such a framework can be used for testing purposes, or it can be part of a fault protection strategy. The long term goal is to explore the synergy between the fields of runtime verification, focused on program monitoring, and aspect-oriented programming, focused on more general program development issues. The work is inspired by the observation that most work in this direction has been done for JAVA, partly due to the lack of easily accessible extensible compiler frameworks for C. The work is performed using the SILVER extensible attribute grammar compiler framework, in which C has been defined as a host language. Our work consists of extending C with ASPECTC, and subsequently to extend ASPECTC with state machines.

runtime verifications↗

Tools Ensure Reliability of Critical Software

In November 2006, after attempting to make a routine maneuver, NASA's Mars Global Surveyor (MGS) reported unexpected errors. The onboard software switched to backup resources, and a 2-day lapse in communication took place between the spacecraft and Earth. When a signal was finally received, it indicated that MGS had entered safe mode, a state of restricted activity in which the computer awaits instructions from Earth. After more than 9 years of successful operation gathering data and snapping pictures of Mars to characterize the planet's land and weather communication between MGS and Earth suddenly stopped. Months later, a report from NASA's internal review board found the spacecraft's battery failed due to an unfortunate sequence of events. Updates to the spacecraft's software, which had taken place months earlier, were written to the wrong memory address in the spacecraft's computer. In short, the mission ended because of a software defect. Over the last decade, spacecraft have become increasingly reliant on software to carry out mission operations. In fact, the next mission to Mars, the Mars Science Laboratory, will rely on more software than all earlier missions to Mars combined. According to Gerard Holzmann, manager at the Laboratory for Reliable Software (LaRS) at NASA's Jet Propulsion Laboratory (JPL), even the fault protection systems on a spacecraft are mostly software-based. For reasons like these, well-functioning software is critical for NASA. In the same year as the failure of MGS, Holzmann presented a new approach to critical software development to help reduce risk and provide consistency. He proposed The Power of 10: Rules for Developing Safety-Critical Code, which is a small set of rules that can easily be remembered, clearly relate to risk, and allow compliance to be verified. The reaction at JPL was positive, and developers in the private sector embraced Holzmann's ideas.

Source record↗

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗

Mars Science Laboratory CHIMRA/IC/DRT Flight Software for Sample Acquisition and Processing

The design methodologies of using sequence diagrams, multi-process functional flow diagrams, and hierarchical state machines were successfully applied in designing three MSL (Mars Science Laboratory) flight software modules responsible for handling actuator motions of the CHIMRA (Collection and Handling for In Situ Martian Rock Analysis), IC (Inlet Covers), and DRT (Dust Removal Tool) mechanisms. The methodologies were essential to specify complex interactions with other modules, support concurrent foreground and background motions, and handle various fault protections. Studying task scenarios with multi-process functional flow diagrams yielded great insight to overall design perspectives. Since the three modules require three different levels of background motion support, the methodologies presented in this paper provide an excellent comparison. All three modules are fully operational in flight.

sample processing↗

Managing Cassini Safe Mode Attitude at Saturn

The Cassini spacecraft was launched on October 15, 1997 and arrived at Saturn on June 30, 2004. It has performed detailed observations and remote sensing of Saturn, its rings, and its satellites since that time. In the event safe mode interrupts normal orbital operations, Cassini has flight software fault protection algorithms to detect, isolate, and recover to a thermally safe and commandable attitude and then wait for further instructions from the ground. But the Saturn environment is complex, and safety hazards change depending on where Cassini is in its orbital trajectory around Saturn. Selecting an appropriate safe mode attitude that insures safe operation in the Saturn environment, including keeping the star tracker field of view clear of bright bodies, while maintaining a quiescent, commandable attitude, is a significant challenge. This paper discusses the Cassini safe table management strategy and the key criteria that must be considered, especially during low altitude flybys of Titan, in deciding what spacecraft attitude should be used in the event of safe mode.

Attitude Control↗

Verification of Pointing Constraints for the Dawn Spacecraft

NASA's Dawn spacecraft, an ion-thrust science mission to Vesta and Ceres, has numerous pointing constraints critical for safe operation. Onboard software automatically chooses target attitudes but enforces only a simplified constraint set at slew endpoints. Onboard fault-protection also uses simplified constraints, and violations can result in safing events that dramatically consume mission margins for missed thrust. Lastly, for funding reasons the operations team is lean, forcing the development of month-long command sequences. These factors place a premium on reliable maneuver design, prediction, and verification against pointing constraints. This paper presents Slewth, a ground tool built to address these concerns.

Vanelli, C. Anthony↗

Extended Bright Bodies - Flight and Ground Software Challenges on the Cassini Mission at Saturn

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.

Sung, Tina S.↗

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

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

Matsumoto, Sun Kang↗

The 13th Technology of Deep Space One

On October 24th, 1998, the Deep Space One (DS-1) spacecraft launched aboard a Delta II rocket as the first step towards the bold task of testing and validating 12 new technologies for future missions. This launch also represented yet another thrilling event; namely, the successful test and validation of a 13th heretofore undisclosed technology: model-base-code-generation of the spacecraft's system-level fault-protection (FP) software from behavioral state diagrams and structural models.

model-based-code-generation↗

Experience Report: Using Formal Methods for Requirements Analysis of Critical Spacecraft Software

Formal specification and analysis of requirements continues to gain support as a method for producing more reliable software. However, the introduction of formal methods to a large software project is difficult, due in part to the unfamiliarity of the specification languages and the lack of graphics. This paper reports results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development. Our experience indicates that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain.

Formal↗

Runtime Verification - 17 Years Later

Runtime verification is the discipline of analyzing program executions using rigorous methods. The discipline covers such topics as specification-based monitoring, where single executions are checked against formal specifications; predictive runtime analysis, where properties about a system are predicted/inferred from single (good) executions; specification mining from execution traces; visualization of execution traces; and to be fully general: computation of any interesting information from execution traces. Finally, runtime verification also includes fault protection, where monitors actively protect a running system against errors. The paper is written as a response to the ‘Test of Time Award’ attributed to the authors for their 2001 paper [45]. The present paper provides a brief overview of what lead to that paper, what has happened since, and some perspectives on the future of the field.

Rosu, Grigore↗

Runtime Verification Logics A Language Design Perspective

Runtime Verification is a light-weight approach to systems verification, where actual executions of a system are processed and analyzed using rigorous techniques. In this paper we shall narrow the term’s definition to represent the commonly studied variant consisting of verifying that a single system execution conforms to a specification written in a formal specification language. Runtime verification (in this sense) can be used for writing test oracles during testing when the system is too complex for full formal verification, or it can be used during deployment of the system as part of a fault protection strategy, where corrective actions may be taken in case the specification is violated. Specification languages for runtime verification appear to differ from for example temporal logics applied in model checking, in part due to the focus on monitoring of events that carry data, and specifically due to the desire to relate data values existing at different time points, resulting in new challenges in both the complexity of the monitoring approach and the expressiveness of languages. Over the recent years, numerous runtime verification specification languages have emerged, each with its different features and levels of expressiveness and usability. This paper presents an overview and a discussion of this design space.

Reger, Giles↗

A Framework for Extending the Science Traceability Matrix: Application to the Planned Europa Mission

One of the most critical functions of the systems engineering requirements process for a large multi-instrument science-driven space mission is to successfully communicate customer expectations into a comprehensive and traceable science requirements flowdown. These requirements are essential to communicating the constraints on the scope of the science investigations and clarifying how multiple instruments contribute to a given science goal. They also provide insight into how the science goals of the whole mission are affected by design choices. There is little specific guidance available on best practices for developing this science-driven flowdown. A unified Science Traceability Matrix (USTM) contains a significant amount of information that can be leveraged for that purpose, but the USTM was not designed to directly produce a complete science requirements flowdown. Thus, starting with the principles codified in a USTM, the authors propose a framework that directly maps into the requirements flowdown and supports broader systems engineering processes while retaining its meaning to the science team. This Science Traceability and Alignment Framework, or STAF, defines a set of common definitions and valid relationships to structure communication across the project. In addition, STAF populates a network of information that can be useful to support complex mission analysis activities such as fault protection. This work discusses the highest-level implementation of the STAF, the project-domain or P-STAF, which describes an approach to decomposing customer requirements into science requirements. The planned Europa Mission is used as a case study for the implementation of this framework and its potential benefits to a project.

Susca, Sara↗

Cassini’s Grand Finale – Attitude Control Subsystem Performance During Proximal Ring Plane Crossings

On April 22nd, 2017, the Cassini spacecraft made its final close targeted flyby of Titan, placing Cassini in the gap between Saturn and its innermost D-ring for the first time ever of its mission at Saturn. Cassini proceeded to fly through this region 22 times, and on September 15th, 2017, Cassini plunged into Saturn’s atmosphere, concluding a remarkable, nearly 20-year mission. The attitude control subsystem performance during these 22 “proximal” orbits exceeded expectations. Prior to the proximal orbits mission, the effects of dust hazards, Saturn atmospheric drag torque on Cassini’s control authority, radiation on the sensitive instruments, bright body interferences to the star tracker, pointing discrepancies caused by trajectory deviations, and possible fault protection scenarios were assessed. This paper discusses the results of these risks experienced by the attitude control subsystem over the proximal orbits mission, any interesting telemetry observed, as well as any last minute procedural changes implemented along the way.

Sung, Tina S.↗

Radio-hosted Flight / Ground Interface for Operations Standardization

The interface between a spacecraft and its ground operations segment includes the flow of commands, configuration, and sequencing elements to the spacecraft, and the flow of telemetry and data products from the spacecraft. Creating and implementing a complete definition of this interface simplifies and standardizes mission operations, allowing easy sharing of operations personnel across missions. Early spacecraft featured a simple flight / ground interface (FGI) using hardware command decoding in the radio, driven by technological limitations of the time. Modern spacecraft use command and data handling (CDH) avionics on which flight software executes, which in turn controls and configures the mission, executes subsystem and instrument instructions, and implements critical fault protection actions. Deep space missions feature advanced operations software for running sequenced activities over a period of weeks, which allows them to function with only infrequent ground contact. This approach comes at the cost of increased complexity in the FGI, requiring expensive modifications to heritage flight software and ground systems. By hosting the interface in the radio instead of the CDH avionics, modern missions can approximate the FGI design simplicity of early spacecraft, with significant advantages for vendor competition, lowered costs, standardization of operations, and reduction of implementation risk.

Lock, Patricia D.↗

InSight Mars Lander Instrument Deployment Arm Flight Software

The Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) lander landed on Mars on November 26, 2018 and continues to investigate the internal structure of the planet two years later. The Instrument Deployment Arm (IDA), a robotic arm on the lander, was used to deploy the science instrument payloads from the lander deck to the surface of Mars and to take images of the lander and the surrounding environment. This was the first precision deployment and release by a robotic arm on another planet. After deploying the instruments, the IDA has been used for instrument commissioning, scientific data gathering, and to assist with troubleshooting one of the science instruments. This paper provides a high-level summary of the flight software that controls the IDA. The paper provides an overview of the IDA software interfaces, task structure, command handling strategy, motion specification, motion planning, motor control, grapple control, fault protection, and telemetry.

Ali, Khaled S.↗