Modules/DAQGate

Main function of this module is the data reflection of the subsystem "Data acquisition" of the remote OpenSCADA stations on the local ones. In its work, the module uses the OpenSCADA self protocol (SelfSystem) and service functions of the subsystem "Data acquisition".

The module realizes following functions:

• Reflection of the parameters structure of the subsystem "Data acquisition" of the remote station. This structure can be periodically synchronized while working.
• Access to the parameters configuration. Configuration of the controllers parameters of the remote stations is transparently reflected that lets you to change it remotely.
• Access to the current values of the parameters attributes and the possibility of their modification. Values of the parameters attributes are updated at a periodicity of execution of the local controller object. Requests for modification of the attributes are transmitted to the remote station.
• Reflection of the value archives of individual attributes of the parameters. The archives reflection is realized in two ways. The first method includes creating of the local archive for the attribute and its synchronization with the remote one, at the same time, there provided the archive recovering at the time of the remote station's inaccessibility. The second method is the translation of the requests of the local archive to the one of the remote station.
• Messages reflection from selected data sources of the remote station to local messages archive with the prefix "{Station}:", including violations (negative reports).
• Provides implementation of the vertical redundancy mechanism as an opportunity to reflect data from the multiple stations at the same level.
• Realization of the horizontal redundancy functions, that is working in the conjunction with the remote station of the same level.

Using of the available redundancy schemes is graphically represented in Figure 1.

Fig.1. Horizontal and vertical redundancy.

1 Controller object

To add a data source a controller object of OpenSCADA is created and configured. An example of the configuration tab for a controller object of this type is shown in Figure 2.

Fig.2. Configuration tab of a controller object.

With this tab you can set:

• State of the controller object, that is: status, "Enabled", "Running" and the database name containing the configuration.
• Identifier, name and description of the controller.
• The state "Enabled" and "Running", in which the controller object must be translated at start up.
• Table of the parameters cache storage those are created even when the data source is not available.
• Acquisition schedule policy and priority of the data acquisition task.
• Time interval of repetition attempts to restore communication with the lost station, in seconds.
• Maximum depth of data of the archive values and messages to restore when start, in the hours. Zero for disable the remote archive access.
• Level of requested messages of the data sources.
• Period of synchronization with the remote station, in seconds. Zero for disable the periodic synchronization.
• List of the reflected remote stations. Several stations in the list enable the vertical redundancy mechanism.
• List of the reflected controller objects and parameters. The list can be used as for controller objects for the reflection of all their parameters, and for individual parameters too.
• Command to go to configuration of the remote stations list.
• Allow the automatic removal of parameters and attributes to update to the actual state.

In the production mode, it's better to turn this off!

2 Parameters

The module, though, provides the ability to create parameters manually, but it is meaningless, since such a parameter, in the absence of it at the remote station, will be empty. All parameters are created automatically, taking into account the list of reflection controller objects and parameters. Parameters can be stored in the cache for subsequent creation even in the absence of communication with the remote station. An example of a mirrored parameter is shown in Figure 3.

Fig.3. Configuration tab of a reflected parameter.

3 Notes

In work with this module, in general, the following order is recommended:

• For the time of active development, and thus to change the parameters structure of the remote station, it is necessary to enable synchronization with intervals of 60 seconds and to allow the deletion of parameters and attributes.
• Before starting up in the production, you need to: disable synchronization, by interval 0, prevent the removal of parameters and attributes, and save the current parameters structure by saving the controller object. This is to minimize traffic and load the remote station for the exchanging, which is especially important for high-loaded PLC, since synchronization, although it distributes the synchronization of individual parameters by the cycles of the exchange, but still is a resource-intensively function.
• Performance of service changes of the structure should be carried out as follows:
  • the parameters structure of the remote station changes;
  • synchronization is enabled, its period of 10 seconds is set;
  • these 10 seconds are expected to be synchronized and checked for execution, by the changes presence;
  • synchronization is disabled, its period of 0 seconds is set;
  • the mirrored parameters structure is saved, while the controller object of the gateway is stored.