GLAST Large Area Telescope: Instrument Flight Software WBS: 4.1.7.9 Presenting for the FSW group:

GLAST LAT Project CDR/CD-3 Review May 12-15, 2003

Flight Software v5 1

GLAST Large Area Telescope:GLAST Large Area Telescope:

Instrument Flight Software WBS: 4.1.7.9

Presenting for the FSW group:Gunther Haller Stanford Linear Accelerator CenterManager, Electronics, DAQ & FSWLAT Chief Electronics Engineer

[email protected](650) 926-4257

Gamma-ray Large Gamma-ray Large Area Space Area Space TelescopeTelescope



ContentContent

• Overview• Peer CDR-Review RFA Status• Interface• Requirements• Mapping of Requirements/Functions/Tasks/Packages• Boot• Event-Filtering• File/Object Management• Development• Verification



LAT FSW – Part of DAQ SubsystemLAT FSW – Part of DAQ Subsystem

3 Event-Processor Units (2 + 1 spare)– Event processing CPU– LAT Communication Board– SIB

ACD

spare

EPU-3

EPU-2EPU-1

spare spare

Pwr Dist. Box

GASU

spare

spare

SIU-P SIU-R

Spacecraft Interface Units

– Spacecraft Interface Board (SIB): Spacecraft interface, control & data

– LAT control CPU– LAT Communication

Board (LCB): LAT command and data interface

16 Tower Electronics Modules– DAQ electronics module (DAQ-EM)– Power-supplies for tower electronics

* Primary & Secondary Units shown in one chassis

Power-Distribution Unit (PDU)*

– Spacecraft interface, power

– LAT power distribution

– LAT health monitoring

Global-Trigger/ACD-EM/Signal-Distribution Unit*

TKR

CAL

FSW is an integral part of the data acquisition (DAQ) subsystem and is managed, budgeted and scheduled as part of the DAQ subsystem

TKR Front-End Electronics (MCM)ACD Front-End Electronics (FREE)

CAL Front-End Electronics (AFEE)



FSW Organization ChartFSW Organization Chart

FSW Lead

J. J. Russell

Project Manager(IPM)

W. Althouse

Electronics & FSW Manager

G. Haller

FSW Test/QAOversightS. Sawyer

ConfigurationManager

A. P. Waite

Performance &Safety Assurance

D. Marsh

I&T Support

C. Brune

Boot &S/C Interface

D. Wood

Algorithms

J. J. Russell

LAT Configuration

J. Swain

SoftwareArchitecturesA. P. Waite

Thermal Control

J. Swain

DAQ

M. Huffer

Test Executive

S. Maldonado

Front EndSimulatorsO. Saxton

Cmd & TelemDatabaseB. Davis

RAD750Processor

R. Caperoon



LAT FSW Team HeritageLAT FSW Team Heritage

• Small effective group• Very experienced

– HEP >50 man-years– FSW >20 man-years

• Successful track record• Leads are developers• Leads are scientists

• Employ highly interactive development process • All members are expert in LAT architecture, able to contribute in many

areas• Independent oversight provided by systems engineering• Produce fully documented design• Process allows/requires software to be in use from early subsystem

development/testing to full LAT verification

Experiment # CPUs

Man-years

LOC

SLD > 500 12 150K

Babar > 200 15 > 500K

BFEM 2 2.6 44K

LAT – HEP 3 9 71.5K

LAT – Boot &

SC I/Fs

1 3 6.1K



Changes Since PDRChanges Since PDR

• Processor selection– BAE RAD750 has become baseline processor– Number of processors has been determined

• 2 SIU (1 active, 1 cold spare)• 3 EPUs (2 active, 1 cold spare)

– SIU and EPU crates now look alike• Interface to SSR has become part of GASU

– Some SIU code has migrated to EPU or common code



Review RFA Status SummaryReview RFA Status Summary

• Delta-PDR software related RFA’s (Request for Action)– “Determine the need date for processor down-select based

on software design impact”• Have selected and placed order for BAE RAD750

– “Finalize the flight-software management plan and test plan”• Flight software management plan (LAT-MD-00104) and

Flight software test plan (LAT-TD-00786) released and in cyberdocs

• Peer-CDR software related RFA’s– Generated 12 software related RFA’s

• 9 responses accepted• 3 responses need more work• Listing in appendix



Requirements (Example)Requirements (Example)

• Example requirements• Full listing of requirements appears in appendix• Released in cyberdocs: LAT-SS-00399

Requirement#

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].

Demo

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.

Demo

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.

Demo

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.

Demo

5.2.2.2 Event Processor Reset

The EPU FSW shall perform a re-initialization on command from the SIU. Demo

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.

Demo



SIUSIU FSW External Interfaces FSW External Interfaces

Ground / SC Commands / Uploads

SC TimeTone

SC Ancillary/Attitude Data

Telemetry to SC

SIU FSW

Via 1553

Immediate Trigger from GBM

GRB Telecommand from GBM

Via 1553

Via 1553

Via 1553

Discrete

Discrete1 PPS Time Hack from SC

Command / Response Data Via LCB

Via 1553

LAT Repoint Request to SCVia 1553

Telemetry to SSRVia LCB

Communications to EPUVia LCB

Command / Response CMDs to LAT HW(includes configuration data)

Via LCB

Boot Status Outputs(2 levels – i.e. 2 bits)

Discrete

TCS Heater Control SignalsPCI

PDU / GASU Power On SignalsPCI

Communications from EPUVia LCB

SRS 5.3.1.1

SRS 5.3.1.1

SRS 5.3.1.1

SRS 5.3.1.1

SRS 5.3.1.1

SRS 5.3.1.1

SRS 5.3.1.2

SRS 5.3.1.2SRS 5.3.1.3

SRS 5.3.3.1

SRS 5.3.3.1

SRS 5.3.1.4

SRS 5.3.3.2

SRS 5.3.3.2

SRS 5.3.1.3

SRS 5.3.1.3



EPUEPU FSW External Interfaces FSW External Interfaces

SC TimeTone

SC Ancillary/Attitude Data

EPU FSW

Discrete1 PPS Time Hack from SC

Communications from SIU Via LCB

Processed Events to SSRVia LCB

Communications to SIUVia LCB

Via LCB

Via LCB

Event DataVia LCB

SRS 5.2.1.1

SRS 5.2.1.1

SRS 5.2.1.1

SRS 5.2.1.1

SRS 5.3.1.4

SRS 5.2.1.3

SRS 5.3.1.2



FSW ICDsFSW ICDs

• FSW interfaces to SC managed by Spectrum Astro

– 1553 Bus Protocol ICD

– SC-LAT ICD• FSW interfaces

within the LAT are detailed at right

• All released or in release process

SIU/EPU

SIB

CRU

LCB

TCS EBM

TEM

PDU GEM

AEM

FESGTCC

GTRC

GTFE

GCCC

GCRC

GCFE

GARC

GAFE

LAT-SS-00606

LAT-TD-01547

LAT-SS-00605

LAT-TD-01544

LAT-SS-00176 LAT-SS-00238 LAT-SS-00363

LAT-SS-01825

LAT-SS-01545

LAT-SS-01546

LAT-SS-00860

LAT-SS-01543

LAT-SS-01539



FSW Introduction to TermsFSW Introduction to Terms

Requirements

Functions

Tasks

Packages

Releases

Testing

High level statements of specific characteristics or capabilities necessaryto the FSW

Categories or broad areas of capability (functionality) that the FSW must implement to satisfy the requirements

Concurrent processes executing on the processor that perform the required functions of the FSW (equivalent to the concept of threads)

Logical organization of actual code into groupings of files and associated data for documentation, testing and compilation; packages provide specific services or carry out specific functions that are building blocks of tasks

Specific collections of packages (or partially implemented packages) that compile properly and execute to implement a specific subset of the total defined FSW tasks, providing a subset of the overall FSW functions that satisfy a subset of the FSW requirements; the full LAT FSW release must satisfy all FSW requirements

Each release must be tested to verify that it does what it was designed to do and that the design satisfies the intended requirements; the full LAT FSW release must be shown to satisfy all FSW requirements



SIU FunctionsSIU Functions

• Boot (SRS 5.3.4.1)• Command processing and distribution (SRS 5.3.4.2)• Telemetry management (SRS 5.3.4.4)• Time, attitude and ancillary data processing (SRS 5.3.4.3.4-6)• Configuration of LAT (SRS 5.3.4.6)• Health, status and safety monitoring

– Housekeeping and low rate science (SRS 5.3.4.8)– Software watchdog (SRS 5.3.2.1)– Load shed, safe mode, SAA (SRS 5.3.4.3.7-9, 5.3.4.12)

