INTEGRATING INDUSTRIAL CONTROL SYSTEMS INTO THE
CONTROL ENVIRONMENT OF THE TECHNICAL INFRASTRUCTURE
OF CERN
P. Sollander, D. Blanc and A. Swift
CERN, Geneva, Switzerland

Abstract
At CERN, more and more of the technical infrastructure is controlled by industrial systems, using Programmable
Logic Controllers (PLCs) supplied by different manufacturers. The systems are also increasingly being installed andconfigured by our industrial partners. These diverse systems need to be integrated into the existing control environment,
which itself is part of the accelerator control system, so that a standard environment for supervision can be provided
to the Technical Control Room (TCR). Recently, several systems for electrical distribution, cooling water, safety andcontrolled access to accelerator radiation zones were equipped with new controls and required integration. This paper
describes the solutions adopted for common interface standards, selected hardware systems and software packages andthe collaboration with industrial partners. It also discusses the difficulties encountered.

I. INTRODUCTION
The CERN Technical Control Room (TCR) is responsible for the overall surveillance and control of the technicalinfrastructure covering systems such as cooling, ventilation, electricity distribution and safety. The TCR is an alarmdriven control room in the sense that the arrival of an alarm will alert the operator and make him take appropriate actions.
The operator acts upon the alarms primarily by consulting and interacting with mimic diagrams.
These human–computer interfaces, alarms and mimic diagrams have been structured systematically and they havebeen standardized to a large extent, in spite of the large diversity of installations being supervised. Any new installationmust be integrated harmoniously into this environment.
Until recently, technical infrastructure equipment has been connected to the control network at the lowest level via
specific CERN-developed front ends, called Equipment Control Assemblies (ECAs). For new projects, however, industrial controllers (PLCs) are being increasingly used. In the same way industrial supervision systems are being installed
and must be integrated with the existing control system.

II. CURRENT ENVIRONMENT
A. The Reference Database
For a large part of the technical infrastructure, accessible equipment parameters that are known to or used by the TCR
are described in a reference database (STRefDB). Every parameter or point is uniquely identified and describes the typeof point (alarm, event, measurement), the geographical location of its controller and its logical location in the control
system, i.e. which supervisor, which front-end computer, data block, word and bit holds the information.
This information is used to define the alarms for the central alarm server, to configure the supervisors and to create
the mimic diagrams.
B. Equipment Front-End Computers
Process equipment is connected to the control system via ECAs. The ECAs are CERN-developed microcomputers,
usually VME-based, which are directly connected to the process equipment with digital or analog input/output or via
serial interfaces such as RS 232. The ECA communicates with the level above in the control system, the Process Control
Assemblies (PCAs) via MIL-1553 field-buses.
C. The Central Alarm Server
The Central Alarm Server (CAS) [1] concentrates all the alarms from the equipment, constructs the alarm messages
and dispatches them to the users. Every user can subscribe to the categories of alarms he is interested in. The CAS works

with one standard human–computer interface which is used in several control rooms at CERN. All new alarms must use
the CAS and its user interface.
Alarms are fed to the CAS via alarm servers distributed throughout the control system. The CAS receives “V2-strings”
that contain, amongst other information, the triplet FaultFamily–FaultMember–FaultCode which uniquely identifies analarm.
D. The Mimic Diagrams
All mimic diagrams used in the TCR have been developed using a high-level graphics environment called the Uniform
Man Machine Interface (UMMI) [2]. It uses the graphics package DVdraw and DVtools, on top of which is added a setof functions and languages which eases the work for the application programmer and gives a standard look-and-feel for
all applications.
The applications are primarily made for the TCR operators, but they are also used by the equipment specialists whowant to check their equipment remotely (e.g. from their offices).

III. INDUSTRIAL CONTROL SYSTEMSThe control system of the technical infrastructure is a hybrid of in-house and industrial systems. This infrastructurevery much resembles that of any industrial site with systems like cooling-water circuits, electric-power distribution,ventilation and safety. It is therefore possible to take advantage of products existing on the market for industrial controls
to shorten development time and to ease the maintenance burden.
CERN has been using industrial PLCs for some of its technical infrastructure for several years. These PLCs areof different makes depending on the installations they control and are all connected to the CAS and the UMMIs using
in-house-developed concentrating devices for their integration.
In recent years, industrial supervisory systems that include data acquisition, trending, graphical user interfaces andalarm displays have become popular at CERN. These systems provide a high-level control environment and are designed
for the upper level of the control network. They are usually configuration tools rather than programming libraries. Suchsystems are best suited for installations of a specific type (of a limited size, a defined geographical area, etc.)
Amongst other systems, CERN has used Siemens PLC equipment and the industrial supervisor FactoryLink for someof its recent installations. It is the integration of these two products into the current environment which will be discussed
in this paper.

