Using the CERN generic Windows infrastructure in a specific control
environment
Ivan Deloose, David Foster, Alberto Pace
CERN, CH-1211 Geneva 23, Switzerland
Abstract
CERN has a large Windows 95/NT infrastructure withmore than 3500 PCs connected that is used as one of
the main information services for the laboratory. Thisinfrastructure is used for a wide set of services,including Office Automation, Computing Aided
Engineering, Calculations, Software Development,and ... controls. This paper will describe the CERN
generic infrastructure for Windows 95 and Windows
NT and then give several examples of PC control
applicationsandfuturedirections.
Theimplementation of an object oriented device server
based on Windows NT and ActiveX in the CERNISOLDE-REX experiment will be reported.
Invited paper presented at PCaPAC 1999, the second
workshop on PCs and Particle Accelerator Control, 12- 15 January, 1999, KEK, Tsukuba, Japan.

Introduction
CERN has more than 3500 Personal Computers (PC)connected to its internal Local Area Network (LAN)that where purchased in the last 5-6 years. The park is
composed mainly of Pentium and Pentium II
computers and they have a memory size ranging
between 16 MB and 128 MB of memory.
All Windows PCs are running any of the two
supported operating systems: either Windows 95(75 %) or Windows NT 4 (25 %). PCs running Linuxare in addition. All computers are connected to central
servers or to local workgroup servers which provide
the network services. There are more than 25 central
servers1 running Novell Netware offering more than
400 GB of disk space distributed across more than 100
volumes which are used to store software, home
directories and data. All PCs have pre-installed thenecessary software components to run any of the morethan 100 packages available from the software servers.
The software configuration2 of all PCs is standardisedand centrally maintained. The hardware configurationof every PC is known and is kept in an asset
management inventory which is dynamically updated.
All users and all PCs are centrally managed3. Thisimplies that the same application software available toall users and all software is available to all PCs,
always loaded from the network. The service ismanaged to satisfy user software availability andstability requirements and to reduce the requirement
for end-users to instal software locally on their harddisk.
The only digression from the standard configurationis possible within the boundaries of well-known andmanaged workgroups. Inside a workgroup, the local
administrator can decide to support non-standard
hardware or additional software when this isnecessary4. To ensure 24 hours/day service, theworkgroup administrator can also replicate allnecessary support files to his local workgroup server.
It is within this frame that the control system of theCERN ISOLDE-REX experiment described later inthis paper has been developed and implemented.

Windows at CERN
Windows at CERN is supported within the NICE
(Network Integrated Computing Environment) projectthat has the vision to create a desktop environment
capable of accessing all the information systems andto provide a single entry point into all information
resources at CERN.
Two client configurations have been defined: The firstone is NICE95, based on Windows 95 andrecommended for low end PCs, for portable computers,
and for users requiring excellent applicationcompatibility with 16-bit software originally designedfor MS-DOS or Windows 3.1. The second
configuration is NICENT, based on Windows NT, andrecommended for high end computers and for usersneeding to run mainly 32-bit applications.
Both Windows 95 and Windows NT configurations5
can run Windows 32-bit applications on which all theCERN major services are based.
For all computers, Windows is installed on the localdisk. A consistent set of Windows “system” files(mainly dynamic link libraries and OLE controls) on
the local disk is a mirror copy of an image on thereference server. With this model, the local disk is
considered a cache of the network disk that provides
the stability of the local installation and themanageability of the diskless installation. To preserve
the installation of local applications that may require
newer versions of system files, the internal“Fileversion” resource is checked before copying any
file from the server to the local disk.

