CAN field bus for industrial-controls applications in high-energy physics experiments.

W.P.J.Heubers, H.Boterenbrood, J.T.van Es, R.G.K.Hart NIKHEF National Institute for Nuclear and High-Energy Physics Amsterdam, The Netherlands ABSTRACT
CAN bus, a popular field bus choice in industry, has gained momentum in high-energy physics research for industrial-controls-like applications in experiments and accelerators. This paper describes at first the controls problems which next-generation particle-physics experiments are facing. It will then discuss the hardware and software developments of prototype systems for analogue sensor readout by the CERN-recommended CAN field bus.

INTRODUCTION
The Large Hadron Collider (LHC) at CERN is a particle accelerator that will collide beams of protons with an energy of 7 TeV. Four high-energy physics particle detectors will be installed on well-defined locations in the 27-km long accelerator ring. These detectors will be designed, built and operated under responsibility of large collaborations with participants from all over the world. Because of the extremely long time scale, the start of LHC operation is foreseen in 2005, and the complexity of the instrumentation one has to take care that when possible, widely accepted industrial standards and solutions will be implemented. Reliability and maintainability have to be ensured during the many years of operation. A typical area where one can not select standard industrial solutions is the inner part of the detector, where space is limited and environmental conditions are hostile. Especially the amount of radiation and constraints concerning low-power dissipation and limited space, require custom designed and radiation-hard electronics for the readout of the large number of data channels. In the outer parts of the detectors the environmental conditions are somewhat better and one can consider the use of commercially available electronics, such as micro controllers as intelligent nodes connected to a field bus. Physicists and engineers cannot enter the caverns where the detectors are installed to inspect the functioning of the instrumentation when LHC is operating. A reliable and redundant control system is required to be able to set and monitor the estimated number of several 100,000 I/O points remotely from the control rooms. Mixing of the control data with the physics data on the high bandwidth data channels from the detector to the counting rooms must be avoided, to prevent a blocking of the control signals in case of congestion in the data channels.

THE ATLAS DETECTOR

The largest detector to be installed in LHC is the ATLAS detector, measuring 20 by 40 meters. The ATLAS detector consists of three main detection systems (muon detector, calorimeters and tracking detectors) and of a number of subsystems, such as the magnet system, the cooling system and the data acquisition system. The outer detector is the Muon Spectrometer and occupies the largest volume of the ATLAS de3 tector (approximately 16.000 m ) and a radius of 11 meters. This Muon Spectrometer consists of a barrel and two end-caps with a total number of 1194 precision chambers and 800 trigger chambers, generating physics data on more then 1,000,000 readout channels. One has to take into account that the instrumentation for the Muon Spectrometer has to operate in a magnetic field with values of typical 0.5-2 Tesla and with a radiation background of mainly low-energy neutrons and photons. In this paper a description will be given of the ideas for the readout of analogue sensors to continuously monitor the temperature and the values of the magnetic field in the precision chambers in the Muon Spectrometer. The proposal is to install on each of these chambers a field bus node where analogue signals can be digitized and transmitted to the detector control system.

DETECTOR CONTROL SYSTEM

The ATLAS Detector Control System DCS [1] will be divided into subsystems. A requirement of DCS is that these subsystems can be operated independently from each other to be able to test and commission parts of the detector during installation and maintenance periods. The division of DCS into subsystems can be either a functional division (e.g. the magnet system) or a topological division (e.g. the precision chambers in the barrel). The supervisory control has to interconnect all these subsystems together and provide the operators with a global and consistent interface to the detector. Local Control Stations will interface to the hardware, typically modular sys-

tems (most likely VME) with connections to field bus networks and PLC systems.

SELECTION OF A FIELD BUS

