FSW Overview

1
FSW Overview

• LAT FSW is divided into two components
• SIU FSW
• LAT command and control from SC via 1553
• LAT hardware configuration and data collection
  control
• LAT hardware power control
• LAT thermal control system
• Gathering and distribution of LAT TLM via 1553
  and SSR
• Low rate science
• Event monitoring for performance information
• Transient detection (GRB / AGN)
• Alert messages to ground
• Repoint requests to SC
• Calibration / diagnostics
• EPU FSW
• LAT event data processing / filtering
• Calibration / diagnostics

2
Changes Since PDR

• COMMENT- See Wall

• Processor selection
• BAE RAD750 has become baseline processor
• Number of processors has been determined
• 2 SIU (1 cold spare)
• 3 EPUs (2 active, 1 cold spare)
• SIU and EPU crates now look alike
• Event Builder has become part of GASU
• Some SIU code has migrated to EPU or common code
• SSR is now a node on event fabric

3
FSW ICD Tree

• COMMENT- See Wall

LAT-SS-01539
LAT-SS-00606
LAT-SS-00860
LAT-TD-01547
LAT-SS-01546
LAT-SS-01543
LAT-SS-01545
LAT-SS-00605
LAT-SS-01825
LAT-TD-00639
LAT-SS-00176
LAT-SS-00238
LAT-SS-00363
4
Milestones

• COMMENT- See Wall

• Detailed FSW development plan, schedule, and
  reviews are part of LAT PCMS, down to the task
  level (WBS 4.1.7.9)
• Plan identifies milestones for progress
  assessment
• LAT CDR will serve as review of high-level FSW
  design and detailed EM1 design
• Incremental milestones for each package
  completion
• Detailed in FSW Development Schedule
• Will additionally be tracked and discussed in
• Weekly LAT-wide project meetings with discussion
  of each sub-system
• LAT Project Weekly Report
• Monthly LAT-wide PMCS reviews system-specific
  past months accomplishments, plans for following
  month, risk evaluation, cost and schedule review
  of last months scheduled and budgeted versus
  actual accomplishments

Releases
EM1 Code Release 8/1/03
EM2 Code Release 1/1/04
FU Code Release 9/1/04
Beam Test 5/24/04-6/16/04
Reviews
CDR 4/29/03
EM2 Peer Review 10/1/03
FU Peer Review 4/1/04
FU release to IT 10/1/04
5
EM1 Release

• Hardware
• 1 Partially populated tower
• 1 Tower Electronics Module
• 1 COTS CPU (VME)
• Ethernet
• Serial port
• LCB communications
• Command/response
• Event acquisition

• Software
• Interfaces (other than VxWorks)
• LCB command/response
• LCB event acquisition
• TEM configuration setting and read-back
• Write to and read from all tower registers
• CAL, TKR, TEM
• Format and export event data from tower
• Charge injection calibration
• Inject a known charge signal directly into the
  (TKR, CAL) electronics in lieu of the detector
  output
• Read the resulting event data output
• Sample and collect a subset of tower / TEM
  housekeeping and LRS data
• Continue EPU filter development and testing
  separately on desktop machine

Status Development complete against
preproduction electronics Deployed to field in
IT test stands
6
EM2 Release

• Hardware
• Multiple towers (single tower plus FESs)
• Multiple TEMs
• GASU (or simulation)
• Command Response Unit (CRU)
• Event Builder Module (EBM)
• ACD Electronics Module (AEM)
• Global Trigger Electronics Module (GEM)
• 1 COTS SIU/EPU CPU (cPCI)
• Ethernet
• Serial port
• SIB
• LCB

• Software
• All of EM1 functionality
• Multiple tower capabilities
• AEM configuration
• AEM event acquisition
• Capability to inject marker events into event
  streams to provide notice of filter parameter
  changes
• LAT mode transitions
• Engineering and safe modes
• LAT spacecraft interface
• 1553
• Command and telemetry
• File management system
• Desktop EPU for filter testing and
  troubleshooting

7
Full LAT FSW Release

• Hardware
• All towers / TEMs
• ACD
• GASU
• Command Response Unit (CRU)
• Event Builder Module (EBM)
• ACD Electronics Module (AEM)
• Global Trigger Electronics Module (GEM)
• Development on multiple engineering RAD750s to
  emulate flight SIU/EPUs

• Software
• All of EM2 functionality
• Multiple processor capabilities
• EPU configuration by SIU
• Spacecraft message processing
• Attitude, time, ancillary data
• Transient detection and reporting
• LAT hardware power control
• Thermal control system

8
Requirements vs. Task

• COMMENT- See Wall

