CANDIDE
A fieldbus system to control detector front-end electronics.
W.P.J.Heubers, R.G.K.Hart, H.Boterenbrood, P.Rewiersma, I.Weverling
NIKHEF, National Institute for Nuclear and High-Energy Physics
P.O.Box 41882, 1009 DB Amsterdam, The Netherlands
The CANDIDE system is developed to control and monitor the front-end electronics of a subdetector prototype for
the ATLAS inner tracker. CANDIDE was based on the Controller Area Network (CAN), which is developed by
Bosch from Germany for the automotive industry. Low cost, reliability and real-time capabilities were important
issues in the selection of this fieldbus for the control of the front-end electronics. Prototype CAN nodes, based on thePhilips 80C592 micro controller, have been built to control functions such as setting discriminator thresholds,
masking noisy channels and monitoring temperature sensors of the channels in the ATLAS subdetector. This paper
describes the implementation of a network of these prototype CAN nodes. Additionally, the integration of a genericfieldbus controller into the Cortex distributed control system (CICERO project) is discussed.

1. Introduction.
ATLAS is a high-energy physics detector to be used in the Large Hadron Collider at CERN and is planned to be
operational around the year 2004. At present the detector control system for the ATLAS project is in the phase ofdetermining the user requirements. Prototypes are built and tested in the laboratories and in test beam runs at CERN.
Section 2 gives a brief outline of the organization of a detector control system and in some more detail thesubsystem for the front-end controls. In section 3 a description is given of the Controller Area Network (CAN) andsection 4 presents the CANDIDE system, based on this fieldbus. Section 5 outlines a contribution to an R&D project
initiated by CERN [1], concerning the definition of a generic fieldbus controller that has to be integrated into theCortex (object-oriented) control system.

2. Detector control.
From a control system point of view the ATLAS detector is a large scale system,that can be described as a set ofdevices, such as the inner tracker detector, the calorimeter, the muon detector and systems like the data acquisition
system and the gas system. Each of these devices and systems can be decomposed into subsystems with their ownfunctionality and degree of autonomy. This hierarchical organization of the detector control system is illustrated infigure 1.
For each subdetector (device) the control and monitoring of the front-end electronics can be considered as a
subsystem of the overall detector control system. In case of malfunction of the front-end electronics, an alarm
generated by this subsystem must be reported to the detector control system. Typically for each channel (or set ofchannels) in the detector, slow control functions, such as setting a discriminator threshold or masking noisy
channels, could be implemented. Besides these control commands, it is necessary to monitor continuously the statusof certain parameters in the front-end system (e.g. voltage trip levels and temperature), which generates possible
alarms. The number of detector channels in a high-energy physics detector like ATLAS can be very large.
Depending on the type of (sub)detector several thousand (sets of) channels, geographically distributed in thedetector, have to be controlled and monitored.
The environment in which the front-end electronics operates puts special requirements to the system. The detectoris only accessible during maintenance periods. This puts demands on the reliability and fault-tolerance of the control
system. The control path must be redundant and independent from the functioning of the data acquisition systemitself. Another important constraint concerns the radiation. This is especially a problem in the inner part of thedetector where all electronic components must be radiation hard.

ATLAS
experimentsubdetector 1

front-end
controlfieldbuses

PLC

subdetector 2magnetcontrol

VME

Fig. 1. An example of the hierarchical organization of a detector control system.

