The calorimeter trigger comprises three subsystems each of which is implemented in a number of VME crates. Each crate will have its own CPU and the whole system will be controlled by a small number of workstations (eg Linux PCs).
For the hardware and software configuration, we will follow the proposals
of the Online software group. One or more OKS files will contain the hardware
description: perhaps one file per subsystem and one file for common items
such as worstations. A separate file will contain descriptions of the
software. Other files will describe the DAQ partition(s) which draw
together the required hardware and software setup.
The calibration data makes up the largest data volume. It is proposed
that this is split into separate files for each crate and for each major
type of calibration. Separation by crate means that each crate CPU only
needs to load the data pertaining to its crate. Separate by type of
calibration makes sense because the different calibrations will be run
with different frequencies: some every day, others weekly, monthly, or
yearly.
It is possible that OKS will not be the best system for storing large
amounts of data. If so, some other scheme can be used provided that
the run time view remains the same.
The trigger menu is generated offline and will need to be distributed
to the processor crates by some mechanism. This may be by copying OKS
files, or possibly some dynamic database access will be implemented.
If the trigger menu is implemented in OKS, we expect a single file
per trigger menu - at least for those parts relevant to the level 1
calorimeter trigger.
Run parameters will typically only be set and accessed via the Online
software Information Service component. However the complete set of
level 1 calorimeter trigger run parameters may be backed up to a
single OKS file.