Req't Title Summary Verif. Method
5.2.1.1 Interface To The SIU The EPU FSW shall communicate with the SIU via a custom CPU-to-CPU serial message protocol described in 5. LCB Svc
5.2.1.2 Interface To The EPU Watchdog Once booting is complete, the EPU FSW shall provide a periodic heartbeat to a hardware watchdog. The watchdog shall re-initialize the EPU if the heartbeat is not received. SW Watchdog
5.2.1.3 Interface To The Event Builder The EPU FSW shall receive fully assembled events from the Event Builder formatted according to the custom hardware and software protocols defined in 5. The event data shall be placed directly in the EPU memory. LCB Svc
5.2.2.1 Event Processor Boot An EPU processor shall perform a minimal boot from non-writeable PROM with the hardware watchdog disabled. The minimal boot shall establish communications with the SIU and the secondary boot shall be directed by the SIU. Boot
5.2.2.2 Event Processor Reset The EPU FSW shall perform a re-initialization on command from the SIU. Boot
5.2.2.3 Event Monitoring The EPU FSW shall monitor event data for integrity and to track changes in event and detector statistics. The EPU FSW shall notify the SIU via CPU-to-CPU protocol in the event of an error or anomaly. Instr. Phys. Slave (EPM)
5.2.2.4 Event Filtering The EPU FSW shall filter the input stream of events accepted by the electronic trigger to an output stream commensurate with the spacecraft (SC) storage rate and capacity, keeping events meeting the science objectives. Instr. Phys. Slave (EFP)
5.2.2.5 Event Filter Reconfiguration The event filtering software shall be reprogrammable via the SIU. Instr. Physics
5.2.2.6 Event Filter Bypass The event filtering software shall be capable of passing a pre-scaled sample of unfiltered events for monitoring and analysis upon request via the SIU. Instr. Phys. Slave
9
Requirements Verification Matrix (cont.)

• COMMENT- See Wall

