LAT Flight Software
End-To-End Testing
Number:
Subsystem:
Supersedes:
Type:
Author:
Created:
Updated:
Printed:
LAT-TD-xxx.x
Data Acquisition/Flight Software
None
Technical Note
J.J. Russell
23 September 2003
23 July 2016
Addresses the end-to-end testing of the LAT, enumerating both the tests and the available tools and
techniques. The emphasis is on those tests unique to end-to-end testing. Unit testing is outside the scope of
this document.
Format for Storing Configuration Constants
Record Of Changes
Version
0.1
Date
23-Sep-03
LAT-TD-xxx.x
Title Or Brief Description
Draft Release
Entered By
J.J.Russell
i
Format for Storing Configuration Constants
Contents
0
Introduction ..................................................................................................................................... 3
0.0
Unit Level Testing ............................................................................................................................. 3
1
Testing Tools .................................................................................................................................. 4
1.0
GlastSim ........................................................................................................................................... 4
1.1
LAT Testbed ..................................................................................................................................... 4
1.2
FES – Front-End Simulator .............................................................................................................. 5
1.3
SIIS – Spectrum-Astro Instrument Simulator ................................................................................... 5
1.4
ISIS – LAT Instrument Simulator ...................................................................................................... 5
1.5
The LAT ............................................................................................................................................ 5
1.6
The Airplane Flight ........................................................................................................................... 6
2
Major Issues .................................................................................................................................... 7
2.0
Power On Sequencing ...................................................................................................................... 7
2.1
Boot Process .................................................................................................................................... 7
2.2
Bandwidth consideration .................................................................................................................. 8
2.3
Global Trigger ................................................................................................................................... 8
2.4
Filter Performance ............................................................................................................................ 8
2.5
On-board Science ............................................................................................................................. 9
2.6
Housekeeping and Monitoring .......................................................................................................... 9
2.7
Calibration and Diagnostics .............................................................................................................. 9
3
Testing ........................................................................................................................................... 10
Figures
Tables
ii
LAT-TD-xxx.x
Format for Storing Configuration Constants
0 Introduction
This note addresses the end-to-end testing of the LAT with particular emphasis on the triggering
and data handling. In addition the focus is even sharper, looking specifically at those aspects of
the triggering and data handling that cannot be addressed at the unit level.
Section 2 outlines the major functionality that needs to be tested, while Section Error! Reference
source not found. offers an overview of the tools and methods available for testings. Section 3
marries a major functional test with a test tool.
0.0 Unit Level Testing
This section is included to specifically call out tests that are excluded. It will be assumed that all
tower level TEM tests for both the CAL and TKR have been performed as well as testing at the
FREE board level for the ACD. For example, all read/write testing of the TEM and FREE frontend registers and movement of data off the TEM or off the FREE boards will assume to have
been done by the I&T group.
Various aspects of trigger can also be tested in a standalone fashion, but here the situation is a
bit murkier.
LAT-TD-xxx.x
3
Format for Storing Configuration Constants
1 Testing Tools
This section enumerates the available tools and test methods.

GlastSim

Test-Bed

FES – Front-End Simulator

SIIS – Spectrum Astro Instrument Simulator

ISIS- Lat Simulator

The LAT itself

The Airplane Flight
1.0 GlastSim
This is the offline Monte Carlo generator. It has been equipped to produce two styles of data
relevant to LAT testing.

Data formatted as it comes from the Event Builder into an Event Processing Unit

FES formatted data. Data in this format can be replayed through the FES (see section
1.2)
1.1 LAT Testbed
This consists of a full electronics version of the LAT from the cable interface down for 15 of the 16
towers. All that is missing are the front-end sensors (except for the 16th tower, which does include
a live tower along with front-end electronics). All other system components are present, including
a CRU, PDU, a GASU, 2 SIUs and 3 EPUs. The system, as envisaged, contains both primary
and redundant components and paths. The live tower will not show up until after launch. Before
launch, a min-live tower will stand in its stead. Preliminary indications is that it will have 8 tracker
layers (4x and 4y) and 2 CAL layers (1x and 1y).
4
LAT-TD-xxx.x
Format for Storing Configuration Constants
1.2 FES – Front-End Simulator
This is a major piece of electronics devoted entirely to testing. It is meant to simulate the detector
at the cable level. Thus its outputs are the 8 TKR and 4 CAL cables on each TEM and the 12
FREE cables going to the AEM along with the full complement of trigger lines. The FES itself
consists of 9 COTS PCs connected to 17 boards. The boards break down into the following
flavors

