Modules/LogicLev

This module is a pure implementation of the logic-level mechanism, based on the templates of parameters of the subsystem "Data acquisition (DAQ)". This implementation of the module is based on the "Logical level of the parameters of OpenSCADA". Practically, this module is an implementation of the subsystem "Parameters" of the project without templates and moved to the module.

The module provides a mechanism for forming the parameters of the subsystem "DAQ" of the user level based on other sources of this subsystem. Actually, the module uses templates of the subsystem "DAQ" and the specific format for description of references to the parameter attributes of the subsystem "DAQ".

Also, the module implements the functions of the horizontal redundancy, that is working in conjunction with the remote station of the same level. In addition to synchronizing the values and archives of the parameter attributes, the module synchronizes the values of the computational templates for the purpose of non-hit pickup of algorithms.

1 Controller object

To add a data source of the logical level parameters, a controller object of OpenSCADA is created and configured. An example of the configuration tab for a controller object of this type is shown in Figure 1.

Fig.1. Configuration tab of a controller object.

With this tab you can set:

• State of the controller object, as follows: status, "Enabled", "Running" and the storage name containing the configuration.
• Identifier, name and description of the controller.
• The state "Enabled" and "Running", in which the controller object must be translated at start up.
• Policy of scheduling and priority of the data acquisition task.

2 Parameters

The module provides two types of parameters: "Logical (Prm)" and "Reflection parameter (PrmRefl)". The additional configuration fields of the parameters of this module (Fig. 2) are:

• Logical (Prm), with the parameters table name "LogLev{TypeId}_{CntrId}":
  • Parameter template — address of the DAQ parameter template.
• Reflection parameter (PrmRefl), with the parameters table name "LogLev{TypeId}_{CntrId}":
  • Source parameter — address of the source of the reflecting parameter.

Fig.2. Configuration tab of a parameter.

2.1 Logical (Prm)

When forming a template of the logical type of the parameter of this module, the specific of the link format of the template must be taken into account. The link should be written as: {Parameter}|{identifier}, where:

• {Parameter} — string, characterizing the parameter;
• {Identifier} — identifier of the parameter attribute.

This record allows to group multiple attributes of the source parameter and assign them only by the choice of the same parameter. That is, in the configuration dialog of the template (Fig.3) only the parameter will be specified. This however does not rule out the possibility of assigning the attributes of the parameters separately to each one, in addition, if you omit the link description in the specified format in the template configuration, then the attribute of the parameter (Fig.4) will be assigned.

The module provides a special processing of a number of attributes of the template:

• f_frq — frequency of the calculation of the template procedure or the time after the last calculation (negative in seconds) for planning by CRON, read-only.
• f_start — sign of the first execution of the template procedure — start-up, read-only.
• f_stop — sign of the last execution of the template procedure — stop, read only.
• f_err — parameter error, full access. The value of this attribute of the template falls into the error attribute of the parameter "err". Write here EVAL for the possibility of setting the attribute "err" from the outside and all others in the Read Only mode.
• SHIFR — code of the parameter, read-only.
• NAME — name of the parameter, read-only.
• DESCR — description of the parameter, read-only.
• this — object of the parameter, allows access to the attributes of the parameter, for example, to access archives-history.

The sign "(+)" at the end of the address signals the successful linking and presence of the target object. For object-type attributes, hierarchical access to a specific property of the object is allowed by defining its path through the '#' symbol, for example: "LogicLev.experiment.Pi.var#pr1.pr2".

Fig.3. Configuration tab of a parameter template.

Fig.4. Configuration tab of a parameter template. Show only attributes.

In accordance with the template underlying the parameter, we obtain a set of attributes of the parameter as in Figure 5.

Fig.5. Tab of attributes of a parameter.

2.2 Parameter reflection (PrmRefl)

All attributes of the parameter specified in the reflection simply become available in this parameter, thereby performing the proxying function, for example, to bring the parameters of other sources into one — the export object of the controller (for the PLC).

3 User programming API

Due to the support of the logical type parameters, it makes sense to provide a number of functions of the user API for calling them from the template of the logical parameter.

The object "Parameter" [this]

• bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [for enabled parameter of the logical type] — adds the attribute id with the name name and the type tp. If the attribute is already present, the properties will be applied that can be changed on the go: name, selection mode and selection options.
  • id, name — identifier and name of the new attribute;
  • tp — attribute type [boolean | integer | real | string | text | object] + selection mode [sel | seled] + read-only [ro];
  • selValsNms — two lines with values in first and their names in second, separated by ";".
• bool attrDel( string id ) [for enabled parameter of the logical type] — removes the attribute id.

4 Service commands-functions of the Control Interface

Service functions are an interface for accessing OpenSCADA from external systems through the Control Interface. This mechanism is the basis of all exchange within OpenSCADA, implemented through weak links and OpenSCADA's own exchange protocol.

Getting for values of the template IO of the Logical Level parameter of the controller object
REQ: <get path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr" />

• CNTR, PRM — controller object and parameters.

RESP: <get path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr" rez="0">{IOs}</get>

• IOs — IOs of the template execution context of the Logical Level parameters in the tags "ta": <ta id="{ID}">{value}</ta>
  • ID — identifier of the IO;
  • value — value of the IO.

<get path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2ftmplAttr" rez="0" user="roman">
  <ta id="in">44.9998202036118</ta>
  <ta id="inProc" />
  <ta id="var">44.9999585116556</ta>
  <ta id="ed">ton/h</ta>
  <ta id="min">0</ta>
  <ta id="max">100</ta>
  <ta id="scSqr">0</ta>
</get>

Setting for values of the template IO of the Logical Level parameter of the controller object
REQ[root-DAQ]: <set path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr">{IOs}</set>

• CNTR, PRM — controller object and parameters;
• IOs — IOs of the template execution context of the Logical Level parameters in the tags "ta": <ta id="{ID}">{value}</ta>
  • ID — identifier of the IO;
  • value — value of the IO.

<set path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2ftmplAttr">
  <ta id="in">44.9998202036118</ta>
  <ta id="var">44.9999585116556</ta>
</set>