Req't Title Summary Verif. Method
5.3.1.1.1 Command, Telemetry and Data Bus Protocol The SIU FSW shall exchange commands, low rate telemetry, time messages and ancillary data with the SC CDH across a MIL-STD-1553B bus using the MIL-STD-1553B physical layer protocol. 1553 Svc
5.3.1.1.2 Command Rates The SIU FSW shall receive commands across the CTDB at a maximum rate of 10 commands per second. 1553 Svc
5.3.1.2 Discrete Signals From The SC To The LAT The SC shall provide 16 primary and 16 redundant discrete pulse signals for configuration and power control of the LAT. NA
5.3.1.3 Discrete Signals From The LAT To The SC The SIU shall be capable of generating up to 16 primary and 16 redundant monitor signals to the SC for communicating status and coordinating communications recovery in the event of a failure of CTDB communications. Boot
5.3.1.4 Science Data Interface To The SC The LAT science data interface shall accommodate data transfer rates to SC storage up to the maximum bandwidth of the interface (32 Mbps required with a goal of 64 Mbps). The SIU FSW shall format data into CCSDS 102.0-B-4 packets tagged with application IDs (APIDs). LCB Svc
5.3.1.5 Data Storage Storage of LAT science and housekeeping data shall be external to the LAT, with the SIU FSW exporting data through the CTDB or science data interfaces. 1553 Svc, LCB Svc
5.3.2.1 SIU Watchdog Once booting is complete, the SIU FSW shall provide a periodic heartbeat to a hardware watchdog. The watchdog shall re-initialize the SIU if the heartbeat is not received. SW Watchdog
5.3.3.1 Cmd, Config and Data Collection I/F To The Instrument Subsystems The SIU FSW shall communicate with the LAT instrument subsystems for the purposes of configuration and retrieval of housekeeping and low rate science data using the custom command and response hardware and software serial data protocols defined in 5. HSK
5.3.3.2 Cmd, Config and Data Collection I/F To The EPUs The SIU FSW shall configure and reprogram the EPUs and receive filtered event data from them via the CPU-to-CPU serial message protocol described in 5. LCB Svc
10
Requirements Verification Matrix (cont.)
Req't Title Summary Verif. Method
5.3.4.3.1 GRB Alert Message From SC The SIU FSW shall be able to reconfigure and direct the operation of the LAT instrument in response to a Rapid Burst Alert notification message received from the SC across the CTDB (see also section 5.3.4.10). Instr. Phys. Master (GBM)
5.3.4.3.2 GRB Alert Message From GBM The SIU FSW shall be able to reconfigure and direct the operation of the LAT instrument in response to a GRB notification message from the GBM instrument forwarded by the SC via the CTDB (see also section 5.3.4.10). Instr. Phys. Master (GBM)
5.3.4.3.3 GRB Interrupt From GBM Forwarded By SC The SIU FSW shall be able to reconfigure and direct the operation of the LAT instrument in response to a GRB interrupt from the GBM instrument on a discrete line (see also section 5.3.4.10). Instr. Phys. Master (GBM)
5.3.4.3.4 GPS Time Hack From SC The SIU FSW shall receive and process a 1 Hz GPS time hack on a discrete signal line, generating a correlation between the GPS time hack and the LAT internal 20 MHz clock. Magic 7
5.3.4.3.5 GPS Message From SC The SIU FSW shall receive and process a 1 Hz GPS time message from the SC on the CTDB that provides information on the relationship between the GPS time hack and external time (UTC). The message shall arrive within 500 msec of the GPS time hack. The SIU FSW processing shall generate a mapping of external time (UTC) to the LAT internal 20 MHz clock. Magic 7
5.3.4.3.6 Ancillary Data From SC The SIU FSW shall receive and process an ancillary data packet from the SC delivered at the SC attitude control loop rate on the CTDB. The data content of this packet is specified in the LAT section of the Data Format Control Book (TBS), but at a minimum shall supply the information necessary for the LAT to determine its time correlated attitude to within the error budget specified in 1. Magic 7
11
Requirements Verification Matrix (cont.)
Req't Title Summary Verif. Method
5.3.4.3.7 Safe Mode Notification From SC The SIU FSW shall receive and process a safe mode notification message from the SC, then execute the necessary configuration commands to place the LAT in a predetermined Safe Mode. Primitive
5.3.4.3.8 Load Shedding Notification From SC The SIU FSW shall receive and process a load shedding notification message from the SC, then execute the necessary configuration commands to perform the TBD desired level of load shedding. Primitive
5.3.4.3.9 SIU Reboot Signal From SC The reset pin of an SIU shall be connected to a discrete signal line from the SC. NA
5.3.4.4.1 LAT Housekeeping Data To SC The SIU FSW shall respond to a SC request (format TBD) on the CTDB by providing a housekeeping data set as defined in the LAT section of the Data Format Control Book (TBS). HSK
5.3.4.4.2 LAT Science Data Subset To SC The SIU FSW shall respond to a SC request on the CTDB by providing a defined subset of science data to be included with the housekeeping data set. LAT science data shall be formatted as defined in the LAT section of the Data Format Control Book (TBS). HSK
5.3.4.4.3 LAT GRB Alert Message To SC The SIU FSW shall be able to send a GRB alert message to the SC across the CTDB (see also section 5.3.4.9). Instr. PhysicsMaster,1553 Svc
5.3.4.4.4 LAT GRB Repoint Request Message To SC The SIU FSW shall be able to send a GRB repoint request message to the SC across the CTDB (see also section 5.3.4.9). Instr. Physics Master,1553 Svc
5.3.4.4.5 LAT Request To SC To Power Both SIUs The SIU FSW shall provide a means of requesting the SC to turn on both SIUs for diagnostic purposes. The message shall include a parameter defining which SIU is the primary. NA
12
Requirements Verification Matrix (cont.)
Req't Title Summary Verif. Method
5.3.4.5.1 Operating Modes The SIU FSW shall support the observatory modes of (1) sky survey, (2) pointed observation, (3) repointed observation, (4) autonomous repointed mode, and (5) engineering checkout, in addition to Safe Mode and any required special modes for in orbit checkout. Instr. Physics
5.3.4.6.1 Configuration Of Subsystems The SIU FSW shall configure the CAL, TKR, ACD, TDF and LAT power supply subsystems by writing to the TDF provided configuration registers. Primitive
5.3.4.6.2 Readback Of Subsystems The SIU FSW shall be able to read back and record the configuration of the CAL, TKR, ACD, TDF and LAT power supply subsystems by reading back the TDF provided configuration registers. Primitive
5.3.4.7.1 Calibration The SIU FSW shall provide the means to perform on-orbit calibration of the ACD, TKR and CAL subsystems by establishing configurations and executing algorithms provided by the subsystem designers. Instr. Phys. (SCL,ECL)
5.3.4.7.2 Diagnostics The SIU FSW shall provide the means to perform on-orbit diagnostics of the ACD, TKR CAL and TDF subsystems by establishing configurations and executing algorithms provided by the subsystem designers. Instr. Phys.
5.3.4.8.1 Housekeeping The SIU FSW shall acquire and monitor health and environmental data from the CAL, TKR, ACD, TDF and LAT power supply subsystems. HSK
5.3.4.8.2 Low Rate Science The SIU FSW shall acquire and monitor low rate science data (rate counters) from the CAL, TKR, ACD and TDF subsystems. HSK
13
Requirements Verification Matrix (cont.)
Req't Title Summary Verif. Method
5.3.4.9 GRB Detection In any science observation mode, FSW shall monitor the science data to identify GRBs. Instr. Phys. Master (GRB)
5.3.4.9.1 GRB Location Accuracy For a GRB with gt 100 reconstructed photons above 1 GeV in less than 20 seconds, the SIU FSW shall locate the source of the GRB to within 10 arcmin (1s radius). Instr. Phys. Master (GRB)
5.3.4.9.2 GRB Alert Message And Latency For a GRB meeting the conditions defined in 5.3.4.9.1, the SIU FSW shall send a GRB alert message to the SC within 5 seconds for immediate relay to the ground. The goal is to provide the notification within 2 seconds. Instr. Phys. Master (GRB)
5.3.4.9.3 GRB Repoint Request Message For a GRB meeting the conditions defined in 5.3.4.9.1 and if the capability is enabled, the SIU FSW shall send a GRB repoint request message to the SC. Instr. Phys. Master (GRB)
5.3.4.10 GRB Response The LAT FSW shall respond to GRB alert messages from all sources (a Rapid Burst Alert from a source external to GLAST, a GRB alert message/interrupt from the GBM or an internally generated GRB alert). Instr. Phys. Master (GBM,GRB)
5.3.4.10.1 Burst Filtering When a GRB is identified, the SIU FSW shall provide the capability to automatically apply a set of looser event filter parameters, allowing more events to be collected for a limited period of time. Instr. Phys. Master (GRB)
5.3.4.10.2 Burst Buffering The SIU FSW shall provide buffering for a minimum of 10,000 (TBR) photon events from a burst. System
14
Requirements Verification Matrix (cont.)
Req't Title Summary Verif. Method
5.3.4.11.1 Deadtime Contribution The FSW is an element of the TDF subsystem and shall conform to its allocated contribution to the overall TDF deadtime requirements. System
5.3.4.11.2 Deadtime Duty Cycle The SIU FSW in conjunction with TDF hardware shall provide the means to control the deadtime duty cycle in response to varying trigger rates. System
5.3.4.12 SAA Transit The SIU FSW shall provide instrument reconfiguration, monitoring and recovery from mode-save for SAA transits via SC command and/or time-tagged internal LAT command. (LCP)
5.3.4.13 Thermal Control The SIU FSW shall provide the active element of the LAT high precision thermal control system by a mechanism TBD. The SIU FSW shall not be responsible for survival mode thermal control. HSK
5.4.1 System Of Units The LAT shall conform to the observatory requirement to observe the current NASA policy directive, NPD 8010.2C, Use of the Metric System of Measurement in NASA programs. System
5.4.2.1 LAT Coordinate System The FSW shall use the LAT coordinate system defined in 6. System
5.4.2.2 Celestial Coordinate System The FSW shall report celestial coordinates in the J2000 inertial coordinate system, using right ascension (RA) and declination (DEC). System
5.4.3 Resource Margin At launch, FSW shall utilize less than 50 of processor resources (RAM, EEPROM and CPU cycles). System
15
FSW External Interface Summary SIU

