11-1 MAVEN PFP ICDR May 23-25, 2011 PF Flight Software Critical Design Review May , 2011 Peter R Harvey Mars Atmosphere and Volatile EvolutioN (MAVEN) Mission

11-2 MAVEN PFP ICDR May 23-25, 2011 Agenda 1.Software Management SwCDR Summary Software Development Plan Software Assurance Plan Software Risk Management Software Configuration Management Software Test Plan Requirements Verification Test Environment, Test Beds Software Maintenance Plan Software Change Requests/Problem Report System Software Deliverable Schedule/Status

11-3 MAVEN PFP ICDR May 23-25, 2011 Agenda 2.Software Design Flight Software Overview Hardware Context Module Design Detailed Design Boot Initializaton/Safing/Modes/RTS S/C Interface - Command, Time, Telemetry Data Collection, Data Processing Memory Requirements Data Compression CPU Usage Telemetry APIDs Fault Protection – (New Since PDR)

11-4 MAVEN PFP ICDR May 23-25, 2011 SwCDR Peer Review Review Agenda 1.Agenda: 2.Introduction 3.Project Overview 4.Management Overview 5.Development Process and Plans 6.Software Overview 7.Software Testing 8.Delivery, Installation, and Maintenance 9.Software status 10.Risks 11.Issues, TBDs, and action items 12.Abbreviations and Acronyms Review Agenda 1.Agenda: 2.Introduction 3.Project Overview 4.Management Overview 5.Development Process and Plans 6.Software Overview 7.Software Testing 8.Delivery, Installation, and Maintenance 9.Software status 10.Risks 11.Issues, TBDs, and action items 12.Abbreviations and Acronyms Review Team Stewart Harris; UCB (Chair) Ellen Taylor, Robert Abiad; UCB Jim Francis Stasia Habenicht, Doug Leland, David Hirsch; LMCO Steve Scott; NASA IIRT Bob Bartlett, Sara Haugh, Tom Jackson; NASA Maven Project Date: 5/09/2011 Time: 1-5pm Location: UCB/SSL Report Issued: 5/13/11 Actions: 1 (RFA12) Recommendations: 0 Status: 1 of 1 submitted for approval

11-5 MAVEN PFP ICDR May 23-25, 2011 Software Development Plan Software Products: Boot FSW (PROM) Build1 : Support ETU DCB Test, S/C Interface tests Build2 : Updated, Built for Flight Unit PROM Operational FSW (EEPROM) Build1 : Support S/C Interface, ETU Instrument I&T Build2 : Support Storage Capabilities, Onboard Data Processing, FLT I&T Build3 : Updated, Built for Flight EEPROM Command and Telemetry Database FSW Test Scripts Table Load Scripts Software Personnel: One Software Engineer (34 months)

11-6 MAVEN PFP ICDR May 23-25, 2011 Software Assurance Plan Assurance Products Quality Assessments to Coding Standard Boot FSW CPT Review/Approval Operational FSW CPT Review/Approval Inspection Report Review/Approval Problem Report/Change Request Closure Review/Approval PR/CR Document Maintenance Test Bed ESD Verification FSW Review Support Support to IV&V Assurance Personnel PF Quality Assurance Src: MAVEN_PF_SYS_008A_PFDPUFlightSoftwareDevelopmentPlan.doc

11-7 MAVEN PFP ICDR May 23-25, 2011 Software Risk Mgmt Plan Software Risk Management MAVEN_PF_SYS_012_RMP MAVEN_PF_SYS_008_PFDPUFlightSoftwareDevelopmentPlan All PF Personnel are Responsible for Defining Risks PF FSW Personnel are Responsible for Additional Tracking Efforts All FSW Risks must be submitted to PF SysEng for possible inclusion FSW Risk Process Continuous Identification of Risks Assess Risk / Reevaluate Monthly Develop Contingency Plans Provide Risk Status Monthly Mitigation if Authorized by SysEng Src: MAVEN_PF_FSW_009_SRD.xls

11-8 MAVEN PFP ICDR May 23-25, 2011 Software Config Mgmt Plan Change Authority FSW-SysEng-CogE CCB for Level 4 FSW only on Level 5 changes Software Configuration L5 Requirements Command&Telemetry Spec Analysis Files Test Scripts Displays Test Reports All Source & Object modules All Include files Version Descriptors Method Used Software: Tortoise SVN Hardware: maven.ssl.berkeley.edu Provides Change Tracking/Reversion MAVEN_PF_SYS_010_FSWRequirements.xls (Level 4) MAVEN_PF_FSW_002_SRS.doc (Level 5a: Boot, Level 5b: Operational) Boot Operational Src: MAVEN_PF_FSW_002_SRS_Tables.xls