• File upload/download management (derived SRS 5.3.4.2)• Calibration and diagnostics (SRS 5.3.4.7)• Mode control (SRS 5.3.4.5)• Thermal control system (SRS 5.3.4.13)• Instrument physics

– GRB processing (SRS 5.3.4.3.1-3, 5.3.4.9-10)– Summary analysis, statistics (derived, 5.2.2.3, 5.3.4.11)



EPU FunctionsEPU Functions

• Boot (SRS 5.2.2.1)• Command receipt management (SRS 5.2.2.2, derived)• Telemetry management (derived)• Health, status and safety monitoring

– Software watchdog (SRS 5.2.1.2)• Calibration and diagnostics (derived)• Instrument physics

– Event filtering (SRS 5.2.2.4)– Filter configuration (SRS 5.2.2.5, 5.2.2.6)



SIU Tasks, Functions, RequirementsSIU Tasks, Functions, Requirements

Function Task(s) SRS Ref.

Boot (Boot) 5.3.4.1

CMD processing and distribution 1553 Rx, LCB Rx 5.3.4.2

TLM management 1553 Tx, LCB Tx 5.3.4.4

Time, attitude, ancillary data processing SC Att./Time, 1 PPS Int. 5.3.4.3.4-6

Configuration for EPU, filters Instrument Physics 5.3.4.6

Housekeeping, low rate science HSK 5.3.4.8

Software watchdog SW Watchdog 5.3.2.1

File upload/download management File/Obj Derived, 5.3.4.2

Load shed, safe mode, SAA 1553 Rx, Primitive 5.3.4.3.7-9, 5.3.4.12

Calibration and diagnostics Instrument Physics 5.3.4.7

Mode control Instrument Physics 5.3.4.5

Thermal control system HSK, Primitive 5.3.4.13

GRB processing Instrument Physics 5.3.4.3.1-3, 5.3.4.9-10

Summary analysis, statistics Instrument Physics Derived, 5.2.2.3, 5.3.4.11

• Correlates SIU functions with the tasks that perform them



EPU Tasks, Functions, RequirementsEPU Tasks, Functions, Requirements

• Correlates EPU functions with the tasks that perform them

Function Task(s) SRS Ref.

Boot (Boot) 5.2.2.1

CMD receipt management LCB Rx Derived

TLM management LCB Tx Derived

Time, attitude, ancillary data processing SC Att./Time, 1 PPS Int. 5.3.4.3.4-6

Configuration of LAT Instrument Physics 5.2.2.2, 5.2.2.5, 5.2.2.6

Housekeeping, low rate science HSK 5.3.4.8

Software watchdog SW Watchdog 5.3.2.1

File upload/download management File/Obj Derived, 5.3.4.2

Calibration and diagnostics Instrument Physics Derived

Event filtering Instrument Physics 5.2.2.4



FSW Task FrameworkFSW Task 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



FSW Architecture with Task FrameworkFSW Architecture with Task Framework

1553 Rx service

Spacecraft Interface Unit

Q

QQ

Q

Q

QQ

Q

Q

Q

QQ

Masters

1553 Tx service LCB Tx service

SC Att./Time

Primitive

File/Object

HSK

Instr. Phys.

LCB Rx service

QQ

Other Tasks

Software Watchdog

Q

Q

Q

Slaves

SC Att./Time

File/Object

HSK

1 PPSInterrupt

GBM Interrupt

Event Processing Unit(s)

QLCB Tx service

LCB Rx service

Q

Other Tasks

Software Watchdog

Q

Q

Q

Slaves

SC Att./Time

File/Object

HSK

1 PPSInterrupt

QInstr. Phys.Q

Event Builder (EB) output side. The EB is an element of the GASU.

To EPU(s)To SSR

Event Builder (EB) input side. The EB is an element of the GASU.

Command/Response Unit (CRU). The CRU is an element of the GASU.

From SIU From EPU(s) Event Assembly

SolidState

Recorder

Spacecraft

1553

LAT Instrument

Legend

Telecommand (SC to LAT)

Telemetry (LAT to SC)

Master to slave

Slave to master

Physics data from LAT

Data to SSR

Command/Response

Discretes(to RAD750 PIDs)

To SIU



Description of Master TasksDescription of Master Tasks

• SC Att./Time deals with dispatching the seven messages per second from the spacecraft – 5 attitude– 1 time-tone– 1 ancillary (containing orbit information as well as status info)

• Instr. Phys. master deals with all instrument data related processing – May execute different code depending on operating mode

• GRB detection and performance monitoring in normal mode• Other algorithms in calibration/diagnostics modes

• File/Object master deals with all file upload/copy/delete/… processing• HSK master deals with accumulating and examining housekeeping

– Acquires information from SIU (self), EPUs, electronics hardware– Provides monitoring and alarming– Outputs telemetry

• Primitive (or immediate) master deals with the very primitive LAT configuration command set



FSW PackagesFSW Packages

• FSW partitioned into functional blocks, then tasks, based on the SRS

– Tasks 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 package’s 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

– Unit tests are developed and code managed within the package



Task to Package MappingTask to Package Mapping

FMP

HU

T

EDP

EOP

EMP

ECL

ECP

GN

AT

GC

FG

SOP

SMP

SCL

GB

M

GR

B

HSK

CH

P

THP

TCS

MC

P

EFP

GPS

LAP

LCP

SDF

SWD

SSR

LIO

CO

1553

PBS

Exc

Mem

Test

Boo

tSh

EEPR

OM

PCI

CC

SDS

Upl

oad

ZLIB

Boo

tUt

1553 service l l lLCB service l l lSoftware W atchdog l lPrimitive l l l l l l l l l l l lInstr. Phys. master l l l l l l l l l l l l l l l l l l l lSC Att./Time master l l l l l l l l l lHSK master l l l l l l l l l l l lFile/Object master l l l l l l l l lInstr. Phys. S lave l l l l l l l l l l l l l l l lSC Att./Time master l l l l l l l l lHSK slave l l l l l l l l l lFile/Object slave l l l l l l l l lBoot l l l l l l l l l l l l

Package

Task



Package DescriptionsPackage Descriptions

PACKAGE DESCRIPTION LOCRISK

FACTOR CONTINGENCYPBS Basic Services 1800 1,2 75FMP File Management 1500 3 450CHP CPU Housekeeping 1000 3 300SWD Software Watchdog 1000 3 300LIO LAT LCB I/O driver 3000 5 1500HUT Histogrammer 1750 3 525SSR SSR services 1000 5 500SDF SIU Diag Framework 1000 10 1000TOTALS 12050 4650


FACTOR CONTINGENCYEDP Event Dispatch 2100 3 700EOP Event Output 3750 3 1125EMP Event Monitoring 3500 2 700ECL Calibration (client) 4950 5 2475ECP Command/Control 3400 3 1020SOP Event output 1250 2 250EFP Event Filtering 10000 5 1000TOTALS 28950 7270


FACTOR CONTINGENCYGNAT LAT DAQ cmd/resp 1550 1 155GCFG DAQ configuration 5850 1,3 925LCP LAT commanding/1553 3600 2 360SMP Event output 3100 3 930SCL Calibration (server) 3200 5 1600HSK Housekeeping 6350 3 1905THP Trend/bounds check 1500 2 300MCP Mode control 1300 3 390GPS GPS services 800 3 240LAP SC attitude services 1300 3 390GBM Response to GBM data 1550 3 465GRB GRB detection 2400 3 720TCS Thermal Control 2000 5 1000TOTALS 34500 9380


FACTOR CONTINGENCYREV Reset/exceptions 400 2 40MEM Memory test 100 1 10BSH Boot shell 1000 3 300EDV EEPROM driver 100 1 5PCI PCI driver 300 0 0CCSDS CCSDS formatter 400 0 0UPL Upload parser 1000 3 300ELF ELF dynamic loader 500 0 0ZLIB ZLIB integration 40 0 0BUT Boot Utilities 200 0 0LCB LCB driver (polled mode) 400 5 200CO1553 1553 driver (polled mode) 400 0 0TOTALS 4840 855


FACTOR CONTINGENCYFES Front end simulator 5600 3 1680LTX Test executive 5200 5 2400TOTALS 10800 4080

Common code – SIU and EPU

EPU specific code

Test and verification code

SIU specific code

Boot code

*See next slide for discussion of contingency

Grand Totals: 91,140 LOC with 26,235 contingency (~30%)*Contingency algorithm is described in Appendix




Verification Program

Design & DevelopmentDesign & Development



BootBoot

• Principal requirements: SRS 5.2.2.1, 5.3.4.1• Boot document: LAT-TD-001806-04