Concerning the time scale and the complexity of the instrumentation projects for the LHC accelerator and particle detectors, a policy has been defined to apply industrial solutions and standards where ever appropriate. Field buses are typical examples of industrial developments and they will be implemented on a large scale to control and monitor a wide range of equipment in the accelerator and experiments. As many different kinds of field buses are available from industry, it was felt necessary to restrict the choice of field buses to be used at CERN [2]. The CAN field bus has been selected as the solution for relatively simple control tasks and sensor readout. Reliability, availability of inexpensive controller chips from different suppliers, ease of use, wide acceptance by industry and the expectation that CAN will be available for a long period of time, were strong arguments in favour of this choice. Both data link layer and physical layer (not including the transmission medium) from the ISO/OSI reference model are defined for the CAN bus as the open standard ISO/DIS 11898 [3].

Apart from the temperature sensors and Hall probes, output from other sensors, such as strain gauges or gas pressure sensors, can be digitized and collected by the CAN nodes as well.

PROTOTYPE MUON DETECTOR

The Demonstration of Atlas Chamber Alignment (DATCHA) is a prototype of a barrel section of the Muon Spectrometer. This prototype consists of three precision chambers and is intentionally built to test the accuracy of the alignment system. DATCHA is 12 meters high and has been installed in one of the underground caverns at CERN. To gain experience using the CAN field bus for chamber control we considered DATCHA as an excellent opportunity to work out our ideas and to show it as a real application to the ATLAS collaboration. CAN nodes have been designed and implemented to control and monitor the readout electronics, to set and monitor the high-voltage channels and to monitor temperatures. The field bus network is interfaced to a Sun Unix system by a VME-CAN interface from MicroSys [4].

GENERAL PURPOSE CAN NODES

The heart of the CAN nodes that control the DATCHA prototype detector is a general-purpose credit-card sized module. This module contains a CAN controller, a micro controller, memory and I/O and is used in combination with dedicated electronics to add more specific functionality. These generalpurpose modules can be programmed for different application and combine local intelligence, extensive I/O capabilities and the CAN-bus interface on a small board. Two different implementations of this general purpose CAN module are used for the DATCHA detector: one is the General-Purpose CAN module (GPCAN), an in-house development of NIKHEF, and the other one is commercially available (MicroKey [5]). Both have a Philips micro controller of the 8051 family with an on-chip integrated CAN bus controller and extensive I/O functions. Three dedicated CAN nodes are designed with these general- purpose CAN modules for the control and monitoring of the precision chambers in DATCHA: 1. 2. 3. Detector Control Card (DCC) Quad High-Voltage Card (Quad-HV) Crystal CAN system.

CAN CONTROL FOR MUON PRECISION CHAMBERS

As mentioned earlier, one of the main detection systems in the ATLAS detector is the Muon Spectrometer. The barrel of this spectrometer contains about 600 Monitored Drift Tube (MDT) chambers. These precision chambers are arranged in three concentric cylinders around the beam axis at radial distances of about 5, 7.5 and 10.5 meters. Each chamber is an assembly of six parallel layers of drift tubes on a support frame, three layers on each side. From a control system point of view each of these chambers can be considered as a separate entity controlled by one CAN node which is mounted on the frame of the chamber. The barrel of the spectrometer consists of about 600 precision chambers, consequently a field bus network configuration has to be designed of (at least) 600 CAN nodes interfaced to the detector control system by VME modules. Monitoring of the temperature on different spots of the supporting frame on a precision chamber is required with a resolution of 0.5 C with a repetition rate in the order of ten seconds. Collecting this information regularly is required because the resolution of the drift tubes and the deformation of the chambers are functions of the temperature. When measuring the temperature on an average of 16 locations on each chamber, close to 10,000 sensors are needed for the 600 chambers in the barrel of the Muon Spectrometer. Hall probes will be mounted on many chambers to monitor continuously the three field components of the magnetic field. The output values for these probes will be compared with the results of calculations on the three-dimensional field model.

After a short description of the DCC and the Quad-HV, we will give a more detailed description of the Crystal CAN system for analogue sensor readout in the next chapters.

DETECTOR CONTROL CARD

