From OpenSCADAWiki
Jump to: navigation, search
Translate this page
Other languages:
English • ‎mRussian • ‎Українська
  • Author: Roman Savochenko
      Maxim Lysenko (2010) — the page initial translation

Data acquisition of the SCADA (Supervisory Control and Data Acquisition)-system is its integral part, which get data from sources of different type. The nature of data, which operates SCADA, is characterized by signals of basic value's types (Integer, Real, Boolean and String). The signals vary over time and has their history — life. In the theory of technological processes (TP), under the signal means the value of TP sensor in the ADC code — "raw" signal or in the real value — engineer one. Signals can be combined in groups, which are often called parameters or complex tags. For example, the advanced data sources can provide the structures of parameters with the predefined set of related signals. In addition to the direct data acquisition, to the function of this mechanism also includes the transfer of actions on the executive control devices of TP, usually it is: latches, pumps and control valves. Taken together, this equipment is known as Matching to Object Device (MOD).

Data sources are characterized by a large variety, which can be divided in three groups:

  • Sources of "raw" data, providing the ADC code or levels of discrete signals, and also the sources which include simple processing. Typically, these are modules of distributed MODs or simpler industrial programmable logic controllers (PLCs).
  • Powerful industrial PLCs, which have significant computing power and the possibility of formation of complex parameters with different structure.
  • Local or related data sources. For example, the MOD as expansion cards, and also the data of the environment of hardware and software in which the system operates.

The variety of data sources has created a wide range of mechanisms to access them. Local data sources are different in application programming interface (API), and network sources, in their turn, in transport and protocol interaction level. In general, this has led to the fact that the addition of support for a new data source requires the creation of interface module or driver. Taking in account the great variety of sources, it is extremely expensive and actually impossible to cover the entire spectrum of the market of these devices. The situation is somewhat simplified with the network source due to the presence of the number of standard and free interaction protocols, but many sources still use their own protocols: private, commercial or protocols, tied to private mechanisms of the commercial operating systems (OS).

In terms of OpenSCADA, the following objects of the data model to serve the data acquisition mechanism are provided:

  • "Attribute" — reflection object of the signal data, includes the current value of the specified type of signal and access to the history of the change of these values;
  • "Parameter" — object of the attributes' group with the structure corresponding to the characteristics of the separate data source;
  • "Controller object" — object of the separate data device. Typically, this is a separate MOD module or a device of industrial PLC.

To account the features of different data acquisition devices, as well as the different mechanisms of interaction, in OpenSCADA the modular subsystem "Data acquisition" is provided. The module of the subsystem is the driver for interfacing with a data source of specific type. Each module can contain the configuration of several devices of this type as controller objects. The general scheme of objects of "Data acquisition" subsystem is shown in Figure 1.

Fig. 1. Scheme of the subsystem "Data acquisition".

1 Data acquisition methods

Taking in account variety of the data sources, and also the ways of their possible interaction, the data acquisition methods can be divided to: simple synchronous, simple asynchronous, package and passive ones.

In the review of the mechanisms below, the following objects will be involved:

  • "ObjectSCADA" — any object of the SCADA-system, which refers to the value of the signal, such as archives and visualizers;
  • "DAQParamAttribute" — parameter attribute of the subsystem "Data acquisition", which is an intermediary for access to the value of the data source signal;
  • "DAQParamAttributeArch" — object of the attribute's archive;
  • "HardwarePLC" — data source object, for example, modules of the allocated MOD or industrial PLC.

1.1 Simple synchronous acquisition mechanism

The mechanism is characterized by requests to the data source synchronously with the request to the parameter attribute (Fig. 2). This mechanism is usually used when working with local data sources, characterized by low latency, i.e. delay in response to the request. With this method you can get actual data directly with the request, but the time of the request of the object will include the time for transportation and processing of the request by the data source.

Fig. 2. Diagram of the sequence of interaction with the synchronous requests.

