OpenSCADAWiki: Home Page En/Doc/DAQ ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
This is an old revision of HomePageEn/Doc/DAQ from 2016-10-15 13:42:09..

Data acquisition in OpenSCADA

Author: Roman Svochenko, Maxim Lysenko (2010)


Contents Data acquisition

Introduction

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 it's meant the value of TP sensor in the ADC code, "raw" signal or in the real value. Signals can be combined into groups, which are often called parameters. 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 in the function of this mechanism is also included the transfer of actions to control devices of TP; usually it's a gate valve, pumps and control valves. Taken together, this equipment is known as computer-process interface (CPI).


Sources of data are characterized by their great variety, which can be divided into 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 into 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 limited range of commercial operating systems (OS).


In terms of OpenSCADA system the following objects 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 the 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 a configuration of several devices of this type in the form of "Controller" objects of OpenSCADA. The general scheme of objects of "Data acquisition" subsystem is shown in Figure 1.


The subsystem\'s [Data acquisition] scheme. (41 Kb)
Fig. 1. The subsystem's "Data acquisition" scheme.

1. Data acquisition methods

Taking into 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.


To the examination of the mechanisms below the following objects will be involved:

1.1. Simple synchronous acquisition mechanism

The mechanism is characterized by requests to the data source synchronously with the request to the attribute of parameter (Fig. 2). This mechanism is usually used when working with local sources of data, 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 object will include the time for transportation and processing of the request by the data source.


 (10 Kb)
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:


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

1.2. Simple asynchronous acquisition mechanism

The mechanism is characterized by requests to the data source, regardless of the request to the attribute of parameter (Fig. 3). Usually, requests to the source of the data are made periodically in the own polling task of the single controller and with the blocks of few signals. This request to the parameter's 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 a 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 asynchronous mechanism is that the request of the value of attribute of the parameter returns not actual at the time of request value, but value of the last session of the polling of the controller. However, taking into account that the source of data 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 a runtime of PLC.


 (15 Kb)
Fig. 3. Diagram of the sequence of interaction with the asynchronous requests.

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


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

1.3. Package acquisition mechanism

Package data acquisition mechanism 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 synchronous and asynchronous mechanisms.


In the case of working with a synchronous mechanism the actual transfer of the archive of data source for operational work in the system is done (Fig. 2). As the simple synchronous mechanism, it's desirable to apply only to low-latency data sources or to the sources whose work is a session type, for example, in the commercial account to read the values of the counters.


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


 (16 Kb)
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:


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

1.4. Passive acquisition mechanism

The feature of the passive data acquisition mechanism is the initiative of the providing data in the SCADA-system from the data source. This mechanism is quite rare, but can occur in certain conditions or restrictions of the possibility of using the direct data acquisition mechanisms, Fig. 5. An example of such a situation can be the geographically allocated systems of data acquisition through mobile networks GPRS/EDGE. In such networks, empowering the individual client nodes with the real IP-address or the formation of a corporate wireless network can be rather expensive, and therefore more accessible is an initiative of the data transfer session from client dynamic IP-addresses to the one real IP-address of the SCADA-system server. Nevertheless it is possible to work through the network DBMS of the dealer.


Actions of the modification are transmitted to the source of data at the time of data transfer session by the source.


 (12 Kb)
Fig. 5. Diagram of interaction sequence with the passive working mode.

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


In OpenSCADA this mechanism has not been yet used, but in principle there is the possibility of its realization in the system, for example, through a writing by the standard protocols "ModBus", "OPC-UA".

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 physical data. Practically the formation mechanisms of virtual data 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 computings are often provided with the help of high-level programming languages and formal languages.


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


At the OpenSCADA kernel the mechanism for user-defined functions or API of user programming is integrated. User functions can be provided by any object of the system, 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 language of the user high-level programming.


Module JavaLikeCalc provides the OpenSCADA system with the mechanism to create dynamic user-defined functions and libraries for Java-like language. Description of functions for Java-like language is to tie up the parameters of the function by the algorithm. In addition, the module has the functions of the direct calculations by creating a computer controllers with the associated computational function. Module provides the mechanism to precompile the context-dependent functions that are used to embed the user algorithms directly in the context of the various components of OpenSCADA. For example, the mechanism of the parameters' templates of subsystem "Data acquisition" and the visual control engine (VCA).


Module BlockCalc provides the OpenSCADA system with the mechanism for creating user calculations. Mechanism of calculations based on the formal language of block diagrams. Languages of block programming based on the concept of block diagrams (functional blocks). And depending on the nature of the block, 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 concept of programming area block — is a frame of values associated with the object of function. Inputs and outputs of blocks are to be connected to get the whole block scheme.


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


The overall structure of the components of the programming area (85 Kb)
Fig. 6. The overall structure of the components of the programming area.

3. Logic level of data processing

Above we talked that type of data source can vary from a "raw" to the complex. The "raw" means the source that provides only the basic signal (Integer, Real, Boolean, String, ...) separately. Under the complex it's meant the source that groups the signals and in the parameter of subsystem "DAQ" it provides the attributes of an additional purpose, covering practically all diagnostic tasks, i.e. the parameter is the complete object, which do not need any additions.


