Українська?
Российский

Logical level of parameters of OpenSCADA

Author: Roman Savochenko

1 Introduction

Open SCADA system OpenSCADA belongs to the class of SCADA (Supervisory Control and Data Aquisition) systems. Systems of this class are used as an element of technological processes automation systems (ACS TP).

OpenSCADA system is constructed as a modular and highly scalable system. Hence the internal structure of the system must meet the high demands of flexibility.

To get data from outside the OpenSCADA system provides so-called "Data sources". All data sources are contained in the subsystem of the same name and grouped by type of data sources, defining the module of subsystem of data sources (DAQ). The module is the separate component of the OpenSCADA system, which for the "DAQ" subsystem's modules contains the controllers with parameters of the predetermined structure. Under the structure of the parameter it is meant the number of its attributes.

The nature of the data source can range from "raw" to the full. The "raw" means the source that provides only the basic signal (integer, float, boolean). The full one means the source, which in the parameter contains the attributes of additional values, covering virtually all diagnostic tasks, ie parameter is a complete object, not requiring additional information.

Given this variation, the situation may cause when information in the object of the parameter is not enough to describe the object as a whole and the derived object is needed on the higher level of abstraction. The solution of this situation may be the formation of complementary parameters, which is not convenient and confusing. The better solution is to create layer, so-called "Logic level", which serves as the flexible formation of parameters/objects with necessary structure, including post-processing.

2 Purpose

Functionally, the development is intended to provide the OpenSCADA system with the mechanism of freely formation of parameters' objects of required structure.
Operating purpose of the development is:

• broadening the scope of the OpenSCADA system by increasing flexibility of description of objects of parameters;
• reducing the labor costs for the creation of complex automated systems.

3 Requirements

Architecturally logical level must meet the following requirements:

• be implemented as the subsystem of the OpenSCADA system (subsystem "Parameters");
• contain the containers of parameters and parameters' templates;

On the basis of architectural considerations it can be formed the requirements for individual components.

Requirements for the subsystem "Perameters":

• contain the containers of parameters and their templates;
• provide the mechanism for periodic calculation of the parameters built on templates;
• provide the scripts(scenarios) of the user interface for the configuration of subsystem and for the access to the parameters and their templates.

Requirements for objects "Prameters templates":

• contain the structure of the attributes of the parameter;
• support the user access to the attributes (the side of configuration): constant, link;
• support the grouping of the attributes' links by the to the parameters with the automatic appointment of the necessary attributes after specifying the parameter;
• support the ability to specify the type of the attribute (the side of the resulting parameter): no attribute, an attribute with full access, attribute for read-only access;
• provide the mechanism for calculating of the imported attributes with the purpose of the formation of new (based on the object model of the OpenSCADA system);
• provide the scripts(scenarios) of the user interface for configuring the template of the parameters.

Requirements for the objects of "Parameters":

• support the modes: direct mapping and the formation on the template;
• realization of high-performance mechanism of linkage with the original attributes/parameters;
• provide scripts(scenarios) of the UI (control interface of the system) for the configuration of the parameter.

4 Projecting

Based on the above requirements we will develop the logic level of the parameters. The overall structure of the Logical level, in the context of its interaction with the physical one, is shown in Fig. 1.

Fig. 1. The overall structure of the logic level

Development of the "Parameters" subsystem does not substantially different from other subsystems of OpenSCADA, therefore, we'll not stop on the features of its formation. Templates of parameters and parameters are an interesting question, therefore, lets examine the features of their formation.

The requirements to the template of the parameters voiced the necessity to store the structure of attributes, that will featured on the part of the configuration of the parameter, and on the side of the resulting attributes. In addition, there must be possible to compute the attributes. The good solution would be to use for these purposes the objects of functions of programming area. Such an approach would obviate the need for the mechanism of addition the attributes because they will be added and formed in the form of the function's parameters. The overall structure of the formation of the parameter with the help of the template is shown in Fig. 2 .

Fig. 2. Formation of the logic level parameter on the template

The architecture of the logic level is obtained the extremely simple. The class diagram of it is shown in Figure 3. Description of the classes is given in Table 1.

Fig. 3. Class diagram of the logical level of the parameters

Table 1. Classes of the logic level of parameters

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

• The parameter is associated with the template from which it acquires the structure of attributes in accordance with the template's function.
• At the moment of the linkage the parameter with the function the associating of the frame of the parameter's values with the template's function takes place.
• Further, according to the function's template, the links structure is formed.
• Based on the links structure the form of the parameter's linkage is formed.
• The user sets the links.
• Then, when you access the attributes of the parameter the check for the presence of direct link is made. In the case of the direct link presence the request is redirected to this link, otherwise the value is taken from the frame of the function's values.
• At this moment the the computation of the template's function on the frame of the parameter's values is running. Before the calculation the reading the values on the links is made, and after calculating the results are recorded on these links.

In the parameter's template the attribute has two properties: "Attribute", "Access" and "Value". The "Attribute" property describes the reflections on the attribute of the parameter. The following options for this property are provided:

• no attribute - function parameter is not an attribute;
• read only - function parameter is the attribute to read-only access;
• full access - function parameter is the attribute with full access.

The "Access" property defines the links between this parameter of function with the physical layer. The following options for this property are provided:

• Constant - is set only at the level of the template;
• Public constant - set at the parameter's level by the user;
• Link - link on the attribute of the parameter of the physical level.

The field "Value" describes the value for the constants and the the preferred attribute of the parameter for the links. Description of the preferred attribute of the parameter for links is used to describe the implicit distribution of attributes of the parameters. The structure of the description is as follows: <Parameters description>|<attribute>. Where "Parameters description" is used to combine the parameters and place on the configuration form, and the "attribute" for the automatic linkage at the time of the parameter's appointment.

5 Implementation

In the process of implementation the all components were created, as well as scripts(scenarios) of configuration and control interface for them. Configuration forms of the parameter's templates are shown in Fig. 4 and Fig. 5. Configuration forms of the logic level parameters are shown in Fig. 5, Fig. 7 and Fig.8.

6 Comments

• In the process of implementation it was not solved the question of productivity. The problem is that for addressing the attributes the string identifier is used, both when addressing the attributes of parameter, and in the process of calculating the frame of values by the template's function. As a result, the total computation and access time is considerable!
• In the process of using the logic level of parameters there had appeared the thought to use the designed mechanisms on the physical level of separate data sources. For example, these mechanisms can be used in the data source of the S7 controllers to form the parameters of the required structure. The difference from the logical level of parameters it will be only the other sense of links, so they will describe the data blocks and offsets in them.
• Later, afterwards the practical using and the thoughts above it was done the simplifying of the logic level of parameters subsystem, as the separate entity, and its mechanisms: templates of the parameters and the parameters of the logic level were transferred to the subsystem "DAQ" (templates of parameters) and to the individual modules (the parameters of the logic level). Thus, it became possible to include the mechanisms of formation of parameters on the template into any module of the data source.
• The mechanism of the complete description of the template in itself is done. You do not need to separately form the functions for the object model.

Fig. 4. Template: The general information

Fig. 5. Template: Configuration

Fig. 6. Parameter: General information

Fig. 7. Parameter: Attributes

Fig. 8. Parameter: Configuration of the template

Links