In accordance with the diagram above, we obtain the following sequence of requests for data acquisition and their transfer:

  • object of the SCADA-system sends the value request to the object of the parameter attribute DAQParamAttribute::getVal();
  • object of the parameter attribute, receiving the request, sends it to the data source HardwarePLC::valueRequest();
  • data source after processing the request returns the result;
  • object of the parameter attribute, receiving the result, returns its to the SCADA-system object.

In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":

  • JavaLikeCalc — calculator on the Java-like high level language. As a data source, a user program in a Java-like language acts. Parameter attributes of the module synchronously address the inputs/outputs of the computing context of the user function.
  • LogicLev — module of the logical-level parameters of the data acquisition, see more about it in section 3. As the data source of this module stand other parameters of the subsystem "Data acquisition" and the execution context of the parameters template. parameter attributes of the module synchronously address the attributes of other parameters in the reflection mode of the parameters of the subsystem "Data acquisition", or the inputs/outputs of the execution context of the template when work under the template.
  • BlockCalc — calculator in the language of block diagrams. As a data source, the user block diagram is stood. Parameter attributes of the module synchronously address the inputs/outputs of the blocks of block scheme.
  • DAQGate — module of the reflection of the controller objects of the remote OpenSCADA-stations on the local one. In the module the synchronous mode for recording data is implemented.
  • ModBus — module of the accessing to the sources data through the ModBus protocols family. In the module the synchronous mode for recording data is implemented.
  • DiamondBoards — module of the data accessing of the PC/104 cards of the Diamond Systems company. PC/104 boards are available on the ISA-bus, hence are local and available relatively quickly. When data acquisition is made not by interruption the access to the values of the ADC is synchronous. Recording mode of the DAC values always works synchronously.

1.2 Simple asynchronous acquisition mechanism

The mechanism is characterized by requests to the data source, regardless of the request to the parameter attribute (Fig. 3). Usually, requests to the data source are made periodically in own polling task of the single taken controller and with the blocks of several signals. This request to the parameter attribute returns the value obtained from the last connection session with the data source. This mechanism is usually used when working with remote (network) data sources, characterized by high latency, i.e. delay in the response to the request.

With this method it's possible to optimize the time resource spent on one signal, and thereby increase the maximum number of requested signals during the time interval of the polling.

As an example, lets examine an industrial PLC "Siemens S7-315" during requesting him on the bus ProfiBus (1,5 Mbit/s). The average processing time of the MPI-request of this controller is 30 ms. If you use the synchronous mechanism for each signal, i.e. one request for each signal, then in one second we can get something about 33 signals. And if you apply the asynchronous mechanism, i.e. in the MPI-package to receive up to 220 bytes or 110 signals of integer type of 16-bit, then we can for one second get up to the 3630 signals. As you can see, the effectiveness of the asynchronous mechanism in this case is 110 times, that is the maximum capacity of MPI-package.

The disadvantage of the asynchronous mechanism is that the request of the value of parameter attribute returns not actual at the time of request value, but value of the last session of the polling of the controller. However, taking in account that the data source can be updated at intervals of ADC hardware limitations, and the sensors themselves may have certain restrictions on the reaction rate, the using of the asynchronous acquisition mechanism could have a serious grounds.

Application of the asynchronous mechanism for recording the values to the PLC is a fairly rare fact, because recording of values usually involves impact of the operator on the TP. Operator on the fact rarely makes adjustments to the process, therefore, the recording can be performed synchronously. However, there are situations, such as managing of the TP by the regulator on SCADA-system, acting as the runtime environment of PLC.

Fig. 3. Diagram of the sequence of interaction with the asynchronous requests.

In accordance with the diagram above, we obtain the following picture:

  • parameter attribute, or the parent controller object, performs the periodic requests HardwarePLC::valueRequest() to get the value of signal or group of signals;
  • received signal values are located locally in the parameter attributes;
  • object of the SCADA-system sends the value request to the parameter attribute DAQParamAttribute::getVal() and gets locally saved value of the previous session of the data source polling.

