1000 words
On December 11, 1998, NASA launched the Mars Climate Orbiter (MCO). The mission of the MCO was to gather Martian climate data and serve as a relay station for the Mars Planet Lander (MPL), which would follow shortly thereafter. For nine months the MCO traveled through space. Some unplanned course corrections were executed during the trip, but no major issues were identified [1]. On September 23, 1999, the MCO entered Martian atmosphere. It began an orbit that would take it temporarily out of radio contact behind the planet, as expected. The satellite was never heard from again.
Subsequent investigation revealed that a systemic failure caused the MCO to enter the atmosphere at an altitude approximately 100 miles lower than planned. The failure was traced to thrusters designed to use Metric units but supplied data programmed in English units. The satellite may have incinerated in the Martian atmosphere or continued traveling through space, unable to communicate with Earth.
The Mars Climate Orbiter Mishap Investigation Board was commissioned to investigate what happened. This investigation report identified 8 contributing causes that allowed the units problem to remain undetected [1]. Figure 1 lists these contributing causes. A selected set of these items will be discussed in this paper and suggestions will be made to address them. This paper will also examine the concept of Intellectual Bias as it applies to the loss of the MCO. The investigation report also proposed 15 general recommendations for mitigating problems in the future. These recommendations are, in the main, generalizations that require specific mappings into existing processes used by NASA. The general recommendations are enumerated in Figure 4.
|
Contributing Cause [1] |
Intellectual Bias |
Technology shortcoming |
Operational Shortcoming |
Possible Solution |
||
|
|
Complexity bias |
Incentive bias |
Asymmetry bias |
|
|
|
|
1. Undetected mismodeling of spacecraft velocity changes |
|
|
Overvaluing the present state during flight. |
|
|
Ontology / Business Rule |
|
2. Navigation Team unfamiliar with spacecraft |
Remaining in comfort zone |
|
|
|
Management |
|
|
3. Trajectory correction maneuver number 5 not performed |
|
Following the herd |
Clinging to the assumption of goodness |
|
|
|
|
4. System engineering process did not adequately address transition from development to operations |
|
|
|
SIS (Software Interface Specification) not followed |
SIS (Software Interface Specification) not followed |
Formal Methods |
|
5. Inadequate communications between project elements |
|
|
|
Email was used to communicate, discussions became fragmented |
|
Modern collaboration tools for large projects: SharePoint. |
|
6. Inadequate operations Navigation Team staffing |
|
|
|
|
Management |
|
|
7. Inadequate training |
|
|
|
|
Management |
|
|
8. Verification and validation process did not adequately address ground software |
|
|
Clinging to the assumption of goodness |
|
|
XML file encodes data units and measurement systems. Unit testing. |
Figure 1 : Contributing Causes attributed to the MCO Mishap
Ontologies, in the context of knowledge sharing, are a means for making content-specific agreements [5]. Unfortunately, an ontology mismatch was identified after the MCO was lost during entry into the Martian atmosphere. As illustrated in Figure 1, Contributing Cause #1 is ‘Undetected mismodeling of spacecraft velocity changes.’ English units were assumed to be Metric units. This information could be captured in a business rule and stored for reference by all involved parties. Business rules can be formalized using the Semantics of Business Vocabulary and Business Rules, SBVR, as defined by the Object Management Group, OMG [3]. Business rules offer a framework for defining unambiguous terminology and rules along with techniques for expressing those rules. An effective business rule could be established to define how units are to be stored and represented.
|
Building a Business Rule |
|
|
1. Start with a fact |
Measurement has unit |
|
2. Add a model operator |
It is obligatory that Measurement has unit |
|
3. Quantify and Qualify |
It is obligatory that each Measurement has unit unit unit one and only one unit. |
Figure 2 : A Sample business rule to formalize the relationship between measurements and units
A software module named SM_Forces (Small Forces) computed velocity changes that were misinterpreted by the MOD thrusters. These velocity changes were stored in a file titled AMD. Internet research did not reveal the format of the AMD file or any specifics of the Small_Forces program [1]. It is reasonable to assume the AMD file did not contain unit semantics. A competent programmer writing the code on the thruster side would certainly have browsed the contents of the AMD file and applied necessary units conversion logic. Reformatting the file to include such semantics could mitigate a units discrepancy in future projects. An XML-formatted file could be contrived to specify English/Metric as well as specific units of measure for all the values in the file. Figure 3 illustrates how such an XML file might be structured.
|
<?xml version="1.0" encoding="ISO-8859-1"?> <VelocityChange> <System>Metric</System> <unit>Newtons</unit> <direction>X</direction> <Delta>100</Delta> </ VelocityChange> |
Figure 3 : A Sample XML file for encoding units semantics along with data
As described in the Mars Climate Orbiter Mishap Investigation Board Phase I Report, the Software Interface Specification (SIS) document for the SM_Forces program did in fact call for the use of metric units [1]. Developers of that software evidently ignored the SIS or otherwise misinterpreted it. Internet research did not reveal the actual SIS involved in the MCO mishap, nor any other MSOP Project Software Interface Specification. A software audit by an independent third party may have exposed this problem. However, given the fact that an intermediate file was generated, a software audit could very well overlook identify a discrepancy between a specification document and that data file.
An effective solution would be to commission independent developers to write unit tests based on the SIS. Those developers would have written code to exercise the SM_Forces logic; hopefully they would not make the same mistake and their tests would expose the omission of the original developers.
Intellectual Bias
The failure of the MCO project cannot be attributed to failed computer hardware or mechanical difficulties. Thrusters and computers behaved properly. Systems did what they were programmed to do. This failure is solely attributable to operational issues occurring during the development of software and decisions made during the execution of the mission.
It can be shown that Intellectual Hazard contributed to the mishap. Intellectual Hazard consists of Complexity Bias, Incentive Bias, and Asymmetry Bias [2].
Complexity Bias is an inability to consider external circumstances [2]. It may also be the negative artifacts of ‘tunnel vision’ or oversimplification. The mismodeling of the AMD data is an example of this bias. As early as April of 1999, 5 months before mission failure, there was evidence of mismodeling as in-flight trajectory corrections did not produce desired results. Contributing Cause #1 in Figure 1 can be partially attributed to complexity Bias.
Incentive Bias is a willingness to ‘go with the flow’ or ‘follow the herd. [2]’ Contributing Cause #3 in Figure 1 refers to a situation in which a trajectory correction maneuver was discussed, but not executed. It is possible that if project members had been more assertive, the disaster could have been avoided despite units problems inherent in the navigation data.
Asymmetry Bias overvalues the present state of circumstances at the expense of possible changes that could alleviate problems [2]. Contributing Cause #8 in Figure 1 refers to an all too prevalent problem in systems: lack of testing. Testing is painful, stressful, and consumes resources. It does not produce tangible functional results. Lines of code or total functionality or whatever metric used to measure system development progress are not increased by adding additional testing. In the case of the Mars Climate Orbiter, properly applied testing would almost certainly have exposed a problem as significant as improper unit modeling.
Contributing Cause #3 in Figure 1 refers to a navigation correction as assertions of trajectory trouble were discussed by engineers. Management evidently ignored these potenbtial problems. Another example of Asymmetry Bias is described by [4] :
… various versions of the trajectory debate in the final days of the flight indicate that in the face of uncertainty, decision-makers clung to the assumption of goodness; assertions of trajectory trouble had to be proved rigorously. Just the opposite attitude should have ruled the debate.
Conclusion
MCO: Faults and Fixes Bill Nicholson Trustworthy Embedded Systems, Spring 2014, Dr. Carla Purdy
In this paper we discussed a selected set of Contributing Causes of the Mars Climate Orbiter project failure. Suggestions were be made to address the issues. The paper also examined the concept of Intellectual Bias as it applies to the loss of the MCO.
Page 1 of 8
|
MPL Recommendations |
|
|
|
· Conduct software audit for specification compliance on all data transferred between JPL and Lockheed Martin Astronautics |
|
|
|
· Verify Small Forces models used for MPL |
|
|
|
· Compare prime MPL navigation projections with projections by alternate navigation methods |
|
|
|
· Train Navigation Team in spacecraft design and operations |
|
|
|
· Prepare for possibility of executing trajectory correction maneuver number 5 |
|
|
|
· Establish MPL systems organization to concentrate on trajectory correction maneuver number 5 and entry, descent and landing operations |
|
|
|
· Take steps to improve communications |
|
|
|
· Augment Operations Team staff with experienced people to support entry, descent and landing |
|
|
|
· Train entire MPL Team and encourage use of Incident, Surprise, Anomaly process |
|
|
|
· Develop and execute systems verification matrix for all requirements |
|
|
|
· Conduct independent reviews on all mission critical events |
|
|
|
· Construct a fault tree analysis for remainder of MPL mission |
|
|
|
· Assign overall Mission Manager |
|
|
|
· Perform thermal analysis of thrusters feedline heaters and consider use of pre-conditioning pulses |
|
|
|
· Reexamine propulsion subsystem operations during entry, descent, and landing |
|
|
Figure 4 : MPL Recommendations for addressing the Contributing Causes
References
[1] Stephenson, Arthur G., and others, Mars Climate Orbiter Mishap Investigation Board Phase I Report, November 10, 1999.
[2] Miller, Geoffrey P. and Rosenfeld, Gerald, Intellectual Hazard: How Conceptual Biases in Complex Organizations Contributed to the Crisis of 2008 (November 4, 2009). NYU Law and Economics Research Paper No. 09-43. Available at SSRN: http://ssrn.com/abstract=1499789 or http://dx.doi.org/10.2139/ssrn.1499789.
[3] Documents associated with Semantics of Business Vocabulary and Business Rules (SBVR), V1.2, http://www.omg.org/spec/SBVR/1.2/index.htm.
[4] Oberg, James, Why the Mars Probe Went Off Course, Spectrum Magazine December 1, 1999.
[5] Gruber, Thomas R., and Olsen, Gregory R., An Ontology for Engineering Mathematics, Fourth International Conference on Principles of Knowledge Representation and Reasoning, Gustav Stresemann Institut, Bonn, Germany, Morgan Kaufmann, 1994.