REG NASA-LLIS-0740-2000 Lessons Learned Deficiencies in Mission Critical Software Development for Mars Climate Orbiter (1999).pdf

1、Lessons Learned Entry: 0740Lesson Info:a71 Lesson Number: 0740a71 Lesson Date: 2000-02-24a71 Submitting Organization: JPLa71 Submitted by: David OberhettingerSubject: Deficiencies in Mission Critical Software Development for Mars Climate Orbiter (1999) Abstract: The root cause of the MCO mission los

2、s was an error in the “Sm_forces” program output files, which were delivered to the navigation team in English units (pounds-force seconds) instead of the specified metric units (Newton-seconds). Comply with preferred software review practices, identify software that is mission critical (for which s

3、taff must participate in major design reviews, walkthroughs and review of acceptance test results), train personnel in software walkthroughs, and verify consistent engineering units on all parameters.Description of Driving Event: Upon arrival at Mars in September 1999, the Mars Climate Orbiter (MCO)

4、 began a scheduled 16-minute Mars orbit insertion (MOI) maneuver to achieve orbit. Approximately 49 seconds before the anticipated occultation by Mars, communication was lost and never reestablished.The root cause of the mission loss was an error in the “Sm_forces“ program output files. The JPL MCO

5、review board determined that the files containing the magnitudes of the small impulses applied to the spacecraft had been delivered by the Spacecraft Operations Team to the Spacecraft Navigation Team in English units (pounds-force seconds) instead of the specified metric units (Newton-seconds). See

6、Lesson No. 0641, first paragraph under Lesson LearnedThe discrepancy in these files led to an underestimate (by a factor of at least 4) of the influence of the twice-a-day momentum wheel desaturation burns on the spacecraft trajectory. The cumulative effect of these small impulses led to a 169 km na

7、vigation disparity, which was catastrophic to the mission.The erroneous engineering units provided by these files to the navigation software were not discovered in the walkthroughs of requirements, design, code, and testing. Contrary to preferred Provided by IHSNot for ResaleNo reproduction or netwo

8、rking permitted without license from IHS-,-,-practice:1. The “Sm_forces“ software was misclassified as non-mission critical, which reduced the rigor of the review program.2. The Software Management and Development Plan (SMDP) was not followed in the walkthroughs of the “Sm_forces“ software, and the

9、overall training in the software walkthrough process was not adequate. Specifically, required persons were not always in attendance, the Software Interface Specification (SIS) was not used, minutes were not taken, and action items were not published.3. An (end-user) navigation representative was not

10、 specifically requested to be present at any of the major development phase reviews, software walkthroughs, or the software acceptance test.4. The “Sm_forces“ software interface with navigation software was not tested.5. There was no flowdown of requirements from the higher-level MCO SIS to the soft

11、ware requirements document.6. The “Sm_forces“ requirements specification did not state the required engineering units for parameters.References:1. Report on the Loss of the Mars Climate Orbiter Mission, JPL D-18441, JPL Special Review Board, November 11, 1999.2. Phase I Report, (NASA) Mars Climate O

12、rbiter Mishap Investigation Board, November 10, 1999.3. “Mars Climate Orbiter Mishap Investigation Board - Phase I Report“, Lesson Learned Number 0641, December 1, 1999.4. Corrective Action Notice No. Z66254, MCO-JPL/SRB Finding 4.2: “Software Development Process,“ November 23, 1999.Lesson(s) Learne

13、d: 1. Non-compliance with preferred software review practices may lead to mission loss.2. To identify mission critical software, require concurrent engineering and thorough review by a team of systems engineers, developers, and end users. See Lesson No. 0641, Recommendation #123. For all mission cri

14、tical software (or software interfaces between two systems or two major organizations), systems engineers, developers, and end users should participate in 1) major design reviews, 2) walkthroughs of requirements, design, and acceptance plans, and 3) examination of acceptance test results. See Lesson

15、 No. 0641, Recommendation #2, 8, 114. Train personnel in the proper conduct of software walkthroughs, including disseminating minutes to appropriate management, tracking action items, and reporting liens. See Lesson No. 0641, Recommendation #55. For mission critical software, specify and require ver

16、ification of consistent engineering units Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-on all parameters. See Lesson No. 0641, Recommendation #1Recommendation(s): Same as in Lesson LearnedEvidence of Recurrence Control Effectiveness: N/ADocuments

17、Related to Lesson: N/AMission Directorate(s): a71 Exploration Systemsa71 Sciencea71 Aeronautics ResearchAdditional Key Phrase(s): a71 Configuration Managementa71 Flight Operationsa71 Risk Management/Assessmenta71 Safety & Mission Assurancea71 Softwarea71 Spacecrafta71 Test & VerificationAdditional Info: Approval Info: a71 Approval Date: 2000-04-4a71 Approval Name: Eric Raynora71 Approval Organization: QSa71 Approval Phone Number: 202-358-4738Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-