• COMMENT- See Wall

Via 1553
Ground / SC Commands / Uploads
Via 1553
Telemetry to SC
Via 1553
SC Ancillary/Attitude Data
Via 1553
LAT Repoint Request to SC
Via 1553
SC TimeTone
Via LCB
Telemetry to SSR
Via 1553
Via LCB
SIU FSW
GRB Telecommand from GBM
Communications to EPU
Command / Response CMDs to LAT HW (includes
config. data)
Via LCB
Discrete
Immediate Trigger from GBM
Boot Status Outputs (2 levels i.e. 2 bits)
Discrete
Discrete
1 PPS Time Hack from SC
PCI
TCS Heater Control Signals
Via LCB
Command / Response Data
PCI
PDU / GASU Power On Signals
Via LCB
Communications from EPU
16
FSW External Interface Summary EPU
Via LCB
SC Ancillary/Attitude Data
Via LCB
SC TimeTone
Via LCB
Processed Events to SSR
EPU FSW
Via LCB
Communications to SIU
Discrete
1 PPS Time Hack from SC
Via LCB
Communications from SIU
Via LCB
Event Data
17
RAD750 Interfaces Backplane, PCI and PIDs

• COMMENT- See Wall

GASU Cable
SC Cable
TCSBoxes
PCI Bus
Custom Bus
CLK
PPS
GBM
1553
LATp
Discretes
Discretes
LCB
20 MHz / 2
Results FIFO
Buffering
FPGA (CorePCI)
SIB
1553 Summit
SIB
40 MHz
1553 RAM
Thermal Control
FPGA (CorePCI)
EEPROM
RAD750
RAD750 RAM
Bridge Chip
Bridge Chip
RAD750 CPU
Section that deals with PCI/memory operations
Section that deals with PIDs
18
1553 Interface

• MIL_STD_1553B (1553) bus is primary interface for
  exchanging information between LAT and SC
• Commands from SC
• Telemetry to SC
• Commands to SC (limited to SC Repoint Request)
• SC will act as bus controller (BC) node
• Each SIU can act as remote terminal (RT) node
• Bus protocol and schedule under control of SC
• Spectrum Astro 1553 Bus Protocol Interface
  Control Document
