ConSys – A CONTROL SYSTEM WITH A HIGH DEGREE OF
ABSTRACTION.
K. T. Nielsen, CERN, PS/OP
J. S. Nielsen, T. Worm, ISA, Institute for Storage Ring Facilities in Aarhus

1 INTRODUCTION
A new control system, ConSys, for the accelerators atISA, Århus has been developed1,2. The control systemfollows the standard model, as well as thepublisher/subscriber model3. The resulting system is ahighly modular control system based on object orientatedtechnologies.

2 THE ABSTRACT MODEL
The ConSys control system is designed in a highlyobject oriented structure. A very limited number of baseobjects define and implement the core functionality.
Devices are the interface between the controlled hardware
and the control system. Data servers register at devices
and serve as data transmitters between the device and theclients. Before a client can access parameters on thecontrol system it must send a data request to the system.
The data request must include an address specifying theparameter. For all data in the control system, a ConSys
data object is used as base class. All data transmitted
between computers by the transport object must be
descendants of the ConSys data object.

2.1 Parameters
When designing a control system it is very important todecide what the basic data unit for access in the systemshould be. Many control systems select a full device as
the basic access unit4, resulting in a large number ofobject types to maintain. For simplicity a small number ofbasic object types are desirable. These may afterwards be
combined into logical groups reflecting the hardware
structure. When the operators are operating the machine,
they tend not to operate on say a full power supply, but onfor example the voltage setting. The ConSys control
system acts on single parameters. A parameter may be avoltage setting on a magnet, or an on/off bit for a power
supply. As the value of a parameter is transmitted as adescendant object of the data value object, a great
flexibility in the contents of a parameter is possible. Most
parameters are of simple types, like floating and binary
values, but could as well be a full spectrum from a dataacquisition. As a rule the parameters on the system tend tobe as fine-grained as feasible.

2.2 Addressing
A central concept in the control system is thegeneralised address space. As the access method of theindividual hardware devices may vary greatly, the control
system must provide a uniform and flexible way ofaccessing parameters. To create a homogeneous control
system it is important to hide the details of parameter
access, and only make use of this knowledge in thedevices. The address object contains the informationneeded to access a parameter in the device. The address isfully qualified; there is no need for more information todetermine the location of a parameter. The base address
only contains information about the computer and thedevice. Any additional information is provided bydescendant classes.

2.3 Devices
The device object provides the abstraction between thehardware instrument drivers and the control system. The
device provides the real time database containing theparameters needed by theApplication
given device. Actual data
storage depends on thenimplementation. The base
Clientobjectdefines
abstract
methods
forreadingand1writing. An address object
Transport n
included with these methods
locates the parameter in then1
device.
Theobjectn
furthermore includes anData Server
abstract
methodfor0, 1
parameter
subscription.
Data servers may call thisDevice
method in order to register0, 1for subscription at thedevice. The device signals
NT Device Driver
the registered data servers
Figure 1: ConSys Object whenever data has changed
relationsin the device.
An important concept is a virtual device - a device
without direct connection to hardware. In the simplest
case, a virtual device is just a storage device for persistent
information. A more advanced use of the virtual device isintelligent data handling - that might be automation ofoperation or as special conversions between say physicalparameters and direct controls. In the lather case thevirtual device utilises the ability to connect to any
parameter on the control system, just as any other client
application on the system.

2.4 Data Servers
Obtaining and transmitting data to the client is done bydata servers. A data server may register itself at a device.
The device will signal the data server when data may
have changed. It is the responsibility of the data server todecide whether the data should be send to the client ornot. When a writing operation takes place, it is theresponsibility of the data server to ship the data to thedevice. The data server may also act as a agent for theclient, combining information from one or more device on
the behalf of the client. As the data server does notassume a connection to a device, a data server may startup other data servers or act as a client, to do complicatedtasks. As opposed to a device, a data server provides nopersistent storage.
To provide the control system with initialisation
information about the data servers a data request object isused. The data request includes information about thetype of data server to load, and from which library to getit. The object may also contain a reference to an instanceof the address object. This allows the data server to accessa device. The request also contains a handle to uniquely
identify data received and transmitted by the data server.
Descendant objects may add additional information usedby the data server, such as criteria for transmission of data
to the client.

2.5 The ConSys Client
Applications interface to the control system through theConSys client object. This object provides a small but
powerful set of methods to be used by the client program
to gain access to the control system data. On creation theclient is supplied with a data request. Based on the data
request the client will create all necessary connections.
Most programs will only use two methods provided by
the client - one for writing data to the system and one tohandle data arriving from the control system. Internally in
ConSys the data servers and devices are important usersof the client object.

handle in order to let the system send the data to thecorrect destination.
In figure 1 the relations between the important objects
in the ConSys control system are drawn. An application
may create as many client objects as it wants, dependingon the structure of the application. Each client then opens
a transport layer, which in turns creates a single dataserver. The specific type of the data server depends on therequest specification. The data server may create as many
helper data servers or new client objects as it needs. It
may also connect to a single device. A device may create
as many client objects it wants. If the device is a virtualdevice it will not connect to a device driver. If the device
is controlling hardware, it connects to a single device
driver. The figure 1 illustrates the fact that the control
system is its own best client, with data servers anddevices acting freely as clients on the system in parallelwith access from other applications.