• Boot proceeds in two stages– Primary boot (from on-board SUROM)– Secondary boot (from EEPROM on SIB board)

CPU Crate (SIU or EPU)

RAD750 SIB

Reserved for Secondary

Boot

(Managed byTFFS software)

EEPROM Bank 0

(Managed by TFFS software)

EEPROM Bank 1

1553 communications to SC(not used by EPU boot)

SUROM

(256 kB)

750

CPU

Bridge Chip

SDRAM

(128 MB)

LCB

LCB communications to SIU(not used by SIU boot)

Discrete I/O



Primary BootPrimary Boot

• CPU reset from SUROM– Run bridge chip initialization procedure– Set initial watchdog timeout– Map out SDRAM, SUROM and PCI I/O spaces– Enable processor L1 instruction cache– Disable interrupts

• Memory test SDRAM– Memory test (all 0’s, all 1’s, checkerboard) (runs from ROM/cache)

• Start primary boot shell (now using RAM resources)– Enable processor L1 data cache– 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



Primary Boot Command ProcessingPrimary Boot Command Processing

Startup

SIANCILLARY Packet

Received Last HKP Packet Sent

Timeout - No Command Message Received

Operational Command

Packet Received

SIANCILLARY Packet

Received

Command Start Telecommand

Received

Last HKP Packet Sent

Upload Packet Received

RTOS Execute Command

Poll 1553 Remote Terminal

Prepare Next HKP Telemetry Packet

Record Time Information

Parse Operational Command

Load and Execute RTOS

Parse Upload Packets

Poll 1553 Remote Terminal / Initial

Command Timeout

Initialization



Secondary BootSecondary 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



Boot StatusBoot Status

• Development environment at NRL (Dan Wood)

– Prototype version RAD750

– JTAG programming environment

– Engineering version SIB (access to 1553 and EEPROM)

• Recently added man-power: Brian Davis, Ray Caperoon

• Boot code progress:

Code Block Language LOC estimated LOC written CommentReset and Exception Vectors ASM 400 200 Estimate based on existing TCPU-603 code

Memory Test ASM 100 0 Coded in ASM to carefully control memory accesses

Boot Shell C 1000 0 Estimate based on ICM boot shell source code

1553 driver (polled) C 400 400 Done (part of CO1553 package)

LCB driver (polled) C 400 0 Analogous to 1553 polled mode driver

EEPROM driver C 100 50 Estimate based on existing TCPU-603 flash memory driver

PCI driver C 300 0 Estimate based on the BAE RAD750 PCI boot driver

CCSDS packet library C 400 400 Done (CCSDS package)

Upload parser C 1000 0 Estimate based on ICM memory loader

ZLIB file inflator C 1700 1700 Done (ZLIB is public domain software … just packaging)

Boot utilities C 200 100 Take from OSKIT (FreeBSD) - ~100% code reuse

LAT utilities C 400 350 Subset of package PBS (BSWP, SPIN) – 90% complete



Event FilteringEvent Filtering

• Principal requirement: SRS 5.2.2.4

• Numerology– Event size: ~1kB– Physics signal: ~10Hz (whole orbit)– Background: ~2kHz (orbit min) to ~10kHz (orbit max)– Orbit average: ~6kHz trigger rate (6MB/sec)– Allowable data rate to SSR: ~35kB/sec– Filter rejection efficiency required: ~99.6%– Filter must keep up with maximum rate: ~100 sec/event (orbit max)

• Status– 98.4% background rejection achieved at 14 sec/event; executing on

RAD750 (see previous Boot Status slide)

• How to get from 98.4% to 99.6% and when?– Implement final set of cuts being used by ground software– Investigate data compression techniques (more sophisticated than ZLIB)– Target date for completion: EM2 release



Event Filtering – PerformanceEvent Filtering – Performance

Events

Cut Analyzed (%) Rejected (%) <Time> sec

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 < 350Mev + Veto Tile 3931 (25.5) 224 (1.5)

CAL < 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 < .01 1294 (8.4) 156 (1.0)

CAL Energy Layer 0/Total Energy > .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 < 350 Mev, Number of Tracks < 2 699 (4.5) 461 (3.0) 29.9 40.5

Final 238 (1.5) 15182 (98.5) 7.7 13.3



File/Object ManagementFile/Object Management

• Principal requirement: 5.3.4.2.4

• Adopting a file system and TFFS reduces object management to file management– File system provided by VxWorks

• TFFS (True Flash File System)– Balances writes across EEPROM memory– “Bad blocks” bad EEPROM memory locations

• File uploads go to RAM disk first and are then (by command) committed to EEPROM

CPU Crate

RAD750 (Software View)SIB (Hardware View)

Applications

Posix file calls VxWorks

DosFs (Fat16 file system)

RAM disk TFFS

EEPROM driver

(Secondary Boot Code)

Managed by TFFS software

EEPROM Bank 0

Managed byTFFS software

EEPROM Bank 1

(Other SIB functions)

Code written by LAT FSW

VxWorks base product

VxWorks layered product



FSW Resource Usage Current EstimatesFSW Resource Usage Current Estimates

• Principal requirement: SRS 5.4.3

Resource Total Available Anticipated

Usage

Margin Factor

EPU Boot PROM 256 kB 128 kB 2

SIU Boot PROM 256 kB 128 kB 2

EPU EEPROM 4 MB 1.5 MB 2.7

SIU EEPROM 8 MB 1.5-2.5 MB 3-5

EPU CPU cycles 200% in 2 EPUs 30% > 6

SIU CPU cycles 100% in 1 SIU 25% 4

EPU memory 128 MB 16-32 MB 4-8

SIU memory 128 MB < 16 MB 8

Bandwidth – instrument to EBM 45 MB/sec 10 MB/sec 4.5

Bandwidth – EBM to CPU 20 MB/sec 5 MB/sec 4

Bandwidth – CPU to EBM 2.5 MB/sec 20 kB/sec 125

Bandwidth – EBM to SSR 5 MB/sec 40 kB/sec 125



Development EnvironmentDevelopment 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– Autogeneration of documentation: Doxygen– Documentation: Microsoft office suite (also Adobe / Framemaker, etc.)



Software Development ApproachSoftware Development Approach

• 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

• Independent quality assurance and test oversight manager

– Reviews test plans, procedures, scenarios, data

– Reports directly to LAT QA, systems engineering



Software Design for SafetySoftware 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

• Not recoverable and CPU compromised: Stay with reboot strategy

– 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

• Not recoverable but CPU integrity good: Report to ground and await intervention

• Fully recoverable: Perform recovery action, continue operation



FSW Fault DetectionFSW Fault Detection

• Hardware Fault Detection– Run bridge chip built-in test– Examine checksums on SC communications– Detect missing messages from SC– Look for parity errors on LAT internal communications– Check housekeeping of LAT voltages, currents and temperatures

• Software Fault Detection– Keep CPU housekeeping metrics: memory usage, idle time– Enforce the software watchdog

• All registered tasks must regularly report progress in order for the software watchdog to reset the hardware watchdog

• Instrument Data Fault Detection– Monitor low rate science (counter) readings– Compare instrument configurations read out from beginning and

end of data collection runs (must agree)– Examine single event data for correct format, completeness– Check single event data for physics consistency



Development ProcessDevelopment Process

• Initial design effort– Define hardware interfaces and

architecture– Build stable development infrastructure– Generate high-level requirements (SRS)

that capture scope of project– Generate high-level design that captures

basic architecture and interfaces

• For each FSW release– Generate detailed design of new functionalities– Employ iterative design/code/test process to converge on the detailed

design (“little spirals”)• Allows experienced developer to proceed more rapidly to explore the design

parameter space, discover issues, and resolve them• Ultimately produces a more optimal design than one selected in advance

based only on analysis and limited data• Extensive documentation of resulting code is produced as it is built• Iterative process is a continuous rapid prototyping cycle that supports higher

productivity and a higher quality final product

Act

ivit

y

Time

Code/Test

Architecture,design

Qualitative example for 3 major spirals



1st 2003 2nd 2003 3rd 2003 4th 2003 1st 2004 2nd 2004 3rd 2004 4th 2004

CDR4/29/03

EM2Peer Review

10/1/03EM1 CodeRelease7/1/03

FUPeer Review

4/1/04

FU releaseto I&T

10/1/04EM2 CodeRelease3/1/04

FU Code Release9/1/04

EM1 cycle (Single Tower, Single CPU)

EM2 cycle (Multi-Tower, Single CPU)

FU cycle (All)

Breakdown of Development CyclesBreakdown of Development Cycles

Design/Develop Develop/Test System-Level Test

