FROM A UNIX TO A PC BASED SCADA SYSTEM
F. Momal, CERN, Geneva

Abstract
In order to facilitate the development of supervisory
applications involved in slow process control (such ascryogenic control), the LHC/IAS Group (EquipmentControls Group) opted, a few years ago, for an industrial
SCADA package which runs on UNIX platforms.
However, to reduce costs and following market trends, it
has been decided to move over to a PC-based package.
Several processes relating to the testing of the prototypesof the LHC magnets are already controlled in this way.
However, it was still necessary to provide all theservices previously available to the users, for example,
data archiving in central databases, real-time accessthrough the Web, automatic GSM calls, etc. This paper
presents the advantages and drawbacks of a PC-based
package versus a Unix-based system. It also lists thecriteria used in the market survey to arrive at the final
selection, as well as, the overall architecture,highlighting the developments needed to integrate thepackage into the global computing environment.
1A UNIX SYSTEM

Several years ago, when we were asked to installsystems to supervise and control the tests of the LHC
magnet prototypes, we looked to industrial SCADA(Supervisory Control and Data Acquisition) packages[1].
They are usually composed of some kind of real-time
database (RTDB) holding the last known values of all
the process variables one wants to monitor. Around thisRTDB, a set of programs executes the most commontasks requested by the operators: PLC (Programmable
Logic Controller) protocol drivers, trending andarchiving tools, alarm handling programs, animatedgraphical representations of the process, etc. Choosing
an industrial package would release us from the burdenof having to develop and maintain our own software[3].
However we could only use these systems if they could
be smoothly integrated into the overall CERN
environment and if our different needs could beanswered[2].
Firstly, and this is perhaps the most important
requirement for these kind of systems, the software andits environment must be as stable as possible. Since
several parts of the program were to run at the sametime, for example, the PLC protocol driver and the MMI(Man Machine Interface), the operating system of themachine had to be multitasked. We wanted the archives
to be accessible from all machines and, for some data,
inserted into a central Oracle database. We wanted somealarms to be sent to the Unix based CERN Alarm Server.
It should be possible to connect remote consoles to thesystem. At a time when Microsoft Windows 3.1 was stillin its youth, we did not even think of another alternative
than UNIX. SCADA packages offered in thisenvironment had answers for all the major requirements.
Apart from the stability that was undisputed, this OS wasmade to be multitasked. The use of X Windows gave us
a convenient way of having multiple remote screensconnected to the same machine. This was mandatory
since several operators working in different control
rooms were to use the program. Offering an access fromeverywhere to the data was simple thanks to the standard
TCP/IP environment. All the archives and configuration
files were stored on AFS. Using the API (ApplicationProgramming Interface) which comes with the software,
we developed a lot of specialised programs ranging fromcomplex sensor calibrations to Web interface. We ended
up with a system which offered all that the process
specialists were asking for and which offered us areliable and solid environment.
Paradoxically, the main limitations we encountered werecoming from the used technologies. We found thefrequency of the operating system updates too fast. Due
to incompatibilities, a new release of the Unix system
was generally leading a new release of the SCADA
package. We lost a considerable amount of time
installing new versions of the used tools, running patches
and converting applications. The level of expertiseneeded to resolve the problems forced us to invest
largely in courses and time. X Windows which we foundso powerful was too demanding in terms of network
bandwidth to allow the use of home or portable PCs tobe used as occasional consoles. Finally the combined
price of the machines, the maintenance and the software
was relatively high.
2TOWARDS A PC-BASED SYSTEM

A couple of years ago, we decided to launch a newmarket survey on SCADA packages. This was based on
two main facts: Europeans systems now existed and themarket trend seemed to be drifting towards WindowsNT. This last point became particularly crucial when welearnt that the company that was selling us our current
SCADA had taken the decision to stop the development
on UNIX. It seems more obvious daily that software
companies are turning away from Unix, apart from verylarge and very expensive systems. Even more alarming,

1standards such as OPC are emerging which are comingfrom the Windows world.
Firstly, we had to make sure that the previously
described major requirements could be answered.
Windows NT 4.0 seemed stable enough. The PC
machines are nowadays as powerful as our Unix
workstations. File servers such as Novell servers areoffering the universal remote file access which we wereseeking. Multiscreen cards offer the operator all theviewing comfort he asks for. However, we still had tofind a way to provide the remote services people wereexpecting. This was an important point of our market
survey.
On the other hand, doing the transition to a Microsoft
Windows based system brings many advantages. The
price of the different components of the system, whether
it is hardware or software is smaller. Maintenance also ismuch cheaper. People are often used to the Windowsenvironment and, although the solving of a complex
problem requires an expertise as important as before,
simple problems may now be handled by the users
themselves. The quantity of programs that can be used toextend the system is enormous. As far as an API isoffered by the SCADA, powerful and user-friendly
compilers may be used. Several drawing programs exist
to draw the MMI screens and many products can be used
to analyse, chart and archive the data. Finally, if the new
product follows the Windows interoperability standard,
it could be easy to tightly link different products with theSCADA package.
3A MARKET SURVEY