In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":

  • DAQGate — module of the reflection of controller objects of the remote OpenSCADA-stations on the local one. In the module the asynchronous mode of reading data is implemented.
  • System — module of accessing the data of the execution area of OpenSCADA. In the module the asynchronous mode of reading data is implemented.
  • ModBus — module of accessing the data sources through the "ModBus" protocols family. In this module the asynchronous mode is implemented both for the data reading and recording (optional) to the PLC.
  • SNMP — module of accessing the data of the network devices through "the Simple Network Management Protocol". In the module the asynchronous mode of reading data is implemented.
  • Siemens — module of accessing the data of Siemens controllers of the S7 series. In this module the asynchronous mode is implemented both for the data reading and recording (optional) to the PLC.

1.3 Acquisition mechanism in packages

Acquisition mechanism in packages is characterized by the acquisition of data for each signal by the packet that includes the history of its changes. I.e. per one session of data poll we obtain multiple values of history of the signal. The package mechanism works in conjunction with the synchronous and asynchronous mechanisms.

In the case of working with the synchronous mechanism, the actual transfer of the data source archive to operational work in the system is performed (Fig. 2). Like the simple synchronous mechanism, it is desirable to use it only on low-latency data sources or with sources that work in sessional, for example, in the field of commercial accounting for reading the values of counters.

When working in conjunction with the asynchronous mechanism, history of the received signals is usually placed directly in the archives (Fig. 4), and the current value of the parameter attribute is set to last value of the package. Such combination is effective in acquisition fast data or synchronizing archives after losing connection with the remote data source.

Fig. 4. Diagram of the sequence of interaction with the asynchronous requests of the package mechanism.

In accordance with the diagram above, we obtain the following behavior of the package mechanism for asynchronous requests:

  • parameter attribute, or the parent controller object, performs the periodic requests HardwarePLC::valueRequest() to get the value's packages of a signal or group of signals;
  • received value packages of the signals are placed in the archive by the request DAQParamAttributeArch::setValues(), and the last value of the packages is located in the parameter attribute;
  • object of SCADA-system sends the request of the archive's fragment to the parameter attribute DAQParamAttribute::getValues(), and he relays the request to the archive DAQParamAttributeArch::getValues(). As the result, the fragment of the archive, available after the previous session of the polling of the data source, is returned;
  • object of the SCADA-system sends the request of the last value of the parameter attribute DAQParamAttribute::getVal() and gets the locally saved value of the previous session of the data source polling.

In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":

  • DAQGate — module of reflection of controller objects of the remote OpenSCADA-stations on the local one. The synchronous and asynchronous packet mode of reflection of the archives of the remote OpenSCADA-stations is provided.
  • DiamondBoards — module for data accessing of PC/104 cards of Diamond Systems company. PC/104 cards are available on the ISA-bus, hence, are local and available relatively quickly. When data acquisition is done through interruption the expectation of the packets of fast values (up to 200 kHz) in one second (up to 200000 values in the package) is made and the subsequent placing of packets in the archives of the DAQ parameter attributes are performed.

1.4 Passive acquisition mechanism and initiative connections

The passive acquisition mechanism is characterized by the initiative of providing data to the SCADA-system from the data source. This mechanism is rare but can occur in certain conditions or restrictions of the possibility of using the direct data acquisition mechanisms, Figure 1.4a. An example of such situation can be the geographically allocated systems of the data acquisition through mobile networks GPRS/EDGE/3G/4G/... . The allocation of all nodes to individual real and static IP-addresses, or the formation of a corporate mobile network, may prove to be expensive in such networks, therefore, the initiative of the data transferring from behind dynamic IP-addresses to one real IP-address of the SCADA-server is more accessible. Modification actions are transmitted to the data source at the time of the data transmission session by the source — reading. Although, typical requests are possible here through a VPN connection from a data source and proceeding through a network intermediate DBMS.

Fig.1.4a. Diagram of the sequence of interaction with the passive working mode.

In accordance with the diagram above, we obtain the following behavior of the passive mechanism:

  • data source object carries out periodic connection sessions with the parameter attribute DAQParamAttributeArch::setVal() to transfer its own data and receive influence commands;
  • object of the SCADA-system sends the request to the last value of the parameter attribute DAQParamAttribute::getVal() and gets the locally stored value of the previous connection session of the data source.