IV. INTEGRATION
A. Reference Database
The reference database STRefDB must now cater for the new data structures used with PLCs and FactoryLink. The
procedure for entering new data into the reference database is as follows: The PLC programmer establishes a list of all
equipment parameters and their location in the PLC; hen this list is completed with alarm information and FactoryLink
tag names and then imported into the database. We use spreadsheets as support for initial and completed data to ease data
entry and to ensure correctness. The content of the spreadsheet is then converted into ASCII text and imported into thereference database using a standard SQL*Load package.
Data must then be extracted from the database to provide the CAS with the information necessary for handling thealarms and the supervisory system with the parameters for the control of the systems. Extraction tools have been createdto translate the reference database data into the appropriate formats (Fig. 1).
Data gathering and data definition are lengthy processes prone to errors. The implementation of specific procedures
to rationalize this activity must be envisaged.
B. Equipment Front-End Computers
The integration at the front-end level using PLCs demands that a coherent approach towards the equipment be applied.
Each type of equipment, be it fire-detection systems or cooling-water systems, has its own types of interface and data,i.e., the interface to the equipment will inevitably vary with the application. The interface from the PLCs upwards to therest of the control network, as well as the organization of the data inside the PLC, should be dealt with in a single way for
all types of equipment as far as possible. Having a number of PLCs for various installations, we have developed genericcommunication procedures and a standard organization for any PLC.
We use the Siemens implementation of the Profibus (DIN 19245) protocol called SINEC L2 for communication
between PLCs and the Siemens ethernet (IEEE 802.3) protocol SINEC H1 for the interface between the concentrator
PLC and the supervisor.

This ensures efficient network usage and allows the connection of different systems made by different firms on a single
field bus communicating with one standard concentrator PLC. The procedures are integrated into PLCs programmed either
in house or by an external firm.

Central alarm server
CASAlarm definitions

Reference database
STRefDBFL tag definitions

FL alarm definitions

FactoryLinkFL AlarmServerFigure. 1. Information extraction from the STRefDBC. Central Alarm Server
To allow alarms generated by FactoryLink to be transmitted to the CAS, an alarm module [3] was added to FactoryLink. This module is fed a list of strings associating a FactoryLink tag with a CAS V2-string where each tag corresponds
to one specific alarm. The alarm module detects any change of state in one of the tags and generates the corresponding
alarm by sending the V2-string to the CAS.
D. Mimic Diagrams
The use of FactoryLink does not imply the abandonment of our UMMI environment. As the UMMI is our standard
graphical user interface, it must be possible to use it with data coming from any source. On the other hand, for somespecific applications we do use FactoryLink graphics which must be granted access to existing ECA equipment as wellas to PLCs.
We have added two modules to FactoryLink which conform to the communication standard Equip [4] built at CERN
and based on Remote Procedure Calls (RPC). It allows transparent data access to compliant equipment or computers
by giving the equipment description. An Equip transaction is made between a client, generally in a console of thecontrol room, and a server implemented on the equipment. Control room clients may now access an industrial process
via FactoryLink as if it was home-made equipment using an Equip server [3]; FactoryLink may access home-madeequipment via an Equip client.
E. Architecture
Figures 2 and 3 show the hardware and software system architectures after integration.

V. APPLICATIONS
Several systems have now been integrated into the supervisor. One supervisor covers the control for the entire
demineralized water system for the Proton Synchrotron (PS) accelerator and another deals with the safety alarms for theMeyrin site and the demineralized water for the West Zone experimental area of the Super Proton Synchrotron (SPS).
It is furthermore envisaged to extend the system to include the heating plants of the Meyrin site and a large part of theCERN ventilation systems.

A. Safety Applications
The first application that was developed using the above architecture was the safety system for the Chorus [5] andNomad [6] experiments. The system is controlling fire, gas detection and emergency-stop equipment in one experimental
hall. The alarms generated are distributed to the TCR, the CERN fire brigade and to both experiments via the CAS andits user interface.
As this system controls personnel safety equipment, the alarm transmission to the fire brigade is made in parallel witha hardwired synoptic display located in the fire station.
As a follow up to this project we are currently installing new fire detection equipment on the Meyrin site in the sameway. All new equipment is now ordered with a SINEC L2 interface for smooth and standard integration.
Operator
Console Xterm

UMMI
application

Alarmdisplay

UMMI CAS
HP-UX

UMMI Equip
clientAlarm generationand distribution

Equip server

Alarm server

Supervisor on
HP-UX

Run-Time database
Data acquisition
Protocol drivers

Concentrator
PLC

Data collection
and transmission
Local control
softwareLocal controller
PLC

Protocol drivers
Equipment