11-9 MAVEN PFP ICDR May 23-25, 2011 Software Test Plan Test Environment Test Platform ETU DCB or ETU PFDPU Test Equipment: GSE PC GSEOS Software Spacecraft Sim. Instrument Sim. Logic Analyser* Digital Scope* Data Storage: All instrument data and housekeeping Command/Event logs Network access (to Science and Remote GSE computers) *: Not shown Src: MAVEN_PF_FSW_006_STP Revision -, 4/22/2011

11-10 MAVEN PFP ICDR May 23-25, 2011 Software Verification FSW Verification (Source: MAVEN_PF_FSW_006_STP) MAVEN_PF_FSW_002_Tables.xls tracks requirement flows Development status, test overview and procedure name

11-11 MAVEN PFP ICDR May 23-25, 2011 Software Tests & Environments Other Tests/Environments  PF ETU Integration and Test of all Instruments LPW SEP MAG SWEA SWIA  STATIC PFDPU – S/C ETU Test at LM  Long Duration Testing on PFDPU ETU (Boot & Op)  Comprehensive Performance Testing on PFDPU ETU (Boot & Op)  PF FLT Integration and Test of all Instruments  PF High Fidelity Simulator to LM Test Bed  These environments provide considerable independent testing

11-12 MAVEN PFP ICDR May 23-25, 2011 Software Maintenance Plan FSW Maintenance PF DPU ETU & GSE Maintained in Flight Configuration No External PROM simulation. Verify command uploads prior to uplink Anomaly resolution Inject test cases Display / verify result

11-13 MAVEN PFP ICDR May 23-25, 2011 Software Problem Reports Problem Reports/Change Requests Kept for Delivered Products CogE’s added as needed Analyses of Cause Before/After Code sections Test procs included Tracked in Reports/Reviews Closed before Delivery

11-14 MAVEN PFP ICDR May 23-25, 2011 Software Deliverable Schedule Deliverables (src:MAVEN-SYS-PLAN-0020 rev B)

11-15 MAVEN PFP ICDR May 23-25, 2011 FSW Design Overview Development Plan : MAVEN_PF_SYS_008A Processor : 16 MHz Coldfire IP Memory : 32K PROM, 256K EEPROM, 3 MB SRAM, 8 GB Flash Language: C Deliveries: Boot, Operational Requirements: 66 (Boot), 188 (Operational) SLOC : ~3900 in 9 modules (Boot), ~15000 in 19 modules (Operational) Test Platform: DVF (Development and Verification Facility) Major Functional Requirements: – Command Reception & Distribution – Engineering Housekeeping Telemetry – On-Board Limit Monitoring, Fault Response – Relative Time Command Sequences – Real-Time Data Collection and Playback – Archive Data Collection and Playback – Data Compression – High Voltage Controls – Attenuator Controls – Controllers for Six Science Instruments – Fault Protection

11-16 MAVEN PFP ICDR May 23-25, 2011 Hardware Context CPU Block Diagram (DCB)

11-17 MAVEN PFP ICDR May 23-25, 2011 Module Design FSW Major Modules

11-18 MAVEN PFP ICDR May 23-25, 2011 Boot/Initialization Hardware Reset –Power-On –WDRST -- Watchdog Reset (8-seconds) –SCRST – Spacecraft Reset (Commandable) Reset Sequence –FPGA Copies PROM into RAM –FSW Initializes Local Data RAM to zero –Initializes Each Module –If Power-On Reset, Starts in Safe Mode –Begins Engineering Telemetry (1-sec) –Checksums EEPROM programs (2-4 of them) –Selects first-program with Good Checksum –Waits 4 seconds elapsed time –Runs Selected Operational Program –Continues to run Safing Sequence

11-19 MAVEN PFP ICDR May 23-25, 2011 Boot/Safing Seq FSW Safing Sequence Delays 1 second to allow Operational program to stop this sequence; Turns Off all HVs (STATIC, SWIA, SWEA); Delays 60 seconds to allow HV to dissipate; Turns Off all Instruments; Delays 200 seconds to allow Actuator Guardband lockout to timeout; Closes EUV, SEP1 and SEP2 doors; Issues “Safe Me Request” to Spacecraft invoking HDW sequence HDW Safing Sequence Spacecraft Will Power Off PF Automatic Power-Off Door Closures Will Actuate