If the host initiating the connection has a dynamic address that is not "gray", that is, it can be connected directly, then the initiating connection can only be used to obtain a return address to which it is directly back connected, and in the controller of such connections only updating the dynamic addresses is performed.

At.png A special case is the initiative of the TCP-connection establishing from the data source and the standard requests do next by the server through the connection, that the input transports of the module "Sockets" and the module "SSL" are currently supported. This mode is currently even the most popular!

OpenSCADA also supports the initiation of such connections itself, that is, it can act as a data source for "gray" and dynamic IP. So, the input transport of the module "Sockets" and the module "SSL" in the mode 2 initiates the connection and then sends an identifying sequence and enters the normal mode of receiving requests from the host to which it is connected. At.png Regarding what is currently especially useful is the remote control of OpenSCADA stations in "gray" networks with such a connection.

Fig.1.4b. Initiative connection of the Data Sources.

2 Virtual data sources

In addition to the physical data acquisition the function of the virtual data acquisition is also important. Virtual data are the data obtained inside the system both independently and on the basis of the physical data. Practically, the virtual data formation mechanisms are implemented in conjunction with the mechanism of user computing. Among the industrial controllers and SCADA-systems the different programming languages are used. In the case of controllers such languages can be for example low-level languages (assemblers), but in recent years the high-level languages (C, Pascal and others) are increasingly used, as well as the formal languages of IEC 61131-3 (sequential function chart SFC, function block diagrams FBD, LD relay circuits and text ST, IL). In the case of SCADA-systems, the computing is often provided with the help of high-level programming languages and formal languages.

In OpenSCADA the programming interfaces and virtual data sources on the basis of different languages can be implemented, in separate modules of the subsystem "Data acquisition". At the current time the available modules of virtual calculators are:

The mechanism of user functions, or User Programming API, is integrated into the OpenSCADA core. User functions can be provided by any object of the program, including modules in accordance with their functionality, thus providing the user with the set of functions for the control of one or another object. User API functions can be either static, i.e. implementing the fixed functionality of an individual object, and the dynamic ones, i.e. formed by the user for the desired task in the internal high-level programming language of the user.

The module JavaLikeCalc provides OpenSCADA with the mechanism to create dynamic functions of the user and their libraries on the Java-like language. Description of the function in the Java-like language consists in binding the parameters of the function by an algorithm. In addition, the module has the functions of the direct calculations by creating a computer controllers with the associated computational function. The module provides the mechanism of precompiling the context-dependent functions, that are used to embed the user algorithms directly in the context of the various components of OpenSCADA, that is, for example, the parameters templates of the subsystem "Data acquisition" and the Visual Control Area engine (VCA).

The module BlockCalc provides OpenSCADA with the mechanism for creating user calculations, based on the formal language of the block schemes. Languages of the block programming based on the concept of block schemes and functional blocks. Moreover, depending on the block nature, block scheme can be: logic circuits, relay logic circuits, a model of technological process and others. The essence of the block scheme is, that it contains the list of blocks and links between them. From a formal point of view, the block — is an element (function), which has inputs, outputs and an algorithm for computing. Based on the programming environment concept, the block is a frame of values associated with the function object. Inputs and outputs of blocks are to be connected to get the whole block scheme.

With the purpose of filling the user programming API with the functions, the following specialized modules of static functions of the user programming API are created:

  • Library of System API functions: FLibSYS;
  • Library of standard mathematical functions: FLibMath;
  • Library of function for the compatibility with SCADA Complex1: FLibComplex1.
Fig. 6. Overall structure of the programming area components.

3 Logic level of the data processing

Above we noted, that the type of the data source can vary from a "raw" to the complex. The "raw" means the source, that provides only the basic signals (Integer, Real, Boolean, String, ...) separately. The complex ones refers to the source that groups the signals and, in the parameter of the subsystem "Data acquisition", provides additional attributes that cover practically all diagnostic tasks, that is, the parameter is a completed object, that does not need to be supplemented.