Figure. 2. Hardware architecture

Figure.3: Software architecture

B. Cooling Water in the West Zone
The second system to be integrated in the new control architecture was a cooling station for the West Zone experimental
areas. The process control was developed by an external firm using two PLCs. The field bus used for the previous Chorus
and Nomad safety system was extended to include also these two PLCs. The communication functions for the PLCs wereprovided by CERN to ensure compatibility.
C. Cooling Circuits for the Proton Synchrotron Accelerator Complex
The cooling water control systems for the Proton Synchrotron (PS) were entirely rebuilt in the period 1994–95. The
project was given to an external firm who was asked to deliver a SINEC H1 connection to an HP-UX machine running
FactoryLink.
The complex comprises 15 cooling stations controlled by PLCs connected to two separate field buses by SINEC L2
to a concentrator PLC which is the connection point with FactoryLink installed on the HP-UX machine.
Owing to the large number of equipment parameters controlled and the relative stability of the system, an event-driven
data acquisition system was implemented. A change of state of any parameter of an installation will trigger the sendingof the information upwards in the control chain. To ensure the integrity of the supervisor’s database, status informationis also sent regularly at 30-second intervals.
D. Access ControlThe PS and the SPS machines have recently been equipped with new access control systems. In both cases an external
firm was asked to deliver a turnkey product using the CERN standards.
In these two applications, which are operated only from specific consoles, FactoryLink was used for both data acquisition and mimic diagrams, and since there is no alarm handling through the CAS there is no need to hold the data on theSTRefDB.

E. Electricity Distribution
For reasons of electrical protection and in order to comply with safety standards, the approach of the electrical group issomewhat different, since we have to buy specific equipment from agreed manufacturers. However, since this equipment
broadly resembles the more general purpose PLCs used by other groups, in that it communicates via a serial protocol,
the problems of integration of this equipment into the control network are identical. The message structures contained inthis protocol are equipment-specific, which is why we have chosen to insert a data-concentrator/decoder (called a BusManager) between the equipment and the control system, in order to transform all equipment data into a single standardformat. At the supervisory level we are at present studying the possibility of integrating one of the many supervisors
available on the market, dedicated to electrical supervision, into the proposed Technical Data Server (TDS) [7].

VI. CONCLUSION AND OUTLOOKThe different projects that integrate lower level industrial control equipment and higher level industrial supervisor
packages so far have shown us the major advantages and disadvantages of both the products and the policy of outsourcing
development work.
For the industrial supervisor FactoryLink, it can be said that it is not generally the best solution to our problems due
mainly to the fact that we cannot make use of all of its features. We are limiting ourselves to the data acquisition and thereal-time database, not using its graphics, alarm handling or trending. On the other hand, for applications like the access
control systems, FactoryLink seems to be adequate.
For the users, the new control architecture has meant shorter response times due to the fact that we now acquire datafrom a powerful machine situated high up in the control network instead of acquiring data directly from the equipment.
The time it takes to update a mimic diagram has gone down from approximately 15 to less than one second. The fact thatthe information read is a few seconds old does not matter in the operation of this kind of equipment. This is, however,not true for the access control applications, in which the system is carrying data from a person wanting to access theaccelerator to an operator and rapid transmission of information is very important.
The difficulty of integrating industrial equipment has been found not so much in the higher levels concerning thealarms and mimic diagrams as in the lower levels concerned with integration of the actual equipment to the industrialPLCs. In effect, systems like fire detection are not designed to be a part of a larger control system but are normallystand-alone systems with their dedicated user interfaces and alarm screens. A solution to this is to order the low-level
integration directly with the system, specifying the communication protocol desired.
At present we are trying a different product for the integration of industrial controls. We plan to use the distributed
control system RTworks for some systems. This product also has the advantage of directly integrating with our existing
mimic diagrams made with DVdraw.

References[1] M. Tyrrell, “The LEP Alarm System”, in Proc. ICALEPCS’91, pp. 254–259.
[2] P. Ninin and P. Sollander, “Utilisation d’un logiciel commercial graphique pour le contrôle des installations techniques du CERN”, CERN/ST/MC/TCR/92, presented at EERIE, Nı̂mes, France, October 1992.
[3] J. Brahy, “Une passerelle entre le monde des automates programmables industrielles et le contrôle des accélérateurs”,
AT 93–05 (IC) (private communication).
[4] P. Charrue, “Accessing equipment in the SPS-LEP controls infrastructure: The SL-EQUIP package”, SL/Note 93–86(CO) (private communication).
[5] http://choruswww.cern.ch/welcome.html[6] http://nomadinfo.cern.ch/[7] P. Ninin et al., “The Technical Data Server for the Control of 100 000 Points of the Technical Infrastructure atCERN”, these Proceedings