Data Sharing in a Client/Server Environment

VTScada benefits from a well-tested Remote Procedure Call (RPC) system, which manages inter-server communications (from one VTScada server to another). Advanced users who are trying to write code to manage I/O synchronization or alarm evaluation are advised to look first to this built-in system.

 

VTScada is composed of many independent modules that run locally. The RPC system ensures that information about those modules is synchronized between servers and that only a single machine can act as the server for a service at any time.

 

For example, many modules run as tags. The RPC engine guarantees that their stored parameters are synchronized among the machines in the server list. Variables that are not defined as parameters are not synchronized unless they are registered with their own RPC service or use the service provided by another module such as a driver.

 

Consider a typical example of an I/O tag as it requests and then displays a value:

  1. The I/O tag asks the attached driver to provide the value associated with a given address.
  2. The driver requests that value using its own process, which is usually a protocol exchange with an external device such as a PLC.
  3. This request operation takes place only in the server currently assigned to the driver’s RPC service. (The current primary server for the driver.)
  4. After the request operation, the driver calls the standard VTSDriver service, which updates the local tag through direct assignment.
  5. The VTSDriver service then sends an RPC update message to the instances of this driver service on all other connected servers.
  6. Those update their local instances of the requesting tag, thus assuring that the same tag reports the same value on all servers.

 

This process and more is shown in the following illustration. It assumes that one machine is currently the server for all communications, historian and alarms. A dashed arrow means that the request will be usually ignored, while dash-dot means it will be ignored on pure clients:

RPC process for I/O, logging, alarms and alarm notifications

 

Let's continue this example by considering both logging and alarms.

 

If the I/O tag has an attached Historian, and if it decides that the new value is to be logged (the change is greater than the deadband or a set time period has elapsed) then the I/O tag will ask the Historian to log the value. Because all instances of the tag, running on different servers, receive the same data, and have no knowledge of the source of that data (direct communication or RPC broadcast), they are all going to request the Historian to store the value and timestamp. Conflicts are avoided because the Historian has an RPC service of its own. It will only perform data authoring if it is running on the current primary server for the Historian service. The action proceeds as follows:

 

The Historian running on the current primary server will write the data to the configured data store.

Following the write, it will send an RPC broadcast message to all other historian servers, which will store a copy of the written data, rather than the version sent by the local I/O tag. This guarantees that it will be assigned the same timestamp on all servers, thus avoiding duplicate records.

 

If the new I/O value changes the alarm status, then a parallel task will run, either inside the I/O tag or through a connected alarm tag. This task will evaluate the value locally on all machines by calling the Alarm Manager, which also runs an RPC service.

The alarm status returned by the tag itself will be defined locally. The alarm event will be raised by the Alarm Manager, but only on the current alarm server. Like the Historian, it will record an alarm event to the database and broadcast that to all other servers.

A significant difference from the process used for logging I/O data is that Alarm Historian tags are usually configured to enable Client Storage. This means that all clients act like backup servers, regardless of whether they are included in the server list. They will always receive new alarm records from the current primary server and will try to log those events themselves if unable to communicate with the server.

 

The VTScada Alarm Notification System also uses its own RPC service and is based on the alarm event records stored by the Alarm Manager. Notification behavior is synchronized across the network based on the status currently defined on the database.

 

For more information about VTScada's Remote Procedure Call service, see: RPC Manager Service