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:
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:
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.
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:
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.
In accordance with the diagram above, we obtain the following sequence of requests for data acquisition and their transfer:
In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":
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.
In accordance with the diagram above, we obtain the following picture:
In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":
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.
In accordance with the diagram above, we obtain the following behavior of the package mechanism for asynchronous requests:
In OpenSCADA this mechanism is implemented by the following modules of the subsystem "DAQ":
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.
In accordance with the diagram above, we obtain the following behavior of the passive mechanism:
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.
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. Regarding what is currently especially useful is the remote control of OpenSCADA stations in "gray" networks with such a connection.
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:
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:
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:
General mechanism of the "Logic Level" on the example of the LogicLev module is shown in Figure 7.
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.
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:
Parameters template in general provides the following:
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.
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:
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:
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:
The further linking in general can be carried out by:
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.
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.
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:
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. 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:
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.
In the case of the "Data acquisition" subsystem, data reservation (Fig. 12) serves as:
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!
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.
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.
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:
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.
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:
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.
| Documents/DAQ/en - GFDL | March 2024 | OpenSCADA 0.9.7 |