LAT Flight Software. End-To-End Testing

Transcription

1 LAT Flight Software End-To-End Testing Number: LAT-TD-xxx.x Subsystem: Data Acquisition/Flight Software Supersedes: None Type: Technical Note Author: J.J. Russell Created: 23 September 2003 Updated: 23 September 2003 Printed: 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.

2

3 Record Of Changes Version Date Title Or Brief Description Entered By Sep-03 Draft Release J.J.Russell LAT-TD-xxx.x i

4 Contents 0 Introduction Unit Level Testing Testing Tools GlastSim LAT Testbed FES Front-End Simulator SIIS Spectrum-Astro Instrument Simulator ISIS LAT Instrument Simulator The LAT The Airplane Flight Major Issues Power On Sequencing Boot Process Bandwidth consideration Global Trigger Filter Performance On-board Science Housekeeping and Monitoring Calibration and Diagnostics Testing...10 Figures Tables ii LAT-TD-xxx.x

5 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

6 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 16 th 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

7 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

8 1.6 The Airplane Flight Format for Storing Configuration Constants 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

9 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

10 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 Format for Storing Configuration Constants 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

11 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

12 3 Testing 10 LAT-TD-xxx.x