This page is frozen, 
actual one hereThe module <DAQGate> of subsystem "Data Acquisition"
| Module: | DAQGate |
| Name: | Gateway of the data sources |
| Type: | DAQ |
| Source: | daq_DAQGate.so |
| Version: | 1.7 |
| Author: | Roman Savochenko, Maxim Lysenko (2009) |
| Description: | Allows you to perform the locking of the data sources of the remote OpenSCADA stations in the local ones. |
| License: | GPL |
Introduction
The main function of this module is the reflection of the data of the "Data acquisition" subsystem of the remote OpenSCADA stations on the local ones. In its work, the module uses the self protocol of the OpenSCADA system (SelfSystem) and service functions of the subsystem "Data acquisition".The module realizes following functions:
- The reflection of the structure of the parameters of the subsystem "Data acquisition" of the remote station. The structure can be periodically synchronized while working.
- Access to the configuration of the parameters. Configuration of the parameters of the controllers of remote stations is transparently reflected that lets you to change it remotely.
- Access to the current value of the attributes of the parameters and the possibility of their modification. The values of the attributes of the parameters are updated at a frequency of execution of the local controller. Requests for modification of the attributes are transmitted to the remote station.
- Reflection of the archives of values of individual attributes parameters. The reflection of the archives is realized in two ways. The first method includes creating of the local archive for the attribute and its synchronization with the remote, the restoration of the archive at the stop of the station is provided. The second method is the translation of the requests of the local archive file to the one of the remote station.
- Messages reflection from selected data sources of remote station to local messages archive with prefix "{Station}:", include also alarms (negative level messages).
- Provides the implementation of the mechanism of the vertical redundancy as an opportunity to reflect data from the multiple stations at the same level.
- Realization of the functions of horizontal redundancy, namely, 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 of data
For addition of the data source the controller's object is created and configured in the system OpenSCADA. Example of the configuration tab of the controller is depicted in Figure 2.
Fig.2. Configuration tab of the controller.
From this tab you can set:
- The state of the controller, as follows: «Enable», «Run» and the name of the database containing the configuration.
- Id, name and description of the controller.
- The state, in which the controller must be translated at boot: «To enable» and «To start».
- The table for store of cache parameters, which next created also on data source miss.
- The acquisition schedule policy and the priority of the task of data acquisition.
- Recurrence interval of time of the attempting to restore a lost connection with the station in seconds.
- Maximum depth of data of the archive values and messages to restore when start, in the hours. Zero for disable archive access.
- Gather messages level from remote.
- The period of synchronization with a remote station in seconds. Zero for disable periodic synchronization.
- List of the reflected remote stations. Several stations in the list include a mechanism of vertical redundancy.
- The list of the reflected controllers and parameters. The list can be used as for controllers for the reflection of all their parameters, and for individual parameters too.
- The commands to go to the configuration of remote stations.
- Allow automatic remove parameters and attributes to fresh its current state. To the production mode you better disable the option!
2. Parameters
The module though provides the ability to create the parameters manually, but it does not make sense as a parameter in absence it on the server will be empty. All parameters are created automatically, taking into account the list of reflected controllers and parameters. The parameters can be stored into the cache for following its creation even on link to the server miss. Example of the reflected parameter is shown in Fig. 3.
Fig.3. Configuration tab of the reflected parameter.