1 / 15

MAVEN Particles and Fields Operational Flight Software Code Walkthrough Fault Protection

MAVEN Particles and Fields Operational Flight Software Code Walkthrough Fault Protection Peter R. Harvey. Fault Protection (FP). Failure detection and correction (FDC) requirements, approach, and detailed design.

lassie
Download Presentation

MAVEN Particles and Fields Operational Flight Software Code Walkthrough Fault Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MAVEN • Particles and Fields • Operational Flight Software • Code Walkthrough • Fault Protection • Peter R. Harvey

  2. Fault Protection (FP) Failure detection and correction (FDC) requirements, approach, and detailed design • R1. The spacecraft shall provide the instrument zone alert states to the PFDPU, RSDPU, and NGIMS at a rate of once a second for the following: • EUV boresight in Ram below parameterized altitude • SEP 1 parameterized rectangular FOV 1 in Sun • SEP 1 parameterized rectangular FOV 2 in Sun • SEP 2 parameterized rectangular FOV 1 in Sun • SEP 2 parameterized rectangular FOV 2 in Sun • Ambient Density STATIC > parameterized density limit • Ambient Density SWIA/SWEA > parameterized density limit • Ambient Density EUV > parameterized density limit • IUVS parameterized rectangular FOV in Sun • Ambient Density IUVS > parameterized density limit • Ambient Density NGIMS > parameterized density limit • R2. The payloads shall respond to a transition into a zone alert region by putting the affected instruments into a known safe state until a transition out of the zone alert region occurs. • R3. The payload shall respond to a transition into a zone alert region by blocking all internally sequenced and spacecraft initiated commands that would put an instrument into an unsafe instrument state until a transition out of the zone alert region occurs. • R4. The payloads shall issue a safe me request if the affected instrument is unable to properly configure upon transition into a zone alert region. Instruments shall stop generating HeartBeat messages. • R5. The payloads shall configure all affected instruments into a safe state if a zone alert message has not been received for a parameterized amount of time. • R6. The payloads shall configure all affected instruments into a safe state upon power up until a zone alert status is established. • R7. HeartBeat should indicate PFDPU is fully functional, meaning TBD (should be sent every 1 second).

  3. FP Requirements Associated Requirements • P1. Users must be able to disable HV or Door operations, regardless of S/C Zone Alerts. • (e.g. PF GSE cannot release Zone Alert and allow HV to ramp up when we don’t want it to. ) • P2. Door Actuations have a timeout following actuation of TBD seconds for the SMA to cool down. Implementation Details • Telemetry Task does not itself need to be monitored. If it fails, the S/C will know and take action. • When Tasks succeed, they clear their respective “time-since-task” register. • PF will principally rely upon Relative Time Sequences for Open/Close or HVON/HVOFF sequences. • PF FSW will have two independent software activities: one for safing actions, one for safety verification. • Each safing action expected duration will be independent of others and will be commandable • If you remove power from PF, hardware circuits will safe the HV and will close the EUV, SEP1, SEP2 doors within 5 minutes. On power up, PF is guaranteed to be safe (meet R6). • If you remove power from STATIC, SWEA or SWIA, their High Voltages are zero. So, before asking for the Spacecraft to safe the PF, the PF FSW would prefer to turn off these non-complying instruments.

  4. FP HV Details HV Registers These are high voltages, each separately controlled, so they all need to come down to be safe. SWEA: SWEMCPHV SWENRHV Note SWENRHV does not have a DAC. It just comes on to full scale when you enable it. Analyzer, Def1, and Def2 HV are based on NRHV. If NRHV is low, the others have to be. SWIA: SWIMCPHV SWIDefRawV SWISwpRawV Note – the last two share a single control – they should ramp up and down together. Analyzer, Def1, and Def2 HV are based on DefRaw and SwoRaw. If DefRaw and SwpRaw are low, the others have to be. STATIC: STAAccHV STAMCPHV STADefRawV STASwpRawV Note – the last two share a single control – they should ramp up and down together. Analyzer, Def1, and Def2 HV are based on DefRaw and SwoRaw. If DefRaw and SwpRaw are low, the others have to be.

  5. FP Definitions • Safing Status • Quick digest on all requests and measures • “Allowed” register is combination of Zones and User Enables registers. • “Instrument Status” is independent measures of what’s actually happening. Safing Status can be returned in “Safe Me” message

  6. FP CMD & TM Tasks • CMD Task • Decodes all S/C messages • ZoneAlerts Reset Timer[6] • TM Task • Determines “Safe Me” status from safety failures or task stoppages (meets R5, R7). • Will not send normal telemetry including NOOP (Heartbeat) when “Safe Me” is being req’d (meets R4)

  7. FP Safing Task, Failures • Has_Failed( bit ) • If the Instrument Status bit is safe, then returns(NotFailed) • If the bit is Allowed, returns( NotFailed). • Otherwise, the Instrument is out-of-compliance. The respective Timer is incremented. • If the Timer exceeds its Limit, then it returns (Failed=1) • Safing Task • Computes the Instrument Status register (6 bits) • Computes what is Allowed by a combination of Zone Alerts and User Enables. • Calls Door and HV managers to act (meets R2). • Calls Power managers to shut off non-complying instruments (meets R2).. • Clears its task timer. A failure is an unallowed state for a period of time. Status is developed by reading back from electronics, not by FSW variables.

  8. FP EUV Aperture • IsEUVOpen() • FSW reads the 2-bit status of the EUV Ap • Compares that to the Open & not-Closed condition. • IsEUVAllowed() • If either “Boresightin RAM” or “Density High” ZoneAlerts, then EUV Aper is not allowed. • If user Enable is low, EUV Aper is not allowed. • ManEUVAper() • If open but not allowed, this routine starts RTS (5) • If closed but allowed, this routine starts RTS(11) • Does not matter whether LPW/EUV power is On or Off

  9. IsSEP1 Allowed() SEP1 FOV1 in Sun? Yes Return( 0 ) Zone[1]=1? No SEP1 FOV2 in Sun? Yes Return( 0 ) Zone[2]=1? No User Enabled ? No Return( 0 ) Enable[1]=1? Yes If no SEP1 comm No Return( 0 ) Is Task[12] > Limit? Yes Low BiasMon => Sun Yes Return( 0 ) BiasMon > "-0.2V" OK, its allowed No Return( 1 ) SEP FP SEP1&2 Doors • IsSEP1Open() • FSW Selects SEP1 Door status and directly reads its status. • IsSEP1Allowed() • If either “SEP1 FOV1” or “SEP1 FOV2” ZoneAlerts, then SEP1 Door is not allowed. • If user Enable is low, SEP1 Door is not allowed. • ManSEP1Door() • If open but not allowed, this routine starts RTS[6], SEP1 Door Closure. • If closed but allowed, this routine starts RTS(11), SEP1 Door Open • If SEP is off, doors will close as a result. • Identical logic used in SEP2

  10. FP STATIC HV • STAT Mgr() • Decodes STATIC messages • Resets Timer(9) when HSK message found. • Resets its timer when STATIC is off. • IsSTATHVOn() • If STATIC Off, HV is off. • If any HV > 100V, then HV is ON. • IsSTATAllowed() • If Zone Alert[5]=1 then No. • If User Enable[3]=0, then No.

  11. FP STATIC HV • ManSTATHV() • If STATIC is off, HV is off so exit. • If HV is ON but not allowed, this routine starts RTS[8], STATIC HV Off. • If HV is OFF but allowed, this routine starts RTS(14), STATIC HV On • ManSTATPower() • If no HSK coming out, then turn STATIC off. • If HV not complying, then turn STATIC off.

  12. FP SWIA HV • SWIA Mgr() • Decodes SWIA messages • Resets Timer(10) when HSK message found. • Resets its timer when SWIA is off. • IsSWIAHVOn() • If SWIA Off, HV is off. • If any HV > 100V, then HV is ON. • IsSWIAAllowed() • If Zone Alert[6]=1 then No. • If User Enable[4]=0, then No.

  13. FP SWIA HV • ManSWIAHV() • If SWIA is off, HV is off so exit. • If HV is ON but not allowed, this routine starts RTS[9], SWIA HV Off. • If HV is OFF but allowed, this routine starts RTS(15), SWIA HV On • ManSWIAPower() • If no HSK coming out, then turn SWIA off. • If HV not complying, then turn SWIA off.

  14. FP SWEA HV • SWEA Mgr() • Decodes SWEA messages • Resets Timer(11) when HSK message found. • Resets its timer when SWEA is off. • IsSWEAHVOn() • If SWEA Off, HV is off. • If any HV > 100V, then HV is ON. • IsSWEAAllowed() • If Zone Alert[6]=1 then No. • If User Enable[5]=0, then No.

  15. FP SWEA HV • ManSWEAHV() • If SWEA is off, HV is off so exit. • If HV is ON but not allowed, this routine starts RTS[10], SWEA HV Off. • If HV is OFF but allowed, this routine starts RTS(16), SWEA HV On • ManSWEAPower() • If no HSK coming out, then turn SWEA off. • If HV not complying, then turn SWEA off.

More Related