• All traffic will consist of CCSDS packets

19
1553 Architecture
20
LCB Interface

• Communication within LAT provided by LAT
  Communications Board (LCB)
• Built in two form factors
• PMC mezzanine card (used for EM1/EM2 with mv2304
  SBCs)
• cPCI module (used for EM2/Flight with
  mcp750/rad750 SBCs)
• LCB communicates with nodes on the command and
  event fabrics
• Instrument to CPU (asynchronous, event fabric)
• CPU to CPU (asynchronous, event fabric)
• CPU to SSR (asynchronous, event fabric)
• CPU ? instrument (synchronous, command/response
  fabric)
• LATp is packet protocol for all traffic through
  this interface

21
LCB Architecture
P C I B U S
DMA Engine
Buffering and Logic
CMD Data
CMD/RSP Fabric
RSP Data
Control Registers
Fabric Reset
Export FIFO
Event Data Fabric
Event Data In
Results FIFO
Event Data Out
22
LAT Protocol (LATp) Overview

• Document LAT-TD-00606
• LATp packet consists of one or more 128-bit LATp
  cells
• First cell in sequence contains 16-bit LATp
  header
• Each cell is preceded by a 2-bit cell announce
  sequence
• Each cell is trailed by a truncate bit and parity
  bit
• LATp packet formats
• For hardware configuration, packet formats are
  specified in programming ICDs
• For CPU-to-CPU and CPU-to-SSR communications,
  LATp packets are built up into CCSDS source
  packets

• LATp status
• Already developed and in use for hardware testing
  at 16 sites world-wide (SLAC, NRL, GSFC and Italy)

23
Design Architecture
24
FSW Architecture

• LAT FSW architecture strongly coupled to LAT
  hardware design
• All LAT-side CPU communications go via the LCB
• SIU to EPU via GASU (EBM)
• SIU to PDU for internal power control via GASU
  (CRU)
• Initial PDU and GASU power on via separate SIB
  mechanism
• SIU to TEMs for instrument configuration via GASU
  (CRU)
• SIU to AEM, GEM for instrument configuration via
  GASU (CRU)
• Event data to EPU for processing via GASU (EBM)
• All data to SSR from SIU or EPU via GASU (EBM)

25
GASU Role in FSW Communications Architecture
SIU
GASU
CRU
Command/Response Unit
4 x 32 bit registers
RAD750
PDUs
TEM0
cPCI
SIB
TEM1
TEM2
.
.
EBM
LCB
TEM15
31 x 32 bit registers
EPU 0
Event Builder Module
SIU In
RAD750
SIU
GEM
EPU 0 In
EPU 0
cPCI
(SIB)
22 x 32 bit registers 17 x 64 bit
registers 19 x 96 bit registers 1 x 112 bit
register
EPU 1 In
EPU 1
LCB
Merge
SSR
EPU 1
ACD Electronics Module
cPCI
GLT Electronics Module
TEM0
CombinatoricLogic
TEM1
TEM2
Event Data Fragments
.
.
TEM15
Trigger Data
26
FSW Framework

• Fundamental construct for LAT FSW is Master/Slave
  tasks
• Master running in SIU
• Slaves running in SIU or in EPUs or in both
• Communications between master and its slaves is
  full-duplex
• Slave tasks may have multiple inputs
• E.g. a slave task receiving instrument data as
  well as messages from its master task
• Slave will have two input queues with priority
  given to messages from the master task
• Master tasks may also have multiple inputs
• Needed to achieve connectivity back to the
  spacecraft
• Master task will also have two input queues, one
  from the slave(s) and one from the spacecraft
  1553 dispatch, with priority given to the 1553
  messages
• Structure of masters and slaves can be replicated
  as often as necessary to accomplish all the
  functions required of FSW

27
FSW Architecture with Internal Framework
SIU Crate/Backplane
EPU Crate/Backplane
Other Tasks
Other Tasks
1553 Rx service
Software Watchdog
1 PPSInterrupt
GBM Interrupt
Software Watchdog
1 PPSInterrupt
LCB Rx service
LCB Rx service
Masters
Slaves
Slaves
Q
Q
Q
Magic 7
Magic 7
Magic 7
Q
Q
Q
Instr. Phys.
Instr. Phys.
Q
Q
Q
Q
Q
File/Object
File/Object
File/Object
Q
Q
Q
Q
HSK
HSK
HSK
Q
Q
Q
Primitives
LCB Tx service
Q
Q
Q
LCB Tx service
Q
Q
1553 Tx service
Q
Telecommand (SC to LAT)
Master (SIU) to slave (EPU)
Physics data from instrument
Telemetry (LAT to SC)
Slave (EPU) to master (SIU)
Data to SSR
Command/Response
28
Description of Masters

• COMMENT- See Wall