Services for Users
The end-user just uses the computer he has on his
desk and he does not need to understand what aservice is. However, the fact that he can start a wide
variety of different tasks using his computer meansthat there are services tightly integrated on his
desktop, despite the fact that these may have been
provided by different groups or divisions in thelaboratory.
Every user has a Home Directory that he can use tostore his documents. The home directory is by default
read-protected for other users but has a publicreadable subdirectory where public information can bestored. The user can change the access rights to hishome directory as he wishes. All security features areavailable to the user and rights can be granted to every
single directory (who, from where, when, what).
Data saved in home directories is backed up daily andthe information is easily shareable with other users on
multiple platforms (DOS, Win31, Win95, WinNT,Macintosh, the World Wide Web, and UNIX via NFS).
These facilities provide compelling reasons to use thenetwork disk instead of the local hard disk, which isgenerally not backed up.
A large set of application software is available to all
Windows desktops in order to be able to satisfy allusers requirements. Solutions are available to all theusers in the following fields: Word Processing andDesktop Publishing, Drawing and Drafting (withclipart image libraries), Spreadsheet, Management,
Presentation Graphics, Computer Aided Design(Mechanical, Electrical and Electronic), Computer
Aided Engineering, Symbolic and Numerical Analysis,Controls, Tests, Instrumentation, Programming (in C,C++, Basic, Java, Nodal, and FORTRAN), Databaseaccess (remote and local), Communication andInternet access (Telnet, FTP, Mail, X terminal, WWW
clients, …).
The application software is either pre-installed on theserver or installed-on-demand in the local disk, and itis therefore the same on all PCs within the sameworkgroup. Well defined processes are in place tomake software available CERN-wide by installing iton the central servers or in the local workgroupserver6. Central software usage accounting is done inorder to monitor the simultaneous usage of allcommercial software packages which are accessed by
the user accesses using the Windows “Start Menu”
which is the same on all computers.
Every computer has access to all the printers on thesite7,8 (more than 1000). Print services are available
from both 95 and NT platforms using a CERN
designed LPR client on TCP/IP.

The CERN Printing Architecture

All PCs are directly connected on the Internet: they
have access to the World Wide Web, to electronic
mail, can run X-applications and can telnet or ftp toany host world wide.
All home directories and divisional volume files areaccessible from the Internet remotely using FTP orWWW. The host name http://nicewww.cern.ch is a
gateway that provides transparent access to all data
files without the necessity to hard-code in the URL thephysical server name or volume name or directory
name, and leaves complete freedom to the server
administrators to move/copy/rename/split volumes
without breaking URLs hard-coded in the HTML
documents. Using this facility, every user can easily
have his home page on the Web9
Access to the CERN network is also possible using
telephone lines, GSM and ISDN. Portable computers
can dial into CERN and access remotely all
documents located at CERN and get access to theInternet using a dial-up connection10.
A set of document is available to end users. The
general documentation11 is made available in Frenchand English, while the technical documents5,10 are
normally available in English only.

The ISOLDE-REX control system as anextension in the NICE architecture
The standard software is always installed on areference “program disk” saved on the reference
server. To ensure a correct scalability of the system(able to support more than 4000 simultaneous PCsconnected) this “program disk” is replicated several
times with a consistent replication process which
ensures that all copies are identical.

SRV1_NICE

SRV2_NICE

SRV1_ISOLDE

SRV0_NICEREPLICAThe reference program disk is replicated on other servers

The reference “program disk” can also be replicatedto a “workgroup server disk”. The replication process
can be automatic or manual under the supervision of
the local workgroup administrator. An automatic
replication can be used when the workgroup
administrator wants to ensure that all softwareservices are local and independent from the network
availability (typically for an experiment running 24hours/day, 7 days/week). A manual replication can beused when the workgroup administrator wants tocontrol all software upgrades that are taking place on
the desktops he manages, to freeze the environment
for an experimental run for example.
The ISOLDE-REX control system is implemented inthis way. A server SRV1_ISOLDE contains acontrolled replica of the standard reference server andit has, in addition, an entire volume containing
specific control software used to run the experiment.

How the software is distributed
As the start menu is centrally managed on everycomputer, an entry for the ISOLDE-REX control
system is made available to every computer on theCERN site. The shortcuts of the ISOLDE-REX
specific software point in the specific ISOLDE serverwhich is attached on-demand. The advantage of thisapproach is that all CERN personal computers haveaccess (provided they have enough privileges) to any
application of the control system.

Some control applications available to all CERN PCsTheISOLDE-REX
architecture

controlsystemThe ISOLDE control system is designed as a two levelsystem: Consoles and Front-End-Computers (FEC)
physically connected to the equipment. As consoles,
standard desktop PCs are used with no specialconfiguration. This is why any normal office PCs atCERN can be seen as a potential console to theISOLDE console system. In the computer connected tothe equipment (FEC) a network listener is runningand executes control requests coming from theconsoles. For slow types of controls, like power
supplies, these computers are running MS-DOS, while
for all fast or sophisticated types of access, like
instrumentation, the FEC computers are running
Windows NT4.