The market survey was launched together with a list ofcriteria which was to be used to sort the SCADAsystems. The package should:• Run under Windows NT.
• Have a client-server and modular structure. Thismeans that while the RTDB is running on someserver doing the PLC acquisition, the MMI can run
on other client machines.
• Implement the mainly used automation protocol
standards (at least Profibus, FIP, and OPC).
• Offer a complete API.
• Have an object-oriented RTDB.
• Use a standard computing language as the integrated
programming language.
• Be automatically programmable using an external
description source. This mainly means that theconfiguration files used in the different parts of theSCADA can be editable in ASCII.
• Follow the Microsoft interoperability standards(known as OLE, ActiveX and DCOM).
• Export the archives in a standard format.

•Be European. This is due to internal CERN
constraints.
We did not ask for an Internet access through a browser
due to the fact that we thought that the market wasunprepared for a good solution in this area. However, wechecked that the developers were making provision for
this.
After a general pre-selection, four systems answering
several of these criteria were analysed thoroughly and
one was selected.
4

Before putting the selected system into operation, we
had to set-up a global computing architecture that could
offer the services previously described.
The base of the architecture is composed of a dataserver. This machine is dedicated to acquiring the valuesof the different process variables to be monitored. Thisdata server contains the RTDB of the SCADA system.
The connection with the PLCs is done through a specificnetwork card from Applicom. This card holds onboard the PLC protocol driver. The data server issending, whenever there is a change, the values of theprocess variables to the remote clients that havesubscribed them. A second PC, identical to this dataserver, serves as a hot back-up. If the data server, for any
reason, breaks down, then the back-up automaticallytakes its role. By dedicating a PC to data acquisition anddistribution, one stabilises the load on the machine.
A client machine handles the archives2. On its hard disk,a few days of data can be held. Being a module of theSCADA system, it allows MMI clients to quickly accessthe recent values. For long term archiving, the data aresent to a central database running on a UNIX machine.
Another client machine, which is also a SCADA
module, takes care of the alarms. In a unique location, it
manages the handling of the process alarms by theoperators. By connecting a specific program to thisclient, automatic messages are sent to the GSM phonesof the operators who are on call. This machine serves
also as a gateway to the CERN’s central alarm server, ifneeded.
MMI clients located near the process, in a central control
room or in the office, are also connected to the dataserver. All the graphical animations are done on theclients and thus the network load between the MMI
client and the data server is very low. Only the values ofthe subscribed process variables are sent, on change, by
the data server to the MMI clients. This allows having afull client that runs on a computer at home, the modem’s
bandwidth being sufficient. This solution proves to be
more efficient than the X Windows approach. A network21

OLE for Process Control

A GENERIC ARCHITECTURE

For small systems, all the clients may run on the samemachine than the data server.

failure between the client and the server no longer
affects the data server.
All the configuration files are available on a file server,
allowing a central maintenance of the versions.
Internet access to the data is done through anotherprogram tightly linked to the SCADA system. This
program offers Internet oriented interfaces, such as aJava API and JavaBeans. This interface is used mainly tohave a remote synthetic view of the process rather thanfor a full remote control.
The main underlying concern that led to this architecture
is modularity. Ideally, it should be possible to replace
any part of the system with another one without
jeopardising the overall architecture. If, for example, wewere to use another SCADA package, we would nothave to change any of the hardware parts (neither thePCs nor the acquisition cards). We could still use thelong-term archiving system, the alarm gateway and theInternet access.
Developments needed to integrate the SCADA packagein the architecture and to connect it to the different
services (archives, alarms, and remote access) were notvery important. This is due to the fact that we managed
to find compatible software. We only had to do somecoding for the connection with the archiving system andon the Java MMI used to access the data through theWeb.
5

PRACTICAL EXPERIENCES

wishing to do the same transition should not forget it inthe planning.
We have had no problem yet with the stability andeverything seems to behave as expected. We can only
recommend not trying to limit the PC hardware
components. SCADA packages are resource demanding
and a lot of memory, a large disk and a fast CPU arewelcomed.
The only complaint we had from the users of oursystems was regarding the change in the SCADA
graphical screens. In fact, we took the opportunity to try
to upgrade the quality of the MMI, but as often in thesekind of applications, stability is one of the mostimportant points.
REFERENCES[1] F. Momal, D.Bienvenu, D.Brahy, D.Lavielle, R.
Saban, B. Vullierme, L.Walckiers, “A Control
System based on Industrial Components for
Measuring and Testing the Prototype Magnets for
LHC” , EPAC’94,London,1994(http://mish231.cern.ch/docs/papier2.htm)[2] F.Momal,
D.Brahy,
R.Saban,
P.Sollander,"Integrating a commercial Industrial control System
to the Accelerator Control System", ICALEPS'93,Berlin[3] R.Saban, P.Ciriani, A. Guiard-Marigny, H.Laeger,
M.Rabany and A.Swift, "Equipment IndustriallyControlled ",ICALEPS'93 Berlin

We have already installed Windows NT based SCADA
systems on several processes. It took some time toacquire the required Windows NT expertise and anyone

Control RoomOffice
Portable

ObserverRemote MMI StationAlarmServer
RealTime
DataServer

ArchivedDataServerArchiver
Data DescriptionOracleDataServer

Hot Backup
DataServer
AFS Storage
PLCsFigure 1: The general architecture