• Magic 7 deals with dispatching the 7 magic
  messages per second from the spacecraft
• 5 attitude
• 1 time-tone
• 1 ancillary (containing orbit information as well
  as status info)
• File master deals with all file
  upload/copy/delete/ processing
• Housekeeping master deals with accumulating and
  examining housekeeping information
• Requests info from SIU, EPUs, GASU, hardware
• Provides monitoring and alarming
• Outputs telemetry
• Instrument Physics master deals with all
  instrument data related processing
• Immediate (or primitive) master deals with the
  very primitive LAT configuration command set

29
Boot

• Boot Document LAT-TD-001806-04
• Boot Resources
• Boot Proceeds In Two Stages
• Primary Boot (from on-board SUROM)
• Secondary Boot (from EEPROM on SIB board)

CPU Crate
RAD750
SIB
LCB
SUROM (256 kByte)
750 Processor
SDRAM (128 MByte)
EEPROM Bank 0
Reserved for Secondary Boot
(Managed byTFFS software)
EEPROM Bank 1
(Managed by TFFS software)
Bridge Chip
Discrete I/O
1553 communications to spacecraft(SIU only)
LCB communications to SIU
30
Primary Boot

• CPU Reset from SUROM
• Run EMC initialization procedure
• Set initial watchdog timeout
• Map out SDRAM, SUROM and PCI I/O spaces
• Enable processor L1 caches
• Disable interrupts
• Memory Test SDRAM
• Memory test (all 0s, all 1s, checkerboard)
  (runs from ROM/cache)
• Start Primary Boot Shell (now using RAM
  resources)
• Configure PCI bus
• Configure 1553 device (SIU) or LCB device (EPU)
• Go into command loop (?)
• Initial command timeout for automatic start
• Poll for new commands
• Send housekeeping telemetry
• Reset watchdog timer

31
Primary Boot Command Processing
Parse Upload Packets
Parse Operational Command
RTOS Execute Command
Operational Command Packet Received
Upload Packet Received
Record Time Information
Poll 1553 Remote Terminal
Prepare Next HKP Telemetry Packet
SIANCILLARY Packet Received
Last HKP Packet Sent
SIANCILLARY Packet Received
Command Start Telecommand Received
Last HKP Packet Sent
Load and Execute RTOS
Poll 1553 Remote Terminal / Initial Command
Timeout
Timeout - No Command Message Received
Initialization
Startup
32
Secondary Boot

• Secondary Boot Functions
• Inflate (ZLIB algorithm) VxWorks image to
  prepared memory location
• Branch to VxWorks entry point
• Execute secondary boot script to run application
  code
• Inflate (ZLIB algorithm) and link application
  code modules from EEPROM
• Call application initialization functions
• The system is running!

33
LAT Startup (0)

• Choose 1 chart

• The following details the cold startup procedure
  in a step-by-step fashion. The outline follows
  the consistent procedure
• Check if conditions are OK to proceed by
  examining SC and/or LAT telemetry.
• If OK, then by ground command to either the SC or
  LAT, execute the next step.
• The steps that involve strictly SC telecommands
  or decisions based on SC telemetry are indicated
  as the bold, underlined numbered steps. The steps
  that involve strictly LAT telecommands or
  decisions based on LAT telemetry are indicated as
  normally numbered steps.

34
LAT Startup (1)
35
LAT Startup (2)
36
Event Filtering - Introduction
Choose 1 Chart

• Requirements
• On off board science
• Sets photon capture efficiency
• Constraints
• Processing rate
• Orbit max trigger rate is 10kHz 100 ?sec per
  event system-wide
• Downlink bandwidth
• Orbit average of 300kbps 20 Hz background /
  10Hz physics
• Send few events. Filter must reject 99.8 of
  background events
• Send small events. Design dense event formats.
• Processing throughput is a complex function of
• Event size (longer events result in more memory
  accesses)
• Event layout (memory accesses can be saved with
  good layout)
• CPU architecture (CPU speed, memory speed,
  execution units, )
• Filtering code
• Algorithms
• Implementation

37
Event Filtering Development Path

• Using Monte Carlo events generated in GLASTsim
• Event size of 1 kB includes noise at prescribed
  rates
• Event layout is finalized
• Algorithmic development
• Designing and debugging on SUN/LINUX boxes
• Measuring performance on Motorola MV2303 and
  RAD750
• Event features used in current round of analysis
• TKR layer hit bits (very fast access)
• ACD tile hit bits (disordered but access still
  fast)
• CAL energy sums (slowest access needs coarse
  calibration constants)
• Minimal track finding