Design/Develop: Start design, code small prototypes, no hardware available, only descriptionsDevelop/Test: Code and test against real hardware, take snap-shot at end (i.e. define release)System-Level test: Test against system-level test scenarios, release to I&T at end



EM1 FSW ReleaseEM1 FSW Release

• Hardware– 1 Partially populated tower– 1 Tower Electronics Module– 1 COTS CPU (VME)

• Ethernet• Serial port• LCB

• Software– Interfaces (other than VxWorks)

• LCB command/response• LCB event acquisition

– TEM configuration setting and read-back• Read/write all TEM/TKR/CAL registers

– 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– Collect TEM housekeeping and LRS data

• In Parallel– Filter development and testing– Boot, 1553 development

Status:

Development complete against preproduction electronics with the exception of LCB support (using VME I/O communications boards instead)

Deployed to field in I&T test stands

Goal: Demonstrate Single-Tower, Single-CPU Operation



EM1 FSW ArchitectureEM1 FSW Architecture

“1553 Rx” (e-net)


QQ

Q

QQ

Q

QQ

Masters

“1553 Tx” (e-net) “LCB Tx” (e-net)

Primitive

HSK

Instr. Phys.

LCB Rx service

Q

Other Tasks

Software Watchdog

Q

Slaves

HSK

QInstr. Phys.Q

“Spacecraft” (Host System)

Ethernet

LAT “Instrument”

Legend



Master to slave

Slave to master


Data to SSR

Command/Response

Single Tower



EM1 Function/Task/Package MappingEM1 Function/Task/Package Mapping

• SIU Functions

– Command Distribution

– Telemetry Management

– Configuration of (subset of) LAT

– Health, status monitoring

– Mode control

• “EPU” Functions

– Event acquisition and formatting

FMP

HU

T

EDP

EOP

EMP

ECL

ECP

GN

AT

GC

FG

SOP

SMP

SCL

GB

M

GR

B

HSK

CH

P

THP

TCS

MC

P

EFP

GPS

LAP

LCP

SDF

SWD

SSR

LIO

CO

1553

PBS

Exc

Mem

Test

Boo

tSh

EEPR

OM

PCI

CC

SDS

Upl

oad

ZLIB

Boo

tUt

1553 service ¡ l ¡LCB service l l lSoftware W atchdog l lPrimitive l l ¡ ¡ ¡ l ¡ ¡ l ¡ l lInstr. Phys. master ¡ l l l ¡ ¡ ¡ ¡ l ¡ ¡ ¡ l ¡ ¡ l ¡ l l ¡SC Att./Time master ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ lHSK master l ¡ ¡ ¡ ¡ l ¡ ¡ l ¡ l lFile/Object master ¡ ¡ l ¡ ¡ l ¡ l lInstr. Phys. S lave ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ l ¡ ¡ l l l ¡SC Att./Time master ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ lHSK slave ¡ l ¡ ¡ l ¡ ¡ l l lFile/Object slave ¡ ¡ l ¡ ¡ l l ¡ lBoot ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

Package

Task



EM1 FSW Packages (1 of 2)EM1 FSW Packages (1 of 2)

• GNAT – Physical IO & Protocol to Command/Response Fabric– Controls the access to the physical layer of the Command/Response

Protocol – %age of final package needed for EM1: 100%

• GCFG – Configuration of Front-End Electronics – Configures the LAT electronics by sending commands to the various boards

and their associated registers – Readback of the configuration is also supported here – 50% needed (70% planned)

• Only need TEM specific code• SOP – SIU Event Output Package

– Attaches auxiliary data and packages events with CCSDS format for output to SSR

– 30%• HSK – Housekeeping and Low Rate Science

– Handles housekeeping and low rate science data– 50%

• Need infrastructure and ability to handle 40 TEM telemetry points• MCP – Mode Control

– Handle run control– 50%



EM1 FSW Packages (2 of 2)EM1 FSW Packages (2 of 2)

• SDF – Frameworks – New feature in top-level design to uniformly handle communications needs

across all major functional blocks and shelter application developer from dealing with task-to-task communications

– 100%• SWD – Software Watchdog

– Monitor activity in other tasks– 100%

• LIO – LAT Communication Board I/O– Hardware interface for all LAT internal communications– 100%

• PBS – Processor Basic Services– Resource allocation and management tools– 100%

• PCI– Provide PCI interface– 100%

• CCSDS – Format CCSDS packets– Used to wrapper events– 100%



EM2 FSW ReleaseEM2 FSW Release

• Hardware– Multiple towers (real or FESs)– Multiple TEMs– GASU

• Command Response Unit (CRU)• Event Builder Module (EBM)• ACD Electronics Module (AEM)• Global Trigger 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– Charge injection calibration

• In Parallel– Filter development and testing– Boot development and testing

Goal: Demonstrate Multi-Tower, Single-CPU Operation with 1553 interface



EM2 FSW ArchitectureEM2 FSW Architecture

1553 Rx service


Q

QQ

Q

Q

QQ

Q

Q

Q

Q

Masters


SC Att./Time

Primitive

File/Object

HSK

Instr. Phys.

LCB Rx service

Q

Other Tasks

Software Watchdog

Q

Q

Q

Slaves

SC Att./Time

File/Object

HSK

1 PPSInterrupt

GBM Interrupt

QInstr. Phys.


To SSR



From SIU Event Assembly

“SolidState

Recorder”

“Spacecraft”(SIIS or SBC)

1553

LAT “Instrument”

Legend



Master to slave

Slave to master


Data to SSR

Command/Response


To SIU

Multiple Towersor

Front EndSimulators

Q

Q



EM2 Function/Task/Package MappingEM2 Function/Task/Package Mapping

• SIU Functions … EM1 plus

– Extended LAT configuration

– Extended health, status monitoring

– SC Att./Time message processing

– File management

– Mode control

• “EPU” Functions … EM1 plus

– Event filtering

– Charge injection calibration (all subsystems)

FMP

HU

T

EDP

EOP

EMP

ECL

ECP

GN

AT

GC

FG

SOP

SMP

SCL

GB

M

GR

B

HSK

CH

P

THP

TCS

MC

P

EFP

GPS

LAP

LCP

SDF

SWD

SSR

LIO

CO

1553

PBS

Exc

Mem

Test

Boo

tSh

EEPR

OM

PCI

CC

SDS

Upl

oad

ZLIB

Boo

tUt

1553 service l l lLCB service l l lSoftware W atchdog l lPrimitive l l ¡ ¡ ¡ l ¡ ¡ l l l lInstr. Phys. master ¡ l l l ¡ ¡ ¡ ¡ l ¡ ¡ l l l l l l l l lSC Att./Time master ¡ ¡ ¡ l l ¡ ¡ l l lHSK master l l ¡ ¡ ¡ l l ¡ l l l lFile/Object master l ¡ l ¡ ¡ l l l lInstr. Phys. S lave ¡ ¡ ¡ ¡ ¡ ¡ l ¡ ¡ l ¡ l l l l lSC Att./Time master ¡ l ¡ l ¡ ¡ ¡ l lHSK slave ¡ l l ¡ l ¡ ¡ l l lFile/Object slave l ¡ l ¡ ¡ l l l lBoot ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

Package

Task



EM2 FSW Packages (page 1 of 2)EM2 FSW Packages (page 1 of 2)

• All of EM1 100% packages plus

• FMP – File Management Package– 70% (use with RAM disk only)

• EDP – EPU Event Dispatch– 100%

• GCFG – Configuration of Front-End Electronics – Complete to 100%

• SOP – SIU Event Output Package – Complete to 100%

• HSK – Housekeeping and Low Rate Science– Handles housekeeping and low rate science data– 80%

• Handle all hardware test points in EM2• Monitor CPU metrics

• CHP – CPU Housekeeping– Generate CPU metrics (memory, idle time)– 100%



EM2 FSW Packages (page 2 of 2)EM2 FSW Packages (page 2 of 2)

• MCP – Mode Control– Handle run control– 50%

• EFP – Event Filtering– Filters out background events– 100%

• GPS – Global Positioning System– Handles GPS time hack/message/LAT time correlation– 100%

• LCP – LAT command handling– Dispatch of 1553 messages– 100%

• CO1553 – 1553 driver– Interface to 1553 hardware– 100%

• ZLIB – Data deflate/inflate– Compress/decompress files– 100%



Full LAT FSW ReleaseFull LAT FSW Release

• Hardware– All towers / FESs / TEMs– ACD FES– GASU

• Command Response Unit (CRU)• Event Builder Module (EBM)• ACD Electronics Module (AEM)• Global Trigger Module (GEM)

– Multiple engineering RAD750s– SIIS

