Toward a Model-Based Approach for Flight System Fault Protection

Day, John; Meakin, Peter; Murray, Alex

Home/Archive/NASA NTRS

NASA NTRS · 20130009355

Toward a Model-Based Approach for Flight System Fault Protection

Day, John·Meakin, Peter·Murray, Alex

View original source ↗Export metadata ↓

Abstract

Use SysML/UML to describe the physical structure of the system This part of the model would be shared with other teams - FS Systems Engineering, Planning & Execution, V&V, Operations, etc., in an integrated model-based engineering environment Use the UML Profile mechanism, defining Stereotypes to precisely express the concepts of the FP domain This extends the UML/SysML languages to contain our FP concepts Use UML/SysML, along with our profile, to capture FP concepts and relationships in the model Generate typical FP engineering products (the FMECA, Fault Tree, MRD, V&V Matrices)

Explore related subjects

fault protection

Keep this discovery

Explore connections, maps & timelines

BibTeX RIS

Day, John, Meakin, Peter, Murray, Alex. 2012-03-08. Toward a Model-Based Approach for Flight System Fault Protection. https://ntrs.nasa.gov/citations/20130009355

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related reports

NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗

NASA NTRS2016

Cassini Operational Sun Sensor Risk Management During Proximal Orbit Saturn Ring Plane Crossings

NASA's Cassini Spacecraft, launched on October 15th, 1997 which arrived at Saturn on June 30th, 2004, is the largest and most ambitious interplanetary spacecraft in history. As the first spacecraft to achieve orbit at Saturn, Cassini has collected science data throughout its four-year prime mission (2004–08), and has since been approved for a first and second extended mission through 2017. As part of the final extended missions, Cassini will begin an aggressive and exciting campaign of high inclination, low altitude flybys within the inner most rings of Saturn, skimming Saturn’s outer atmosphere, until the spacecraft is finally disposed of via planned impact with the planet. This final campaign, known as the proximal orbits, requires a strategy for managing the Sun Sensor Assembly (SSA) health, the details of which are presented in this paper.

fault protection↗

NASA NTRS2013

The Unparalleled Systems Engineering of MSL's Backup Entry, Descent, and Landing System: Second Chance

Second Chance (SECC) was a bare bones version of Mars Science Laboratory's (MSL) Entry Descent & Landing (EDL) flight software that ran on Curiosity's backup computer, which could have taken over swiftly in the event of a reset of Curiosity's prime computer, in order to land her safely on Mars. Without SECC, a reset of Curiosity's prime computer would have lead to catastrophic mission failure. Even though a reset of the prime computer never occurred, SECC had the important responsibility as EDL's guardian angel, and this responsibility would not have seen such success without unparalleled systems engineering. This paper will focus on the systems engineering behind SECC: Covering a brief overview of SECC's design, the intense schedule to use SECC as a backup system, the verification and validation of the system's "Do No Harm" mandate, the system's overall functional performance, and finally, its use on the fateful day of August 5th, 2012.

fault protection↗