A Detector Control Card (DCC) with a CAN node and additional electronics has been installed on each of the three precision chambers of the prototype detector DATCHA. The DCC module adjusts the analogue threshold values, disables noisy channels, generates test signals and monitors the temperature of the front-end electronics. An important feature here is the function to disable noisy channels in the chambers. Each frontend module connects to 32 tubes in the precision chamber and has a 32-bits register to disable individual channels. The register is written and read through a JTAG interface, as defined by the Boundary Scan Architecture standard [6] by the micro controller. The Detector Control Card is implemented by a GPCAN from NIKHEF with the Philips 87C592 micro controller and integrated CAN-bus interface.

CRYSTAL CAN SYSTEM

One of the requirements of the future ATLAS DCS is that it should be able to measure the magnetic field and temperature inside and around different parts of the detector. The Crystal CAN system is developed as a prototype for distributed and multiplexed analogue sensor readout. The hardware is made up of two module types: the Controller Module and the Sensor Module. The controller module hardware is the same in all applications. The software running on the module will provide application specific features. The sensor module is built around the same ADC in all applications, but the signal conditioning electronics around it depends on the application (the type of sensors to be read out). The Controller Module is based on a commercially available universal micro controller module (MicroKey 20CN592), designed around the Philips 80C592 8-bit micro controller running at a clock frequency of 16 MHz. The micro controller has an integrated CAN controller and the on-board CAN transceiver (Philips 82C250) provides an ISO/DIS-11898 standard CAN-bus interface. The module offers 48 KB of user application ROM (flash) and 63.5 KB of RAM. This amount of memory is enough to build quite large applications. User application code can be downloaded through a serial port (standard) or optionally via the CAN-bus, an option that could be very useful once the modules are integrated into an experiment. These features are provided by the onboard firmware

HIGH-VOLTAGE CONTROL CARD

The Quad High-Voltage Card (Quad-HV) is meant for the control and monitoring of the high-voltage channels for the precision chambers. It consists of a CAN node, which controls four independent high-voltage generators. The node is able to switch on and off the power supply, to set the value between 0 and the maximum value of 4096 Volt, to monitor the actual voltage and current values and to trip the supply when preset limits are exceeded. The CAN node is based on the same GPCAN node as used for the detector control card described above.

CRYSTAL CS5525 ADC

3

analog in n selection

sensor 1

Analog Mux

sensor 2 n

Controller Module
1 SCLK SDI SDO 3 selection 8 3 2 3

sensor 2

Sensor Module #1

20CN592 Micro Module

CAN controller

Digital Mux

CRYSTAL CS5525 ADC

analog in n selection

sensor 1

Analog Mux

sensor 2 n

sensor 2

Sensor Module #2

CAN field bus

SCLK,SDI,SDO

CRYSTAL CS5525 ADC

analog in n selection

sensor 1

Analog Mux

sensor 2 n

sensor 2

Sensor Module #8

Figure 1. Crystal CAN system configuration.

delivered with the module. The controller module also contains a multiplexer chip to enable connections to several sensor modules. One controller module may control up to eight sensor modules. A digital multiplexer-chip is used to switch the controllers serial interface I/O port to any of the connected sensor modules. The CRYSTAL CS5525 ADC [7] is the heart of the Sensor Module that digitizes the analogue quantities to be measured. This 16-bits ADC contains an instrumentation amplifier, a programmable gain amplifier, a digital filter and calibration circuitry. It also has four output latch pins, which are used to control an external analogue multiplexer to directly select any of up to 16 analogue inputs. In our case we use the CPD output as a fifth bit to be able to select even up to 32 analogue inputs. The CS5525 can perform conversions with rates of 3.76, 7.5, 15, 30, 60, 123, 169 and 202 Hz with voltage input ranges of 25 mV, 55 mV, 100 mV, 1 V and 5 V, unipolar as well as bipolar. The CS5525 is controlled through a three-wire serial interface that is compatible with SPI and MicroWire standards. The interface signal lines are connected to I/O ports of the micro controller in the controller module, which runs software implementing the protocol across these lines [8].