Taking into account this variation, the situation may occur, when the information in the object of data source controller's parameter, is insufficient to describe the real TP object in general and the derived object of a higher level of abstraction 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 layer, so-called "Logic Level", serving for the flexible formation of parameters, containers of signals with the necessary structure, and which has post-processing.


Functionally "Logic Level" is intended to provide the OpenSCADA system with mechanism of free formation of parameters' objects, containers of signals of the necessary structure.


Operating appointment of the "Logic Level" is:


The conception of "Logic Level" based on the parameters' templates for which in the subsystem "DAQ" it's provided the container of the templates libraries (Fig. 1). Each library contains templates of parameters that can be used by the modules of "DAQ" subsystem for the implementation of parameters based on templates. The modules of OpenSCADA, 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.


The mechanism of the "Logic Level" on the example of LogicLev module. (31 Kb)
Fig. 7. The mechanism of the "Logic Level" on the example of LogicLev module.

On the figure you can see that the parameters of the logic level controller function as reflections of other parameters of "DAQ" subsystem (on the example of parameters 1 and 4) and the free formation of parameters based on templates 1, 2 and other parameters of "DAQ" subsystem (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.


Structure of the parameters, with a template in its basis. (14 Kb)
Fig. 8. Structure of the parameters, with a template in its 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's function with the set of inputs/outputs and the computation program of the template on the language of 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's 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 image of the configuration tab of the parameters' template of subsystems "DAQ" as the table with the configuration of inputs/outputs and the text of the program of user programming.


The configuration tab of parameters' template of subsystem "DAQ". (134 Kb)
Fig. 9. The configuration tab of parameters' template of subsystem "DAQ".

The input/output tab of the parameter's template provides the following properties of special purpose: "Attribute", "Configure" and "Value".


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


The "Configure" property is the sign indicating the using of input/output of the template's 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 configuration template of the external links. Template of the configuration of external links is used to describe the mechanism of grouping and automatic allocation of external links. The structure of the template of configuration of external links is the specific for each module of subsystem "DAQ", which uses the template's mechanism. In the case of the logic level module the allocation is made over the external attributes of the parameters with the template of configuration of the external link of the form: {Parameter}|{attribute}. Where "Parameter" is used to combine the parameters and place on the configuration form, and an attribute — for the associated linkage of the attributes at the appointment of the parameter.


As an example of the template's using in Figure 10 lets show an images of the parameter of the logic level module "F3". In Fig.10 the tab "Template config" is presented', it serves for the configuration, including the linkage, of the parameter's template. In Fig.11 the tab "Attributes" is shown with the list of attributes and their values, created through the template.


The "Template config" tab of the "F3" parameter of the logic level module. (79 Kb)
Fig. 10. The "Template config" tab of the "F3" parameter of the logic level module.

The "Attributes" tab of the "F3" parameter of the logical level module. (110 Kb)
Fig. 11. The "Attributes" tab of the "F3" parameter of the logical level module.

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 load distribution between the co-operating nodes.


Horizontal and vertical redundancy. (33 Kb)
Fig. 12. Horizontal and vertical redundancy.

In case of a subsystem "DAQ" of OpenSCADA system the data redundancy (Figure 12) performs following functions:


There is recommended the redundancy configure in way for DBs of the redundant stations save equal and that will allow you to copy its painlessly to each the station and then to backup only one the DBs set. And the configurations specified to the different stations will save into the configuration file and you can simply configure and change the needed station by the proper configuration file select.


The "Subsystem" tab of the "Transports" subsystem. (68 Kb)
Fig. 13. The "Subsystem" tab of the "Transports" subsystem.

Äàëåå íà êîíêðåòíîé ñòàíöèè, ñ êîïèåé îáùåé ÁÄ, íàñòðàèâàåì å¸ ñïåöèôè÷åñêèå ïàðàìåòðû âî âêëàäêå "Ðåçåðâèðîâàíèå" ãëàâíîé ñòðàíèöû (ðèñ.14), êîòîðûå áóäóò ñîõðàíåíû â êîíôèãóðàöèîííîì ôàéëå.


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


The "Redundance" tab of the main page. (77 Kb)
Fig. 14. The "Redundance" tab of the main page.

After that all next configurations of redundancy perform into the tab "Redundancy" of subsystem "Data Acquisition" (Fig.15), and if you will set the parameter "Local primary commands transfer" (Fig.14) then the configurations, like to any other generic configurations, can be performed at any one from the stations and all the performed changes will be transferred to all other ones, sure if its are available.


The "Redundance" tab of the "Data Acquisition" subsystem. (116 Kb)
Fig. 15. The "Redundance" tab of the "Data Acquisition" subsystem.

The service task of the redundancy mechanism is always running and executed at intervals which are prescribed 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 implies:


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


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

Links

Referring pages: HomePageEn/Doc
HomePageEn/Doc/VCAconcept/part4/part10
HomePageEn/Doc/Vision


 
There are no files on this page.[Display files/form]
There is no comment on this page. [Display comments/form]