• Software– All of EM2 functionality– Boot and startup operations– LAT hardware power control– Thermal control system– Multiple processor capabilities

• CPU to CPU communications• Scatter/gather synchronization by SIU• EPU configuration by SIU

– Spacecraft message processing• Attitude, time, ancillary data

– Event filter operation– Transient detection and reporting

Goal: Demonstrate Full LAT Operation (Multi-Tower, Multi-CPU, SC interfaces)



Full LAT FSW ArchitectureFull LAT FSW Architecture

1553 Rx service


Q

QQ

Q

Q

QQ

Q

Q

Q

QQ

Masters


SC Att./Time

Primitive

File/Object

HSK

Instr. Phys.

LCB Rx service

QQ

Other Tasks

Software Watchdog

Q

Q

Q

Slaves

SC Att./Time

File/Object

HSK

1 PPSInterrupt

GBM Interrupt

Event Processing Unit(s)

QLCB Tx service

LCB Rx service

Q

Other Tasks

Software Watchdog

Q

Q

Q

Slaves

SC Att./Time

File/Object

HSK

1 PPSInterrupt

QInstr. Phys.Q


To EPU(s)To SSR



From SIU From EPU(s) Event Assembly

SolidState

Recorder

Spacecraft

1553

LAT Instrument

Legend



Master to slave

Slave to master


Data to SSR

Command/Response


To SIU




Verification Program

VerificationVerification



Software Testing PlanSoftware Testing Plan

• Development Testing– Software code and package level testing– Performed on developer’s platform or captive embedded system– Verify algorithm development, debug software logic

• System-Level Testing– Software composite testing

• Higher level functionality tests – combine many packages• Verify functionality and interfaces

– System build testing• Highest level tests – verify / validate against requirements

– Acceptance Test• Test environments

– Software / hardware integration and test• Performed on FSW test bed with breadboard / brassboard

hardware (COTS and then RAD750) • Verify software executing on target processors with real-time

operating system (VxWorks)• Verify software interfaces with input/output hardware in loop

– Software / system integration and test• Performed on flight spacecraft hardware in EGSE environment• Verify FSW with flight spacecraft hardware



System-Level Test MatrixSystem-Level Test Matrix

TEST NUMBER

001

002a

002b

003

004

005

006a

006b

007a

007b

007c

007d

008a

008b

009a

009b

010

011

012a

012b

013a

013b

014

015

100

101

102

103

100

101

102

103

LA

T F

SW

TE

ST

S

FU

NC

TIO

NA

L T

ES

TS

1553

INT

ER

FA

CE

TE

ST

CO

MM

AN

D F

UN

CT

ION

AL

ME

MO

RY

UP

LOA

D V

ER

IFIC

AT

ION

NA

RR

OW

BA

ND

TE

LEM

ET

RY

VE

RIF

ICA

TIO

N

WID

EB

AN

D T

ELE

ME

TR

Y V

ER

IFIC

AT

ION

VE

HIC

LE S

IGN

ALS

INT

ER

FA

CE

VE

RIF

ICA

TIO

N

SIU

/EP

U C

PU

-TO

-CP

U C

OM

M F

NC

TL

TE

ST

EP

U IN

TE

RN

AL

CO

NF

IGU

RA

TIO

N T

ES

T

T&

DF

INT

ER

NA

L C

ON

FIG

UR

AT

ION

TE

ST

TK

R IN

TE

RN

AL

CO

NF

IGU

RA

TIO

N T

ES

T

CA

L IN

TE

RN

AL

CO

NF

IGU

RA

TIO

N T

ES

T

AC

D IN

TE

RN

AL

CO

NF

IGU

RA

TIO

N T

ES

T

EV

EN

T F

ILT

ER

ING

- A

LGO

RIT

HM

VE

RIF

ICA

TIO

N

ELE

CT

RO

NIC

CA

LIB

RA

TIO

N

FS

W A

ND

LA

T IN

ITIA

LIZ

AT

ION

FS

W A

ND

LA

T R

E-I

NIT

IALI

ZA

TIO

N A

ND

RE

CO

VE

RY

LAT

PO

INT

ING

CA

LCU

LAT

ION

S

GR

B H

AN

DLI

NG

/RE

PO

INT

ING

RE

QU

ES

TS

AD

DL

SC

I PR

OC

- G

RB

DE

TE

CT

ION

AN

D L

OC

AT

ION

AD

DL

SC

I PR

OC

- R

EP

OIN

TIN

G L

OG

IC

OP

ER

AT

ION

AL

MO

DE

S -

SA

FE

MO

DE

S

OP

ER

AT

ION

AL

MO

DE

S -

SC

IEN

CE

MO

DE

S

LAT

DIA

GN

OS

TIC

AN

D C

ALI

BR

AT

ION

MO

DE

S

LAT

TH

ER

MA

L C

ON

TR

OL

SY

ST

EM

OP

ER

AT

ION

AL

SC

EN

AR

IO T

ES

TS

LAT

ON

OR

BIT

INIT

IALI

ZA

TIO

NS

NO

RM

AL

OP

ER

AT

ION

S –

SK

Y S

UR

VE

Y M

OD

E

NO

RM

AL

OP

ER

AT

ION

S –

PO

INT

ED

OB

S M

OD

E

LAT

PE

RF

OR

MA

NC

E V

ER

IFIC

AT

ION

S

AC

CE

PT

AN

CE

TE

ST

S

LAT

ON

OR

BIT

INIT

IALI

ZA

TIO

NS

NO

RM

AL

OP

ER

AT

ION

S –

SK

Y S

UR

VE

Y M

OD

E

NO

RM

AL

OP

ER

AT

ION

S –

PO

INT

ED

OB

S M

OD

E

LAT

PE

RF

OR

MA

NC

E V

ER

IFIC

AT

ION

S

ENGINEERING MODEL RELEASES

EM1 P P P X X X T P P

EM2 P P X P P X X X X X T P P P P P P

FULL LAT RELEASE

AMBIENT X X X X X X X X X X X X T X X X X X T X X X X P X X X X X X

LAT BEAM TEST X X X X X X

THERMAL VACUUM HOT X X X X X X X X X X X

THERMAL VACUUM COLD X X X X X X X X X X X

X = Test is performed P = Partial test is performed T = Test performed on separate testbed w ith simulated data

LAT FSW RELEASESAND

TEST PHASES



LAT Test Executive (LTX)LAT Test Executive (LTX)

• LAT Test Executive (LTX) designed to provide a uniform, efficient method to– Create and track a test description/procedure (in a computer format)

• Code developer or external organization prepares two files– Test description and procedure

» A structured XML file» Editor provided by the test executive (enforces structural rules)

– Test script• These files reside in standard CMX packages

– Code managed and versioned using CMX / CMT / CVS– Can be either

» Part of a main line package (unit level / white box testing)» In a dedicated test package (composite or system level / black box testing)

– Run a test and capture the results into persistent storage• Results captured into a random access database (MySQL)

– All tests uniquely identified– Test associated files (e.g. terminal logs) saved in protected area and

referenced by entries in the database– Attach an analysis suite to a test output

• Code developer writes an analysis script• Analysis products indexed to original test



LAT Test Executive (LTX)LAT Test Executive (LTX)

LTX“run”

TargetSystem 0

TestScript

(Python)

Create

TargetSystem 1

TargetSystem n

LTX“edit”

LTX“analyze”

TestDescription

(XML)

AnalysisScript

(Python)

MySQLdatabase

Run

Analyze

LTX“extract”

TestProcedureDocument

Future Goals

LTX“extract”

TestResult

Document

LTX“extract”

LTX“browse”

LTX“browse”

“Terminal” Connections

Test FileStorage • Status

– Tools selected• Python, XML, MySQL, Qt

– First release of stages• Create• Run (without MySQL capture)

– Available to developers now



Front End Simulator (FES)Front End Simulator (FES)

• Document: LAT-TD-1825• Requirement

– Provide realistic simulation of TKR, CAL and ACD detectors and front-end electronics including:

• Events, noise, pile-up, faults and commands– Do this for extended periods (full orbit’s worth)

• ~90 minutes at event rates from 2 kHz to 10 kHz• Implementation

– Prepare simulated datasets in near-electronics format– Drive datasets from PC storage into TEM / AEM cable inputs

• Data goes through custom FES board– Buffers the data– Keeps strict timing relationships– Same board used for TKR, CAL and ACD … only state

machine firmware different



Front End Simulator StatusFront End Simulator Status

• Trade studies performed to select hardware– Driven by

• Data storage requirement• Bandwidth into transition boards

• Hardware selected– Intel Pentium @ 2.4 GHz– 4 x 120 GByte disks– Moselle split bridge from PC to transition