System configuration
Figure 1 shows a schematic of a general configuration of a Controller Module and a number of Sensor Modules. Typically the sensor modules are located a variable but relatively small distance from the controller module and connected by a cable, carrying the control signals and power. The individual sensors either are part of the sensor module or are connected to the sensor module by a cable. The controller module is connected to the outside world through a CAN field-bus. The CAN-bus can extend several hundred meters with its -in this applicationforeseen 125 Kbit/sec transfer rate and can connect up to about 64 controller modules, thus providing the required distributed control capability. Figure 2 shows a possible configuration of a local control station as part of the DCS of the ATLAS detector. It is a hierarchical system: the controller modules monitor the sensors, the Bus-to-CAN interfaces possibly may possess some intelligence and monitor the controller modules on their CAN-bus and the host controller monitors the various CANnetworks through the system-bus interfaces and may provide a local (graphical) user interface. The whole system is remotely monitored and controlled by the central DCS.

Detector Control System DCS

controller + sensors

controller + sensors

controller + sensors

controller + sensors

system bus (e.g. VME, PCI)

Host Controller

Bus-to-CAN interface

CAN bus

CAN bus
Bus-to-CAN interface controller + sensors

(local) user interface

Local Control Station

controller + sensors

controller + sensors

controller + sensors

ATLAS detector

Figure 2. Sensor readout configuration for ATLAS DCS.

B-field sensors
The B-field Sensor Module [9] consists of six Hall elements, a reference element, a temperature sensor and the CS5525 ADC, multiplexer and some additional electronics. There are a total of eight analogue quantities to measure: six B-field values, a reference resistor for calibration and an NTC temperature sensor. The hall probes are calibrated regularly for a full scale of 1,4 Tesla with a resolution of 50 microTesla. The maximum scan frequency is in the order of 10 Hz and is determined mainly by the time needed for the analogue signal to stabilise after switching the analogue multiplexer. The components of the sensor module do not contain materials that disturb the magnetic field.

Device NODE CAN RS232 ADC PWM WD PAR_IO DIG_IO HEX HV BST CS5255

Number 1 1 1 1 1 1 1 4 1 4 1 8

Description General status of the node CAN controller/interface Serial I/O port 10-bits internal ADC Pulse-width modulator output Watchdog timer 8-bit parallel I/O port 1-bit I/O port On-board hex switches High-voltage supply controller JTAG port with BST functions 16-bits CRYSTAL ADC

Temperature sensors
The temperature sensor module [10] consists of a small box containing the ADC, multiplexer, reference resistors for the calibration inputs, some additional electronics and 30 connectors for the NTC temperature sensors, which can be spatially distributed around the module (distances between NTCs and box are typically up to several meters). There are a total of 32 analogue quantities to measure. The input voltage to the ADC on the module as a function of the temperature of the NTC temperature sensor is a non-linear function, requiring a lookup table. Table 1. Software devices defined for our applications. can handle a status request, although the format of the status returned depends on the type of the device. Two types of devices can be distinguished in our applications: 1. Simple or standard devices mapping directly to the 80C592's I/O-devices, like the ADC or the 8-bit I/O ports, or mapping to the hardware layout, like the hex-switches which are mapped to I/O port 0 (via a buffer with enableinput) or the on-chip watchdog. Specialized devices that combine certain 80C592 on-chip I/O-devices in combination with specific hardware to form the functionality of a more complex kind of device, e.g. a high-voltage supply (with a ramping function, a trip-monitor function and a calibration function) or a JTAG interface with Boundary Scan Test (BST) functionality.

SOFTWARE ASPECTS
Higher-level standards for communication across the CAN-bus are available from several suppliers in the market. Examples of these communication standards are Smart Distributed System SDS from Honeywell, DeviceNet from Allen-Bradley and CAL/CANopen from the CAN users and manufacturers association CAN in Automation. Nevertheless it was decided to develop our own simple protocol in order to get started quickly. It was also assumed that the overhead of a high-level standard for the relatively simple applications we planned would be too costly. Moreover, the high-level standard preferred by us -the non-proprietary CANopen protocol- was not available at the time that we started developing our first CANbus applications. Actually, it is seen as one of the advantages of the CAN-bus that it is so easy to implement one's own application-specific protocol and quickly get to a working system. All software written for the CAN nodes has been written in the C-language. The software is designed in a device-oriented manner: a CAN module can be viewed as a collection of devices, each device being of a certain device-type (class), capable of handling certain commands (processing certain received messages) and sending certain messages or replies. In line with the object-oriented approach is that commands can be given to any or to several device-types although the exact action performed by a device depends on its device type. E.g. almost any device 2.