11-20 MAVEN PFP ICDR May 23-25, 2011 Modes & Enables FSW Modes Safe – Minimal Activities Allowed Normal - FLASH Memory Allowed, HV, Attenuators Engineering – EEPROM Writing Implementation All Enables are Masked by ModeMask for Safe/Norm/Eng Mode Transitions Have Associated Mode Initialization Script

11-21 MAVEN PFP ICDR May 23-25, 2011 Relative Time Sequences RTS Database has up to 64 RTS Sequences. All RTS can run simultaneously. Commands executed at 4 Hz. RTS are variable length. Each can be enabled/disabled. RTS can start other RTS sequences and/or loop. Boot Oper

11-22 MAVEN PFP ICDR May 23-25, 2011 S/C CMD Interface Command/Timing Information Commands Use 56 Kbaud Async messaging S/C Inter-command gap of 30 msec DMA channel input to 2 x 1024 byte buffers DMA Automatically switches buffers at 2 ms gap FSW verifies FPGA transfer status, verifies format prior to use Time Update Messages at 1Hz PF FSW must tolerate time update gaps Zone Alerts Messages at 1Hz PF FSW must initiate Safe Mode if 3 ZA’s missed in a row PF FSW must safe the instrument and report “Alive” If FSW cannot implement safing, it reports “SafeMe” Format same as TLM (see below)

11-23 MAVEN PFP ICDR May 23-25, 2011 S/C CMD Time Update Timing Dual Time Bases Required (Spacecraft & Instrument) S/C & Instrument Both Provide 1Hz Ticks DCB Actel Latches Time Difference Between Ticks S/C Sends Time Update 500msec before the 1pps pulse At DCB 1pps, FSW latches S/C time+offset, increments afterward. Accuracy of 0.01 sec required Src: MAVEN_PF_FSW_020_Analyses.xls

11-24 MAVEN PFP ICDR May 23-25, 2011 S/C TLM Interface Telemetry Information Telemetry Uses 56 Kbaud Async messaging Telemetry will use CCSDS packet headers inside Transaction Telemetry will use 2x5120 byte DMA buffers Telemetry must send Aliveness message every second Commandable Rate: 4.77 Kbps average to kbps (4636 Bytes/sec) Compressing Data Allows Archive Playback Allotment FSW monitors/adjusts RealTime & Archive mix Transaction Format IP = Internet Protocol UDP= User Datagram Protocol CIP= Common Inst Protocol IDP=Inst Dependent Protocol

11-25 MAVEN PFP ICDR May 23-25, 2011 S/C TLM Timing

11-26 MAVEN PFP ICDR May 23-25, 2011 Data Collection –DMA Channels are Assigned to Each Data Instrument –FSW Writes Destination Addresses into Each DMA Controller –DMA Registers are Double-Buffered to Eliminate Gaps –DMA Buffers Automatically Swap at 1, 2 or 4 seconds –FSW Modules Process Messages Using Inst. Message Headers –Expect to Process using 1-second instead of 2 or 4 secs Data Collection Rates –Max Raw Input Rate of ~153 KB/sec (1.2 Mbps) –Vast Majority Summing Counts

11-27 MAVEN PFP ICDR May 23-25, 2011 Data Processing BKG Interrupts –256 Hz Interrupt Process –Distributes CPU Time per Table –Basic ¼ second table repeats 4Hz CMD, PWR, HSK get 32 Hz Instruments get 8-16 Hz, etc. –Implements module requirements –Easily reconfigurable (spares) –FSW measures time in each ISR –FSW measures total CPU% –Design for < 50% usage EXEC Loop - Up to 4 User Programs - Calcs that take > 2ms

11-28 MAVEN PFP ICDR May 23-25, 2011 INST Manager Generic Instrument Manager Design (type1)

11-29 MAVEN PFP ICDR May 23-25, 2011 INST Manager Generic Instrument Manager Design (type 2)

11-30 MAVEN PFP ICDR May 23-25, 2011 STATIC Memory Requirements Primary Buffers Processing Buffers Non-Volatile Storage Src: FSW_020_Analyses.xls Data Processing Svy = Survey Telemetry Arc = Archive Storage

11-31 MAVEN PFP ICDR May 23-25, 2011 SEP Memory Requirements

11-32 MAVEN PFP ICDR May 23-25, 2011 SWEA Memory Requirements

11-33 MAVEN PFP ICDR May 23-25, 2011 SWIA Memory Requirements

11-34 MAVEN PFP ICDR May 23-25, 2011 LPW Memory Requirements

11-35 MAVEN PFP ICDR May 23-25, 2011 MAG Memory Requirements