board (PCI standard)– This configuration sufficient to drive two

towers– Two copies purchased

• PC development environment selected (VxWorks)

• Skeleton of PC processing coded• Transition boards in testing




Cost & Schedule

Cost and ScheduleCost and Schedule



FSW Summary ScheduleFSW Summary Schedule

ActivityID

Activity Description %Comp

OrigDur

EarlyStart

EarlyFinish

TotalFloat

4 GLAST INSTRUMENTS

4.1 GLAST LAT PROJECT

4.1.7 ELECTRONICS4.1.7.9 FLIGHT SOFTWARE

4.1.7.9.1 INFRA-STRUCTURE DEVELOPMENT/TEST BENCH SUPPORT4.1.7.9.1.1 INFRA-STRUCTURE DEVELOPMENT

7EN7000050 FSW Support during Integration/Testing (SLAC) 247 09/21/04 09/19/05 380

7EN7000060 FSW Support during Integration/Testing (NRL) 247 09/21/04 09/19/05 380

4.1.7.9.3 ENGINEERING MODEL 14.1.7.9.3.8 EM1 Code Design/Develop

7EN9380000 iN: EM1 Hardware Specification 0 10/07/02* 66

7EN9381000 SIU/EPU Common Application Code 70 01/22/03* 04/30/03 0

7EN9382000 SIU Specific Application Code 70 01/22/03* 04/30/03 0

4.1.7.9.3.9 EM1 Code Develop/Test

7EN9390000 iN: EM1 Hardware for Develop/Test (Early) 0 03/17/03* 37

7EN9391000 SIU/EPU Common Application Code 65 05/01/03 08/01/03 0

7EN9392000 SIU Specific Application Code 65 05/01/03 08/01/03 0

7EN9393110 AV: EM1 Final Code Release 0 08/01/03 0

4.1.7.9.3.A EM1 Formal Test

7EN93A0000 ND: EM1 Mini-Tower (from I&T) 0 08/01/03* 0

7EN93A1000 EM1 Formal Test 42 08/04/03 10/01/03 0

4.1.7.9.4 ENGINEERING MODEL 24.1.7.9.4.C EM2 CODE DESIGN/DEVELOP

7EN94C0000 iN: EM2 Hardware Specification 0 03/03/03* 0

7EN94C1000 SIU/EPU Common Application Code 108 03/04/03 08/04/03 0

7EN94C2000 EPU Specific Application Code 108 03/04/03 08/04/03 0

7EN94C3000 SIU Specific Application Code 108 03/04/03 08/04/03 0

4.1.7.9.4.D EM2 CODE DEVELOP/TEST

7EN94D0000 EM2 Peer Review 0 10/01/03* 0

7EN94D0010 iN: EM2 Hardware for Develop/Test (Early) 0 08/04/03* 0

7EN94D1000 SIU/EPU Common Application Code 119 08/05/03 02/02/04 0

7EN94D2000 EPU Specific Application Code 119 08/05/03 02/02/04 0

FY03 FY04 FY05SEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOV

© Primavera Systems, Inc.

Start Date 04/03/00

Finish Date 04/05/07

Data Date 06/01/02 NEW FSW SCHEDULE

FSWR

Gamma Ray Large Area Space TeleFSW Schedule

Sheet 1 of 2



FSW Summary Schedule (cont.)FSW Summary Schedule (cont.)

ActivityID

Activity Description %Comp

OrigDur

EarlyStart

EarlyFinish

TotalFloat

7EN94D3000 SIU Specific Application Code 119 08/05/03 02/02/04 0

7EN94D4010 AV: EM2 Final Code Release 0 02/02/04 0

4.1.7.9.4.E EM2 FORMAL TEST

7EN94E1000 EM2 Formal Test 42 02/03/04 04/01/04 0

4.1.7.9.6 FLIGHT UNIT4.1.7.9.6.1 FU CODE DESIGN/DEVELOP

7EN9610000 iN: Flight Code Inputs Available 0 06/02/03* 0


7EN9612000 EPU Specific Application Code 182 06/03/03 03/01/04 0


7EN9614100 FU Peer Review 0 04/01/04* 0

4.1.7.9.6.2 FU CODE DEVELOP/TEST

7EN9620000 iN: Flight Hardware for Develop/Test (Early) 0 03/01/04* 0


7EN9622000 EPU Specific Application Code 108 03/02/04 08/02/04 0


7EN9624100 iA: FU Code Release 0 08/02/04 0

4.1.7.9.6.3 FU FORMAL TEST

7EN9631000 FU Formal Test 34 08/03/04 09/20/04 0

7EN9634000 AV: FU Final Code Release to I&T 0 09/20/04 0

4.1.7.9.7 Science/Spacecraft7EN9700000 Science/Spacecraft 424 01/22/03* 09/30/04 0

4.1.7.9.8 FLIGHT CPU BOOTING7EN9800000 Flight CPU Booting 424 01/22/03* 09/30/04 0

4.1.7.9.9 FRONT END SIMULATOR7EN9900000 Front End Simulator 255 01/22/03* 02/02/04 0

4.1.7.9.A TEST EXECUTIVE7EN9A00000 Test Executive 264 01/08/03* 02/02/04 0

FY03 FY04 FY05SEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDECJANFEBMARAPRMAYJUNJULAUGSEPOCTNOV

© Primavera Systems, Inc.

Start Date 04/03/00

Finish Date 04/05/07

Data Date 06/01/02 NEW FSW SCHEDULE

FSWR

Gamma Ray Large Area Space TeleFSW Schedule

Sheet 2 of 2



FSW Budget by Fiscal YearFSW Budget by Fiscal Year

0

200

400

600

800

1,000

1,200

FY01 FY02 FY03 FY04 FY05

Bud

get (

K$)



Manpower Plan (FSW)Manpower Plan (FSW)

4.1.7.9 Flight Software

0.0

2.0

4.0

6.0

8.0

10.0

12.0F

Y0

0

FY

01

FY

02

FY

03

FY

04

FY

05

FT

Es

DOE + NASA Project Contributed




Risk & Summary

RiskRisk



RiskRisk

• LAT instrument FSW not critical to mission safety

– No LAT commands or FSW actions can result in damage to hardware

– All relevant hardware has built-in self-protection

• Current limiting protects PMTs during SAA if HV reduction not performed in advance by ground command or FSW action

• LAT instrument FSW supports mission success

– Extensive ground testing (as with balloon flight) prior to flight

– Use of FSW for electronics and system level testing to achieve more user hours by non-developers

– Reprogrammability

• Fully reprogrammable on orbit except for small amount of primary boot code

• Primary boot code being treated as critical code

• Schedule is tight



FSW Status SummaryFSW Status Summary

• FSW requirements and design understood– Architecture– Interfaces– Functionality

• Design for EM1 complete– Development and testing in progress– Running on test stands at GSFC, NRL, SLAC, UCSC, Italy

• Development path through EM1, EM2, FU phases in place, including verification






Cost & Schedule

AppendixAppendix





ContingencyContingency

• 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

RISK FACTOR CRITERIA

0 Written1 Significant coding already complete, also testing or previous experience

(e.g. balloon flight)2 Partial coding already complete, also limited or very well defined scope3 Well understood scope, possibly some coding completed5 Scope partially undefined, limited previous experience or high complexity

10 Scope poorly defined



Peer Review RFA StatusPeer Review RFA Status

ID # Status RFA Description RFA Response/Closure Plan

2 Accepted Boot Process

LAT-TD-01806 describes the primary boot sequence in time order. We agree that the document needs to be extended to include more information about the secondary boot. The goal is to provide that at CDR, or 4 weeks after CDR at the latest.

3 Accepted Explanation of terms

Many of these terms are already defined in detail in the appropriate FSW documents. The FSW team will provide a summary of terms in a separately released document prior to CDR.

4 AcceptedAllocation and derivation of requirements

A version of the SRS with the references to higher level requirements documents included (these references were also included in the SRS review presentation) will be released prior to CDR. We are also planning a series of slides in the CDR that maps requirements to functions, functions to tasks, tasks to packages, and packages to releases. This sequence of slides will also be included in a revised release of the development plan prior to the CDR.





5 Accepted Representation of SW We combined this RFA with RFA4, so see RFA4.

10 AcceptedBenchmarking of data reduction

Tests have already been run on data sets of photons that indicate large numbers of photons are being rejected. However, preliminary analysis suggests that the rejected photons are being legitimately rejected because they are not reconstructable. More detailed analysis is necessary to determine the statistics for rejection of reconstructable photons. There is a need for a test data set of tagged photons (with tags indicating which photons are reconstructable), so that reliable statistics can be generated. Richard Dubois’ group is working on generating this data set. The goal is to have a preliminary report by CDR and a complete analysis by 60 days after CDR.