8 TKR boards each simulating two towers

8 CAL boards each simulating two towers

1 AEM board, simulating the AEM
The FES can be run a tower at time or as a coherent instrument simulating the whole LAT. The
nominal running mode is to load disks local to each PC with data representing that PCs
contribution to the event. This data is driven into the FES boards where the data is reformatted to
match the cable data stream. A system clock meters out the events from the FES data memory
onto the cables. Once on the cables, the TEM/AEM/GLT, in principle, cannot tell whether the data
is from actual front-end sensors or from the FES memory.
Two distinct types of data are seen. The first is test pattern data. This will demonstrate the
integrity of data handling system, i.e. can it move a known collection of bits from one end to the
other. The second type is GlastSim Monte Carlo events in FES format. This data can be unused
to measure throughput of the system, either end-to-end, or a piece of the pipeline at a time.
1.3 SIIS – Spectrum-Astro Instrument Simulator
The SIIS is a surrogate for the spacecraft. Of primary interest is its capability of delivering 1553
commands to the LAT. While outside the domain of the LAT DAQ system proper, it also reads the
analog temperature and voltage sensor. It also provides a number of discrete logic signals to the
LAT. Some of these are inputs to the LAT that control the primary/redundant path selection and
some are outputs from the LAT indicating boot status. It should be possible to test the LAT’s
power on sequence and commanding interface with the SIIS
1.4 ISIS – LAT Instrument Simulator
This is the mirror of the SIIS (unfortunately the SIIS is a palindrome, so we couldn’t just reverse
the acronym). Since it acts as a surrogate for the LAT, it is likely not that useful in testing the
LAT. It is mentioned here only for completeness.
1.5 The LAT
Once tests are refined on the testbed, they can be then be run on the real LAT. Sooner or later
this must happen. An open issue is whether the FES will every be connected to the real LAT.
Given the physical problems in doing this, this is a very remote possibility. This leaves one with
an uneasy feeling. Even if the testbed hardware performs flawlessly, there are a number of tests
that can only be done with the FES.
LAT-TD-xxx.x
5
Format for Storing Configuration Constants
1.6 The Airplane Flight
While more a technique than a tool, operating the LAT as a full up instrument during its airplane
flight is likely the only way to address the questions raised in section 1.5. The event rate at 25K
feet should about match the on orbit rate. It would represent a true end-to-end test of the trigger
and dataflow system, but, because the particle mix does not match the on orbit profile, would not
verify the filter and on-board science processing.
6
LAT-TD-xxx.x
Format for Storing Configuration Constants
2 Major Issues
This section describes the major functionality that needs to tested. These are

Power on sequencing

Boot process, both SIU and EPU

Setting up the plumbing, testing primary and redundant paths

Bandwidth considerations

Global Trigger

Filter performance

Onboard Science

Housekeeping and Monitoring

Calibration

State transition including watchdog time functionality
Many of these functions can be tested using only a subset of the LAT testbed/FES. However, the
goal of these end-to-end tests is to prove that everything not only works, but works together. So,
while much of the initial checkout and preliminary work can be done in a more isolated and
contained environment, ultimately, it must all run together.
2.0 Power On Sequencing
Using the SIIS, in principle one can emulate a spacecraft initiated power on sequence.
2.1 Boot Process
Once power has been established the SIU boot can be tested from the SIIS. Once the SIU boots,
it can then establish the plumbing be selecting the specified combinations of primary and
redundant paths and initiate the EPU boot sequence. Once the SIU is booted, the plumbing
established and the EPU booted, the LAT front-end electronics, trigger and event builder can be
configured. At this point the LAT is ready to take data.
LAT-TD-xxx.x
7
Format for Storing Configuration Constants
2.2 Bandwidth consideration
The bandwidth needs to be measured at a couple of points in the detector.

FREE -> AEM

TEM / AEM -> Event Builder