11-36 MAVEN PFP ICDR May 23-25, 2011 Memory Summary

11-37 MAVEN PFP ICDR May 23-25, 2011 Real-Time Data Mgmt RT Data Management

11-38 MAVEN PFP ICDR May 23-25, 2011 Archive Data Mgmt Archive Data Management

11-39 MAVEN PFP ICDR May 23-25, 2011 Archive Data Storage FLASH Hardware 8 GB Capacity Each 4GB powered separately EDAC Enabled Write/Read DMA-Channel to/from SRAM Block Addressable 2^16 128KB Blocks Each Block has 2K extra bytes EDAC Bad-Block-Indicator Erase Count Write Time FSW Functions Stores/Retrieves Archive Science Blocks Circular Memory with Separate Read & Write Ptrs Playback Commanded by Block Number and Length Both Read/Write Block pointers Telemetered Ground S/W keeps Time-to-Block Number relationship FMAP of 256 provides 32 MB control FSW_020_ANALYSES.XLS FMAP : FLASH Virtual-to-Physical Memory Map

11-40 MAVEN PFP ICDR May 23-25, 2011 PFP-RFA-12 Title : SSR Control Reviewer: S. Harris (Chair) Action: Provide rationale for the additional layer of bad block mapping, that is provided by the physical-to- logical mapping of 32MB chunks of FLASH memory. This seems like large blocks of memory that are getting flagged as bad. Rationale: Bad blocks in the FLASH memory are already flagged, at the 128kB block level. Why does the FLASH need additional segregation into 32MB chunks? Response: The presentation didn’t address some of the concerns of the Flash memory, and so it is unclear why there is a need for recovery at larger levels than the native 128KB block. There are basically three effects which the map solves. [1] If there are long sections of memory in which there are bad 128KB blocks, the software writing speed will decrease as the software searches for a good block to write on. This may lead to the point where we lose data. For MAVEN, given the basic logic shown at SwCDR, it would require about 8 seconds of reading status to skip an entire 32 MB (32MB/128KB=256 blocks, 256 Blocks/4 = 64 interrupts, 2 interrupts per read of 4 blocks -> 8 seconds). So, we could maintain about 60 kbps without data loss if there was just 1 bad 32MB section.

11-41 MAVEN PFP ICDR May 23-25, 2011 PFP-RFA-12 Title : SSR Control (con’td) [2] Using the Flash memory itself for the status data has some risk that the 128KB memory status doesn’t actually write. Thus, even if we set the status to say “BAD,” the 128KB block may still say “GOOD”. [3] There is some possibility that there is a problem powering one of the 4GB memory modules, either because the switch fails or the Flash module takes too much power, or perhaps doesn’t work at all. These cases are handled by mapping out the complete module. The map element (1/256) is only 0.4% of the memory so this is reasonably small from the percentage point of view.

11-42 MAVEN PFP ICDR May 23-25, 2011 Data Compression Count Compression Four scales required {19-to-8, tbd, tbd, tbd} Standard lossy encoding Offscale limit checking STEREO (80196) rate: 22uS/byte output Compression rate (Coldfire): ~364 kbps CPU Use*: ~7.5% Waveform Delta-Modulator Lossless algorithm from THEMIS & RBSP Inputs 32-sample blocks Result is 1 raw 16-bit sample, 31 deltas Width of the deltas is determined Deltas are tightly packed Compression rate (Coldfire): Mbps CPU Use*: ~3% *: Worst case assumes all 27 kbps compressed with this algorithm

11-43 MAVEN PFP ICDR May 23-25, 2011 CPU Usage CPU Comparison to Prior Instruments Coldfire 16 MHz ~ 8x faster than heritage CPUs Even 2:1 or 4:1 inefficiency for C quite tolerable Will Implement Assembly if needed & where effective Test Sample :”VectorSum() routine” Coldfire C v Z80 Assy Coldfire:Z80 over 5:1 ratio

11-44 MAVEN PFP ICDR May 23-25, 2011 Telemetry APIDs

11-45 MAVEN PFP ICDR May 23-25, 2011 Telemetry APIDs CDR Set of Science APIDs

11-46 MAVEN PFP ICDR May 23-25, 2011 Fault Protection (FP) 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).

11-47 MAVEN PFP ICDR May 23-25, 2011 FP Notes 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. 1.Telemetry Task does not itself need to be monitored. If it fails, the S/C will know and take action. 2.When Tasks succeed, they clear their respective “time-since-task” register. 3.PF will principally rely upon Relative Time Sequences for Open/Close or HVON/HVOFF sequences. 4.PF FSW will have two independent software activities: one for safing actions, one for safety verification. 5.Each safing action expected duration will be independent of others and will be commandable 6.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). 7.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. Implementation Details Associated Requirements