Taking in account this variation, the situation may occur, when the information in the controller parameter of the data source is insufficient to describe the real TP object in general and a derived object of a higher abstraction level is needed. The solution of this situation is the formation of complementary parameters, which isn't obvious and confusing. The better solution is to use the "Logic Level" layer, serving for the flexible formation of parameters-containers of signals with the necessary structure, and which has post-processing.

Functionally, the "Logical level" is intended to provide the OpenSCADA with mechanism for the free formation of parameters-containers of signals of the desired structure.

Operating appointment of the "Logic level" is:

  • expansion of the area of OpenSCADA application by increasing the flexibility of description of parameter of the subsystem "DAQ";
  • reduction of labor costs for the creation of complex automated systems.

The "Logical level" concept is based on the template parameters, for which, in the subsystem "Data acquisition", the container of template libraries is provided (Fig.1). Each library contains templates of parameters that can be used by the modules of the subsystem "Data acquisition" for implementation of parameters based on the templates. The OpenSCADA modules, which use the templates in their work, are:

  • LogicLev — module of implementation the classical conception of "Logic Level" .
  • ModBus — module of accessing data sources through the family of "ModBus" protocols. Besides of the parameter type of the direct description the registers list it also supports the logical type, where the "ModBus" registers described in links of the template.
  • Siemens — data acquisition module for Siemens controllers of the series S7. Thanks to the high flexibility and functionality of the controllers in this series, which allows for the formation of complex data types of diverse structure, all parameters of this module work on templates.
  • OPC-UA — module of accessing data sources through the "OPC-UA" protocol. Besides of the parameter type of the direct description the nodes list it also supports the logical type, where the "OPC-UA" nodes described in links of the template.

General mechanism of the "Logic Level" on the example of the LogicLev module is shown in Figure 7.

Fig. 7. Mechanism of the "Logic Level" on the example of the module "LogicLev".

On this figure you can see that the parameters of the logic level controller perform the reflection function of other parameters of the subsystem "DAQ" (on the example of parameters 1 and 4) and the free formation of the parameters based on templates 1, 2 and other parameters of the subsystem "DAQ" (on the example of the parameters 2, 3 and 5).

Structure of the parameters with the template in their basis has the structure shown in Figure 8.

Fig. 8. Structure of the parameters, with a template in their basis.

As can be seen from the structure, the logic level parameter consists of the function object, attributes and configuration of the template. The function object is an instance of the execution of the template function with the set of inputs/outputs and the computation program of the template on the language of the user programming, usually it's the Java-like programming language of the module DAQ.JavaLikeCalc. But the template may be generally without any program, providing only the structure of transfer the inputs/outputs. Attributes in the structure represent the list of attributes of the result parameter in accordance with the template. Configuration in the structure provides the configuration of the template properties and its external links.

The logic of the work of logic-level parameters can be written as follows:

  • Parameter connects with the template from which it obtains the structure of attributes in accordance with the template function.
  • Binding of the object function of the parameter to the template function is performed.
  • Structure of links is formed in accordance with the template function. Based on the structure of links the form of linkage the parameter is formed and the user sets the links.
  • When accessing the attributes of the obtained parameter the check for the presence of a direct link does. In the case of the direct link presence the request is routed by this link, otherwise the value is taken from the function object of the parameter.
  • In parallel, the calculation of the template works by the function object of the parameter. However, before the calculation the reading of the values by the links is made, and after calculation the changes are recorded by these links.

Parameters template in general provides the following:

  • I/O structure of the template function;
  • signs of the configuration and linkage of the template (constant, link);
  • preset values of the configuration of constants and link templates;
  • signs of the attributes of the resulting logical level parameter, types: not attribute, attribute with full access, attribute with read-only access;
  • mechanism for calculating the I/O of the template function by the user programming language of OpenSCADA.

Figure 9 shows an image of the configuration tab of the parameters template of the subsystems "DAQ" as the table with the configuration of inputs/outputs and the text of the program of user programming.

Fig. 9. Configuration tab of a parameters template of the subsystem "DAQ".

The inputs/outputs tab "IO" of the parameters template provides the following properties of special purpose: "Attribute", "Configuration" and "Value".