Table 1 lists examples of devices that have been defined for our applications. The Number column indicates the quantity of a certain device type present in the node. This number can vary according to the requirements of the application. Besides this notion of devices, the functionality of the software includes network management capabilities, like remote reset of nodes, remote configuration of CAN-controller baud rate, connecting / disconnecting individual nodes and node guarding. The values of devices (e.g. a temperature value) can either be monitored periodically by the network host or can be reported asynchronously by individual CAN nodes when the value exceeds a preset minimum/maximum value.

FUTURE DIRECTIONS
We expect CAN field bus networks be implemented on a large scale in those parts of the future high-energy physics particle detectors, where radiation levels are below a certain level (which is not quantified yet). This excludes the inner parts of the detector, includes probably the outer parts, such as the MUON detector and includes certainly the large number of crates and racks in the counting rooms. In the developments so far we used a commercially available CAN hardware building block based on a type of micro controller we were familiar with, offering ample memory and I/O to ease and speed up development of hardware as well as software. Keeping in mind the large number of sensors required in the coming high-energy physics experiments, in future developments we aim to minimize the hardware in terms of cost, power dissipation and space requirement, however without loosing completely the flexibility we now have. The emphasis will be put on the development of hardware for true -general purpose- control and monitoring tasks, not so much for special purpose tasks like the Detector Control Card we described in this paper, whose main task is to configure hardware on behalf of the data-acquisition system. Conformance to an open high-level standard for the CAN communication protocol used in the CAN application software will certainly be beneficial, especially when the number and the size of the applications will grow, as well as the number of people involved in the project will grow. Moreover the possibilities of integration of commercially available CAN equipment as well as supervisory tools and other (commercial) utilities will be greatly increased when using an open standard. The CANopen communication and device protocol [11] defined by the CAN in Automation users and manufacturers

group (CiA) is a likely candidate to be used as the communication layer standard. CANopen offers -if needed- complete configurability of device and communication parameters, while at the same time allowing on the same network very simple minimal capability devices, because the mandatory minimum requirements for a device to function in a CANopen network are only few. The CANopen standard has the capability of mixing real-time data with non-real-time on the same network without compromising the real-time behavior.

REFERENCES
[1] ATLAS Muon Spectrometer, Technical Design Report (chapter 11), CERN/LHCC-97-22, 5 June 1997 [2] Recommendations for the use of field buses at CERN, Guy Baribaud et al, CERN-ECP/96-11 [3] Road Vehicles Interchange of Digital Information Controller Area Network (CAN) for high-speed communication, Document ISO/DIS 11898, International Standard Organization, 1993 [4] CV002 VME, MicroSys Electronics GmbH [5] 20CN592 80C592 based micro module with an on board CAN bus controller, MicroKey B.V. 1996 [6] Boundary Scan Test, H.Bleeker et al, Kluwer Academic Publisher, 1993 [7] CS5525/CS5526 16-bit/20-bit multi-range ADC with 4-bit latch, data sheets, Crystal Semiconductor Corporation, Sept 1996 [8] Interfacing the CS5526 to the 80C51 Micro controller, AN74, Crystal Semiconductor Corporation, Sept 1996. [9] 3D Magneetveld meter, J.T. van Es, NIKHEF-ETR 97-05 [10] NTC-Temp.sensor Scanner and Conditioner. J.T. van Es, NIKHEF-ETR-97-03 [11] CANopen, CAL-based Communication Profile For Industrial Systems, CiA, DS 301 Version 3.0, October 1996