Event Builder -> Input of LCB board

LCB Board -> CPU
The measurement of the bandwidth from the FREE -> AEM is really more of a tower level test,
but since the AEM resides on the GASU assembly, this test can only be done when the system
includes a GASU.
2.3 Global Trigger
GLT/GASU testing can be broken into two categories

Functional testing

Performance
Much of the functional testing can be done at the unit level. For example, all the GLT registers
can be checked for read/write functionality can be checked in isolation. The dynamic input signals
paths

The TEM contributions of the three-in-a-row and the CAL LO and CAL HI signals

The FREE board contributions of all the ACD veto lines and the 12 CNO triggers

The two special triggers, the periodic and CPU solicited trigger
also can be checked in isolation. In principle, in fact, the logic that combines the various input
signals together to form a trigger request also can be checked in isolation. However, due to the
large number of such signals, it is likely that this kind of test will exceed the capabilities of the unit
test equipment.
A partial list of trigger tests is

Checking the relative timing of real signals i.e. from the front-end sensors across
subsystems and across towers.

Checking the trigger’s contribution to the data

Checking the number of window turns is commensurate with the input signals

Checking the combinatorial logic produces the correct trigger message
2.4 Filter Performance
The onboard filter needs to be check for both purity and efficiency and for timing performance.
The purity and efficiency testing can be done without the aid of any special hardware. This test is
best done with specially prepared sets of GlastSim Monte Carlo data. There is one aspect of this
test that may need the more realistic environment provided by the hardware. One of the filter’s
rejection criteria is the elimination of albedo electrons and gammas. To do this, the filter must
know the direction of the earth’s limb. On orbit, this is information provided by the 5Hz attitude
8
LAT-TD-xxx.x
Format for Storing Configuration Constants
messages. It may be difficult to simulate all aspects of this without resorting to using the real
hardware. Remember that the attitude message is received from the spacecraft, over the 1553
bus on the SIU. The SIU must then distribute this message to its slave EPUs, which must then
time correlate the attitude information with the gamma candidates.
The timing performance of the filter can be measured in isolation on a single BAE RAD750 using
GlastSim data read into the CPU by whatever means is convenient. However, because the CPU
performance can be heavily influenced by cache misses, a bottom line performance number can
be measured only by doing the measurement in the full context of data acquisition. Under these
conditions one expects more memory activity and thus more cache misses. Note that one cannot
simply scale the avail CPU cycles down to account for additional processes running in the EPU.
2.5 On-board Science
From a testing view-point, on-board science falls in the same category as the filter testing. The
algorithmic correctness of the code can be tested without the LAT hardware. This is simply a
matter of feeding it GlastSim events and seeing if it produces the correct result. Well, almost. The
on-board science also needs absolute position information, just as the filter does to do the albedo
rejection. This may mean that ultimate testing of the on-board science must be done with the LAT
testbed/FES.
2.6 Housekeeping and Monitoring
The acquisition of the housekeeping data can be realistically done in the LAT testbed/FES
environment. To the extent that one can simulate the data values using the COTS PC, one can
also provide realistic data. Finally the packaging and transportation of the housekeeping data can
be tested in this environment.
The term monitoring here is used very narrowly to mean monitoring the event data quality and the
performance of the trigger and dataflow system. Almost all this can be done using the LAT
testbed/FES to provide fake events.
2.7 Calibration and Diagnostics
These procedures break into two pieces, acquiring the data from the front-end and analyzing it.
Acquiring calibration and diagnostic data usually means placing the front-end electronics in some
state that is incompatible with normal data taking. For example, the calibration process involves
setting a front-end DAQ to a known value and asking for a number of triggers. This process is
difficult to simulate without the actual front-end electronics. It may be possible using the FES, but
this is stretching what was designed to do. The conclusion is that the testing of the acquisition
phase of this process must likely be done on a fully or partially equipped tower or on the real LAT.
The analysis phase can be simulated in the LAT testbed/FES setup, but once one has committed
to running the acquisition phase on the real LAT, it seems silly not to run the analysis phase there
also.
LAT-TD-xxx.x
9
Format for Storing Configuration Constants
3 Testing
10
LAT-TD-xxx.x