The property "Attribute" is the reflecting sign of the template I/O on the resulting attribute of the parameter. There the following options for this property are provided:

  • No attribute — input/output of the template function does not reflect on the attribute;
  • Read only — input/output of the template function reflects on the attribute with read-only access;
  • Full access — input/output of the template function reflects on the attribute with full access.

The property "Configuration" is the sign indicating the using of input/output of the template function in the resulting configuration of the template on the logic level. The following options for this property are provided:

  • Variable — available for access and control only from the template procedure as a variable saved with the logical level parameter context;
  • Constant — available for setting at the parameter of logic level as a constant in the configuration section of the template;
  • Link — available for setting at the parameter of the logical level as a link in the configuration section of the template.

The field "Value" describes the preset value for the constants and templates of the external links. Template of the external links is used to describe the mechanism of grouping and automatic allocation of the external links. The template structure of the external links is the same in the part of connecting to the attributes of the subsystem "DAQ" and it is expanded by the specific format of the address of a separate module of the subsystem "DAQ", which uses the template mechanism. Connection to the parameters of the subsystem "DAQ" — the configuration template of the external link has the form {Parameter}|{attribute}, where:

  • Parameter — is used to combine the attributes and placing on the configuration form;
  • attribute — for the associated linkage of the attributes at the parameter appointment.

The further linking in general can be carried out by:

  • general definition-selecting the address-attribute of the subsystem "DAQ"; for example, the link "LogicLev.experiment.Pi.var" or "prm:/LogicLev/experiment/Pi/var" performs the access of the parameter attribute to the other parameter attribute; sign "(+)" at the end of the address indicate about successful linking and presence of the target; for the object-type attributes there permissible hierarchical access to a specific property of the object, by specifying its path through the symbol '#', for example: "LogicLev.experiment.Pi.var#pr1.pr2" or "prm:/LogicLev/experiment/Pi/var#pr1.pr2"; in the path with the "prm:" prefix you can use items of the relativity "." and "..";
  • definition of the specific address of a separate module of the subsystem "DAQ";
  • direct setting a constant value in the format "val:Constant value";
  • empty or erroneous address when the value by the link is set to EVAL.

As an example of using the template, in Figure 10 is shown an image of the parameter "F3" of the logic level module, where the tab "Template configuration" is presented' for the configuration of the parameter template, including the linkage. In Figure 11 the tab "Attributes" is shown with the list of attributes and their values, created through the template.

Fig. 10. Tab "Template configuration" of the parameter "F3" of the logic level module.
Fig. 11. Tab "Attributes" of the parameter "F3" of the logical level module.

3.1 Conception of accessing the data by a user protocol

Next level, based on the Logical Level, is a conception of accessing the data by a user protocol, implemented whether directly in the template code or as a different User Protocol object in the Protocol.UserProtocol module, where you currently may also use the DAQ-templates.

The conception of accessing the data by a user protocol we can imagine like to Figure 1.

Fig.1. Conception of user accessing to services and device's data.

As you can see from Figure 1, interaction with devices carried out through some transport on which their physically based. Requests to the transport you can send:

  1. Directly by OpenSCADA system API function of the transport object string messIO( string mess, real timeOut = 0 );, if the protocol specific part is very simple and you need only the data extract.
  2. Wrapped data request req by function int messIO( XMLNodeObj req, string prt ); and for protocol prt, if the protocol part is complex enough and already presented in OpenSCADA.
  3. Wrapped data request specific for user by function int messIO( XMLNodeObj req, "UserProtocol" ); and the user protocol implementation, if the protocol part is complex enough and not yet present in OpenSCADA. The user implements here itself of the protocol specific part in the module UserProtocol and the data specific part in the template for the Logical Level module or directly in controller's procedure on the internal language of the module JavaLikeCalc.
At.png This latter method is currently developed to the possibility of forming a protocol code part directly in the same code of the template as a separate built-in function with call the requesting function of the first method, if there is no need for reuse, or even if such a need exists and it makes sense to create a complex template that can combine the role of the output protocol, through its connection to the user protocol module. And it will be completely stored in a single template library.

