TINE: An Integrated Control System for HERA
Philip Duval, DESY, Hamburg Germany

Abstract
Beginning with the 1998 run period, the PCdominated control system for HERA is largely in place.
Most elements of the machine are controlled via theTINE (Three-fold Integrated Network Environment) data
protocol. TINE offers a multi-platform, multi-protocol,multi-architecture control system. It features distributed,object-based, plug-and-play, front-end devices andmiddle layer servers which communicate directly withconsole (and office) computers. Although the consolesin the HERA control room all run WINDOWS NT, theHERA front end computers and servers run a wide
variety of operating systems and are not always PCs.
TINE has been invaluable in integrating the HERA front
ends into a working system. Furthermore, it offers atransparent way to progressively upgrade existing
hardware (as opposed to replacing everything at once).
We describe below some of the finer points and details
concerning TINE as a control system.

1 INTRODUCTION
For the most part, TINE defines a data-exchange
protocol, which can be used as the basis for a controlsystem. As a control system proper, it is “do-it-yourself”
oriented. That is, it is assumed that a hardware-near dataacquisition system is in place on the relevant front-enddevices. At DESY for instance, the in-house field-bus
SEDAC is in common use, as are the CAN bus andGPIB. There are well-defined drivers and APIs for eachof these, which provide a hardware IO layer for TINE
here. Continuing the “do-it-yourself” discussion, wenote that all redundancy and fault tolerance should beadded where needed. Furthermore, as the ethernet is thedata-exchange medium, it should be noted that missioncritical devices should never depend absolutely on
communication with other elements on the ethernet.
Likewise, it should be noted that TINE has been seen toscale to machines the size of HERA without anyproblems.
TINE follows the traditional “Client-Server”
dichotomy, where the control system elements playeither the role of (and have the characteristics of) aserver or a client. Servers can be attached to hardware(Front End Computers – FECs) or can provide middle
layer services. They have unique names and addresses
and are known on the net via database or name server(i.e. they do not broadcast their services). Clients are“anonymous” and can exist in multiple instances

anywhere on the network. By this, we mean that clientsare nowhere entered in a database, and several clients
can appear bearing the same name. (Each computer on
the ethernet must of course have a unique address).
Clients find Servers by querying either the name serveror the database. Finally, TINE is not database-driven,and does not require any central database forconfiguration.

2 THREE-FOLD INTEGRATION
Perhaps the most distinguishing feature about TINE is
its integration of client and server components of vastlydifferent networking environments. To begin with,
TINE is a multi-platform system, running on MS-DOS,
Win16 (Windows 3.X), Win32 (Windows 95,98, NT),
most UNIX machines, VAX and ALPHA VMS, andVxWorks. TINE is also a multi-protocol system to theextent that IP and IPX are both supported as dataexchange protocols. Finally TINE is a multi-control
system architecture system, allowing client-server,
publisher-subscriber, and producer-consumer dataexchange in any variation. We shall describe these in
more detail below.

2.1 Multi-Platform
TINE runs on a number of platforms as illustrated in
the table below. At HERA, the de-facto console platform
is Windows NT (Window 3.1 in earlier years). All
manner of front-end platforms are in use, but theindividual sub-system laboratories (e.g. the RF group)
stick to their preferred platform for all sub-systemcomponents. There is sometimes a point to using thesame platform for console as for front end. In such cases,
the console application can then run directly on the frontend to aid in system diagnostics and trouble shooting.
Where this is not the case (either not possible or notpractical), one needs to either have an available console
in the general vicinity of the front end, or separate
diagnostic tools available on the front-end platform.
Note also that by allowing a heterogeneous system,
expensive front-end hardware can be used wherewarranted (for mission-critical devices) and inexpensive
hardware used elsewhere. Furthermore a systematic,
piecemeal upgrade of a control system is possible, since
TINE will run fine on older systems such as VAX-VMS
and MSDOS as well as the more modern systems such as
Window NT, Solaris and VxWorks.

OSDOS
Win16
Win32
LinuxSolaris
HP-UX
SGIOSF
VAX-VMSALPHA-VMS
VxWorks

IP Stack
LWP or Client32
WINSOCKWINSOCKNative BSD
Native BSD
Native BSD
Native BSD
Native BSD
UCX
MULTI-NETNative BSD

IPX Stack
NOVELLNOVELLWINSOCKNative BSD-Table 1: TINE Platform and Protocol support

2.2 Multi-Protocol
TINE supports both IP and IPX ethernet protocols. As
seen from the above table, the IP protocol is generalavailable across all platforms, whereas IPX is available
primarily on PC systems (DOS, Windows, Linux).
Where necessary, IPX could also be ported to the otherplatforms. However, an IPX-stack must be obtained andinstalled separately, as it is not in the standard systemkernels for these cases.

