2001 Mars Odyssey: Systems Engineering Case Study

The 2001 Mars Odyssey spacecraft was launched on April 7th, 2001, and arrived at Mars on October 24th, 2001. Then began a three month aerobraking maneuver from Mars Insertion Orbit to the mapping orbit which ended on January 2002. The mission objectives of Odyssey were to detect water and ice, and to study the radiation environment of Mars as a part of the larger Mars Exploration Program objectives.

The science payload consisted of the Thermal Emissions Imaging System to detect the distribution of minerals on the Martian surface, the Gamma Ray Spectrometer to identify mineral and measure their abundance, and the Mars Radiation Environment Experiment to understand the risks radiation may pose to humans in Mars orbit. Odyssey has returned data of incredible scientific value including locations and quantities of water ice deposits on mars. At this point, Odyssey has completed all primary objectives and is currently supporting the Mars Exploration Rovers as a communications relay.

The design and development of Odyssey has been described as “long and arduous.” Ironically, the original “faster, better, cheaper” methodology arguably ultimately caused delays, resulting in a more expensive mission at greater risk, than if a more conservative budget and schedule had been assumed from the beginning. The failure of the Mars Climate Orbiter and Mars Polar Lander resulted in public pressure to take additional measures to ensure that Odyssey was a success. This led to a fundamental change to the systems engineering approach in the remaining development timeline. There are 5 significant systems engineering learning principles explored in this case study:

LP 1, Risks must be managed in the face of ambitious requirements. The Odyssey program was not given sufficient budget and schedule to manage risks. Requirements had to change when the Mars Climate Observer and Mars Polar Lander failed due to similar issues.

LP 2, The mission architecture must be derived with respect to the budget. The low-cost, high-risk design caused entire systems to be cancelled when those resources could have been devoted to making the launched system the best it could be.

LP 3, Margins for cost and schedule should be conservatively estimated. Compromises to subsystems mid-development to keep the mission architecture intact led to problems that prevailed throughout development.

LP 4, The number of anomalies will decrease over time. As the ground team familiarizes itself with mission operations, anomalies will decrease in number and become easier to mitigate.

LP 5, It is easier to mitigate risks when risks have been managed throughout the design. It was a rude awakening when a last-minute risk mitigation effort revealed incorrect assumptions and was forced to make adjustments before launch. 

Read the entire case study here

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s