| Module | Name | Version | License | Source | Languages | Platforms | Type | Author | Description |
|---|---|---|---|---|---|---|---|---|---|
| VCAEngine | Visual control area engine | 4.1 | GPL2 | ui_VCAEngine.so | en,uk,ru,de | x86,x86_64,ARM | UI | Roman Savochenko Maxim Lysenko (2011-2012) — the page translation |
The main visual control area engine. |
The VCAEngine module provides visual control area engine (VCA) in OpenSCADA system. The module same does not implement the visualization of the VCA, and contains data in accordance with the ideology of "Model/data — Interface". Data visualization of that module is implemented by the visualization modules of VCA, such as Vision and WebVision.
Visual control area (VCA) is an integral part of the SCADA system. It applies to the client stations with a view to providing accessible information about the object and to for the the issuance of the control actions to the object. In various practical situations and conditions the VCA based on different principles of visualization may by applied. For example, this may be the library of widgets Qt, GTK+, WxWidgets or hypertext mechanisms based technologies HTML, XHTML, XML, CSS, and JavaScript, or third-party applications of visualization, realized in various programming languages Java, Python, etc. Any of these principles has its advantages and disadvantages, the combination of which could become an insurmountable obstacle to the use of VCA in a practical case. For example, technologies like the Qt library can create highly-reactive VCA, which will undoubtedly important for the operator station for control of technological processes (TP). However, the need for installation of that client software in some cases may make using of it impossible. On the other hand, Web-technology does not require installation on client systems and is extremely multi-platform (it is enough to create a link to the Web-server at any Web-browser) that is most important for various engineering and administrative stations, but the responsiveness and reliability of such interfaces is lower that actually eliminates the using of them at the operator of the TP stations.
OpenSCADA system has extremely flexible architecture that allows you to create external interfaces, including user and in any manner and for any taste. For example, the system configuration OpenSCADA as now available as by means of the Qt library, and also the Web-based.
At the same time creation of an independent implementation of the VCA in different basis may cause the inability to use the configuration of one VCA into another one. That is inconvenient and limited from the user side, as well as costly in terms of implementation and follow-up support. In order to avoid these problems, as well as to create as soon as possible the full spectrum of different types of VCA project of the creation of the conception of the VCA is established. The result of this project — the engine module(data model) of the VCA, as well as direct visualization modules Vision and WebVision.
This module of the engine (data model) of the VCA is aimed to create the logical structure of the VCA and the execution of sessions of individual instances of the VCA projects. Also, the module provides all the necessary data to the final visualizers of the VCA, both through local mechanisms of interaction of OpenSCADA, and through the management Interface of OpenSCADA for remote access.
The final version of the VCA module will provide:
Module itself does not contain mechanisms for visual creating interfaces of VCA, such tools can be given by the final visualization modules of the VCA, for example such a tool provides by the module Vision.
Although the mechanisms for the visual formation of the VCA the module doesn't provide the interface, implemented on the basis of the management interface of the OpenSCADA, to manage the logical structure is provided, and thus it is available for use in any system configurator of the OpenSCADA. Dialogues of this interface are considered further in the context of the architecture of the module and its data.
Any VCA can operate in two modes — the development and running. In the development mode the VCA interface and its components are formed, the mechanisms of interaction are identified. While the running it is carried out the formation of VCA interface based on the developed VCA with the final user interaction is made.
VCA interface is formed of the frames, each of which, in its turn, formed from elements of the primitives, or user interface elements. In doing so, the user interface elements are also formed from the primitives or other user elements. That gives us a hierarchy and reuse of already developed components.
Frames and user elements are placed in the libraries of widgets. The projects of the interfaces of the final visualization of the VCA are formed from these libraries' elements. Based on these projects the visualization sessions are formed.
The structure of VCA is shown in the Figure.
This architecture of the VCA allows the support of three levels of complexity of the developing process of the management interface:
Frame is the window which directly provides information to the user in a graphical or text form. The group of interconnected frames creates whole user interface of VC.
Contents of the frame is forming from the elements of visualization (widgets). Widgets may be the basic primitives (different elementary shapes, text, trend, etc.) and derivatives (formed from the basic or other derivatives of widgets). All the widgets are grouped into the libraries. In the process, you can build your own library of derivative widgets.
Actually the frame is also a widget that is used as a final element of visualization. This means that the widget libraries can store the blanks of frames and the templates of the resulting pages of the user interface.
Frames and widgets are passive elements that do not normally contain links to the dynamics and other frames, but only provide information about the properties of the widget and the nature of the dynamics (configuration), connected to the properties of the frame. Activated frames, ie containing links to the dynamics and active connections, form the user interface and are stored in the projects. In some cases, it is possible the direct appointment of the dynamics in the blanks of frames.
Derivative frames/widgets can contain other widgets (attached), which can be glued (associated) with the logic of one another by one of the languages of programming available in the OpenSCADA system.
The widget is an element, by means of which it is provided:
Tuning and linkage of the widgets is done through their properties. Parent widget and the widgets it contains, can be complemented by user properties. Then the user and static attributes are associated with the properties of embedded widget by internal logic. To show the dynamics (ie, current and archived data), properties of widgets are dynamized, that is linked with the attributes of the parameters of OpenSCADA or properties of other widgets. Using to link of the nested widgets by means of the internal logic with the available programming language of the OpenSCADA system eliminates the question of the implementation of complex logic of visualization, thus providing high flexibility. Practically, you can create fully dynamized frames with complex interactions at the level of the user.
Direct configuration and properties of the final visualization interface are contained in the project of the visualization interface of the VCA, which may be created lot ones.
Each project includes pages from the libraries of the frames/widgets. In some modes the page allowed to include into nested pages as independent from the parent and in using the parent as template. The template's page-widget allows to extremely simplify the process of creating the same type of the frames by the ACS-TP engineer or by the user of OpenSCADA for easy monitoring. An example of such one-type frames may be: groups of contours, groups of graphs, reports and various tables. Mnemonic schemes of technological processes rarely come under this scheme and will be formed directly in the description of the frame.
Page like to a widget on which it is based provides a possibility for bind the dynamics to described into properties, which links at all can be set to dynamic or resolved as constants. Besides, links to the dynamics on the project's page level is preferable to the widget of libraries level.
Example of hierarchical representations of components of the project of the classical interface of VC of the technological process with the description of standard call expressions is given in Figure.
Reserved next the special properties of pages:
Based on these properties combinations the following types of pages are realized:
On the side of the visualization (RunTime), on the following attributes of the basic element "Box", there is the logic regulating how to open the pages:
The logic of the method of the opening the pages works in the following way:
The project's session is expanded tree of the project for direct it execution, which includes an individual task of hierarchical the widget's procedures execution. For each project can be opened many sessions. The end-user visual interface forming performs by the visualizers from data of the project's session, after the session creation by the request.
Between widgets at the different levels of hierarchy complex inheritance relations are arranged, which are defined by the possibility of using some widgets by other ones, beginning with the library widget, and finishing with the widget to the session. To clarify these features of the interaction in Figure comprehensive map of "uses" inheritance is shown.
At the session level widget contains a object of values of calculation procedure. This object is initiated and used in the case of presence of the calculation procedure. At the time of the initialization the list of parameters of the procedure is created and a compilation of procedure is performed with these parameters in the module, implementing the selected programming language and encoded with the full name of the widget. A compiled function is connected to the object of values of the calculation procedure. Further the calculation is performed with the frequency of the session.
Calculation and processing of the widget on the whole runs in the following sequence:
The objects of the session of the project inherit from an abstract object "Widget" and use the appropriate objects of the project. Thus, the session ("Session") uses the project ("Project") and forms expand tree on its basis. Project page "Page" is directly used by the session page "SessPage". The remaining objects ("SessWdg") are deployed in accordance with the hierarchy of page elements.
In addition to the standard properties of an abstract widget ("Widget") elements of the pages of session themselves get the following properties: storage of the object of values of computational procedure, calculation of the procedures and mechanism for processing of the events. Pages of the session, in addition, contain a container of the following by the hierarchy pages. The session generally is computed with the frequency and in the consistency:
This policy allows you to circumvention the pages in accordance with the hierarchy, and to rise on the top during the one iteration for the widget events.
Sessions at the level of the control interface of OpenSCADA supports multi-language depended from values of the generic attributes "lang" and next "user" and which visualizer can set in proper way of self language. This function enabled for dynamic messages translation of OpenSCADA.
It knows that people can have individual characteristics in the perception of graphical information. If these features are not taken into account, it is possible to obtain the rejection and abruption of the user to the interface of VC. This rejection and abruption can lead to fatal errors in the management of TP, as well as traumatize the human by the continuous work with the interface. In SCADA systems the agreements are adopted, which regulate the requirements for creating a unified interface of VC normally perceived by most people. This is practically eliminates the features of people with some deviations.
In order to take this into account and allow centralized and easy to change the visual properties of the interface module is implementing a theme manager of the visualization interface.
User can create many themes, each of which will keep the color, font and other properties of the elements of the frame. Simple changing of the theme will allow you to change the interface of VC, and the possibility of appointing an individual theme in the user's profile allows to take into account his individual characteristics.
To realize this opportunity, when you create a frame, it is necessary for the properties of color, font and others set the "Config" (of the table in the "Process" tab) in the value of "From style". And in the parameter "Config template" to specify the identifier of the style field. Further, this field will automatically appear in the Style Manager and will be there to change. Style Manager is available on the project configuration page in the tab "Styles". On this tab you can create new styles, delete old ones, change the field of the style and delete unnecessary.
In general the styles are available from the project level. At the level of libraries of widgets you can only define styles fields of widgets. At the project level, at the choice of style, it is started the work with styles, which includes access to the fields of styles instead of direct attribute values. In fact, this means that when reading or writing a widget attribute these operations will be carried out with the corresponding field of the chosen style.
When you run the project execution it will be used the set in the project style. Subsequently, the user can select a style from the list of available ones. The user's style will be saved and used next time you run the project.
Given the range of tasks for which the OpenSCADA system may be used, it is necessary to provide a tool for management of interactive user events. This is due to the fact that in dealing with individual tasks of embedded systems, input and control devices can greatly vary. But it is enough to look at the regular office keyboard and notebook one, that would remove any doubt about the necessity for the manager of events.
The events manager must work using the maps of events. Map of the events — is the list of named events, indicating their origin. The origin of the events can be a keyboard, mouse, paddle, joystick, etc. At an event emerge the events manager is looking for it in the active map and compares with the name of the event. A comparison name of the event is placed in the queue for processing. Widgets in this case must process the given queue of events.
The active map of events is specified in the profile of each user or it is set by default (in planes).
In general, four types of events are provided:
Event itself represents deficiently information, especially if its processing occurs at higher level. For the unequivocal identification of the event and its source in the whole the event is recorded as follows: "ws_BtPress:/curtime". Where:
Table 3.5 provides a list of standard events, the support of which should be provided in visualizers of VCA.
Table 3.5. Standard events
| Id | Description |
|---|---|
| Keyboard events: key_[pres|rels][Ctrl|Alt|Shift]{Key} | |
| *SC#3b | Scan-code of the key. |
| *#2cd5 | Code of the unnamed key. |
| *Esc | "Esc". |
| *BackSpace | Removing of the previous character — "<--". |
| *Return, *Enter | Enter — "Enter". |
| *Insert | Insertion — "Insert". |
| *Delete | Deleting — "Delete". |
| *Pause | Pause — "Pause". |
| Print of the screen — "Print Screen". | |
| *Home | Home — "Home". |
| *End | End — "End". |
| *Left | Left — "<-". |
| *Up | Up — '^'. |
| *Right | Right — "->". |
| *Down | Down — '\/'. |
| *PageUp | Page up — "PageUp". |
| *PageDown | Page down — "PageDown". |
| *F1 ... *F35 | Function key from "F1" to "F35". |
| *Space | Space — ' '. |
| *Apostrophe | Apostrophe — '`'. |
| *Asterisk | Asterisk on an additional field of the keyboard — '*'. |
| *Plus | Plus on an additional field of the keyboard — '+'. |
| *Comma | Comma — ','. |
| *Minus | Minus — '-'. |
| *Period | Period — '.'. |
| *Slash | Slash — '\'. |
| *0 ... *9 | Number from '0' to '9'. |
| *Semicolon | Semicolon — ';'. |
| *Equal | Equal — '='. |
| *A ... *Z | Keys of Latin alphabet from 'A' to 'Z'. |
| *BracketLeft | Left square bracket - '['. |
| *BackSlash | Backslash — '/'. |
| *BracketRight | Right square bracket — ']'. |
| *QuoteLeft | Left quote — . |
| Keyboard focus events. | |
| ws_FocusIn | Focus is obtained by a widget. |
| ws_FocusOut | Focus is lost by a widget. |
| Mouse events: | |
| key_mouse[Pres|Rels][Left|Right|Midle] | Pressed/released the mouse button. |
| key_mouseDblClick | Double-click the left mouse button. |
| Events of quittance on the side of the visualizer. | |
| ws_alarmLev | Quittance of all violations by all notices methods and types. |
| ws_alarmNtf{N} | Quittance of all violations by the type {N} (0...7). |
| Events of the primitive of elemental figure ElFigure: | |
| ws_Fig[Left|Right|Midle|DblClick] | Activating of the figures (fills) by the mouse button. |
| ws_Fig{N}[Left|Right|Midle|DblClick] | Activating of the figure (fill) N by the mouse button. |
| Events of the primitive of form elements FormEl: | |
| ws_LnAccept | A new value in the input line is set. |
| ws_TxtAccept | The value of the text editor is changed. |
| ws_ChkChange | The state of the flag is changed. |
| ws_BtPress | The button is pressed. |
| ws_BtRelease | The button is released. |
| ws_BtToggleChange | The button toggle is changed. |
| ws_BtMenu={Item} | Selection of the menu Item. |
| ws_BtLoad | The selected file loaded. |
| ws_CombChange | The value of the combo box is changed. |
| ws_ListChange | The current list item is changed. |
| ws_TreeChange | The current tree item is changed. |
| ws_TableChangeSel | The table's item selection changed. |
| ws_TableEdit_{colN}_{rowN} | The table's cell ({colN}:{rowN}) edited. |
| ws_SliderChange | The slider position changed. |
| Events of the primitive of media content Media: | |
| ws_MapAct{N}[Left|Right|Midle] | Media area with the number N is activated by the mouse button. |
| ws_MediaFinished | Media-stream play is finished. |
Events are the main mechanism of notification and is actively used for user interaction. For the event processing there are two mechanisms:
The mechanism "Scripts for the control the opening of pages" based on the basic attribute of the widget "evProc", which can be used for switching, opening, substitution and navigation through the pages. The scenario of this attribute is stored as a list of commands with the syntax: "{event}:{evSrc}:{com}:{prm}". Where:
The following commands are implemented:
Special characters of the template are deciphered as follows:
To more and true the mechanism of the templates understanding lets cite some real examples:
As an example lets cite the scenario of operation of the main page of the user interface:
ws_BtPress:/prev:prev:/pg_so/*/*/$ ws_BtPress:/next:next:/pg_so/*/*/$ ws_BtPress:/go_mn:open:/pg_so/*/mn/* ws_BtPress:/go_graph:open:/pg_so/*/ggraph/* ws_BtPress:/go_cadr:open:/pg_so/*/gcadr/* ws_BtPress:/go_view:open:/pg_so/*/gview/* ws_BtPress:/go_doc:open:/pg_so/*/doc/* ws_BtPress:/go_resg:open:/pg_so/rg/rg/* ws_BtPress:/so1:open:/pg_so/1/*/* ws_BtPress:/so2:open:/pg_so/2/*/* ws_BtPress:/so3:open:/pg_so/3/*/* ws_BtPress:/so4:open:/pg_so/4/*/* ws_BtPress:/so5:open:/pg_so/5/*/* ws_BtPress:/so6:open:/pg_so/6/*/* ws_BtPress:/so7:open:/pg_so/7/*/* ws_BtPress:/so8:open:/pg_so/8/*/* ws_BtPress:/so9:open:/pg_so/9/*/* ws_BtPress:*:open:/pg_control/pg_terminator
The mechanism "Processing the events with the help of computational procedure of the widget" is based on the attribute "event" and the user procedure of calculating written with the help of the programming language of OpenSCADA. The events, in process of receipt, are accumulated in the attribute "event" till the moment of call of the computational procedure. The computational procedure is called with the specified frequency of calculating the widget and receives a value for the attribute "event" as the list of events. In the calculation procedure the user can: analyze, process and delete the processed events from the list, and add to the list new events. The remaining, after the procedure execution, and new events are analyzed for compliance with the conditions of the call by means of script of the primary mechanism, after which the remaining events are transmitted to the upper by the hierarchy widget to be processed by it, with the correction of the path of events in accordance with the hierarchy of the penetration of the event.
The content of the attribute "event" is a list of events in the format "{event}:{evSrc}", with the event on the separate line. Here is an example of processing events in the Java-like programming language of the OpenSCADA:
for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) {
if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001;
else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002;
else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004;
else ev_rez += sval+"\n";
}
event = ev_rez;
An important element of any visualization interface is the user notification about the violation — alarming. To simplify the perception, but also in mind the close connectivity of visualization and notification (typically notification is amplified with the visualization) it is decided to integrate the interface of a notification in the visualization interface. To do this, all the widget provides two additional attributes (of the session level): "alarm" and "alarmSt". Attribute "alarm" is used to form the signal by the widget, according to his logic, and attribute "alarmSt" is used to control the signaling fact of the branch of the tree of the session of the project.
Attribute "alarm" is a line and has the following format: "{lev}|{categ}|{message}|{type}|{tp_arg}"
Where:
Attribute "alarmSt" is an integer number that represents the maximum alarm level and the fact of the quittance of the branch of the tree of the session of the project. Format of the number is as follows:
Alarm formation and receipt of it by the visualizer.
The alarm formation is performed by the widget by setting its own attribute "alarm" in appropriate way and in accordance with it the attribute "alarmSt" of current and the parent widget is set. Visualizers receive notification of the alarm using a standard mechanism for notifications of the changes of attributes of widgets.
Taking into account that the processing of conditions of the signaling is made in the widgets, the pages containing the objects of signaling should be performed in the background, regardless of their openness to the moment. This is done by setting a flag of the background execution of the page.
Although the mechanism of signaling is built in the visualization area the possibility of formation of visual signaling elements remains, for example by creating the page that will never be opened.
Quittance
Quittance is process of accepting the violation(s) to mind, disabling the notification and action to remove the violation(s). In the display of user's interface the quittance assume only the notification disable.
Quittance performs by specifying the root of the branch of the widgets and the types of notification. This allows to make quittance on the side of visualizer both as by groups, for example by the signaling objects as well as individually by the objects. It is possible to independently quittance different types of alarms. Setting of the quittance is made by the simple modification of the attribute "alarmSt".
Example of the script to work with the signals gives below:
//Secretion of the existence of alarms for different ways of notification
cvt_light_en = alarmSt&0x100; cvt_alarm_en = alarmSt&0x200; cvt_sound_en = alarmSt&0x400;
//Secretion of the existence of alarms which not in quittance for different ways notification
cvt_light_active = alarmSt&0x10000; cvt_alarm_active = alarmSt&0x20000; cvt_sound_active = alarmSt&0x40000;
//Processing of the button's events of quittance and the quittance for different ways of notification
for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) {
if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001;
else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002;
else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004;
else ev_rez += sval + "\n";
}
event = ev_rez;
External notification methods
A first and a typical method of notifications is display's light notification by alarm colors and its dynamic about proper visual elements, which always presents and does not require of specific configuration. But often we need for an external type notification, for example: external lamp, PC buzzer or "howler", arbitrary sound, synthesized speech and etc.
For the possibility of implements the external notification methods and the accorded notification types are free described for the visualization server and same visualizers. On the visualization server side describes for forming/getting the notification resource and same notification. On the visualizers side describes a notification by the resources from the visualization server.
Description of rules and scenarios of notifications performs with user attributes of text type for pages of the visualization project, which applies at the page open. That is potentially for each opening page there possible describe self rules of notifications but typically here enough to describe a generic rules of notification on the main project's page, which open once and doesn't close in work:
//flags=notify[{DL}][|resource[|queue[|qMergeMess]]];
if(doRes) { The command text to form the resource. }
if(doNtf) { The command text to notify. }
//flags=notify[{DL}][|resource[|queue[|quittanceRet]]];
//name={The notifier name}
//ico={The icon name}
{ The notification command text to any or concrete visualizer. }
Flags:
The exchanging variables:
The examples and comments to work of typical notification methods:
//flags=notify
if(en) SYS.system("beep -f 1000 -l 1000000 &", true);
else if((beepPID=SYS.system("pidof beep")).toInt()) SYS.system("kill "+beepPID);
#!/bin/sh #flags=notify if test $en = 1; then beep -f 1000 -l 1000000 & else beepPID=$(pidof beep) if test "x$beepPID" != "x"; then kill $beepPID; fi fi
//flags=notify2
if(en) SYS.system("play -q alarm.ogg");
#!/bin/sh #flags=notify2 if test $en = 1; then play -q alarm.ogg; fi
//flags=queue
//flags=notify2|queue
if(doNtf && en && res.length) {
SYS.fileWrite("tmpPlay", res);
SYS.system("play -q tmpPlay");
SYS.fileRemove("tmpPlay");
}
#!/bin/sh #flags=notify2|queue if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
//flags=queue
//flags=notify2|queue
if(doNtf && en && mess.length) {
SYS.fileWrite("tmpForSpeech", mess);
SYS.system("festival --tts tmpForSpeech");
SYS.fileRemove("tmpForSpeech");
}
#!/bin/sh #flags=notify2|queue if test $doNtf = 1 -a $en = 1 -a "x" != "x$mess"; then echo $mess > tmpForSpeech festival --tts tmpForSpeech rm tmpForSpeech fi
//flags=notify2|resource
if(doRes) res = SYS.fileRead("alarm.ogg"); //Insert here a different method of generation
if(doNtf && en && res.length) {
SYS.fileWrite("tmpPlay", res);
SYS.system("play -q tmpPlay");
SYS.fileRemove("tmpPlay");
}
#!/bin/sh #flags=notify2|resource if test $doRes = 1; then cp -f alarm.ogg $res; fi #Insert here a different method of generation if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
//flags=notify2|resource
if(en && res.length) {
SYS.fileWrite("tmpPlay", res);
SYS.system("play -q tmpPlay");
SYS.fileRemove("tmpPlay");
}
#!/bin/sh #flags=notify2|resource if test $en = 1 -a -s $res; then play -q $res; fi
//flags=notify2|queue
if(doRes && mess.length) {
SYS.fileWrite("tmpText", mess);
SYS.system("text2wave tmpText -o tmpWAV");
res = SYS.fileRead("tmpWAV");
SYS.fileRemove("tmpText"); SYS.fileRemove("tmpWAV");
}
if(doNtf && en && res.length) {
SYS.fileWrite("tmpPlay", res);
SYS.system("play -q tmpPlay");
SYS.fileRemove("tmpPlay");
}
#!/bin/sh #flags=notify2|queue if test $doRes = 1 -a "x" != "x$mess"; then echo $mess > tmpText text2wave tmpText -o $res rm tmpText fi if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
//flags=notify2|queue
if(en && res.length) {
SYS.fileWrite("tmpPlay", res);
SYS.system("play -q tmpPlay");
SYS.fileRemove("tmpPlay");
}
#!/bin/sh #flags=notify2|queue if test $en = 1 -a -s $res; then play -q $res; fi
For the separation of access to the interface of VC and its components every widget contains information about the owner, about its group and access rights. Access rights are recorded as is the convention in the OpenSCADA system, in the form of a triad: "{user}{groups}{rest}" where each element consists of three attributes of access. Groups list writes through symbol ','. For the elements of the VCA the following interpretation is taken:
In the development mode a simple scheme of access "root.UI:RWRWR_" is used, which means — all users can open and view the libraries, their components and projects, and all users of group "UI" user interfaces) can edit.
In the running mode the right described in the components of interface work, which provide possibility for inheritance the owner and the permissions from top to bottom. Wherein by default the inheritance enabled for each widget, then they get the owner and the permissions of the project. Into that time, the permissions direct setting will propagate they to all components of the widget.
To provide relevant data in the visualization interface the data of subsystems "Data acquisition (DAQ)" must be used. The nature of these data as follows:
Considering the first list item it is necessary to allow the possibility of the group of destination links. To do this we use the conception of of the logic level.
In accordance with the list item 2, the links provide transparent conversion of connection types and do not require special configuration here.
To satisfy the opportunities for access to archives, in accordance with the list item 3, links make check of the type of the attribute, and in the case of connection to the "Address", the address of linkage is put into the value.
In terms of the VCA, the dynamic links and configuration of the dynamics are the one process, to describe a configuration of which the tab "Processing" of the widgets is provided. The tab contains a table of configuration of the properties of the attributes of the widget and the text of calculation procedure of the widget.
In addition to configuration fields of the attributes the column "Processing" in the table provides, for selective using of the attributes of the widgets in the computational procedure of the widget, and the columns "Configuration", "Configuration template", to describe the configuration of links.
If the "Processing" column is true, then the variable {widget ID}_{string ID}, for example, cw_value, becomes available in the computational procedure.
The column "Configuration" allows you to specify the linkage type for the attribute of the widget:
The column "Configuration template" makes it possible to describe the groups of dynamic attributes. For example, it may be different types of parameters of subsystem "DAQ" and other widgets of the interface. Furthermore, in the case of correct formation of this field, the mechanism of automatically assign of the attributes with the only indication of the parameter of subsystem "DAQ" or the widget is working, which simplifies and accelerates the configuration process. The value of this column has the following format:
Installation of the links may be of several types, which are determined by the prefix:
Processing of the links occurs at a frequency of calculating the widget in the following order:
In the Figure the tab of links with the group assignment of the attributes by the only specifying the parameter is presented, and in next Figure — with the individual appointment of the attributes.
When the widget that contains the configuration of links is placed to the container of widgets, all links of the source widget is added to the list of resulting links of the widgets' container, but only to a depth of one level of nesting.
The above shows that the links are set by the user in the configuration interface. However, for the possibility of creation of the frames for general use, with the function of providing detailed data of various sources of the same type, a dynamic linkage mechanism is necessary. Such mechanism is provided through a reserved key identifier "<page>" of the group of attributes of links in the frames of general purpose and dynamic linkage with the identifier "<page>" in the process of opening of the frame of general purpose by means of the signal from another widget.
Lets examine the example when we have the frame of general-purpose "Control panel of graph" and a lot of "Graphs" in different tabs. "Control panel of graph" has links with the templates:
At the same time, each widget "Graph" has the attributes tSek, tSize, trcPer and valArch. In the case of a calling of the opening signal of "Control panel of graph" from any widget "Graph" it is happening the linkage of the attributes of the "Control panel of graph" in accordance with the attribute specified in the template with the attribute of the widget "Graph". As a result, all changes in the "Control panel of graph" will be displayed on the graph by means of the link.
In the case of presence of external links to the parameters of subsystem "Data acquisition" in the widget "Graph", the links of "Control panel of graph" will be set on an external source. In addition, if in the "Control panel of graph" will be declared the links to the missing attributes directly in the widget "Graph", it will be made the search for the availability of such attributes from the external source, the first to which the link is directed, performing, thus, the addition of missing links.
To visualize this mechanism the table is cited.
Table. The mechanism of the dynamic linkage.
| Attributes of the "Control panel of graph" (the template of dynamic linkage) | "Graph" attributes | Attributes of an external "Parameter" | The resulting link or an value of the linking attribute |
|---|---|---|---|
| tSek (<page>|tSek) | tSek | - | "Graph".tSek |
| tSize (<page>|tSize) | tSize | - | "Graph".tSize |
| trcPer (<page>|trcPer) | trcPer | - | "Graph".trcPer |
| valArch (<page>|valArch) | valArch | - | "Graph".valArch |
| var (<page>|var) | var | var | "Parameter".var |
| ed (<page>|ed) | - | ed | "Parameter".ed |
| max (<page>|max) | - | - | EVAL |
| min (<page>|min) | - | - | EVAL |
Any newly created widget is based on one of several primitives (end element of the visualization) by installing of the kinship as directly to the primitive, as well as through the several intermediate user widgets. Each of the primitives contains a mechanism (logic) of the data model. A copy of the widget keeps the values of the properties of configuration of the the primitive specially for itself.
The tasks of the visualization interface includes support and work with the data model of the primitives of widgets. Primitives of the widget must be carefully developed and unitized in order to cover as many opportunities in the as possible to a smaller number of weakly connected with each other by their purpose primitives.
Table. The library of the primitives of widgets (basic elements of visualization).
| Id | Name | Function |
|---|---|---|
| ElFigure | Elementary graphic figures |
Primitive is the basis for drawing basic graphic shapes with their possible combinations in a single object. The support of the following basic figures is provided:
For all the figures contained in the widget it is set the common properties of thickness, color, etc., but this does not exclude the possibility of indicating the above attributes for each figure separately. |
| FormEl | Elements of the form |
Includes support for standard form components:
|
| Text | Text | Text element (labels). Characterized by the type of font, color, orientation and alignment. |
| Media | Media | Element of visualization of raster and vector images of various formats, playback of animated images, audio segments and video fragments. |
| Diagram | Diagram | Element of the diagram with the support of the visualization of the flow of several trends, the spectrum, XY diagrams of real-time data, ... . |
| Protocol | Protocol | Element of the protocol, visualizer of the system messages, with support for multiple operating modes. |
| Document | Document | The element of generating the reports, journals and other documentation on the basis of available in the system data. |
| Box | Container | Contains the mechanism for other widgets placement-including with the purpose of creation of new, more complex, widgets and pages of end visualization. |
| Function, in plane | Function of API of the object model of OpenSCADA | Not visual, on the side of execution, widget which allows to include a computing function of the object model of OpenSCADA in the VCA. |
Table. The common set of properties/attributes in the widget
| Id | Name | Number | Value |
|---|---|---|---|
| id | Id | - | Id of the element. The attribute is read-only, designed to provide information on the ID of the element. |
| path | Path | - | The path to the widget. The attribute is read-only and designed to provide full information about the location of the element. |
| parent | Parent | - | Path to the parent widget. The attribute is read-only and designed to provide information about the location of ancestor which the widget is inherited from. |
| owner | Owner | - | The widget owner and group in form "{owner}:{group}", by default the "root:UI". |
| perm | Permission | - |
Permission to the widget in form "{user}{group}{other}" plus inheritance flag, includes the inheritance owner and it's permissions from upper widget.
By default the 01000(inheritance). |
| root | Root | 1 | Id of the widget-primitive (basic element) which underlies the image of visualization of the widget. |
| name | Name | - | Name of the element. Modifiable the element name. |
| dscr | Description | - | Description of the element. Text field, serves for attachment to the widget of the brief description. |
| en | Enabled | 5 | The state of the element — "Enabled". Disabled element is not shown in the execution mode. |
| active | Active | 6 | The state of the element — "Active". Active element may receive focus in the execution mode, and thus receive keyboard and other events with their subsequent processing. |
| geomX | Geometry:x | 7 | Geometry, coordinate 'x' of the element position. |
| geomY | Geometry:y | 8 | Geometry, coordinate 'y' of the element position. |
| geomW | Geometry:width | 9 | Geometry, the width of the element. |
| geomH | Geometry:height | 10 | Geometry, the height of the element. |
| geomXsc | Geometry:x scale | 13 | The horizontally scale of the element. |
| geomYsc | Geometry:y scale | 14 | The vertical scale of the element. |
| geomZ | Geometry:z | 11 | Geometry, coordinate 'z' (level) of element on the page. It also defines order to transfer the focus through active elements. |
| geomMargin | Geometry:margin | 12 | Geometry, the margins of the element. |
| tipTool | Tip:tool | 15 | The text of a brief help or tip on this element. Usually is realized as a tool tip, while keeping your mouse cursor over the element. |
| tipStatus | Tip:status | 16 |
Text information on the status of the element or the guide to action over the element. Usually is implemented in the form of a message in the status bar while keeping your mouse cursor over the element.
|
| contextMenu | Context menu | 17 |
Context menu in form strings list: "{ItName}:{Signal}".
|
| evProc | Events process | - |
Attribute for storing of the script of the processing of event of direct control of user interface. Script is the list of commands to the visualization interface generated at the event receipt (attribute event). Direct events processing for pages manipulation in form: "{event}:{evSrc}:{com}:{prm}". Where:
Examples:
|
| Additional attributes for items placed into the project in the role of a page. | |||
| pgOpen | Page:open state | - |
Sign "The page is open".
|
| pgNoOpenProc | Page:process not opened | - | Sign "Execute the page, even if it is closed". |
| pgOpenSrc | Page:open source | 3 |
Full address of the page which has opened this one.
|
| pgGrp | Page:group | 4 | The group of the page. |
| Additional attributes of the execution mode — by the session. | |||
| event | Event | - | Special attributes for the collection of events of the widget in the list, which is divided by the new line. Access to the attribute is protected by the resource allocation in order to avoid loss of the events. The attribute is always available in the script of widget. |
| load | Load | -1 | The virtual command of the group data download. |
| focus | Focus | -2 | The special attribute of the indicating the fact of receiving the focus by an active widget. Attribute of the widget and of the the embedded widgets is available in the script of widget. |
| perm | Permission | -3 | The virtual attribute of the rights verification of active user on the viewing and control over the widget. |
The visualization engine provides visualizer specific attributes activation. The process of activation does at a session of the project opening and minds for the project: creation of the specific attribute with pointed properties, at case it lack, and activation for modification tracing by the visualization engine, like to the attributes of forming primitive's shapes. For the specific attributes list of the visualizer you can see to proper documentation of the visualizer.
Primitive is the basis for drawing basic graphic shapes with their possible combinations in a single object. Taking into account the wide range of various shapes, which must be maintained by the primitive, and at the same time the primitive must be simple enough for using and, if possible, for implementation, it was decided to limit the list of the basic figures used for the construction of the resulting graphics to these figures: line, arc, Bézier curve and fill of the enclosed spaces. Based at these basic figures, it is possible to construct derived figures by combining the basic. In the context of the primitive, there is possibility to set the transparency of the color in the range [0...255], where '0' — complete transparency.
Table. A list of additional properties/attributes of the primitive "ElFigure"
Primitive is intended to provide the standard form elements to the user. The general list of attributes depends on the type of element.
Table. A set of additional properties/attributes of the primitive "FormEl"
| Id | Name | Number | Value |
|---|---|---|---|
| elType | Element's type | 20 | Type of the element: "Line edit", "Text edit", "Check box", "Button", "Combo box", "List", "Tree", "Table", "Slider", "Scroll bar". On its value it depends a list of additional attributes. |
| Line edit: | |||
| value | Value | 21 | The contents of the line. |
| view | View | 22 | Type of the editing line: "Text", "Combobox", "Integer", "Real", "Time", "Date", "Date and Time". |
| cfg | Configuration | 23 | Configuration of the line. The format of the value of the field for different types of lines:
|
| confirm | Confirm | 24 | Enable the confirm mode. |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}", where:
Examples:
|
| Text edit: | |||
| value | Value | 21 | The contents of the editor. |
| wordWrap | Word wrap | 22 | Automatic division of text by the words. |
| confirm | Confirm | 24 | Enable confirm mode. |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (details above). |
| Check box: | |||
| name | Name | 26 | Name/label of the checkbox. |
| value | Value | 21 | Value of the checkbox. |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (details above). |
| Button: | |||
| name | Name | 26 | Name, the inscription on the button. Allowed symbols '\n' for multiple line names. |
| value | Value | 21 | The value, different for modes:
|
| img | Image | 22 | The image on the button. Image name in form "[{src}:]{name}", where:
Examples:
|
| color | Color | 23 | Color of the button. Color name form "{color}[-{alpha}]", where:
Examples:
|
| colorText | Color:text | 27 | The color of the text. (details above) |
| mode | Mode | 24 | The button operation mode:
|
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (details above). |
| List: | |||
| value | Value | 21 | Current value of the list. |
| items | Items | 22 | The entries of the list. |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (details above). |
| mult | Multiple selection | 23 | Allow for multiple entries selection of the list. |
| Combo box, Tree: | |||
| value | Value | 21 | Current value of the list. |
| items | Items | 22 | The entries of the list or hierarchical items list of tree in path "/{DIR}/{DIR}/{ITEM}". |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (details above). |
| Table: | |||
| set | Setting value | 23 | The value of edition of a cell of the table which address into the event "ws_TableEdit_{colN}_{rowN}". |
| value | Value | 21 | Address of the selected item. It changing follows by the signal "ws_TableChangeSel". The address format depends from the table's selection mode:
|
| items | Elements | 22 |
The table structure and content in XML view:
<tbl>
<h><s>{Header1}</s><s>{Header2}</s></h>
<r><s>{Row1Column1String}</s><i>{Row1Column1Integer}</i></r>
<r><b>{Row2Column1Logical}</b><r>{Row2Column2Real}</r></r>
</tbl>
The tags:
|
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}" (the details above). |
| Slider and Scroll Bar: | |||
| value | Value | 21 | The slider position. |
| cfg | Configuration | 22 | Configuration of the slider in the format: "{VertOrient}:{Min}:{Max}:{SinglStep}:{PageStep}". Where:
|
This primitive is designed to display the plain text used as labels, and different signatures. With the reason of creating a simple frequent decorations the primitive must support the surrounding of the text by frame.
Table. The list of additional properties/attributes of the primitive "Text"
| Id | Name | Number | Value |
|---|---|---|---|
| backColor | Background:color | 20 | Background color. Color name in form "{color}[-{alpha}]", where:
Examples:
|
| backImg | Background:image | 21 | Background image. The image name in form "[{src}:]{name}", where:
Examples:
|
| bordWidth | Border:width | 22 | Border width. |
| bordColor | Border:color | 23 | Border color (detailed in attribute 20). |
| bordStyle | Border:style | 24 | Border style: "None", "Dotted", "Dashed", "Solid", "Double", "Groove", "Ridge", "Inset", "Outset". |
| font | Font | 25 | Font name form "{family} {size} {bold} {italic} {underline} {strike}", where:
Examples:
|
| color | Color | 26 | Text color (detailed in attribute 20). |
| orient | Orientation angle | 27 | Orientation of text, rotation on angle. |
| wordWrap | Word wrap | 28 | Automatic division of text by words. |
| alignment | Alignment | 29 | Alignment of the text: "Top left", "Top right", "Top center", "Top justify", "Bottom left", "Bottom right", "Bottom justify", "V center left", "V center right", "Center", "V center justify". |
| text | Text | 30 | Text value. Use "%{x}" for argument "x" (from 1) value insert to. |
| numbArg | Arguments number | 40 | Arguments number. |
| Attributes of the arguments | |||
| arg{x}val | Argument {x}:value | 50+10*x | Argument x value. |
| arg{x}tp | Argument {x}:type | 50+10*x+1 | Argument x type: "Integer", "Real", "String". |
| arg{x}cfg | Argument {x}:config | 50+10*x+2 | Argument x configuration:
|
This primitive is designed to play different media materials, ranging from simple images to the full audio and video streams.
Table. A set of additional properties/attributes of primitive "Media"
| Id | Name | Number | Value |
|---|---|---|---|
| backColor | Background:color | 20 | Background color. Color name in form "{color}[-{alpha}]", where:
Examples:
|
| backImg | Background:image | 21 | Background image. The image name in form "[{src}:]{name}", where:
Examples:
|
| bordWidth | Border:width | 22 | Border width. |
| bordColor | Border:color | 23 | Border color (detailed in attribute 20). |
| bordStyle | Border:style | 24 | Border style: "None", "Dotted", "Dashed", "Solid", "Double", "Groove", "Ridge", "Inset", "Outset". |
| src | Source | 25 | Media source name in form "[{src}:]{name}", where:
Examples:
|
| type | Type | 27 | Media type variant:
|
| areas | Map areas | 28 | Number of active areas. |
| The attributes of the image (Image) | |||
| fit | Fit to the widget size | 26 | Sign "Coordinate the contents with the size of the widget". |
| The attributes of the video (Movie) | |||
| fit | Fit to the widget size | 26 | Sign "Coordinate the contents with the size of the widget". |
| speed | Play speed | 29 | The speed of playback, as a percentage from the original speed. If the value is less than 1%, the playback stops. |
| The attributes of the full video (Full video) | |||
| play | Play | 29 | Video/audio - "Play". |
| roll | Roll play | 30 | Roll play on the finish. |
| pause | Pause | 31 | Playing pause. |
| size | Size | 32 | Total video size (in milliseconds). |
| seek | Seek | 33 | Seek video playing (in milliseconds). |
| volume | Volume | 34 | Sound volume [0...100]. |
| Active areas | |||
| area{x}shp | Area {x}:shape | 40+3*x | Type of the area x: "Rect", "Poly", "Circle". |
| area{x}coord | Area {x}:coordinates | 40+3*x+1 | The coordinates of area x, are separated by commas: "x1,y1,x2,y2,xN,yN" |
| area{x}title | Area {x}:title | 40+3*x+2 | Title of the area x. |
This primitive targeted to construct various diagrams, including graphs/trends showing ongoing process and the archive data. Following types of the diagrams are implemented:
For all the diagram types possible as the data source sets:
Supported tracing of the current values and the values from the archive, and also the possibility of building the graphs of the parameters which have no archive of values, by the current values accumulation into the diagram buffer and only at the diagram active visibility moment.
The process of access to the archive data is optimized, by means of an intermediate buffer for the display, as well as the package of traffic data in the query, by way the data lead to quality enough for display.
Table. A list of additional properties/attributes of the primitive "Diagram"
| Id | Name | Number | Value |
|---|---|---|---|
| backColor | Background:color | 20 | Background color. Color name in form "{color}[-{alpha}]", where:
Examples:
|
| backImg | Background:image | 21 | Background image. The image name in form "[{src}:]{name}", where:
Examples:
|
| bordWidth | Border:width | 22 | Border width. |
| bordColor | Border:color | 23 | Border color (detailed in attribute 20). |
| bordStyle | Border:style | 24 | Border style: "None", "Dotted", "Dashed", "Solid", "Double", "Groove", "Ridge", "Inset", "Outset". |
| trcPer | Tracing period (s) | 25 | Mode and frequency of the tracing. |
| type | Type | 26 | Diagram type: "Trend", "Spectrum", "XY". |
| General attributes for all the types | |||
| tSek | Time:seconds | 27 | Current time, seconds. |
| tUSek | Time:microseconds | 28 | Current time, microseconds. |
| tSize | Size, seconds | 29 | Size of the trend, seconds. |
| curSek | Cursor:seconds | 30 | Cursor position, seconds. |
| curUSek | Cursor:usek | 31 | Cursor position, microseconds. |
| curColor | Cursor:color | 32 | Cursor color. |
| sclColor | Scale:color | 33 | Color of the scale/grid (detailed in attribute 20). |
| sclHor | Scale:horizontal | 34 | Horizontal mode of the scale/grid: "No draw", "Grid", "Markers", "Grid and markers", "Grid (log)", "Markers (log)", "Grid and markers (log)". |
| sclHorScl | Scale:horizontal scale (%) | 44 | Graphics's horizontal scale in percents, excluding for type "XY". |
| sclHorSclOff | Scale:horizontal scale offset (%) | 45 | Offset of graphics's horizontal scale in percents, excluding for type "XY". |
| sclVer | Scale:vertical | 35 | Vertical mode of the scale/grid: "No draw", "Grid", "Markers", "Grid and markers", "Grid (log)", "Markers (log)", "Grid and markers (log)". |
| sclVerScl | Scale:vertical scale (%) | 40 | Graphics's vertical scale in percents. |
| sclVerSclOff | Scale:vertical scale offset (%) | 41 | Offset of graphics's vertical scale in percents. |
| sclMarkColor | Scale:Markers:color | 36 | Color of the markers of the scale/grid (detailed in attribute 20). |
| sclMarkFont | Scale:Markers:font | 37 | Font of the markers of scale/grid. Font name form "{family} {size} {bold} {italic} {underline} {strike}", where:
Examples:
|
| valArch | Value archiver | 38 | Value archiver in form "{ArchMod}.{ArchivatorId}". |
| valsForPix | Values for pixel | 42 | The number of values per pixel. Increase to enhance the accuracy of export at large time intervals. |
| parNum | Parameters number | 39 | The number of parameters that can be displayed on the one trend. |
| Attributes for type: "Graph" | |||
| sclHorPer | Scale:horizontal grid size, seconds | 43 | Fixed a grid period of horizontal scale, disable automatic calculation for the grid period. Activated if the periods number into overall size more for two and one period size more for 15 pixels. |
| Individual attributes of the parameters of trend/graph/XY | |||
| prm{X}addr | Parameter {X} :address | 50+10*{X} | Full address to DAQ attribute of a parameter X or to an archive. Also supported direct data set by the prefixes:
Example:
|
| prm{X}bordL | Parametr {X}:view border:lower | 50+10*{X}+1 | Lower limit of the parameter X. |
| prm{X}bordU | Parametr {X}:view border:upper | 50+10*{X}+2 | Upper limit of the parameter X. |
| prm{X}color | Parametr {X}:color | 50+10*{X}+3 | Color for display of the trend of the parameter X (detailed in attribute 20). |
| prm{X}width | Parametr {X}:width | 50+10*{X}+6 | Line width for display of the trend of the parameter X, in pixels. |
| prm{X}scl | Parametr {X}:scale | 50+10*{X}+5 | Separated vertical scale mode of the parameter X: "Global", "Markers", "Grid and markers", "Markers (log)", "Grid and markers (log)". |
| prm{X}val | Parametr {X}:value | 50+10*{X}+4 | Value of the parameter X under the cursor. |
| prm{X}prop | Parametr {X}:properties | 50+10*{X}+7 | Real archive properties in form "{BegArh}:{EndArh}:{DataPeriod}", where "BegArh", "EndArh", "DataPeriod" — begin, end and period of archive's data in seconds, real up to microseconds (1e-6). |
This primitive is designed to visualize the data of the archive of messages through the formation of protocols with different ways of visualization, starting from a static scanning view and finishing with dynamic tracing of protocol of message.
Table. A list of additional properties/attributes of the primitive "Protocol"
| Id | Name | Number | Value |
|---|---|---|---|
| backColor | Background:color | 20 | Background color. Color name in form "{color}[-{alpha}]", where:
Examples:
|
| backImg | Background:image | 21 | Background image. The image name in form "[{src}:]{name}", where:
Examples:
|
| font | Font | 22 | Font of markers of scale/grid. Font name form "{family} {size} {bold} {italic} {underline} {strike}", where:
Examples:
|
| headVis | Header visible | 23 | Show header for table or not. |
| time | Time, seconds | 24 | Current time, seconds. |
| tSize | Size, seconds | 25 | Query size, seconds. Set value to '0' for get all alarms, for "lev" < 0. |
| trcPer | Tracing period (s) | 26 | Mode and frequency of tracing. |
| arch | Archivator | 27 | Messages archivator in form "{ArchMod}.{ArchivatorId}". |
| tmpl | Template | 28 | Category template or regular expression "/{re}/". For template reserved special symbols:
|
| lev | Level | 29 | The level of messages. Set value to < 0 for get the current alarms. |
| viewOrd | View order | 30 | View order: "By time", "By level", "By category", "By messages", "By time (reverse)", "By level (reverse)", "By category (reverse)", "By messages (reverse)". |
| col | View columns | 31 | Visible and order columns list separated by symbol ';'. Supported columns:
|
| itProp | Item properties | 32 | Item's properties number. |
| Individual attributes of the item's properties | |||
| it{X}lev | Item {X}:level | 40+5*{X} | Criterion: element's level X, more or equal for pointed. |
| it{X}tmpl | Item {X}:template | 40+5*{X}+1 | Criterion: element's category template X (detailed in attribute 28). |
| it{X}fnt | Item {X}:font | 40+5*{X}+2 | Element X font (detailed in attribute 22). |
| it{X}сolor | Item {X}:color | 40+5*{X}+3 | Element X color (detailed in attribute 20). |
The primitive is designed to creation report, operational and other documents based on templates of documents.
Table. A list of additional properties/attributes of the primitive "Document".
| Id | Name | Number | Value |
|---|---|---|---|
| style | CSS | 20 | CSS rules in rows like "body { background-color:#818181; }". |
| tmpl | Template | 21 | Document's template in XHTML, starts from tag "body" and include procedures parts:
<body docProcLang="JavaLikeCalc.JavaScript"> <h1>Value<?dp return wCod+1.314;?></h1> </body> |
| doc | Document | 22 | Final document in XHTML, starts from tag "body". |
| font | Font | 26 | Basic font of the text. Font name form "{family} {size} {bold} {italic} {underline} {strike}", where:
Examples:
|
| bTime | Time:begin | 24 | Start time of the document, seconds. |
| time | Time:current | 23 | Time of the document generation, seconds. Write the time for the document generation from that point or zero for regeneration. |
| n | Archive size | 25 | Number of documents or the depth of the archive. |
| Attributes of the enabled archival mode | |||
| aCur | Archive:cursor:current | - | Position of the current document in the archive. Record of the value <0 produces the archiving of this document. |
| vCur | Archive:cursor:view | - | Current visual document of the archive. Writing a value of -1 — to select next document, -2 — to select previous document. |
| aDoc | Archive:current document | - | Current archive document in XHTML, starts from the tag "body". |
| aSize | Archive:size | - | Real the archive document size. |
Features of the primitive "Document":
The basis of any document is XHTML-template. XHTML-template is the tag "body" of the WEB-page which contains the document's static in the standard XHTML 1.0 and elements of the executable instructions in one of the languages of the user programming of OpenSCADA in the form of <?dp {procedure} ?>. The resulting document is formed by the execution of procedures and insert of their result into the document.
The source for values of the executable instructions are the attributes of the widget of the primitive, as well as all the mechanisms of the user programming language. Attributes may be added by the user and they can be linked to the actual attributes or parameters or they can be autonomous, values of which will be formed in the script of the widget. In the case of linked attributes the values can be extracted from the history, archive.
Fig. 3.8.7.a shows a block diagram of the widget of the primitive "Document". According to this structure "Document" includes: XHTML-template, the resulting documents and the processing script. The data source for the script and for the resulting documents are the attributes of the widget.
It is provided the work of the widget in two modes: "Dynamic" and "Archive". The difference between archive mode is the availability of the archive of the specified depth and attributes which allow you to control the process of archiving and viewing of the document in the archive.
Generation of the document is always performed at the time of installation of the time attribute time relatively to the set start time of the document in the attribute bTime. With the archive turned off the resulting document is placed directly in the attribute doc. When the archive is turned on the resulting document is placed in the cell under the cursor, the attribute aCur, as well as in doc if the value of the archive cursor aCur and the cursor of visualized document vCur match. Attributes of the archival cursors provide several commands of values:
As it was stated above dynamics of the document's template is defined by the inserts of executable instructions of the form "<?dp {procedure} ?>". The procedures may use the same attributes of the widget and functions of the user programming interface of OpenSCADA. In addition to the attributes of the widget special attributes (Table 3.8.7.a) are reserved.
Table 3.8.7.a. Special and reserved elements of the template.
| Name | Assignment |
|---|---|
| Attributes | |
| rez | Attribute of the results of the procedure execution, the contents of which is placed to the document tree. |
| lTime | Last formation time. If the document is formed for the first time, lTime is equal to the bTime. |
| rTime | Contains the time for the selected values in seconds, it is defined inside the tags with the attribute "docRept". |
| rTimeU | Contains the time for the selected values in microseconds, it is defined inside the tags with the attribute "docRept". |
| rPer | Contains the periodicity of the selection of values (the attribute "docRept"). |
| mTime, mTimeU, mLev, mCat, mVal | It is defined inside the tags with an attribute "docAMess" when parsing messages of the messages' archive:
|
| Special tags | |
| Special attributes of the standard tags | |
| body.docProcLang | Language of executable procedures of the document. By defaults it is "JavaLikeCalc.JavaScript". |
| *.docRept="1s" | Tag with the specified attribute, while the formation it multiplies through the time offset in the attribute "rTime" to the value, specified in this attribute. |
| *.docAMess="1:PLC*" | Indicates the necessity of the tag multiplication with an attribute of message from the archive of messages for the specified interval of time, in accordance with the level of "1" and template of request "PLC*" by the messages category. The template request may specify a regular expression in the form of "/{re}/". For this tag in the process of multiplication the following attributes: mTime, mTimeU, mLev, mCat and mVal are defined. |
| *.docAMessArchs="ArchMod0.Archivator0[;ArchModN.ArchivatorN]" | The attribute "*.docAMess" appends by a list of archivators for messages reading. |
| *.docRevers="1" | Points to invert of the order of multiplication, the last from the top. |
| *.docAppend="1" | The sign of the necessity of addition of the procedure execution result in the tag of the procedure. Otherwise, the result of execution replaces the contents of the tag. |
| body.docTime | Time of formation of the document. It is used to set the attribute lTime in the time of the next formation of the document. It is not set by the user! |
| table.export="1" | Enable for selected table content allow for export to CSV-file and other table formats. |
The primitive container is used to build composite widgets and/or the pages the user interface.
Table. A list of additional properties/attributes of the primitive Box
| Id | Name | Number | Value |
|---|---|---|---|
| pgOpenSrc | Page:open source | 3 | Full address of the page, included inside of the container. |
| pgGrp | Page:group | 4 | Group of the container of the pages. |
| backColor | Background:color | 20 | Background color. Color name in form "{color}[-{alpha}]", where:
Examples:
|
| backImg | Background:image | 21 | Background image. The image name in form "[{src}:]{name}", where:
Examples:
|
| bordWidth | Border:width | 22 | Border width. |
| bordColor | Border:color | 23 | Border color (detailed in attribute 20). |
| bordStyle | Border:style | 24 | Border style: "None", "Dotted", "Dashed", "Solid", "Double", "Groove", "Ridge", "Inset", "Outset". |
Storage of widgets, widgets libraries and projects are implemented into the databases accessible in the OpenSCADA system. The DB is structured on the data belonging to the library-project. Ie a separate library-project stores in a separate group of tables of one or of the different databases. The list of libraries of widgets is stored in the index table of the libraries with the name "VCALibs", with the structure "Libs", and the list of projects in the index table "VCAPrjs", with the structure "Projs". A copy of this table is created in each database, which stores data of the module with the list of libraries which are hold in a given database. To the list of the tables belonging to the library of widgets and projects, are included:
Projections (structures) of basic tables are as follows:
API of the user programming of API of the visualization engine are represented by the OpenSCADA objects directly, which build user interface, and same "Session" and "Widget/page". These objects provide the set of control functions for the user:
Object "Session" ( this.ownerSess() )
Object "Widget" (this)
//New widget adding, based at the text primitive
nw = this.wdgAdd("nw", "New widget", "/wlb_originals/wdg_Text");
nw.attrSet("geomX", 50).attrSet("geomY", 50);
//Set link for eight trend to the parameter
this.linkSet("el8.name", "prm:/LogicLev/experiment/Pi", true);
Object "Widget" of the primitive "Document" (this)
The deprecated API of the user programming of the visualization engine are represented by the group of functions directly in the engine module of the VCA. Calling of these functions from the scripts of widgets can be performed directly by the ID of the function, since their area of names is indicated for the context of the scripts of widgets.
Widget list (WdgList)
Description: Returns a list of widgets in the container of widgets or a list of child widgets. If pg is set it returns a list of pages for the projects and sessions.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| list | List | String | Return | |
| addr | Address | String | Input | |
| pg | Pages | Bool | Input | 0 |
Presence of the node (NodePresent)
Description: Check for the presence of the node, including widgets, attributes and others.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| rez | Result | Bool | Return | |
| addr | Address | String | Input |
Attributes list (AttrList)
Description: Returns list of attributes of the widget. If noUser is set then only not user attributes are returned.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| list | List | String | Return | |
| addr | Address | String | Input | |
| noUser | Without user | Bool | Input | 1 |
Request of the attribute (AttrGet)
Description: Request of the value of the attribute of the widget. The request can be done as by indicating the full address of the attribute in addr, and by indicating separately the address of the widget in addr, and the ID of the attribute in the attr.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| val | Value | String | Return | |
| addr | Address | String | Input | |
| attr | Attribute | Bool | Input |
Setting of the attribute (AttrSet)
Description: Setting of the value of the attribute of the widget. Setting can be done as by the indicating the full address of the attribute in addr, and by indicating separately the address of the widget in addr, and the ID of the attribute in attr.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| addr | Address | String | Input | |
| val | Value | String | Input | |
| attr | Attribute | Bool | Input |
Session user (SesUser)
Description: Return the session user by the session's widget path.
Parameters:
| ID | Name | Type | Mode | By default |
|---|---|---|---|---|
| user | User | String | Return | |
| addr | Address | String | Input |
Service interfaces are interfaces of access to the OpenSCADA system by means of OpenSCADA control interface from external systems. This mechanism — is the basis of all the mechanisms for interaction within OpenSCADA, implemented through the weak ties, and standard exchange protocol of OpenSCADA.
In order to provide unitized, grouping and relatively fast access to the values of attributes of the visual elements the service function of the visual element "/serv/attr" and get/set commands of the attributes' values are provided: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> and <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/>.
Table. Attributes of commands for get/set of the attributes of the visual elements.
| Id | Name | Value |
|---|---|---|
| Requesting command of the visual attributes of the widget: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> | ||
| tm | Time/counter of the changes | Time/counter of the changes set up for the query of the only changed attributes. |
| <el id="{attr}" p="{a_id}">{val}</el> | The formation of the child elements with the results of the attributes | In the child element are specified: string ID attr of the attribute, index a_id of the attribute and its value val. |
| Setting command of the visual attributes of the widget: <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> | ||
| <el id="{attr}">{val}</el> | Setting of the attributes | In the child elements the ID of the attribute attr and its value val are specified. |
| Activation-creation command of specific for the visualizer attribute: <activate path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr/{attrId}" aNm="{Name}" aTp="{Type} aFlg="{Flags}"/> | ||
| attrId | Attribute identifier | |
| aNm | Attribute name | |
| aTp | Attribute type | |
| aFlg | Attribute flags | |
In order to optimize network traffic by eliminating the small queries, but use one, but a large the group query of the attributes' values of visual elements is made. Grouping of this query involves a request of attributes of the entire branch of the widget, including the embedded elements. For this request the service command "/serv/attrBr" provides. Request of this service command is equivalent to the service command "/serv/attr" and looks as follows: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattrBr"/>
Result:
In order to unify and optimize the access to the pages the service function of the session "/serv/pg" and commands of the query of the list of open pages <openlist path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; of opening the pages <open path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; and closing of the pages <close path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/> are provided.
The result of the query is child elements <el>{OpPage}</el> which contain the full path of the open page. In addition to the list of open pages, the query returns the value of the current counter for calculating the session in the attribute tm. If this attribute is set during the query, then for each open page it returns the list of changed, since the moment of the specified value of the counter, widgets of the open page.
To provide a mechanism for global control of the signaling of the session the service function of the session "/serv/alarm" and commands of the query of the signals status <get path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/>; and of the quittance <quittance path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/> are provided.
Request for the status of signals returns generalized condition of the signals, as well as additional a notification resource by attribute "mode" sets to "resource". The notification resource request result is typically a sound file, for playback, and at that time it performs monitoring of the sequence of signaling and quittance of individual the notification resources of the messages.
Request for the quittance performs quittance of the specified widget, attribute wdg, in accordance with the template, attribute tmpl.
To provide a unitize mechanism for manipulation of the sessions by the visualizers of VCA in the module of the VCA engine (VCAEngine) are provided the service function "/serv/sess" and the query commands of the list of open sessions, connection/creation of the new session and disconnection/deleting of the session: <list path="/UI/VCAEngine/%2fserv%2fsess"/>, <connect path="/UI/VCAEngine/%2fserv%2fsess"/> and <disconnect path="/UI/VCAEngine/%2fserv%2fsess"/> accordingly.
Table. Attributes of commands of the mechanism of manipulation with sessions
| Id | Name | Value |
|---|---|---|
| Command of requesting of a list of open sessions for the project: <list path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
| prj | Indication of the project | Specifies the project for which to return the list of open sessions. |
| <el>{Session}</el> | Control of the sessions' list | In the child element the open for the requested project sessions are specified. |
| The command of the connection/opening of the session: <connect path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
| sess | Installation and control of the session name | If the attribute is defined, then connecting to an existing session is to be made, else — creation of the new session is to be made. In the case of opening of the new session in this attribute its name is is placed. |
| prj | Setting the name of the project | It is used to open a new session for indicated project and when the attribute sess is not specified. |
| The command of disconnection/closing of the session: <disconnect path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
| sess | Setting the name of the session | Specify the name of the session from that it is made the disconnection or closing. Sessions, not the background, and to which none of the visualizers is not connected, are automatically closed. |
In order to optimize the performance of local and especially network interaction the service function "/serv/wlbBr" and the command of the query of the tree of widget libraries: <get path="/UI/VCAEngine/%2fserv%2fwlbBr"/> are provided. The result of the query is a tree with the elements of the libraries of widgets, tags wlb. Inside the tags of libraries of widgets are included: icon tag ico and the widgets library tags w. The widgets tags, in their turn, contain the icon tag and tags of the child widgets cw.
Through the management interface of OpenSCADA, components that use it, can be configured from any system configurator OpenSCADA. This module provides an interface to access all the data object of the VCA. Main inset of the configuration page of the module provides access to widgets libraries and projects (Fig. 4.1). The tab "Sessions" provides access to opened sessions of projects (Fig. 4.2).
In addition to the list of open sessions the tab in Figure 4.2 contains a table with a list of sessions that must be created and run at boot time OpenSCADA. Creation of sessions through this tool can be useful for Web-based interface. In this case, when connecting Web-user data is ready and ensures the continuity of the formation of archival documents.
The configuration of container widgets in the face of libraries and widget projects is done through pages in Fig. 4.3 (a project) and Fig.4.5 (a library of widgets). Widgets library contains the widgets, and project — the pages. Both types contain a tab of configuration Mime-data used widgets (Fig.4.6). The project page also contains the tab "Diagnostics" (Fig.4.4) for debug and control all the page's executions by sessions.
From this page you can set:
From this tab you can select time, or refresh to current, and size for diagnostic messages obtain of the sessions of running the project.
From this page you can set:
Configuration of the project's session differs significantly from configuration of the project (Fig. 4.8), but also contains pages of the project.
From this page you can set:
The configuration pages of visual elements, placed in different containers, may be very different, but this difference is the presence or absence of individual tabs. The main tab of visual elements in fact is the same everywhere, differing in one configuration field and three into the session (Fig. 4.8). The pages contains the tabs of the child pages and embedded widgets. The container widgets contains the tab of the embedded widgets. All visual elements contain attributes tab (Fig. 4.9), except the logical containers of the projects. Elements, at the level of which it is possible to build the user procedure and to determine the links, contain the tabs "Process" (Fig. 4.10) and "Links" (Fig.4.11).
From this page you can set: