REG NASA-LLIS-2048-2009 Lessons Learned Autonomous Transfer to Reaction Wheel Control May Lead to Safing Instability.pdf

1、Lessons Learned Entry: 2048Lesson Info:a71 Lesson Number: 2048a71 Lesson Date: 2009-4-14a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Stephen J. Waydoa71 POC Email: Stephen.J.Waydojpl.nasa.gova71 POC Phone: 818-354-4796Subject: Autonomous Transfer to Reaction Whe

2、el Control May Lead to Safing Instability Abstract: In-flight the EPOXI spacecraft exhibited a safe mode instability after a portion of the torque distribution was assigned to a reaction wheel that had been powered down. It was determined that safing assumes that all wheels are operational and does

3、not check the power state of each wheel. It would not significantly increase flight software complexity for safing to check the status of each wheel. Safing designers should also consider avoiding reliance on a software flag to activate a set of RWAs, disabling auxiliary controllers while in safe mo

4、de, avoiding autonomous switching from thruster to RWA control, disabling unnecessary attitude control performance enhancement features while in safe mode, and scrutinizing new features that may have unintended consequences when added to heritage systems.Description of Driving Event: In February 200

5、8, The EPOXI (Extrasolar Planet Observation and Deep Impact Extended Investigation) spacecraft autonomously entered sun safe mode. This state was an appropriate spacecraft response to excessive roll rate errors caused by (1) a reaction wheel assembly (RWA) reaching a speed limit, and (2) fault prote

6、ction (FP) disabling another wheel because an incorrect parameter specification indicated that the wheel exceeded the allowable temperature (Reference (1). However, 40 minutes later the spacecraft began tumbling, FP commanded multiple swaps between redundant attitude control hardware components, and

7、 the flight system re-entered safe mode 5 more times in rapid succession before stability was restored. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-This safing instability was traced to a flight software design feature that may have been inherite

8、d from Earth orbiting missions and intended to simplify safing. Safing does not check the power state of each RWA; instead, it always assumes that all four wheels are exercising attitude control. A “null-space controller“ that balances the speed of the wheels is normally deactivated by software when

9、 fewer than 4 wheels are used for control. But because safing made it appear as if all 4 wheels were available despite the disabled wheel, the controller sent to the failed wheel a portion of the torque needed to correct the initially small attitude errors. In correcting for the conditions that caus

10、ed the initial safing, the incorrect torque distribution to the wheels worsened the initial anomaly to the point of attitude instability. Although the conditions that caused the February 2008 failure are not likely to recur, a variety of credible initial safing events could lead to a similar instabi

11、lity for EPOXI- and potentially other missions. The EPOXI project considered implementing a flight software code change that would enable safe mode to recognize which RWAs are powered, but the project declined to undergo the extensive analysis and test that would be required. Instead, the project op

12、ted to upload a minor change to the sun safing sequence that disables the null-space and torque minimization controllers for the RWAs upon safe mode entry and restores their operation upon safe mode recovery (Reference (2). References: 1. “5 Safing Events After Initial Safing, DOY 2008-048,“ JPL Inc

13、ident Surprise Anomaly (ISA) No. Z92243, February 17, 2008. 2. S. Waydo, et. al., “EPOXI 2008-048 Safing Event Analysis and Recommended Actions,“ June 23, 2008. 3. “Final Report of the NASA Study on Flight Software Complexity,“ NASA Office of the Chief Engineer, March 5, 2009, http:/oceexternal.nasa

14、.gov/OCE_LIB/pdf/1021608main_FSWC_Final_Report.pdf Lesson(s) Learned: 1. A system that permits safe mode to “use“ all four RWAs regardless of the power state of the wheels may minimize flight software complexity, but it may pose an elevated risk of unintended consequences. For EPOXI, it caused erron

15、eous activation of auxiliary controllers. 2. The null-space and torque minimization controllers rely on a software flag for activation of a set of RWAs instead of directly interrogating each RWA on its operational state. The EPOXI anomaly demonstrated that such a flag can be inconsistent with the ac

16、tual hardware available for attitude control. 3. Auxiliary controllers (e.g., the null-space and torque minimization controllers) enhance the attitude control performance of the spacecraft during nominal flight operations, but their Provided by IHSNot for ResaleNo reproduction or networking permitte

17、d without license from IHS-,-,-operation is not essential to stable operation when the spacecraft is in safe mode. The controllers add a degree of unpredictability to the safing performance, and they complicate testing of the safing logic over the full range of failure scenarios. 4. During safe mode

18、, the EPOXI flight software design mandates a transition from attitude control by thrusters back to attitude control by RWAs without review by ground controllers. This feature may have been inherited from missions that have less propellant mass margin and seek to speed the transition from thruster c

19、ontrol to conserve propellant and maximize satellite lifespan. However, autonomous transition to wheel control introduces a plethora of possible failure modes. 5. The EPOXI flight software was derived from a heritage system that (1) lacked the capability to track the RWA hardware set that was actual

20、ly active and (2) would power down a wheel in fewer fault conditions. The EPOXI FP authority to power down a wheel thus represented a new capability, and a more thorough scrub of the flight system heritage logic (defining when to use the auxiliary controllers) might have exposed the attendant risks.

21、Recommendation(s): 1. Incorporating coding in the safing logic that would check which RWAs are truly available, and using the correct control distribution matrix (to torque the corresponding spacecraft mechanical axes) for that set of RWAs would add only marginally to the complexity of attitude cont

22、rol during safing. 2. A robust design solution would have the auxiliary controllers check the actual state of each RWA prior to “using“ them, rather than relying on a secondary control system flag. 3. To further simplify spacecraft safing, consider a flight software design that disables auxiliary co

23、ntrollers (and any other unnecessary attitude control performance enhancement features) while in safe mode. 4. For deep space missions with substantial propellant margin, consider a simple safing design where attitude control relies on the smallest and most trusted set of hardware. 5. Devote extra e

24、ffort to re-evaluating assumptions built into heritage systems when adding new features that may have unintended consequences. (Reference (3) Evidence of Recurrence Control Effectiveness: JPL has referenced this lesson learned as additional rationale and guidance supporting Paragraph 6.6 (“Engineeri

25、ng Practices: Inheritance“) in the Jet Propulsion Laboratory standard “Flight Project Practices, Rev. 7,“ JPL DocID 58032, September 30, 2008. In addition, JPL has referenced it supporting Paragraph 4.7.2 (“Flight System Design: Propulsion System Design - Sizing“) and Paragraph 4.9.2.2 (“System Faul

26、t Protection Design: Fault Protection Response- Flight System Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Safing“) in the JPL standard “Design, Verification/Validation and Operations Principles for Flight Systems (Design Principles),“ JPL Documen

27、t D-17868, Rev. 3, December 11, 2006.Documents Related to Lesson: N/AMission Directorate(s): a71 Sciencea71 Space OperationsAdditional Key Phrase(s): a71 0.“a71 0.“a71 0.“a71 1.Software Engineeringa71 0a71 0a71 1.Mission operations systemsa71 0.“a71 1.Flight Equipmenta71 1.Flight Operationsa71 1.Ground Operationsa71 1.Hardwarea71 1.Softwarea71 1.SpacecraftAdditional Info: a71 Project: EPOXIApproval Info: a71 Approval Date: 2009-07-16a71 Approval Name: mbella71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-