The ISOLDE control system architecture evolution

Access to the ISOLDE-REX control system through the start menu

The access to the control system is not limited to few
specially configured computers in the control room orin the specialist offices: virtually any PC on the CERN
network can run any application from the controlsystem.

All computers are connected to the local Ethernet
where the TCP/IP protocol is used for the equipment
control access. The FECs are all connected to theequipment using the standard PC data acquisition
cards on the local ISA bus. The cards used contains
ADC, DAC, Digital I/O, Timers, Counter, RS232,
CAMAC and GPIB IEEE-488 chips.
For FEC computers requiring large number of cards,
one or two bus extension chassis have been added inorder to accommodate up to 25 control/acquisition
cards per PC. The CAMAC bus has been used inorder to recuperate the large amount of second-hand

CAMAC interfaces that are used to control one fourthof the existing equipment. The RS232 and GPIB bus
has been used to support directly new instruments thatwere purchased and integrated in the system.
To quantify the dimension of the project, the control
system counts roughly 600 devices (elements) andmore than 2000 analogue or digital wires (controlchannels) coming into the control system on fourbuses (CAMAC, GPIB, ISA and RS232).
The Software
The ISOLDE model is object oriented and every object
has his own name: every equipment, also known as aphysical device (e.g. power supply, RF amplifier), hasa unique ASCII name and is registered in the control
system database. Each equipment is member of anequipment type family, called class. A class describes
all parameters that can be controlled for this type.
Every parameter is identified by an ASCII name,called property. The implementation of a class and its
properties is carried out in an equipment module,residing in the Front End Computer.
The original client-server model designed in the early
90s only included synchronous communication calls.
But with the years, several additional features like
data
subscriptions,timingsynchronisation,
asynchronous calls have been added to the system.

The RPC server module, initially running on theISOLDE FECs, has been ported to other front end
environments like Windows 3.1 (PC), OS/9 (VMEcrate) and UNIX (IBM RS/6000 workstation). This
multi-platform extension of the server module has
been initiated in the PS division with the introductionof a gateway providing controlled access from the PC
world to the controls of the PS accelerators.12
With the introduction of Windows NT 4 at CERN, it
became very attractive for ISOLDE to benefit fromthis new CERN supported environment on bothconsole and FEC sides. Combining the powerfulobject oriented development environment of VisualC++ and Visual Basic, the FEC model wasdramatically improved from a single statically linked
executable to a set of OLE objects dynamicallyinteracting at run time. This evolution provided agreat simplification with the ability of reusing existing
software and modifying existing configurations
without relinking executables.13
When Windows NT FECs were introduced, the entire
development environment became much more stable.
The latest version of the development products, forexample the native code compiling capabilities ofVisual Basic, made the PC a very efficient rapid
development platform, especially for prototyping.
Another advantage of this modular evolution was that
the NT computer can simultaneously work as a FEC
and a client (console), which is very useful for local
testing and to implement FEC-to-FEC communication
which is necessary when implementing sophisticatedmeasurements requiring data coming from different
computers.
The Database

One application of the ISOLDE control system

In the early days, the single tasking limitations of MSDOS forced the developer to statically link into one
single executable all subroutines providing all servicesof the FEC. This program consists of a genericsoftware (repeated in every FEC) linked with theequipment specific procedures (equipment modules).
In a DOS FEC environment, such a module is a Cfunction implying a switch to distinguish the property
names.

In the initial design phase of the ISOLDE control
system, all data required by the Consoles and FECs toaccess the equipment was stored in a set ofindependent Comma Separated Values (.CSV) files.
With the addition of the REX-ISOLDE equipment,
maintenance of this flat-database structure would
become increasingly difficult. A new relational
database was therefore developed to accommodate theexisting ISOLDE data as well as data required by theREX extension. The new database allows theorganisation of multiple data tables joined in defined
relationships within one single file.
Microsoft Access was chosen as the new databaseapplication due to availability as well as simplicity
with respect to system configurations, maintenanceand portability of the existing Excel data.

possibility to export to the world wide web any control
applications making them available on demand not
only to all Windows PCs inside CERN but to virtually
any PC world wide connected to the internet.

Conclusions

ISOLDE control system database relationships

