REG NASA-LLIS-0559-1997 Lessons Learned Redundant Verification of Critical Command Timing (1995).pdf

《REG NASA-LLIS-0559-1997 Lessons Learned Redundant Verification of Critical Command Timing (1995).pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-0559-1997 Lessons Learned Redundant Verification of Critical Command Timing (1995).pdf（3页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 0559Lesson Info:a71 Lesson Number: 0559a71 Lesson Date: 1997-05-29a71 Submitting Organization: JPLa71 Submitted by: J. Blosiu/D. OberhettingerSubject: Redundant Verification of Critical Command Timing (1995) Abstract: When a new mission software release was uploaded to the spa

2、cecraft, the inflight upload failed to include a software patch that had been written to fix a defective countdown timer. Because an independent “watchdog timer” was planned, but never implemented due to constrained project resources, the thrusters continued to fire after the desired shutdown time a

3、nd the mission was terminated. Recommendations centered on the need for rigorous software configuration management, a watchdog timer to terminate operations, and testbed verification of in-flight software updates.Description of Driving Event: Flight software for a recent mission included a safety fe

4、ature in which the flight computer initiated a command sequence for enabling the thrusters. It also started a countdown timer which limited the duration of the burn. Flight software contained a known defect: whenever numerical computations produced an overflow, the calculations generated false resul

5、ts. When interplanetary mission software was uploaded following conclusion of the first science objective of the mission, the upload failed to include a software patch which had been written to fix the defect.When the thrusters were enabled for a spacecraft pointing maneuver, the flight computer per

6、formed calculations which generated a numeric overflow. A floating point interrupt occurred, and the processor generated erroneous commands affecting various spacecraft functions, including the propulsion subsystem and the countdown timer. With this timer not functioning, the thrusters continued to

7、fire after the desired shutdown time.The 15-minute ground response to the fault allowed the loss of too much fuel to continue the mission. An independent watchdog timer*, redundant with the countdown timer, was planned but Provided by IHSNot for ResaleNo reproduction or networking permitted without

8、license from IHS-,-,-never implemented due to constrained project resources.Contributing Factors:1. Inadequate Operational Configuration Management. The functions of configuration management and software performance analysis and repair lacked adequate staffing.2. Inadequate Redundancy Design and Ove

9、rflow Detection. Spacecraft hardware and software did not provide redundancy checking on the performance of software, such as fault protection monitors, to detect, diagnose and recover from an overflow condition.3. Insufficient Processing Capability. The spacecraft computer was selected chiefly for

10、its physical attributes - principally mass and radiation tolerance - rather than for its computational power. The decision to omit a watchdog timer was influenced by this hardware limitation.4. Lack of Post-Launch Anomaly Analysis and Software Repair Capability. Only a single software development an

11、d simulation model was available for use by the flight project, and it was used continually after launch to generate flight sequences. This meant that the model was unavailable to generate software revisions to fix known bugs, so various software patches had to be uploaded throughout the mission.* W

12、atchdog Timer: A software module which works in conjunction with a hardware time limiter to anticipate periodic receipt of a system health indication and, in the absence of such indication, initiates a system restart, interrupt, or return to a prior state.Lesson(s) Learned: 1. Maintain a rigorous so

13、ftware configuration management program.2. Provide flight software with an independent watchdog timer to terminate operations which exceed the specified maximum time duration.3. Whenever possible, verify in-flight software updates in a testbed.Recommendation(s): See Lesson(s) LearnedEvidence of Recu

14、rrence 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): N/AAdditional Info: Approval Info: a71 Approval Date: 1997-08-13a71 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-,-,-