At.png Working directly with the output transport of the string messIO(string mess, real timeOut = 0); function does not imply blocking the output transport outside this function call and, therefore, for complex protocols with response packets more than in one packet, which requires the "waiting" process, can not be used a shared transport, at which can be sent packets of different protocols or even one, but for different tasks (controller objects). Therefore, if you need to use shared transport, place the poll parameters in one controller object (task), or use the user protocol module to which this remark is irrelevant, since it performs such blocking at the time of the call of the processing procedure, as well as other modular protocols of OpenSCADA.

Using the conception of user accessing to services and device's data next libraries created:

4 Redundancy of the data sources

Redundancy in general and of the data sources in particular serves to increase the overall level of fault-tolerance of the solution by integrating the redundant nodes in collaboration with the main node. In case of failure of the main node, the grab of the main node functions by the redundant one takes place. The redundant scheme can work in the mode of the load distribution between the co-operating nodes.

Fig. 12. Horizontal and vertical redundancy.

In the case of the "Data acquisition" subsystem, data reservation (Fig. 12) serves as:

  • Redundancy of the data acquisition mechanism. Typically, this function is realized without special arrangements by simply running of the parallel redundancy stations with the same configuration and working independently. However, in the case at the station working as PLC, such approach is unacceptable because of the simultaneous making of the control actions and the absence of synchronization of data of the calculators.
  • Compensation of the data loss on the time of the node inaccessibility with the redundant node archive. There are two mechanisms of the compensation. The first and the main mechanism implements the loading of the sections of the archive from the redundant station at the time of the station startup in general or of individual controller objects. The section of the archive is requested from the moment of the last record in the local archive and till the current time. The depth of the request is limited by the indicating of the limit time in the configuration of the redundancy. The second, complementary mechanism, performs the filling of the "holes" in the archive at the time of the actual user's request to the data. Such an approach on the one hand allows to make the predictable in time synchronization at startup and on the other hand it's actually eliminates the data loss in the case of working at least one station during the entire time.
  • Distribution of the data acquisition load between the nodes. When creating complex allocated systems there can be an important question of predicting and optimizing of the overall system performance. Taking in account these problems, the redundancy mechanism provides execution of the data acquisition tasks of individual sources (OpenSCADA controller objects) only at one station. The other stations' tasks would go to the data synchronization mode with the executive station. In the case of loss of the connection with the executive station, the local data acquisition task is started. It is also provided for the possibility of an optimal load distribution for executing the tasks of the data acquisition for a group of controller objects, between the stations.
  • Optimization of the load on the external data sources through the data request from an external source by the only one node. In practice, we often meet highly loaded data sources or interfaces of accessing to the data sources, for which even the data acquisition by one station can be a problem and would require reducing the acquisition periodicity, i.e. data quality. The mechanism of redundancy, besides the load distribution between the stations as described above, allows you to remove additional load form the data source and its interfaces, thereby improving the quality of the data. Writing to attributes of the controller object under redundancy causes to the modification request sending to the master one, that is — through it.
  • Prevention of some differences of the data on different nodes associated with the mismatch of moments of time at the independent acquisition of the data by individual nodes, performs in a way of receiving the data from the station with the active controller object. In systems of high accountability under the redundancy there should be excluded or minimized the differences in the data at different stations, that means the real acquisition of the data by one station and synchronization with these data of other ones.

It is recommended that the redundancy is configured in such a way that the database of the redundant stations are kept the same, which in the future will allow you to safely copy them, at restoration, to any station and, accordingly, you can save only one set of databases in the backup. In this case, the settings specific to the individual station will be stored in the configuration file and it will be possible to easily configure and change the desired station by choosing the appropriate configuration file.

Redundancy configuration start from the redundant stations appending to the list of OpenSCADA stations in the tab "Subsystem" of the subsystem "Transports" (Fig.13). And to add here you need not only the redundant stations to the current one but the same current one with its external IP, that is some loop. Further this configurations will have been stored in the generic DB of the redundant system, and from this time the DBs will be used in all redundant station creation. Then there is important to make on that stage all need changes in the generic DB and about this project in general!

