From OpenSCADAWiki
< Modules
| Module | Name | Version | License | Source | Languages | Platforms | Type | Author |
|---|---|---|---|---|---|---|---|---|
| DAQGate | Gateway of the data sources | 2.13 | GPL2 | daq_DAQGate.so | en,uk,ru,de | x86,x86_64,ARM | DAQ | Roman Savochenko Maxim Lysenko (2009) — the page initial translation |
| Description | ||||||||
Allows to locate data sources of the remote OpenSCADA stations to local ones.
| ||||||||
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 and service functions of the subsystem "Data acquisition".
The module realises the following functions:
- Reflection of the parameters structure of the subsystem "Data acquisition" of the remote station. This structure can be periodically synchronised 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 realised in two ways:
- means the local archive creating for the attribute and its synchronisation with the remote one, at the same time, there provided the archive recovering at the time of the remote station's inaccessibility;
- means 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 (the negative level). The initial synchronisation procedure involves in general:
- requesting for all active alarms;
- requesting for messages of the specified sources on the depth specified by the parameter "Maximum depth of data of the archive values and messages to restore when start" and up to the time of the previous request, so all new alarms won't definitely appear;
- coming to the normal mode of tracing new messages and alarms about the specified sources.
- Provides implementation of the vertical redundancy mechanism as an opportunity to reflect data from the multiple stations at the same level.
- Realisation 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.
Contents
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 storage name containing the configuration.
Manual restart of the enabled controller object causes the force resync at the sync period >= 0.
- Identifier, name and description of the controller.
- The state "Enabled" and "Running" in which the controller object must be translated at start up.
- 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.
- Asynchronous writing. Enables of writing in the common acquisition cycle for the buffer of accumulated values, by one request.
- Useful for slow and not reliable networks-connections since the writing buffer stores data before the connection restore and the real writing.
- Level of requested messages of the data sources. Also enables the DAQ-messages of the User API function messSet() transferring to the lower stations.
- Synchronization time with the remote station in seconds. Zero to disable the periodic sync and -1 for the sync disabling at the start also.
- Remote OpenSCADA station of the reflected data. 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 OpenSCADA 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!
- Placing different controllers to the different virtual parameters.
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 the periodic synchronisation (by interval 0) or at the start also (by interval -1), prevent the removal of parameters and attributes and save the current parameters structure by saving the controller object. This is to minimise traffic and load the remote station for the exchanging, which is especially important for high-loaded PLC, since synchronisation, although it distributes the synchronisation of individual parameters by the cycles of the exchange, still is a resource-intensively function.
- Performance of service changes of the structure should be carried out as follows:
- change the parameters structure of the remote station;
- set the sync periodicity to 0, if was set -1;
- restart the controller object, that is toggle the state "Running";
- wait for the sync finish, that is disappearance from the controller object state for "Sync".
- return back the sync periodicity to the previous value;
- save the mirrored parameters structure by storing the controller object of the gateway.