ECS interface

The complete LHCb experiment ( magnet, power supplies, front-end, DAQ, etc.) must be under the control of the Experiment Control System (ECS). The ECS system will be responsible for the overall control of the experiment and the monitoring of its correct function. The ECS will be a highly hierarchical system with a large set of local controllers performing the control and monitoring of specific sub-systems.

Loading front-end parameters

A large set of front-end parameters must be initialized to specific values before the system is capable of working correctly. For some detectors it will only be required to down-load a few parameters per detector channel or group of channels. Other detectors rely on individual lookup tables per channel. The loading of the front-end parameters needs in principal not to be performed frequently when the system is working reliably. In the case of front-end electronics located in a hostile environment it may be required that the complete set of front-end parameters are loaded frequently to insure that the local registers storing the parameters have not been corrupted (radiation induced single event upsets). As it is difficult to estimate the order of magnitude of this problem, it is important to construct the front-end hardware in such a way that no critical bottlenecks exists in the architecture of the ECS system. Initially it is acceptable that the complete loading of parameters to the front-end requires several minutes. If reliability problems are encountered in the running of the front-end system because of corrupted registers in the front-end it must be possible to upgrade the ECS system to be capable of reloading all front-end parameters within seconds.

It is important that the bandwidth requirements to the ECS system for loading the front-end parameters are specified (estimated) as early as possible to enable the architecture of the ECS system to handle the specific requirements of all sub-detectors.

Calibration

During calibration runs an extended functionality of the ECS system will be required. Each sub-detector will during a typical calibration run work as an individual unit. Large sets of front-end parameter sweeps will be required to obtain the optimal working conditions of the different front-end systems. Event data collected for a set of front-end parameters must be collected and analyzed by the DAQ system and the ECS must down-load new sets of front-end parameters for the next iteration.

The specific requirements to the ECS system during calibration runs must be specified as early as possible by each sub-detector.

Monitoring

An important role of the ECS system is to continuously monitor the correct function of the experiment. The first priority is to protect the system against hazards that my cause damage to people or the equipment itself ( fire, gas leaks, overheating, etc.). In addition the correct function of the whole experiment while running must be monitored to qualify event data collected.
An independent Detector Safety System (DSS) protects the experiment against major damage to equipment in case the softwarebased ECS system is not running correctly.

For the front-end system the protection system must monitor the correct function of power supplies ( over-voltage, over-current, etc. ) and the cooling of electronic crates ( temperature sensors ). Monitoring of the correct function of front-end modules during operation must to a large extent be built into the front-end hardware. When some malfunction is detected, the front-end must inform the ECS system about the failure.

Testing

The ECS system must also be capable of performing exhaustive tests of individual modules while they are located in the system (in-situ). The ideal case is that each module can perform a self-test initialized by the ECS and a simple status will indicate the result. Alternatively the test of modules can be performed by an external controller processor. In some cases the test of a module will be driven directly by the ECS system, requiring extensive software routines to perform this. The development of these software test routines must be considered an integral part of the development of the module itself as its functions requires detailed knowledge about the implementation of the module.

ECS links

The physical connection to electronic modules in HEP experiments have traditionally been the backplane bus of the crates used (CAMAC, Fastbus, VME) using simple register mapping or message passing. In the higher levels of ECS systems to be used for LHC experiments, data communications will be performed via computer networks ( Ethernet ). At the lowest level of the system the connection to the electronic modules can potentially  also be the same kind of networks. Most computer network interfaces though requires local processors to implement the top levels of the required communications protocol. This will only imply a small hardware overhead using modern components, but may pose significant problems in an environment with radiation (such a local processor is though very useful to perform local monitoring and self-tests). ECS interfaces to electronics modules in LHCb have been standardized to be one of the three following types. 

Credit card PC: A miniature PC on a commercial credit card sized hybrid is mounted on the front-end module and interfaces to the higher levels of the ECS system over 10/100Mbit Ethernet. The standard PC architecture allows standard commercial PC software to run on the Credit card PC. This ECS interface is intended used under standard conditions where radiation effects is not a concern (counting and control room).
Documentation: CC-PC web page

SPECS: SPECS is a simple custom protocol similar to I²C, made specifically for applications in high energy physics. It consists of a single master located in a standard PC communicating with multiple slaves over four twisted pairs at a data rate of 10Mbits/s. A special SPECS slave, implemented in an antifuse FPGA, is made to work in environments with limited radiation levels (LHCb cavern). Special majority voting logic is used in the slave to make it immune to failures caused by single event upsets (SEU).
Documentation: SPECS web page from Orsay

CAN (ELMB): A CAN slave interface based on a self checking master slave configuration is made to work in environments with modest radiation levels.
Documentation: ELMB web page of ATLAS,  ELMB software web page

The selection of an ECS interface to components and modules located inside the detectors or in the cavern must take into account the radiation environment. As this interface is the one and only control path to the front-end it is vital that it is of high reliability. The local control bus used at the board level can be I²C, JTAG or a simple register mapped parallel bus available from all three standardized ECS interfaces.

Module identification

To insure a correct identification and configuration of electronics modules, each ECS interface must have three identification registers. A board type identifier must define the module type (Adr: 0). A revision number must define the hardware revision number (Adr: 1). Configuration data for FPGA’s can in this respect be considered as software versions, if it can be down loaded via the ECS interface. Finally a serial number must uniquely identify the module (Adr: 2). The content of these identification registers should in general be hardwired by jumpers or solder bridges on the module itself. These three identification registers should be found on the three lowest addresses in the local ECS address space, to insure a consistent identification of modules across the whole system. In case a module has software or FPGA configuration data residing in permanent memories (e.g. Flash), it must be possible to read its revision number via the ECS interface. More details.

This page was last modified by JC on 11 May, 2006 . This page has been accessed number of times.