11 OPEN Independent test team

Our development plan acknowledges that an independent perspective can, under certain circumstances, be valuable, but also recognizes that we do not have the budget or personnel resources for a separate team of similar size to the development team. When the project was approved, this item was not in the requirements (MAR), plan, schedule, or budget.

The plan is to provide QA oversight and systems engineering support to generate test cases/scenarios that the development team may not have previously considered.

There are on-going discussions with the project office whether it is possible to independently verify the boot related part of the FSW, and what the impact would be to the schedule and budget of the LAT.

13 AcceptedRequirement of GRB alert notification

Good RFA. SRS will be modified to state that the GRB alert interrupt is being serviced and that no further action is being taken. This will be included in the SRS release prior to CDR.





18 AcceptedList of functionality for each EM0 (?) package

The concept of functionality is more related to tasks than packages for the FSW. Packages are more related to how the actual code is organized, stored and compiled. A task is accomplished by drawing on the integration of a number of packages. The list of functionality in each release has been previously published, most recently in the peer review. The updated CDR presentation will include more details including the relationship between functions, tasks, packages and releases.

19 Accepted Integration of TFFS

The LAT FSW does uploads into RAM (not EEPROM) and does employ a commit process to save the changes into EEPROM. The TFFS principally maintains even wear on all locations of the EEPROM by managing where information gets written. Much of this RFA was satisfied at the time of the review when the reviewer was shown a copy of Figure 1 from Section 3.2 of the February LAT FSW Design Workshop Minutes. The diagram will be included in a formally released FSW document.





21 OpenModification of requirement and test documents

The SRS has been modified based on specific technical comments resulting from the SRS review. Beyond that the LAT FSW team has no plans to create a new release at a significantly higher level of detail. As described in the development plan, the existing SRS has a sufficient level of detail to define the scope of the project and allow the team to proceed with the design process. That was assumed when the project, including plan, schedule and cost, was approved.

The LAT FSW Test Plan will be revised by CDR to include the desired matrix and descriptions of the tools and environment required for testing. Description of acceptance testing is included in the current revision, but will be clarified.





22 OpenAccelerate schedule of delivery documents

The revised MAR does not require a detailed design document until the delivery of the full LAT FSW build. The purpose of the peer reviews is to present design information for review , to demonstrate understanding of architecture, function, etc. The peer reviews called out in the FSW development plan will likely be scheduled to coincide with overall LAT reviews.

The event filtering algorithms are extremely specialized and complex. The bulk of the code is already written and contains detailed documentation embedded in it. The relevant scientists who provide review and guidance on the algorithm development are conversant with this format and use it directly. Production of a algorithm document represents a significant amount of overhead and is not part of our development plan.

25 AcceptedMonitoring of SC keep-alive

The LAT FSW team agrees with this idea and will adopt the overall concept of monitoring the attitude message from the spacecraft as a keep-alive signal. However, the details of how the LAT FSW will respond to loss of the keep-alive must still be worked out. The plan is to define this before the EM2 peer review.



Requirements SummaryRequirements Summary

Requirement#


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].

Demo

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.

Demo

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.

Demo

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.

Demo

5.2.2.2 Event Processor Reset

The EPU FSW shall perform a re-initialization on command from the SIU. Demo

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.

Demo

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.

Demo

5.2.2.5 Event Filter Reconfiguration

The event filtering software shall be reprogrammable via the SIU. Demo

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.

Demo




Requirement#


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 C&DH across a MIL-STD-1553B bus using the MIL-STD-1553B physical layer protocol.

DemoTest

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.

Test

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.

Insp.Demo

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.

Insp.Demo

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).

DemoTest

5.3.1.5 Data Storage The FSW shall export all science and housekeeping data via the science data and CTDB interfaces for external storage.

Demo

5.3.2.1 SIU Watchdog Once booting is complete, the SIU FSW shall provide a periodic heartbeat to a H/W watchdog. The watchdog shall re-initialize the SIU if the heartbeat is not received.

Demo

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].

Demo

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 data from them via the CPU-to-CPU serial message protocol described in [5].

Demo




Requirement#


5.3.4.1 SIU Boot An SIU processor shall perform a primary boot from non-writeable PROM with the hardware watchdog disabled. This boot shall establish communications with the SC and the secondary boot shall be directed by the SC.

Demo

5.3.4.2.1 LAT Command Processing

The SIU FSW shall receive and process all LAT commands from the SC on the CTDB in the order that they are received. All other LAT subsystems and components shall be directed by commands and configuration information from the SIU.

Demo

5.3.4.2.2 LAT Command Confirmation

All LAT commands from SC shall generate telemetry notification of their dispatch for execution in the order they are received. Additionally, the FSW shall generate telemetry notification about their completion status (success or general cause of failure) at the time such information becomes available.

Demo

5.3.4.2.3 Individual Commands from SC

The SIU FSW shall receive and execute commands from the SC on the CTDB. These commands are issued by either (1) a ground station during a ground or TDRSS contact or (2) by the SC from the time-tagged command queue or as a result of an automatic health and safety reponse.

Demo

5.3.4.2.4 Block Commands from SC

The SIU FSW shall process sets of commands from the SC on the CTDB for block memory loads and dumps. Load blocks shall consist of command sequences required to uplink files that contain configuration tables, software loads and command scripts. Dump blocks shall consist of command sequences required to downlink memory images or stored file segments.

Demo

5.3.4.2.5 Command Execution

The SIU FSW shall be able to reconfigure and direct the operation of the instrument through a combination of automatic operation and time sequenced operation by uploaded scripts that are triggered by immediate commands from the SC.

Demo

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).

Demo




Requirement#


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).

Demo

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).

Demo

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.

Test

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.

Test

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].

Test

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.

Demo

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.

Demo




Requirement#


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. Demo

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).

Demo

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 monitor 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).

Demo

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).

Demo

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).

Demo

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.

Demo

5.3.4.6.1 Configuration Of Subsystems

The SIU FSW shall configure the LAT power distribution subsystem and the CAL, TKR, ACD and T&DF subsystems by writing to the T&DF provided configuration registers.

Demo




Requirement#


5.3.4.6.2 Readback Of Subsystems

The SIU FSW shall read back and record the configuration of the LAT power distribution subsystem and the the configuration of the CAL, TKR, ACD and T&DF subsystems by reading back the T&DF provided configuration registers.

Demo

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.

Demo

5.3.4.7.2 Diagnostics The SIU FSW shall provide the means to perform on-orbit diagnostics of the ACD, TKR CAL and T&DF subsystems by establishing configurations and executing algorithms provided by the subsystem designers.

Demo

5.3.4.8.1 Housekeeping The SIU FSW shall acquire and monitor health and environmental data from the LAT power distribution subsystem and the CAL, TKR, ACD and T&DF subsystems.

Demo

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 T&DF subsystems.

Demo

5.3.4.9 GRB Detection In any science observation mode, FSW shall monitor the science data to identify GRBs.

Demo

5.3.4.9.1 GRB Location Accuracy

For a GRB with > 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 (1 radius).

AnalysisSimulation

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.

SimulationTest

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.

SimulationTest




Requirement#


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).

SimulationTest

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.

Insp.Demo

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.

Insp.Demo

5.3.4.11.1 Deadtime Contribution

The FSW is an element of the T&DF subsystem and shall conform to its allocated contribution to the overall T&DF deadtime requirements.

AnalysisSimulation

Demo

5.3.4.11.2 Deadtime Duty Cycle

The SIU FSW in conjunction with T&DF hardware shall provide the means to control the deadtime duty cycle in response to varying trigger rates.

AnalysisSimulation

Demo

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.

Demo

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.

Demo

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.

Insp.

5.4.2.1 LAT Coordinate System

The FSW shall use the LAT coordinate system defined in [6]. Insp.




Requirement#


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).

Insp.

5.4.3 Resource Margin At launch, FSW shall utilize less than 50% of processor resources (RAM, EEPROM and CPU cycles).

Insp.






Cost & Schedule

Back-upBack-up





Onboard Filter DevelopmentOnboard Filter Development

• Filter designs done with the full simulation and ground-based reconstruction, in consultation with FSW group. Demonstration of principles, included in science performance evaluations.

• FSW implemented most of the filter design for benchmarking on the flight processor.

– filtering is hierarchical. Most important to implement the selections that are run first (highest rate, largest multiplier on CPU demand). More cycles/event available for remaining event sample after each step.

• FSW implementation is being wrapped for inclusion in the simulation/recon packages.

