REG NASA-LLIS-0391-1995 Lessons Learned - Galileo Spacecraft Safing Recovery Anomalies.pdf

《REG NASA-LLIS-0391-1995 Lessons Learned - Galileo Spacecraft Safing Recovery Anomalies.pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-0391-1995 Lessons Learned - Galileo Spacecraft Safing Recovery Anomalies.pdf（3页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 0391Lesson Info:a71 Lesson Number: 0391a71 Lesson Date: 1995-05-30a71 Submitting Organization: JPLa71 Submitted by: S.R. Tyler / J.O. BlosiuSubject: Galileo Spacecraft Safing Recovery Anomalies Abstract: The Galileo mission twice experienced difficulties with recovery from saf

2、ing errors due to a lack of a formal safing recovery plan and to software/documentation that had not been kept current on spacecraft states. Maintain and update an anomaly recovery plan, log spacecraft event updates, take care in reusing previously successful command packages, and identify nonstanda

3、rd ground system configurations.Description of Driving Event: Two Galileo Spacecraft anomalies occurred during the week of September 12, 1994. Several difficulties were encountered during the recovery from these anomalies.The first anomaly was a Data Bulk Unit Memory (DBUM) parity error on the Galil

4、eo Command and Data Subsystem (CDS). This nonprivileged error resulted in spacecraft safing but did not bring down either CDS string. In response to this anomaly, the flight team developed a special privileged command program to isolate the failed memory byte. Although this program was almost identi

5、cal to a recent successfully run program, it required a nonstandard ground system configuration for command translation. This configuration was not established, causing the second anomaly which brought down the CDS A-string and re-executed safing.During the recovery from this second safing, an exist

6、ing recovery file was left unchanged from a year earlier, even though the one-way light time had doubled. As a result, an inappropriate Telemetry Modulation Unit (TMU) modulation index command was uplinked, causing a short data outage.During both recovery efforts, it was believed that the system fau

7、lt protection associated with safing had turned off the High Voltage (HV) to the Heavy Ion Counter (HIC). In fact, a patch had been Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-implemented a year earlier, which prevented the fault protection from

8、turning off the HIC HV. A lack of proper configuration management along with an inadequate check of the spacecraft state created this confusion. Since a prolonged lack of HV to the HIC would permanently damage the HIC, the project was forced to consider a risky proposal to switch the HIC to the only

9、 remaining working CDS string in an unnecessary attempt to get the HIC HV back on.The overall recovery time was 12 days. Had the spacecraft been in a critical operation mode, this long recovery time could have been more detrimental. A standardized anomaly recovery plan would have helped avoid some o

10、f the above problems.Additional Keyword(s): CommandingReference(s): IOM GLL OET-95-023-GMcS-SRT, Jan. 20, 1995, Spacecraft Anomaly Recovery and Lessons Learned for the CDS Anomalies.Lesson(s) Learned: 1. No formal safing recovery plan existed. Coupled with an ambitious deadline for recovery completi

11、on, this resulted in inadequate review, inspection, checking and testing of the recovery package.2. Documentation relating to pre-fault and post-fault spacecraft states was not kept current, and the configuration management system to log updates to system fault protection changes was lacking.3. Spac

12、ecraft state is not always easy to identify and errors in spacecraft state determination are possible. This caused some confusion during this event.4. Software packages that have worked in the past could prove to be faulty or inappropriate for the current spacecraft state.5. It is risky to depend on

13、 nonstandard ground system configurations in constructing commands.Recommendation(s): 1. Priority should be given to maintain and update an anomaly recovery plan with an explicitly defined anomaly recovery team, with backups, and roles for each team member.2. Establish a configuration management sys

14、tem to log spacecraft event updates including documentation for software updates, commands, pre-fault and post-fault spacecraft states and anomaly resolution.3. Be prepared to immediately delay, delete or redo less-critical activities to enable highly reliable recovery work.4. Care must be taken whe

15、n reusing previously successful command packages.5. Ensure that nonstandard ground system configurations are clearly identified in operational instructions.Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Evidence of Recurrence Control Effectiveness:

16、N/ADocuments Related to Lesson: N/AMission Directorate(s): N/AAdditional Key Phrase(s): a71 Configuration Managementa71 Softwarea71 SpacecraftAdditional Info: Approval Info: a71 Approval Date: 1995-04-24a71 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-,-,-