Fig. 13. Tab "Subsystem" of the "Transports" subsystem.

Next for the concrete station, with copy of the generic DB, we configure its specific parameters in the tab "Redundancy" of the main page (Fig.14), which will be stored in the configuration file.

Fig. 14. Tab "Redundancy" of the main page.

After that all next configurations of the redundancy performed in the tab "Redundancy" of the subsystem "Data acquisition" (Fig.15). If you will set the parameter "Local primary commands transfer" (Fig.14) then the configurations, like to any other generic ones, can be carried out at one of the stations, and the changes made will fall on all the redundant stations, of course, if they will be available.

Fig. 15. Tab "Redundancy" of the "Data Acquisition" subsystem.

The service task of the redundancy mechanism is always running and executed at intervals which are set in the appropriate configuration field. The real work on implementing the redundancy is carried out in the presence of at least one redundant station in the list of stations, and means:

  • Controlling of the connection with the external stations. In the controlling process the requests to remote stations are made to get the updated information and to check the connection. In the case of loss of connection with the station the repeat of connection to it is made through interval specified in the configuration field "Restore connection timeout". In the "Live" field of the station the current state of communication is displayed. In the "Counter" field the number of requests carried to the remote station, or the time remaining for the next connection attempt to the lost station is displayed.
  • Local planning of execution the controller objects in reserve. Planning is carried out in accordance with the station level and preferences of execution of the controller objects.
  • Calling the data synchronization function for the local controller objects, working in the mode of data synchronization from the external stations.

To control the time spent in the cycle of serving the redundancy, the status field is provided. When approaching the real execution time to the cycle of the redundancy tasks it's recommended to increase the periodicity of this task execution!

For the controller object of the subsystem "Data Acquisition", "Asymmetric" and "Only Alarms" reservation modes are provided. Asymmetric redundancy is working with the configuration of the controller of the remote station, as it is, and does not trying to generalize it. For this mode work all early presented functions and properties of the redundancy. The redundancy "Only Alarms" is working in fact without a redundancy, but with oppressing the alarms from the reserve controller object to exclude a duble messages in the alarms.

5 Timestamp of the data source

In fact, all data sources supported by OpenSCADA use the time of the computer running OpenSCADA as the time-stamp of the operating-current data and polls this data source, even if it is possible to receive the server or source time in the data source, and often even in the case where such a source is a different station-PLC with OpenSCADA.

This approach has been identified for several reasons, that is:

  • appreciation and excretion the time difference of the data source and the data acquisition PC has no practical purpose other than the diagnostic to detect the very difference in time since the current data is archived in the archive of periodic values, where the time stamp one way or another is drawn and rounded to this periodicity, that is, the part time is more precise for the period of the archive data is lost;
  • rarely which data source does have a real-time clock, and when it has something to it immediately the requirement is to synchronize time with an external source of the precision time, which in turn requires solving the difficulties with direct connection of the GPS receiver or access to the NTP server on the Internet or local network; by the definite approach, the precision time is the time of data acquisition PC, even when it is not synchronized itself, since it is one;
  • the data source timestamp may change with its own periodicity, or this update may generally be aperiodic, that if this timestamp is used in the acquisition, it will lead to gaps in the archive, and even if the periodicity of the archiving and updating of the source timestamp is the same, such gaps will occur through the lack of synchronization, which will have to be compensated by a decrease in the periodicity of the acquisition and, accordingly, an increase in the load on the network and the source; so this will make the archive little useful, although it is now possible to take such gaps (passable) not by the fact of the absence or the erroneous nature of the data.

Currently, one method is known when there is practical value from the data source's timestamp, which is the work with the history-archive on the side of the data source, when the data area of the archive-history is asked corresponding to this gap instead of the current-operational data, for example, when there is no communication. And this method is implemented in the module DAQ.DAQGate, when running OpenSCADA on the side of the data source or the PLC.

6 Links

Retrieved from "http://oscada.org/wiki/index.php?title=Documents/DAQ/en&oldid=80846"