The ATLAS pixel module burn-in system tests the longevity of ATLAS pixel modules by subjecting them to a sequence of tests. The system consists of hardware that supplies power to an array of modules and controls them; and of software that allows the system operator to specify and modify the sequence of tests. Two considerations were principal in the design of the system. The first is to allow the concurrent testing of a large number of modules; the second is to provide a flexible mechanism for altering the test sequence without interrupting a run.
The burn-in software follows the producer-consumer model. One process, the producer, concerns itself with controlling the hardware and storing the data the hardware produces. This process is designed for maximal stability; it has to run problem-free until the scheduled tests are done. Another process, the consumer, looks at the data from the producer, and turns it into plots. Since this process does not control the hardware, it will not interfere with the running of the tests if it crashes. Fig. 1.1 shows how the consumer and producer interact; see also Ch. 7.
This document describes the producer, called ATLAS Pixel Module Burn-in Shell (AMBUSH). In Ch. 2 we describe how to get, build and configured the software. In Ch. 3 we describe the structure of AMBUSH: the various instruction buffers for scheduled and conditional statements, the execution queue and data handling system. In Ch. 4 we describe the C-like language in which AMBUSH scripts are written. In Ch. 5 we delve into the gory details of the code. Only slightly scarred, we emerge in Ch. 6 to describe how to make AMBUSH aware of hardware. In Ch. 7 we talk about the interaction between AMBUSH and the data consumer. Finally, in Ch. 8, we list the functions available in AMBUSH scripts.