3 IMPLEMENTATION
In order to take advantage of the huge amount of goodand cheap software and hardware available for PC‘s,
Windows NT is used as platform for ConSys. To reduce
development time and cost the ConSys only runs on theWindows NT platform. Note that this is true for front-end
computers as well as client computers. Having chosen thesame operating system on all machines has given apossibility for a very high degree of symmetry in thesystem. In fact it has been possible to use the same corecode on front-ends and clients, which has greatly
increased simplicity, reliability and flexibility of thesystem.
To a large extent ConSys uses the possibility to set
process and thread priorities. As the overhead of having
many threads running on a system is insignificant, thecontrol system uses a large number of threads at manydifferent priorities to optimise the response time. Theresult is that the system can take a very high load before
the user starts to see a significant performance penalty.

3.1 Name space
2.6 Data objects
The base of all data transmitted in the control system is
the ConSys data object. Although the object can betransmitted on the system, it is the two descendant objects
that are used. The first descendant object is a messageobject, which acts as base object for all messages. The
other descendant is the data value object. This object isthe base object for all parameter information exchangedin the system. In order to distinguish the origin of the datain the control system, the data value objects has a uniquehandle attribute defined by the client in the request. Alldata arriving as a result of a given request is tagged withthis handle. The handle is especially used when therequest results in access to more than one parameter.
Likewise data send to the control system must include a

An identification triplet defines parameters in logicalrelated groups: machine.name.sub-name. The machine
identifies the accelerator to which the parameter belongs.
The name identifies a group of related parameters, i.e.
parameters controlling a given piece of equipment. The
sub-name identifies the individual parameters for thepiece of equipment. Although the triplet usually reflects
the hardware structure, there are no assumptions made by
the control system.

3.2 Establishing a data connection.
For accessing single parameters, simple requests foreach data type exist. Requests include an address andinformation needed to dynamically create the associateddata server. To access more than one parameter from asingle client a packet request is implemented. The packet
request has a list of requests. This list can contain requestof any type - for example other packet requests to create
nested structures. The packet request is closely related tothe packet data server. The packet request specifies
creation of a packet data server. When this special dataserver is created it splits the request list into separate
packet requests depending on destination front-end. For
each of these single front-end requests a new client iscreated. If one of these clients detects a request containing
requests for the local computer it creates the specified
data servers. All other clients contain request for remotecomputers. These clients create a transport to thespecified machine and send the request to the ConSys
kernel on this machine. On the remote machine yet
another packet server is created, now only containing
local requests. This packet server collects data from thelocal data servers on the front-end in the context of its
own thread and routes them back to the original dataserver on the calling machine.
ConSys data is transmitted between computers using an
instance of the transport object. The base transport object
only has a few general methods used to handle thecommunication. It can be created in two modes - either asa server or as a client. When a client in ConSys wants
access to a remote computer, it creates an instance of thetransport in client mode with a specification of the nameof the remote computer. During the creation, the transport
object tries to establish a connection to the specifiedcomputer. If the transport reported a successfulconnection, ConSys data can be transported over thetransport using the serialisation operators for reading andwriting.

3.3 Database
All machine dependent information for the control
system is stored in an ODBC compliant database – at ISAthe Microsoft SQL server 6.5 is used. For performancereasons the object-oriented structure of ConSys cannot be
represented directly in a relational database, instead
generalised tables with free fields are used.
In general, the database tables used to construct ConSys
objects of a given type contain the attributes of the baseobject and a number of generalised fields used for theconstruction of descendants to the base object. Helpertables in the database describe the actual use of thegeneral fields for a given object. With the helper tables, it
has been possible to develop an object oriented database
editor reflecting the object structure of ConSys.
As an example, a parameter definition in the parameter
table includes the informations needed for thecorrespondent address object: An address type field
identifies the address object associated with theparameter, computer name and device identification
number fields contain information needed to initialise thebase part of the address object. The additional informationneeded to initialise the given address object is stored in aseries of general-purpose integer and string fields in theparameter table. The actual use of these fields is describedin a helper table for the address objects in the controlsystem.
The parameter table furthermore specifies theinterpretation type of the parameter. The interpretation
type is a combination of three related parameter attributes- the data type, the conversion type and the display type.
The data type identifies the data objects known by thecontrol system. Each data object type has at least one
conversion object type and one display type. The ConSys
devices on the front-ends may utilise the conversion
objects to convert between native values and physicalvalues. The display type gives the client application
knowledge on how to display the parameter data. The
valid combinations of data types, conversion types anddisplay types are hardwired into the ConSys code andreflected in the database by a table maintained by theprogrammers.

3.4 Dynamic object load
An important mechanism in the control system is theability to dynamically create instances of objects. By
supplying the system with the name of the class and the
dynamic link library, the system is able to create an
instance of the class. This method is used to create thevarious components of the control system. The transportlayer, database interface, and the devices are created atstart-up of the control system. Likewise the data servers isdynamically created as specified by the client request.
This ability to dynamically add and configure the system
without re-compilation has proved a great advantage.

5 CONCLUSION
The object-oriented approach has resulted in a highly
flexible and modular design, where front-end and clientcomputers have identical core software. The limited
number of base objects, the central database for all
machine dependent information and the possibility ofloading and creating object instances dynamically has
lead to a site and machine independent control systemthat is easy to maintain.

REFERENCES[1] J.S.Nielsen K.T.Nielsen and T.Worm: “ConSys – A
new control system for ASTRID and ELISA”,
TUP46G, EPAC98.
[2] www.isa.au.dk/conSys/[3] Christof Fetzer, “Fail-Aware Publish/Subscribe
Communication in Erlang”, Fourth International
Erlang User Conference 1998
[4] Jie Chen, Graham Heyes, Walt Akers, Danjin Wu,
Wiliam A. Watson III: “CDEV: An Object-OrintatedClass Library for Developing Device Control
Applications”, ICALEPCS 1996 proceedings