11-48 MAVEN PFP ICDR May 23-25, 2011 FP Definitions Safing Status 1.Quick digest on all requests and measures 2.“Allowed” register is combination of Zones and User Enables registers. 3.“Instrument Status” is independent measures of what’s actually happening. Safing Status can be returned in “Safe Me” message

11-49 MAVEN PFP ICDR May 23-25, 2011 Summary FSW Development Plans Are Understood FSW Requirements Are Understood FSW Interfaces Are Understood FSW Platform Will Meet Performance Expectations FSW Margins are Good FSW Test Plan is Understood  Keep Going!

11-50 MAVEN PFP ICDR May 23-25, 2011 Backup Backup Slides

11-51 MAVEN PFP ICDR May 23-25, 2011 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. HV Registers

11-52 MAVEN PFP ICDR May 23-25, 2011 Actuator & HV Commands PWR Module, Actuator Commands 1.Records Actuator Requests 2.When Actuator Electronics available: 1.Selects Next Actuator 2.(Can verify Actuator position) 3.If Inhibit_Time remaining, exits 4.If Allowed bit=0, exits (meets R3) 5.Sets Inhibit_Time for opposing Actuator CDI HV Commands 1.Direct Ground-to-Instrument Commanding 2.FSW will trap and insert “HVENBALLOW” 1.STATIC CDI 21bit 0 &= Allowed[3] 2.SWEA CDI 21bit 0 &= Allowed[4] 3.SWIA CDI 21bit 0 &= Allowed[5] 3.When HVENBALLOW=0, 1.All HV’s are zeroed in instrument 2.CDI commands to raise instrument HV registers are ignored by the hardware (meets R3). PWR Module, HV Commands 1.When Allowed[3-5] are 0, FSW will zero corresponding FSW registers for subsequent ramp up. 2.HV commands set HV Targets 3.If HV_Target > HV_Reg, steps HV_Reg up 4.If HV_Target < HV_Reg, sends HV_Reg to Inst

11-53 MAVEN PFP ICDR May 23-25, 2011 CMD & TM Task Definitions CMD Task 1.Decodes all S/C messages 2.ZoneAlerts Reset Timer[6] TM Task 1.Determines “Safe Me” status from safety failures or task stoppages (meets R5, R7). 2.Will not send normal telemetry including NOOP (Heartbeat) when “Safe Me” is being req’d (meets R4)

11-54 MAVEN PFP ICDR May 23-25, 2011 Safing Task, Failures Has_Failed( bit ) 1.If the Instrument Status bit is safe, then returns(NotFailed) 2.If the bit is Allowed, returns( NotFailed). 3.Otherwise, the Instrument is out-of-compliance. The respective Timer is incremented. 4.If the Timer exceeds its Limit, then it returns (Failed=1) Safing Task 1.Computes the Instrument Status register (6 bits) 2.Computes what is Allowed by a combination of Zone Alerts and User Enables. 3.Calls Door and HV managers to act (meets R2). 4.Calls Power managers to shut off non-complying instruments (meets R2).. 5.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.

11-55 MAVEN PFP ICDR May 23-25, 2011 EUV Aperture IsEUVOpen() 1.FSW reads the 2-bit status of the EUV Ap 2.Compares that to the Open & not-Closed condition. IsEUVAllowed() 1.If both “Boresight in RAM” and “Density High” ZoneAlerts, then EUV Aper is not allowed. 2.If user Enable is low, EUV Aper is not allowed. ManEUVAper() 1.If open but not allowed, this routine starts RTS[5] 2.If closed but allowed, this routine starts RTS(11) 3.Does not matter whether LPW/EUV power is On or Off 4.Shown as a diagram but may be implemented using tables.

11-56 MAVEN PFP ICDR May 23-25, 2011 SEP1&2 Doors IsSEP1Open() 1.FSW Selects SEP1 Door status and directly reads its status. IsSEP1Allowed() 1.If either “SEP1 FOV1” or “SEP1 FOV2” ZoneAlerts, then SEP1 Door is not allowed. 2.If user Enable is low, SEP1 Door is not allowed. ManSEP1Door() 1.If open but not allowed, this routine starts RTS[6], SEP1 Door Closure. 2.If closed but allowed, this routine starts RTS(11), SEP1 Door Open 3.Does not matter whether SEP is on/off 4.Shown as a diagram but may be implemented using tables. 5.Identical logic used in SEP2