Search NASA⌕ Search
Home/Archive/NASA NTRS

NASA NTRS · 20070017405

Phoenix Mars Scout UHF Relay-Only Operations

Lewicki, Christopher A.·Krajewski, Joel·Ilott, Peter·Dates, Jason
View original source ↗Export metadata ↓

Abstract

The Phoenix Mars Scout Lander will launch in August 2007 and land on the northern plains of Mars in May of 2008. In a departure from traditional planetary surface mission operations, it will have no direct-to-Earth communications capability and will rely entirely on Mars-orbiting relays in order to facilitate command and control as well as the return of science and engineering data. The Mars Exploration Rover missions have demonstrated the robust data-return capability using this architecture, and also have demonstrated the capability of using this method for command and control. The Phoenix mission will take the next step and incorporate this as the sole communications link. Operations for 90 Sols will need to work within the constraints of Odyssey and Mars Reconnaissance Orbiter communications availability, anomalies must be diagnosed and responded to through an intermediary and on-board fault responses must be tolerant to loss of a relay. These and other issues pose interesting challenges and changes in paradigm for traditional space operations and spacecraft architecture, and the approach proposed for the Phoenix mission is detailed herein.

Explore related subjects

fault protectionspacecraft architecturemission operationstelecommunicationsMarsPhoenix Mars Scout Mission

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Lewicki, Christopher A., Krajewski, Joel, Ilott, Peter, Dates, Jason. 2006-06-19. Phoenix Mars Scout UHF Relay-Only Operations. https://ntrs.nasa.gov/citations/20070017405

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↗