– very early functional testing of the flight algorithms, with high fidelity. Examine details (e.g., existing track finding) using full set of SAS tools, event display, etc.

– detailed evaluation of the filter effects on the science performance

– opportunity for a tuning iteration and optimization of the final set of selections



Summary of Filter and StatusSummary of Filter and Status

Primary Info Design Selection FSW Status

ACD Tile counts (energy dependent) DONE

ACD-TKR Track match with tile DONE

CAL Simple energy selections DONE

CAL Layer ratios DONE

CAL Simple topologies

TKR-CAL Track match with energy centroid

TKR Skirt only cut DONE

TKR Simple hit pattern inconsistent with single prong at low energy

TKR-CAL Minimal #tracks and CAL E, or make additional demands

DONE

TKR Earth direction

TKR TKR hits consistent with a track near CAL if E>0

DONE



Single Development CycleSingle Development Cycle

Design/Develop Develop/Test System-Level Test

Entrance: Sufficient knowledge/documentation to start designActivity: Start design, code small prototypes

Entrance: Target hardware becomes availableActivity: Code and test against real hardware (debug both)

Entrance: Development complete, snapshot taken (release is defined)Activity: Test against system-level test scenarios

Entrance: System-level test plan completed successfullyExit: Release to integration and subsystems



On-Board File SystemOn-Board File System

• LAT will use an on-board file system for storage– Configuration files– Startup & command scripts – Object modules

• File system is managed by TFFS (commercial product)– TFFS compensates for the fact that EEPROM is not infinitely writeable

• Spreads the writes as evenly as possible• Manages damaged memory using bad blocking techniques• Preserves logical continuity even if the file is not physically contiguous

– A 4 MB EEPROM with 1000 writes supports 4 GB lifetime• Translates to ~1 MB/day for 10 years• Example of configuration file sizes: TKR mask bits @ 2 bits per strip

– Stored “dumb”: ~222 kByte– Stored “smart” (OR and XOR the bits then gzip): ~20 kByte– Update frequency estimated at less than once a week

• LAT Usage of the File System– Supports both EEPROM and RAM based file systems

• Allows testing in RAM before commitment to EEPROM– Limits file specifications to 32-bits with sub-directory depth of 1

• Limitation driven by the size restrictions of telecommand packets



Physical Interfaces: Backplane, PCI and PIDsPhysical Interfaces: Backplane, PCI and PIDs

RAD750

SIB

LCB

GASU CablePCI Bus Custom Bus

RAD750 RAM

1553 RAM

SC Cable

Results FIFO

Bridge Chip

Section that deals with PCI/memory operations

Bridge Chip

Section that deals with PIDs

LATp Discretes Discretes1553

RAD750 CPU

1553 Summit

Thermal Control

Buffering FPGA (CorePCI)

FPGA (CorePCI)

20 MHz / 2

TCSBoxes

EEPROM

SIB 40 MHz

CLK

PPS

GBM



1553 Interface1553 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

LAT SIU A(RT = 3)

LAT SIU B(RT = 3 )

Cold Spare

GBM A GBM B

SC CPU (P)(BC-A side)

SC CPU (R)(BC-B side)

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

1553 A/BPAIR I/F

CTDB (P)

CTDB (R)

Side A Side BSide ASide B



LCB ArchitectureLCB Architecture

• 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

Event Data

Fabric

Event Data

Fabric

CMD/RSPFabric

CMD/RSPFabric

PCI

BUS

DMAEngine

ControlRegisters

ExportFIFO

ResultsFIFO

Bufferingand

Logic

CMDDataRSPData

EventData InEvent

Data Out

FabricReset



LAT Protocol (LATp) OverviewLAT 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

Cell Announce Cell Header

Cell Body Cell Truncate

Cell Parity

0 2 18 130 131 132

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

and Italy)



LAT StartupLAT Startup

Step Description Means/Action

1 Ground checks temperatures and voltages on the SIUs, PDUs and GASUs.

Information is in SC to ground housekeeping telemetry. If OK, proceed to Step 2.

2 Select and power one of the two SIUs. Ground to SC ground command.

3 Ground checks temperatures and voltages on the powered SIU.

Information is in SC to ground housekeeping telemetry. If OK, proceed to Step 4.

4 SIU notifies S/C that it has configured its 1553 bus by raising an output discrete line.

The SIU boot process can now use a primitive 1553 driver to transmit telemetry containing boot status and a limited set of LAT housekeeping data.

5 Ground may optionally send telecommands to the SIU during the boot sequence.

The SIU boot process has a pause loop allowing the ground to redirect the boot sequence by sending telecommands This feature is generally (and rarely) used to reconfigure the secondary boot.

6 LAT obtains information on selection of Primary or Redundant signals and components (ordinarily expects Primary).

Information stored in SIU’s EEPROM. Note that both PDUs and both GASUs may be powered simultaneously.

7 The selected LAT main DAQ power feed is switched on. Ground to SC telecommand. Note that no power is drawn on this feed until Step 8.

8 LAT closes the input switches of the selected PDU in accordance with step 6.

Ground command from LAT.

9 Ground checks PDU voltages and temperatures. Information is in SC housekeeping telemetry. If OK, proceed to step 9.

10 SIU powers GASU(s), consistent with step 6. Ground to LAT telecommand.

11 Ground checks GASU voltages and temperatures. Information is in SC housekeeping telemetry. If OK, proceed to step 12.

12 Ground instructs the SIU to start the Thermal Control System.

Ground to LAT telecommand.

13 Ground monitors TEM/AEM housekeeping. Information is in LAT housekeeping telemetry. If OK, proceed to step 14.

14 LAT internal configuration The remaining startup is a LAT internal procedure and does not involve the SC.



GASUGASUc

PC

I

RAD750

EPU 0

(SIB)

LCB

CRU

EBM

4 x 32 bit registers


GEM

22 x 32 bit registers17 x 64 bit registers19 x 96 bit registers 1 x 112 bit register

Command/Response Unit

cP

CI

RAD750

SIU

SIB

LCB

cP

CI

RAD750

EPU 1

(SIB)

LCB

TEM0TEM1TEM2

TEM15

PDU’s

. .

GASU

ACD Electronics Module

Event Builder Module

GLT Electronics Module

Event Data Fragments

Trigger Data

TEM0TEM1TEM2

TEM15 . .

EPU 0 In

EPU 1 In

SIU In SIU

EPU 0

EPU 1

SSRMerge

CombinatoricLogic

Event DataCmd/ResponseTrigger Data



LAT ConfigurationLAT 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 – GARC GAFE

• PDU(s)



Tower Electronics Module (TEM)Tower Electronics Module (TEM)

GTCC 6 x 32 bit registers

GCCC7 x 32 bit registers

GTIC11 x 32 bit registers 2 x 18 bit registers 2 x 16 bit registers 1 x 3 bit register 1 x 112 bit register

Common Controller


GTIC

Common

(trigger reduction)

(overall control)

CAL 2

GCCC

TKR 7

GTCC

TKR 4

GTCC

TKR 6

GTCC

CAL 3

GCCC

TKR 0

GTCC

CAL 1

GCCC

TKR 5

GTCC

TKR 3

GTCC

TKR 2

GTCC

CAL 0

GCCC


TKR 1

GTCC

TO/FROM GASU



TKR & CALTKR & CAL

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

0 1 22 23

GTFE

GTRC

GCFE

GCRC





xz

yz

-xz

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

012223

01910 211

01910 211

01910 211

01910 211

01910 211

01910 211

01910 211

01910 211

1 100 92 11

0

1

2

3

0

1

2

3

0

1

2

3

0

1

2

3

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

0

1

2

3

4

5

6

7

8

Tower Electronics Module (TEM)


1 100 92 11

1 100 92 11

1 100 92 11

1 100 92 11

1 100 92 11

1 100 92 11

1 100 92 11

-yz



ACDACD

GAFE

GARC

012151617

012151617

0 1 2 15 16 17

0 1 2 15 16 1711 x 16 bit registers

44 x 16 bit registersGASU

AEM 8 x 32 bit registers12 x 64 bit registers

AEM

GEM

CRU

Cro

ssov

er

Cro

ssov

er




Front End Simulator Transition BoardFront End Simulator Transition Board

TriggerData

(FIFO)

State Machine


FES Computer

Intel Pentium @ 2.4 GHz4 120 GByte disksHigh speed bridges

VxWorks Operating System

One computer drives two towers (both TKR and CAL)

EventData

(FIFO)

Date post:	18-Jan-2016
Category:	Documents
Upload:	lena
View:	21 times
Download:	0 times

GLAST Large Area Telescope: Instrument Flight Software WBS: 4.1.7.9 Presenting for the FSW group:

Documents