CS Communication Layer

Introduction

Starting with release 3.0, the communication layer of CS has been redesigned.

CS prior version 3.0

Older versions of CS used communication based on LabVIEW message queues and notifications. Messages were sent one-to-one, from exactly one caller object to exactly one receiver object. In order to send messages across the network, the format "objectname@nodename" was used to identify the object and the node. As a result, the communication layer of CS prior version 3.0 had the following drawbacks:

• For implementing a publisher-subscriber mechanism (one-to-many), the caller object (publisher) had to send a separate event to each subscriber. This resulted in a large overhead for the run-time performance and especially for registering/unregistering of clients.
• It was almost necessary to have the DSC engine of LabVIEW. Quite often, the DSC engine was (mis?)used as a kind of central event manager resulting in poor performance of a distributed system (each event had to be sent twice!).
• It was necessary for the caller to know, if the receiver expected the event via a message queue or via a notification.
• When sending events across the network, the TCP/IP implementation of LabVIEW showed poor performance. The situation has improved with the advent of LabVIEW 8, but is still not completely solved. Obtaining a reasonable performance with LabVIEW TCP/IP requires some tricks.
• The naming convention "objectname@nodename" restricted the number of CS systems per node to one system.
• When sending an event to an object, it was necessary to "know" on which node the object was situated.
• The possibility of having an object with the same name on more than one node resulted in frequent confusion.
• No access mechanism was implemented. An access mechanism is required, if a user wants to have exclusive access to, as an example, the power supplies of a beam-line.

CS version 3.0 and above

New versions of CS use a publisher-subscriber pattern. A publisher (server) publishes data (a service) across the network. Many subscribers (clients) may subscribe to the service and receive data whenever the service is updated. This is a one-to-many relationship. In addition a client may also send a command to a server. This is a one-to-one relationship. The publisher-subscriber pattern is intended to work across the network. This implies, that a service is named and that the name of a service is unique across the network. This has the following advantages:

• There is no need for implementing a publisher-subscriber mechanism within CS, it is provided by the communication layer itself. Also setting up and reconnecting connections between clients and server is taken care already in the communication layer. As a result, the communication within CS becomes much simpler.
• The DSC engine of LabVIEW is no longer required as a central event manager, since the publisher-subscriber pattern of the communication layer takes care of distributing data. The DSC engine becomes what it is intended for: It is just the SCADA backend and provides connectivity to OPC.
• A client sending a command no longer needs to know, if the server expects the command via a message queue or via a notification. The client just sends the command.
• The TCP/IP implmentation is encapsulated in the communication layer.
• When sending a command, it is just sent to "objectname". The communication layer takes care of finding the right node.
• One can have many CS systems per node.
• An object is unique in a distributed system. Having two objects with the same name is longer possible ("Inherent Singleton Functionality").
• An access mechanism is much easier to implement using the publisher/subscriber pattern.

DIM

The communication layer for CS is DIM. DIM has been developed at CERN and is provided under the terms of the GNU Public License. DIM is well maintained and tested. DIM provides excellent performance in terms of event rate and throughput; no tricks are needed as in the case of LabVIEW TCP/IP. DIM uses peer-to-peer connections and avoids the bottle neck of a central event manager. DIM is provided for many operating systems and hardware platforms. DIM can be used to manage abouth 1,000,000 process variables. For more information about DIM, have a look at the DIM website.

A LabVIEW interface for DIM has been developed at GSI and is used for CS.

DataSocket

DataSocket is provided together with LabVIEW by National Instruments. Compared to DIM, the performance in terms of event rate and throughput is reduced by a factor of about 3-10. DataSocket requires a central DataSockt server, which implies a central event manager as a bottle neck. The number of process variables that can be maintained with DataSocket can be up to a few thousands. DataSocket is limited to platforms supported by National Instruments. The only reason for using DataSocket with CS is, that DIM is not supported on the PharLap OS used by LabVIEW RT.

We have implemented a wrapper around DataSocket. The wrapper has exactly the same interface (connector panes etc.) as the LabVIEW interface for DIM. Thus, our DataSocket wrapper can be used in place of our LabVIEW interface for DIM. By this, DataSocket can be used as the communication layer of CS without changing anything inside CS.

DIM - DataSocket Gateway

DataSocket is required on LabVIEW RT platforms but DIM is the communication layer choosen for CS. Of course, we have developed a "DIM - DataSocket Gateway". This gateway does the following:

• It subscribes to services published via DataSocket and re-publishes them in DIM.
• It receives commands sent via DataSocket and resends them to DIM.
• It subscribes to services published via DIM and re-publishes them in DataSocket.
• It receives commands sent via DIM and resends them to DataSocket.
• In all cases, it takes care of avoiding loops. As an example, a command is not resent via Datasocket->DIM->DataSocket->DIM->...
• The gateway is completely transparent.

To conclude, CS systems using DataSocket as communication layer can communicate with normal CS systems using DIM as communication layer. By this, even mixed systems (DataSocket, DIM) can form a homogeneous, distributed control system.

Remarks

Starting from LabVIEW 8, National Instruments has introduced so-called "shared variables". Although they provide a lot of features, we have conducted tests to measure their performance (throughput, event rate, maximum number of "process variables") compared to DIM. As a result, DIM is definitely the protocoll of choice when thinking about scaling to larger systems with high performance. If required, and one is willing to take into account the drawbacks of the "shared variables", one could write a wrapper library for the shared variables and use the shared variables as communication layer for CS.

-- DietrichBeck - 27 Jun 2006