2.3 Multi-Architecture
TINE supports three modes of data exchange, each ofwhich could be used to define the control systemarchitecture.
Client-Server: A traditional data exchangemechanism available in most control systems is pure,synchronous client-server data exchange, where a client
makes a request and waits for the completion of therequest. This is not only traditional, but necessary whensending commands to a front end, where the next action
to take depends on the outcome of the command.
Publisher-Subscriber: For many cases, a much better
approach is the publisher-subscriber data exchange.
Here a client (the subscriber) communicates its request
to a server (the publisher) and does not wait for aresponse. Instead it expects to receive a notification
within the timeout period. This can be a single
command, or for regular data acquisition it can be arequest for data at periodic intervals or upon change ofdata contents. In this format, the server maintains a listof the clients it has and what they are interested in.
Producer-Consumer: A third alternative for dataexchange is the Producer-Consumer model. In this casea server is the producer. It transmits its data via
broadcast on the control system network. Clients (i.e.
consumers) simply listen for the broadcasts. This isfrequently the appropriate data transfer mechanism. For
most control systems, there are certain parameters which
are of system-wide interest. At HERA for instance, theElectron and Proton beam-energies, beam-currents,
beam-lifetimes, etc. are made available via system
broadcast at 1 Hz. Such read-only, machine parameters

are of vital interest to a large number of runningapplications and front ends.

3 MECHANICS
3.1 Equipment Modules
TINE is object-based, where TINE servers contain one
or more equipment modules, which are designed topresent an object-view of the equipment being controlled.
These equipment modules have system-wide unique
export names and contain one or more instances of theequipment, defined by device names. Furthermore
equipment modules support device properties, whichreflect the equipment operation.
TINE clients contact a particular device by specifying
the equipment module’s export name and the device
name. The nature of the request is specified by thedevice property.
In Producer-Consumer mode, on the other hand, aserver makes registered data available via broadcast. In
this case a client simply listens.

3.2 Plug-and-Play
A TINE server registers its address, server name andits equipment module names with the equipment nameserver upon startup. A TINE client can then query theequipment name server for names and addresses (andcache the results). As persistent timeouts have the effectof forces an address (re-)resolution, one can take a TINE
server down, and bring it up on another machine (andprotocol!), without the necessity of restarting a client.

3.3 Data Exchange
TINE data requests can consist of up to 64 Kilobytes
of data in either direction (client to server and/or server
to client), both in synchronous as well as asynchronoustransfer modes. There are currently 38 defined systemdata formats, and it is also possible to specify userdefined structures. The latter must be registered at boththe client and server if, it automatic byte-swapping andalignment is to take place.

3.4 Security
As noted above, TINE servers are registered with theequipment name server, which constitutes the control
system database. TINE clients on the other hand areanonymous in this respect.
A TINE server isfundamentally open to access from any a client
anywhere on the ethernet. A specific data request canhowever carry a WRITE access bit, which can in turn befiltered against at the server side. Namely a TINE server
can allow WRITE access only to specific users, and/or
only from specific networks, or network addresses.

3.5 Alarm System
As most alarms ultimately originate during hardware
or service IO operations, it is most natural to locate thefirst layer of alarm processing directly on the front-end.
It is at this level that certain characteristics of the alarm
are best determined, such as whether the alarm isoscillating (comes and goes) or whether it is time for a“heartbeat” message, etc. Furthermore, as TINE isclient-server oriented, where clients are anonymous (i.e.
have no systematically known identities), a server doesnot “send” its alarms anywhere. Instead, it maintains a
local alarm list containing all the relevant information
about each alarm. Clients can then at any time query aserver, i.e. the Local Alarm Server (LAS), as to its alarmstate. The primary client for all local alarm servers isthe Central Alarm Server (CAS), where the next stage ofalarm processing takes place. See reference [2].

3.6 Archive System
The current implementation of TINE at DESY uses anexternal archive system, which acquires and provides
data based on the TINE protocol. It is planned for thenext release of TINE to provide a local archive server,whereby short and long term histories of selected data
can be maintained at the device server.

3.7 Remote Control
TINE offers a good set of remote control and restart ofserver processes for most platforms. The principal
deficiencies exist in the Windows world and the VMSworld. The next TINE release should also be able tooffer better remote services for these platforms [2].

4 CONCLUSIONS
The flexibility of TINE has been invaluable inintegrating the HERA front ends into a working system.
Just as important, it has demonstrated a transparent way
to progressively upgrade existing hardware. Where forpractical reasons the latter must remain on “older”
platforms and operating systems, TINE servers cannonetheless be installed and maintained. When it
becomes practical to “modernize” front-end elements,
this can be achieved piecemeal, without any blanket
restructuring. The implementation of TINE at DESY isPC-dominated. Although TINE works fine in say a pureUNIX world, the number of GUI tools developed for PC
consoles running Win32 make the latter (currently) themost attractive platform on the client-side.

REFERENCES[1] M.Bieler, et al., “PC Based Alarm System for theHERA machine”, these Proceedings.
[2] P.Duval, “The TINE Users Manual”, DESY internal
document.