38
Event Filtering - Results
Cut Events Events Events Events ltTimegt ?sec ltTimegt ?sec
Analyzed () Analyzed () Rejected () Rejected () 603 750
No CAL LO Veto Tile 15420 (100.0) 9923 (64.4)
ACD Splash Veto (pass 0) 5497 (35.6) 1566 (10.2) 4.5 9.2
CAL lt 350Mev Veto Tile 3931 (25.5) 224 (1.5)
CAL lt 10 Mev Any Tile 3707 (24.0) 464 (3.0)
ACD Splash Veto (pass 1) 3243 (21.0) 69 (0.4) 0.3 0.4
TKR tower match with ACD top tile 3174 (20.6) 424 (2.7)
TKR tower match with ACD side tile 2750 (17.8) 304 (2.0)
No connection between CAL energy TKR 2446 (15.9) 1152 (7.8) 5.6 6.7
CAL Energy Layer 0/Total Energy lt .01 1294 (8.4) 156 (1.0)
CAL Energy Layer 0/Total Energy gt .90 1138 (7.4) 94 (0.6) 0.1 0.2
Before track finding 1044 (6.8) 14376 (93.2) 5.8 10.6
TKR/ACD matching 1044 (6.8) 262 (1.7)
Projects into skirt region 782 (5.1) 83 (0.5)
E lt 350 Mev, Number of Tracks lt 2 699 (4.5) 461 (3.0) 29.9 40.5
Final 238 (1.5) 15182 (98.5) 7.7 13.3
39
Event Filtering - Summary

• Current status
• Rejection rate 98.4
• Time (RAD750) 14 ?sec
• Still need to go from 98.4 ? 99.8
• gt 95 rejection in 14 ?sec/event (RAD750) leaves
  an interval of 1.4 msec/event for additional
  processing to go the final 1.4
• To preserve 100 margin in one CPU, still have
  700 ?sec/event
• This is 50 times the event processing time used
  so far
• Status
• Filter development proceeding
• 1 BAE 750 will be sufficient to do filtering with
  100 margin

40
FSW Architecture for EM1
SIU Crate/Backplane

• COMMENT- See Wall

Other Tasks
Ethernet Rx
Software Watchdog
1 PPSInterrupt
GBM Interrupt
LCB Rx service
Masters
Slaves
Q
Q
Instr. Phys.
Instr. Phys.
Q
Q
Q
Q
File/Object
File/Object
Q
Q
Q
HSK
HSK
Q
Q
Primitives
Q
Ethernet Tx
Q
Q
Q
Ethernet Tx
Q
Telecommand (SC to LAT)
Master (SIU) to slave (EPU)
Physics data from instrument
Telemetry (LAT to SC)
Slave (EPU) to master (SIU)
Data to SSR
Command/Response
41
LAT Configuration

• Configuration controlled by setting registers
• Messages sent from SIU via LCB using command /
  response fabric
• Message protocol is LATp
• Routed through CRU on GASU to destination modules
• Message data contains routing information for
  forwarding to final hardware destination
• CRU
• GEM
• EBM
• TEM(s)
• Common
• Common ? GTIC
• Common ? GTCC
• Common ? GTCC ? GTRC
• Common ? GTCC ? GTRC ? GTFE
• Common ? GCCC
• Common ? GCCC ? GCRC
• Common ? GCCC ? GCRC ? GCFE
• AEM
• GARC

42
GASU
SIU
GASU
CRU
Command/Response Unit
4 x 32 bit registers
RAD750
PDUs
TEM0
cPCI
SIB
TEM1
TEM2
.
.
EBM
LCB
TEM15
31 x 32 bit registers
EPU 0
Event Builder Module
SIU In
RAD750
SIU
GEM
EPU 0 In
EPU 0
cPCI
(SIB)
22 x 32 bit registers 17 x 64 bit
registers 19 x 96 bit registers 1 x 112 bit
register
EPU 1 In
EPU 1
LCB
Merge
SSR
EPU 1
ACD Electronics Module
cPCI
GLT Electronics Module
TEM0
CombinatoricLogic
TEM1
TEM2
Event Data Fragments
.
.
TEM15
Trigger Data
43
Tower Electronics Module (TEM)
GTCC
6 x 32 bit registers
GTCC
GCCC
TKR 6
7 x 32 bit registers
GTIC
(trigger reduction)
GTIC
GCCC
GCCC
11 x 32 bit registers 2 x 18 bit registers
2 x 16 bit registers 1 x 3 bit register
1 x 112 bit register
CAL 3
CAL 1
Common Controller
(overall control)
Common
7 x 32 bit registers
TO/FROM GASU
44
TKR CAL
GTFE
5 x 64 bit registers
GTRC
2 x 64 bit registers
GCFE
7 x 16 bit registers
0
1
9
10
2
11
3
3
0
1
9
10
2
11
3
3
GCRC
2
2
8 x 16 bit registers
2
2
1
1
1
1
0
0
0
0
Tower Electronics Module (TEM)
45
ACD
GAFE
0
1
2
15
16
17
0
1
2
15
16
17
11 x 16 bit registers
GARC
GASU
44 x 16 bit registers
CRU
AEM
AEM
Crossover
8 x 32 bit registers 12 x 64 bit registers
Crossover
GEM
0
1
2
0
1
2
15
16
17
46
Charts