3. The CAN fieldbus.
A fieldbus or serial bus is in principle an industrial communication network to which a number of geographically
distributed nodes are connected. Fieldbuses are meant for low level equipment control functions like monitoring
sensors and controlling actuators. The fieldbus network is able to transport relatively small messages in a fast andreliable way to exchange information between the different nodes. Fieldbus nodes often have some degree of local
intelligence, implemented in a micro controller chip, in a PLC system or even in a PC. Low-cost, compactness,reliability and real-time capabilities (requiring response times to be short and deterministic) are important features
for selecting a fieldbus system. See reference [2] for a tutorial on fieldbus applications in physics laboratories.
The CAN (Controller Area Network) fieldbus was selected for the controls of a prototype subdetector for
ATLAS. The CAN fieldbus was developed by the German company Bosch, initially for the automotive industry, but
nowadays CAN is used extensively in industrial fields as well. One major reason for selecting CAN was that the firsttwo layers of the ISO/OSI reference model are available as an open industrial standard as defined in ISO/DIS 11898[3]. This standard does not cover the transmission medium (twisted pair or optical fiber) and the transmission speed(between 5 Kb/s and 1 Mb/s, depending on distance and the medium). The CAN protocol specifications define
multi-master mode, multicasting, a message priority scheme and a high degree of fault-tolerance. Integrated circuit
manufacturers such as Philips, Motorola and Siemens offer both stand-alone protocol controller IC's and integrated
protocol controllers on a micro controller chip.
The application layer of the ISO/OSI reference model is covered by the CAN Application Layer CAL [4]. Thelayers between the data-link layer and the application layer are not implemented in fieldbus networks for
performance reasons, although management control functions available with CAL do offer services concerning
network management, layer management and identifier distribution (figure 2).
The CAL application layer defines a set of services, called CAN-based Message Specification (CMS). With CMS
the applications can specify CMS-objects like variables, events and domains and specify services upon these objectssuch as 'write variable', 'notify event' or 'download segment'. CMS is derived from the ISO/IEC 9506 standard MMS,
an application layer standard designed for the remote control and monitoring of industrial devices (such as PLC's).

application
CAL profile
Proprietaryservices

CAL
services
application

CAL(CMS)sessiontransport
network
datalink
physicalISO/DIS
11898
ISO/DIS11898

Layer Management

presentation

Fig. 2 The CAL reference model

4. CANDIDE.
CANDIDE (a CAN Diverse Interface for Detector Electronics) is developed to control and monitor the front-end
electronics of prototype micro-strip gas counters (MSGC). It was foreseen that the forward trackers of the ATLAS
detector would be partly implemented with MSGCs1.
A general-purpose CAN node GPCAN [5] has been designed around the P87C592 micro controller from Philips
and has been implemented as a piggyback board . This micro controller includes EPROM and RAM memory, aCAN protocol controller, a 10-bit ADC with 8 multiplexed outputs, two 8-bits PWM outputs and five 8-bit I/O ports.
The piggyback card is placed on a GPCAN motherboard, that contains additional functionality such as a serial DAC
and a CAN bus connector. A PC with a CAN controller from Softing GmbH was used for the development of thesystem. The configuration to be used in the test beam runs was hosted by a Sun workstation interfaced by a CV002
VME module from MicroSys Electronics GmbH. The VME module is connected to the actual CAN network by an
optical link as is shown in figure 3.
The application software is not implemented with the CAL standard, but instead a custom-made message format
was defined, with a maximum frame length of 130 bits. A transmission speed of 125 Kb/s on the bus resulted in amaximum transfer time of 1.04 ms per message.

1Recently the ATLAS collaboration took the decision to use silicon strip detectors instead of MSGC's.

CAN
nodegascontrol

CAN
node
CAN
node

CAN
nodeCAN
node

CAN
node

e/o converter
detector

CAN
nodecontrol front-end electronics

sparelink

opticallink

CAN
node

CAN
node

CAN
node
temperaturemonitorCAN fieldbus
optional repeater
to other network

control room

VME
detector control system
Figure 3 Detector front-end control with a CANDIDE fieldbus system

5. Integration in the control system.
As outlined in figure 1, the fieldbus networks are used for low-level, real-time control of the detector front-end
electronics. In a large detector control system as needed for the ATLAS detector, it is foreseen that both fieldbuses
and PLC systems will play an important role in the low-level control of other parts of the detector system as well(e.g. vacuum and magnet systems). Although the aim is to apply within the scope of this project 'standardizedsystems' as much as possible, it is hard to avoid using different PLC and fieldbus systems for different subsystems,
because of complexity and time scale constraints. The control system must be able to integrate these heterogeneous
subsystems into the overall detector control system.
CICERO is a research project at CERN [1] that will outline and provide the main building blocks of a genericcontrol information system in order to reduce costs and maintenance efforts of future experiments there. TheCICERO group has designed and partially implemented an integration framework ('software bus') called Cortex [6].
The Cortex system has two parts: an off-line part in which the configuration of the control system is described andan on-line part where information and commands must be distributed to the components of the system. Cortex has tobe flexible enough to support the addition or removal of components without deteriorating the operation of thesystem. For this purpose Cortex maintains a repository to handle the logical description of the architecture and todescribe the exchange of information between the different components.
Industrial fieldbus and PLC systems often come with their proprietary configuration tools. Most of these tools use
a graphical editor to design the fieldbus or PLC configuration and to generate files that contain tables with theconfiguration information. At the moment there is no standard available for the configuration formats of fieldbus andPLC systems, as there is no generally accepted standard available which specifies the application interface, although
in some cases suppliers publish their interface specifications and make them available as an open standard to othersuppliers. Examples of these are the ISO/DIS 119898 standard that defines the CAN Application Layer for the CAN
fieldbus and the ISO/IEC 9506 standard that specifies the Manufacturing Message Specification for PLC systems.
Work has started to design a generic fieldbus controller for the object-oriented Cortex system as it is defined byCICERO. From this generic or virtual controller, other controllers can be derived for specific fieldbus
implementations. These derived controllers will inherit attributes and methods as they are defined by the genericfieldbus controller. One interesting topic in this respect is how to convert the proprietary configuration formats into
the Cortex repository. As far as the application layer is concerned, the Can Application Layer (CAL) is a goodcandidate for the implementation of a prototype Cortex fieldbus controller.

6. Future directions.
Although the initial application for the CANDIDE system, the micro-strip gas counter detector for the innerdetector of ATLAS, is canceled, nonetheless the project will continue. A modified version of CANDIDE will bebuilt to control the electronics of a prototype muon detector that is part of the outer detector of ATLAS. For thispurpose a CAN node is being developed that can control up to 16 high-voltage channels in the front-end system. The
intention is to interface the application software for this prototype using the CAN-based Message Protocol CMS as
defined in the standardized CAL.
A study on the integration of these fieldbus applications into the higher-level layers of the control system willcontinue within the framework of the CICERO research project.

7. Conclusions.
The use of an industrial fieldbus to control the front-end electronic system of a large detector like ATLAS seems
to be a good choice because of its reliability, compactness and low-cost and because of the industrial support. The
design constraint to separate the data path from the control path can be easily achieved by implementing a fieldbus
network. The CAN fieldbus is an excellent choice, not only for its reliability and its real-time capabilities, but also
because its availability as an open standard. The CAN application layer provides a complete and well-definedinterface to access and manage the fieldbus network configuration. One point not yet resolved,concerns the radiation
hardness of the industrially available micro controllers. Radiation hardness is a major issue, especially in the innerparts of ATLAS .

References.
[1] J.M.Le Goff at.al. CICERO: Control Information system Concepts based on Encapsulated Real-time Objects.
1994 Status Report. CERN/LHCC 95-15 LCRB status report / RD 38[2] R.Rausch, CERN. Tutorial on standard fieldbuses applications in physics laboratories. Invited tutorial paper
ICALEPS '93[3] Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed
communication. International Standard Organization. Reference number ISO 11898:1993(E)[4] Konrad Etschberger CAN, Controller Area Network Grundlagen, Protokolle, Bausteine, Anwendungen ISBN3-446-17596-2[5] ATLAS MSGC Support Document for the Micro Strip Gas Counter Sub-system. ATLAS internal note, INDETNO-076, 15 December 1994
[6] R.Barillere et.al. The Cortex project. A quasi real-time information system to build control systems for highenergy physics experiments. Proceedings ICALEPS'93