REG NASA-LLIS-0310--1994 Lessons Learned Mars Observer Inertial Reference Loss.pdf

1、Lessons Learned Entry: 0310Lesson Info:a71 Lesson Number: 0310a71 Lesson Date: 1994-03-03a71 Submitting Organization: JPLa71 Submitted by: G. T. Chien / J. O. BlosiuSubject: Mars Observer Inertial Reference Loss Abstract: Mars Observer experienced inertial reference loss on several occasions during

2、its cruise to Mars. These incidents were due to the lack of a detailed code walk-through, and to use of gyro noise values, obtained from in-house test, that were more optimistic than the manufacturers specifications. Do not depend on hardware performance being better than the manufacturers specifica

3、tion. Perform detailed code walk-through of critical software modules. Pay special attention to inherited critical software. Design the flight computer and software to permit necessary changes in flight.Description of Driving Event: Mars Observer experienced inertial reference loss on several occasi

4、ons during its cruise to Mars. Two classes of inertial reference loss have been observed:A. In early January 1993, the flight software was unable to identify any star that transited the celestial sensor assembly field of view. The unidentified stars count exceeded the “loss logic limit,“ and the fau

5、lt protection software commanded the spacecraft to the sun coning attitude contingency mode. This occurred three times before a temporary software script to widen the star identification tolerance was uplinked in order to artificially increase the attitude uncertainties, or covariances, used by the

6、software. Design flexibility of the fight computer and software allowed the software patch to be easily performed. It was suspected that the cause was due to the use of the more optimistic gyro noise parameters and values obtained from the in-house test results rather than the manufacturers specific

7、ations. Recovery time: 3 days per occurrence.B. During April and May 1993, three more incidents caused the spacecraft to declare inertial reference loss when the “sun monitor ephemeris“ test, which compares the expected new position with the measured positions, was violated. An algorithm error in th

8、e inherited flight software caused Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-the spacecraft attitude to be incorrectly estimated under certain conditions. A similar problem occurred on the Defense Meteorological Satellite Program (DMSP), an ear

9、th orbiting spacecraft built by the same contractor, that was using the same flight software. This algorithm error puts the spacecraft in additional jeopardy when the attitude covariances are large. Since the script that was intended to prevent the January incidents increases the covariances, the sc

10、ript acted as a catalyst for the three April/May anomalies. The review of the data indicated that no detailed code walk-through was performed on the software patch that widened the star identification tolerance. Recovery time: 5 days per occurrence.Additional Keyword(s): Attitude Determination, Star

11、 ScannerLesson(s) Learned: 1. Hardware performance based on in-house tests are not substitutes for manufacturer specifications for components whose performance varies (degrades) over mission life (gyros, etc.).2. Non-performance of detailed code walk-through for critical software could have serious

12、effects on spacecraft operation. The covariance program “bugs“ in the flight software should have been caught even before testing of the code.3. Inherited software designed for earth orbiting satellites may not be directly applicable to interplanetary spacecraft missions.4. Design flexibility of the

13、 flight computer and software is critical to the ability to uplink software patches for the correction of unexpected in-flight spacecraft anomalies.Recommendation(s): 1. Do not depend on hardware performance being better than the manufacturers specification.2. Perform detailed code walk-through of c

14、ritical software modules, and particularly of flight software patches.3. Special attention should be paid to flight critical software performance that is inherited from previous applications. Prior anomalies must be addressed.4. Allow sufficient flexibility in the flight computer and software to per

15、mit necessary changes in flight.Evidence of Recurrence Control Effectiveness: N/ADocuments Related to Lesson: N/AProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Mission Directorate(s): N/AAdditional Key Phrase(s): a71 Computersa71 Flight Equipmenta71 Softwarea71 Test & VerificationAdditional Info: Approval Info: a71 Approval Date: 1993-09-16a71 Approval Name: Carol Dumaina71 Approval Organization: 125-204a71 Approval Phone Number: 818-354-8242Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-