In order to simplify data entry, a Graphical User
Interface (GUI) has been developed. The database
editor is written in Visual Basic and can be run fromany PC compatible platform
The modular approach
The object oriented modular approach had an
important side benefit also at the console level: thereusability of the code was directly possible in a huge
number of commercial applications. Applications
developed for the ISOLDE-REX control system could
be embedded in any other application (Word, Access,Excel), making it very easy for the users of theseapplications to get (and process) data coming from thecontrol system. The reverse was also possible: Control
system applications could directly use any genericfunctionality of commercial applications to implement
specific functionality (example: the database engine ofAccess, the report capabilities of Word, calculations ofMathematica, etc…).14

A common culture is being generated in the laboratory
where everyone uses the same application set and has
the same way of working, which provides scalability
in terms of central user support and user to usersupport. In the case of the ISOLDE-REX control
system, a direct leveraging of services from thegeneric infrastructure have been in•••••

standard installation of every of Win 95 or NT 5.
Operating system support
network cabling, routing and troubleshooting15
server infrastructure1, maintenance2 and backup
generic application installation6, support andlicensing16
computer inventory, printing support7,8

As a result, the ISOLDE-REX control system has been
completely integrated in the generic infrastructure. In
addition to the very low maintenance cost, the benefitof this approach has been that the control specialists
could focus their efforts in solving control-related
issues and leveraging from the existing support
infrastructure for all the generic PC and Windows
related issues.

REFERENCES
1

See http://nicewww.cern.ch/operations/status.htm forthe list of the online servers and volumes.

2

See http://nicewww.cern.ch/doc/admguide/addescre/addescre.htm for a description of the standard CERN
PC desktop configuration

3

See http://nicewww.cern.ch/doc/admguide/adproce/adproce.htm for a description of the standard PC
system management procedures

4

See http://nicewww.cern.ch/doc/admguide/adntsrve/adntsrve.htm for a description of the administration
facilities available to Workgroup Resource server
administrators

5

ISOLDE control system application available from the internet

P. Hagen, A. Pace, “Installing Windows 95 or NT atCERN”, CERN-UCO/97/196, February 1997,
http://nicewww. cern.ch/doc/install/install.htm and P.
Hagen, A. Pace, “The Windows 95/NT administration
guide at CERN”, CERN-UCO/97/194, February 1997,
http://nicewww.cern.ch/doc/admguide/admguide.htm

6

One direct consequence of this approach has been theSee http://nicewww.cern.ch/doc/admguide/adswinse/adswinse.htm for information on the softwareinstallation procedures at CERN
7See http://wwwcio.cern.ch/Others/printerspage.html
for a description of the printer support service
8I. Reguero, D. Foster and I.Deloose, "Printing at
CERN", CERN-IT, LISA Conf., Dec. 98, Boston,USA

9See http://nicewww.cern.ch/doc/usere/uswwwe/
uswwwe.htm for a description of the WWW gateway
service

10P. Hagen, A. Pace, “Home Access to the CERN
Network from Windows”, CERN UCO/96/192,
January 1997, http://nicewww.cern.ch/win95/acb/acb.htm
11A. Pace, “Using Windows 95 or Windows NT at
CERN”, CERN-UCO/97/195, February 1997,
http://nicewww.cern.ch/doc/usere/users.htm
andA.Pace, “Utilisation de Windows 95 ou Windows NT
au CERN”, CERN UCO/97/197, February 1997,
http://nicewww.cern.ch/doc/userf/userf. htm
12I. Deloose, "Integrating the New Generation ofISOLDE Controls into a Multi Platform
Environment", CERN-PS 96-44, PCAPAC96, Oct. 96,
DESY,
Hamburg,
Germany,
http://nicewww.cern.ch/ps/psco/report96-44.pdf
13I. Deloose, "Windows NT as Device Server for theISOLDE-REX Project", CERN-PSCO Note 97-27,
http://nicewww.cern.ch/ps/psco/note97-27.pdf
14I. Deloose, "Simultaneous access to the Controls ofthe PS & SL machines from the Windows 95 and NT
Platforms via PS & SL passerelles", CERN-PSCO
Note 98-33, http://nicewww.cern.ch/ps/psco/note9833.pdf
1516

See http://network.cern.ch/

See the chapter “Accounting Software usage” on
http://nicewww.cern.ch/doc/admguide/adswinse/
adswinse.htm for a description of the CERN
accounting strategy.