• Task Packages for EM2

47
Development Plan Testing
48
Software Development Approach

• COMMENT- See Wall

• Software lifecycle model
• Iterative / incremental development model
• Multiple builds with increased capability with
  each build
• Regression testing on each build
• Requirements flowdown, analysis, review
• Flowdown from program and system specs
• Peer reviews
• Design and code inspections / review
• Top-level design review
• Detailed design reviews and code inspections on
  per release basis
• Continuous cycle of development and test
• Code management
• Formal control through the CMX / CMT / CVS
  toolchain
• Configuration management
• Formal control through project management tools
• Cyberdocs
• Non conformance reporting system
• Quality assurance and test oversight
• Independent review of test plans, procedures,
  scenarios, data

49
Software Design for Safety

• The software safety environment
• Software cannot damage hardware (hardware
  protects itself)
• Reprogrammable on orbit (except for primary boot
  code)
• The software safety philosophy during development
• Leverage the fact that software cannot damage
  hardware
• Make unexplained conditions fatal but not
  serious and reboot
• Decreases complexity
• Increases reliability / robustness
• Immediate and graceful exit quickly identifies
  code weaknesses
• Improves efficiency for producing reliable /
  robust final code
• On a case by case basis, develop recovery
  strategies
• Fully recoverable Perform recovery action,
  continue operation
• Not recoverable but CPU integrity good Report to
  ground and await intervention
• Not recoverable and CPU compromised Stay with
  reboot strategy

50
Software Fault Detection Methods

• State of health (SOH)
• Bridge chip built-in test
• Software watchdog
• All registered tasks must regularly report
  progress in order for SWD to reset hardware
  watchdog
• Data validity
• Checksums
• Parity bits
• LCB timeouts, error records
• Data reasonableness checks
• HSK queries software/hardware regularly
• Memory correction reports from bridge chip
• Thermal conditions
• Power conditions
• All instrument configurations read out at
  beginning and end of all data collection runs
  (must agree)
• Event monitoring code on EPUs checks event data
  for correct format, completeness
• Event filtering code checks event data for
  physics consistency

51
Software Fault Handling

• Fault Recovery
• On basis of fault identified
• Execute recovery procedure and continue operation
• Notify ground and await intervention
• Reboot
• Always attempt to save a block of information
  describing the fault condition in a known fixed
  memory location so that it can be picked up and
  sent to ground after the reboot

52
FSW Package Development

• FSW partitioned into functional blocks based on
  the SRS
• Functional blocks are then mapped into packages,
  the fundamental unit of the code management
  system
• Package Development
• Detailed design elements (algorithms, finite
  state diagrams, logic flows, etc.) and
  development notes are generated on a per package
  basis
• Design information is stored in a Software
  Development Folder (SDF) which accompanies each
  package
• Contents of SDF are version controlled alongside
  the packages code using the code management
  system
• As the software matures, design descriptions from
  the SDFs evolve along with the code to provide a
  complete set of detailed design documentation

53
Task to Package Mapping
54
Code Management

• FSW partitioned into functional blocks based on
  the SRS
• Functional blocks are then mapped into packages,
  the fundamental unit of the code management system

Common code SIU and EPU
SIU specific code
EPU specific code
Boot code
Test and verification code
See next slide for discussion of contingency
55
Contingency

• Document LAT-TD-01781
• LOC count estimated for each package
• Bottoms up estimate
• Based on package content
• Based on previous experience
• LOC estimates not worst-case
• Represent most likely length of package
• Some longer or more complex, some shorter or less
  complex
• Total LOC for entire FSW load expected to be more
  static than individual package estimates

• Contingency estimation based on risk factor
• Risk factor defined in table above
• Contingency calculated by multiplying the risk
  factor by 10 of total estimated LOC in package
• Contingency represents potential additional lines
  of code

56
Development Environment

• Embedded System
• Processor / operating system BAE RAD750 /
  VxWorks
• Toolset (Wind River Systems)
• Language C
• Development platform Sun / Solaris
• Compiler / linker / binutils GNU cross compiler
  suite
• Debugger Crosswind
• Host System
• Processor / operating system Sun / Solaris or
  Intel / Linux
• Toolset (host simulation or cooperating
  processes)
• Language C
• Development platform Sun / Solaris or Intel /
  Linux
• Compiler / linker / binutils GNU compiler suite
• Debugger GDB / DDD
• Toolset (test executive and scripting)
• Python / XML / MySQL / Qt / Perl
• Other Tools
• Requirements management DOORS
• Code / configuration management CMX / CMT / CVS