OpenSCADAWiki: Home Page En/Doc/VC Aconcept/part4 ...

4.1 Problem definition

4.1.1 Tasks of the SCADA system

In the present days, when constructing the automated process control the user interface with the control system are implemented using computer systems. This approach is due to several reasons: the compactness (in the physical and energetic sense) of modern computer technics, maturity of the methods of presentation the information, great functionality and variability of control systems.

The application of computer technology in the ACS TP in general, and in the workplaces of the operators in particular, has led to the origin of class of software (SW), known as SCADA (Supervisory control and data acquisition).

Thus, the key purpose of SCADA is to provide the interface between the operator and control system of the TP. Often, SCADA also implements the following tasks: the formation of alarm about the violation in TP, making the parameters' archives of TP and protocols of events.

Therefore, SCADA software can be regarded as a set of subsystems: the database of the parameters of TP and connections with the control systems of TP (controllers), the formation of alarms about the violations of TP, archiving, logging, visualization of the operational and archival data.

In addition to the above problems it can be included the separation of access rights for read-modify those or other parameters of TP, implemented in the security subsystem.

Thus modern SCADA systems are fairly complex software systems.

The subject of this subproject is to develop the concept of visualization and control are (VCA) and implementations of VCA's on the basic ways of representation for OpenSCADA SCADA system.

Visualization means the next set of tasks:

• Providing the operator with current information about the parameters of TP (sensors' data, the positions of the mechanisms, actuators). Much attention is paid to alarm about deviations (violations) of TP.
• Display the archive information about the parameters of TP and the events that occurred.
• Reception and transmission of operator's commands to the controlled system.

VCA must operate in two modes - editing (development) and execution. The first phase is planned to implement the development mode only for the QT-version of the VCA!

In the operation process the VCA must use data from other subsystems:

• Subsystem "Data acquisition (DAQ)":
  • development mode - when you connect the dynamics to the frame (widget);
  • execution mode - at the time of formation of the dynamics of the frame (to access the current values of the parameters of its history, as well as violations of the parameters).
• Subsystem "Archives":
  • development mode - when setting up the dynamics of the frame;
  • execution mode - at the time of formation of the dynamics of the frame (access to archival values of the parameters).
• Subsystem "Security":
  • development mode - when setting up access to the widgets;
  • execution mode - when forming the image of the widget, and control capabilities.
• Subsystem "DB": access for loading and saving data for widgets, frames, library of the frames and projects as in the development mode, and in the execution also.

The screen image should be formed from the limited set of basic widgets (primitives). Presentation and interface of the basic widgets for each VCA should be done separately. This is done to optimize performance and simplify the task of creating the library of basic widgets. With the purpose of compatibility between different implementations of the VCA is planned the creation of the general description of the library of basic widgets (data model) with the subsequent implementation of its interface in each VCA.

Basic widgets are to be grouped and form derivatives of widgets, with the further accumulation of them in the user's widget library/frame.

4.1.2 Tasks of monitoring system

Given the purpose of the OpenSCADA system, as a system for monitoring data in many related fields, it is necessary to formulate the tasks for such systems in general.

In monitoring systems, as a rule, there is no control possibility, but the interactive elements must be present.

The primary objective of such systems is the continuous provision of information in an accessible form and on the background of the basic work.

4.2 Formalization

Lets conceptually describe the VCA model using the UML with use case diagram.

Any VCA can operate in two modes - the development and execution. As an actor, in the first case, acts the engineer of the top-level of ACS-TP setting, in the other - the operator.

In development mode lets select the following options of using the VCA:

• Operations over the project:
  • open/save an existing visualization project from/to the DB;
  • creation/delete of the visualization project;
  • work with an open project:
    • add/remove the frame into the visualization project;
    • linkage the frame of the project with the dynamics (dynamization of the characteristics of the frame), creating the visual interface page or the template for the overall dynamics for the pages based on this frame;
    • creation/delete of the visualization interface page based on the frame of the project;
    • linkage the page control interface pages with the dynamics.
  • opening/closing/connection to the execution session of the project.
• Operations on the frame (widget):
  • open/save the widget/frame in the library of the database;
  • create/delete of the widget/frame;
  • work with an open frame:
    • addition/remove the embedded widget on the working frame;
    • selection of widgets on the working frame;
    • change the properties of the selected widgets by means of the widgets' supervisor;
    • grouping/ungrouping of the selected widgets;
    • moving the selected widgets by mouse and/or keyboard;
    • visual change of the size and other geometric parameters of the widget;
    • appointment of the slots of dynamics linkage (parameters) of the widgets or the of the frame as a whole, as well as direct dynamics linkage for the final visualization of widgets (frames);
    • formation of the procedure of links description and other logic of the widget, on he language of the user programming provided by the OpenDCADA system;
    • associative installation of simple and group logical connections by the graphical and configuration way.

Use case diagram for operation of the VCA in development mode is shown in Fig. 4.2.1.

Fig.4.2.1 Use case diagram of the VCA in development mode.

Using variants in the execution mode:

• tracking of the TP for instantaneous values, diagrams, etc.
• control of technical or other processes (TP) through the final visualization interface;
• navigation through the frames and pages of visualization interface;
• hot swap of dynamised properties of the frames and pages;
• formation and print of the reporting documents, instruments and displays of the visualization interface;
• change of the user.

Using diagram of the VCA in the execution mode is shown in Fig.4.2.2.

Fig.4.2.2 Using diagram of the VCA in the execution mode.

Based on the requirements and general considerations the VCA structure can be represented as it shown on the Fig.4.2.3.

Fig.4.2.3 Generalized structure of the VCA.

It should be noted that this approach allows to implement the support of three levels of complexity of the development process of the control interfaces. As a consequence, an ACS-TP engineer can use (to start) the level at which he has enough skill with the ability to improve it further, actually eliminating the rejection of the system because of the over-complexity at the early stage of learning and saving at the same time the considerable flexibility and power of the system. Lets enumerate these levels:

1. VC(visualization and control) interface formation with the help of library of template frames, by placing the frame's templates into the project and their dynamisation.
2. In addition to the first level the formation of its own frames on the basis of libraries of derivatives and basic widgets is done. It is possible as the direct appointment of the dynamics in the widget, and the subsequent its appointment in the project.
3. In addition to the second level the independent formation of derivatives of widgets, the new template frames, and frames with the use of the mechanism of description of logic of interaction and event processing in the language of user programming of OpenSCADA system.

4.3. Frames and elements of visualization (widgets)

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.

The contents of the frame is forming from the elements of visualization (widgets). Widgets may be the basic primitives (different flat 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 (Fig.4.3). For ease of editing the support of grouping of the embedded widgets and then working with the group of widgets as a whole.

Fig.4.3 Example of the structure of the derived widget.

The widget is an element, by means of which it is provided:

• visualization of operational and archive information about TP;
• alarm about a violation of conduction of TP;
• switching between the frames of TP;
• management of technological equipment and the parameters of conduction of TP.

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.

4.4. Project

Direct configuration and properties of the final visualization interface are contained in the project of the visualization interface of the VCA. It may be created a lot of projects of the visualization interfaces.

Each project includes frames from the libraries of the frames/widgets. A frame provides a tool for the dynamics to the properties described therein. All properties of the frame may be associated with dynamics or authorized by the constants, and can act as a template for the formation of derivative pages. In fact, each frame may contain multiple pages with their own dynamics. This mechanism 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.

To provide the possibility of creation of a complex hierarchical interfaces of VC the frames, placed into the project, can be grouped by name in the hierarchical form and by the appropriate visualization in the form of a tree. In addition to this a mechanism of associative description of the calling of the frames through regular expressions is provided.

Example of hierarchical representations of components of the project of the classical interface of VC of the technological process with the description of standard expressions is given in Fig. 4.4.

Fig.4.4 Hierarchical view of components of the project of classical interface of VC of the technological process.

Execution of the project is made in the session of the project. For each project can be opened many sessions. Specific implementations of the VCA connect to the or create the new session of the project. All calculations over the project are made in the sessions. VCA implementations only use the data in the session for the visualization and the collection of user actions. This separation will allow easy to build VCA's for different ways of presenting data.

To provide an opportunity for considering the individual characteristics and preferences of users the mechanism of profiling is provided. In your profile you can set individual color and font preferences, as well as the preferred card of events for the VC interface control.

4.5. Styles

We know 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 seizure of the user to the interface of VC. This rejection and seizure can lead to fatal errors in the management of TP, as well as traumatize the human by the continuous work with such 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 actually 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 scheduled to implement 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 if 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.

4.6. Events, their processing and the events' maps

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.

Event 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. If you have any event manager of the events 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 is set by default.

In general, four types of events are provided:

• events of the images of VCA (prefix: ws_), for example, pressing of the button event- ws_BtPress;
• keyboard events (prefix: key_) - all events from mouse and keyboard in the form of - key_presAlt1;
• user events (prefix: usr_) are generated by the user in the procedures of the calculation of widgets;
• mapping of the event (prefix: map_) - events from the map of events.

Event itself represents little 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 4.5 provides a list of standard events, the support of which should be provided in visualizers of VCA.

Table 4.6. Standard events

Events are the main mechanism of notification and is actively used for user interaction. For the event processing there are two mechanisms: the scriptы used to control the opening of the pages and the computational procedure of the widget.

The mechanism "Scenario of the opening pages control" is based on the core attribute of the widget "evProc", which contains the list of scenarios of operations of the opening pages with the following syntax:<event>:<evSrc>:<com>:<prm>. Where:

• event - the expected event;
• evSrc - the path of the nested widget-source of the event;
• com - session command;
• prm - parameter of the command;

The following commands are implemented:

• open - Opening page. Page to open is specified in the parameter <prm> both: in direct way and as a template (example: /pg_so/1/*/*).
• next - The opening of the next page. Page to open is specified in the parameter <prm> as a template (example: /pg_so/*/*/$).
• prev - Opening of the previous page. Page to open is specified in the parameter <prm> as a template (example: /pg_so/*/*/$).

Special characters of the template are deciphered as follows:

• pg_so - direct name of the desired page with the prefix. Requires the compulsory accordance and is used to identify the last open page;
• 1 - name of a new page in a general way, without a prefix. It is ignored when it detects a previous open pages;
• * - the page is taken from the name of a previous opened page or the first available page is substituted, if the previous opened page is missing;
• $ - points the place of the opened page relative to which you are to go to the next or to the previous one.

As an example lets cite the scenario of operation of the main page of the user interface:

The mechanism "Processing the event 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 language of the user programming of OpenSCADA. Events, in process of receipt, are accumulated in the attribute "event" till the moment of call of computational procedure. 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, events are analyzed for compliance with the conditions of the call by means of script of the first 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 contents 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:

4.7. Signaling (Alarms)

An important element of any visualization interface is the user notification about the violation - alarm. 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:

• lev - signaling (alarm) level; number from 0 to 255;
• categ - alarm category; parameter of the acquisition subsystem, object, path, or a combination.
• message - signaling (alarm) message, for placement in a status line, displaying in the protocol, and placement in the archive of messages;
• type - type of notification (visual, speech, and beep) is formed as a the integer number, which contains the flags of notification methods:
  • 0x01 - visual;
  • 0x02 - beep, is frequently made through the PC-speaker;
  • 0x04 - sound signal from the sound file or the speech synthesis, and if in the <tp_arg> the name of the resource of the sound file is specified, then play it, or in other case the speech synthesis from the text specified in <message> is made.
• tp_arg - argument of the type; it is used in the case of the audible signal to indicate the resource of the sound alarm ( file of the sound format).

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:

• first bite (0-255) characterizes the level of the alarm of the branch;
• the second byte indicates the type of notification (as well as in the attribute "alarm");
• the third byte indicates the type of notification without quittance (as well as in the attribute "alarm");
• the first bit of the the fourth byte has a special appointment, setting this bit is the fact of the quittance of the notification referred to the first byte.

Alarm formation and receipt of it by the visualizer.
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.

This mechanism provides the ability to build the signaling (alarm) interfaces at the level of subsystems "data acquisition", or directly at the level of representation.

Taking into account that the processing of conditions of the signaling is made in the widgets, the page 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 done 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 quit 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 is listed below:

4.8. Rights management

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><group><rest> where each element consists of three attributes of access. For the elements of the VCA the following interpretation is taken:

• 'r' - the right to review the widget;
• 'w' - the right to control over the widget.

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 performance mode the right described in the components of interface work.

4.9. Linkage with the dynamics

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:

1. parameters that contain some number of attributes;
2. attributes of the parameter can provide information of four types: Boolean, Integer, Real and String;
3. attributes of the parameter can have their history (archive);
4. attributes of the parameter can be set to read, write, and with full access.

Considering the first paragraph 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 (RU).

In accordance with paragraph 2, links provide transparent conversion of connection types and do not require special configuration.

To satisfy the opportunities for access to archives, in accordance with paragraph 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 (Fig.4.9.a). 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.

Fig. 4.9.a The tab "Processing" of the configuration page of the widget.

In addition to configuration fields of the attributes the column "Processing" in the table is provided, for selective using of the attributes of the widgets in the computational procedure of the widget, and the columns "Configuration" and "Configuration template", to describe the configuration of links.

Column "Configuration" allows you to specify the linkage type for the attribute of the widget:

• Constant - in the tab of widget links the field for indication of a constant appears, for example of the special color or header for the template frames;
• Input link - linkage with the dynamics for a read-only;
• Output link - linkage with the dynamics just for the record;
• Full link - complete linkage with dynamic (read/write).

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". 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" is working, which simplifies and accelerates the configuration process. The value of this column has the following format: <Parameter>|<identifier>, where:

• <Parameter> - the group of the attribute;
• <Identifier> - identifier of the attribute, this value is compared with the attributes of the DAQ parameters with automatic linkage, after the group link indication.

Installation of the links may be of several types, which are determined by the prefix:

• val: - Direct download of the value through the links mechanism. For example, link: "val:100" loads in the attribute of the widget the value of the 100. It is often used in the case of absence of end point of the link, in order to direct value indicating.
• prm: - Link to the attribute of the parameter or parameter, in general, for a group of attributes, of subsystem "Data acquisition". For example, the link "wdg:/ses_AGLKS/pg_so/pg_1/pg_ggraph/pg_1/a_bordColor ==ЇЇ" implements the access of the attribute of one widget to the attribute of another one. At that moment this type of link is not intended for installation by the user manually, and is installed automatically in the mode of dynamic linkage!

Processing of the links occurs at a frequency of calculating the widget in the following order:

• Receiving of the data from input links.
• The implementation of calculating of the script.
• Transmission of the values by the output links.

In the Fig. 4.9.b the tab of links with the group assignment of the attributes by the only specifying the parameter is presented, and in Fig. 4.9.c - with the individual appointment of the attributes.

Fig. 4.9.b Tab "Links" of the page of configuration of the widget with the group assignment of the attributes by the only specifying of the parameter.

Fig. 4.9.c Tab "Links" of the page of configuration of the widget 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 (Fig. 4.9.d)

Fig. 4.9.d Tab "Links" of the page of configuration of the container of widgets, including widgets with links.

The aforesaid 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 an 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:

• tSek --> "<page>|tSek"
• tSize --> "<page>|tSize"
• trcPer --> "<page>|trcPer"
• valArch --> "<page>|valArch"

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 installed 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 an external source, the first to which the link is directed, performing, thus, the addition of missing links.

To visualize this mechanism the table 4.9 is cited.

Table 4.9. The mechanism of the dynamic linkage.

4.10 Architecture

Based on the foregoing, architectural considerations let's form the static class diagram of the VCA, given the separation of the conceptual part (engine) and the part of self-realization of the VCA (Figure 4.10.1). Table 4.10 describes the classes of the class diagram.

Fig.4.10.1 Static class diagram.

Table 4.10. VCA classes

The static class diagram (Fig.4.10.1) does not reveal the entire hierarchy of interaction of objects, based on an abstract object VCA::Widget. This is due to the implicit inheritance of these properties of the widgeta across all segments of the engine, as well as with the intricacies of inheritance, built by using the data of some widgets in the other ones. To explain these features lets represent the comprehensive map of "using" inheritance in Figure 4.10.2.

Fig.4.10.2 Map of the "using" inheritance of the the components of conception/engine

4.11. The primitives of the widget

Any newly created widget is based on one of several primitives (finite element of the visualization) by installing of the related link as directly to the primitive, as well as through the several intermediate user widgets. Each of the primitives contains a mechanism (logic) of data model. A copy of the widget keeps the values of the properties of configuration of the the primitive specially for itself.

The purposes 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 4.11.a shows the list of primitives of widgets (basic elements of visualization).

Table 4.11.a. The library of the primitives of widgets (basic elements of visualization)

Each primitive, and the widget at all, contains the common set of properties/attributes in the composition which is shown in Table 4.11.b:

Table 4.11.b. The common set of properties/attributes in the widget

4.11.1. Elementary graphic figures (ElFigure)

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.

A list of additional properties/attributes of the primitive is given in Table 4.11.1.

Table 4.11.1. A list of additional properties/attributes of the primitive ElFigure

Id	Name	Number	Value
lineWdth	Line:width	20	Line width.
lineClr	Line:color	21	Line color.(Transparency of the color is defined as follows: red-127 | #ff0000-127, where "127" is the value of transparency.)
lineStyle	Line:style	22	Line style (solid, dashed, dotted).
bordWdth	Border:width	23	Line border width. The zero width indicates the lack of border.
bordClr	Border:color	24	Border color.
fillColor	Fill:color	25	Fill color.
fillImg	Fill:image	26	Fill image.
orient	Orientation angle	28	The rotation angle of the content of widget.
elLst	Element's list	27	List of graphic primitives in the following format: Line. Record form in the list: <line:p1 | (x | y):p2 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Arc. Record form in the list: <arc:p1 | (x | y):p2 | (x | y):p3 | (x | y):p4 | (x | y):p5 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Bézier curve. Record form in the list: <bezier:p1 | (x | y):p2 | (x | y):p3 | (x | y):p4 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Fill. Record form in the list: <fill:p1 | (x | y),p2 | (x | y),...,pn | (x | y):[fillClr | c{n}]:[fillImg | i{n}]>
The attributes for each point from the list of graphic figures elLst
p{n}x	Point {n}:x	30+n*6	Coordinates 'x' of the point {n}.
p{n}y	Point {n}:y	30+n*6+1	Coordinates 'y' of the point {n}.
w{n}	Width {n}	30+n*6+2	Width {n}.
с{n}	Color {n}	30+n*6+3	Color {n}.
i{n}	Image {n}	30+n*6+4	Image {n}.
s{n}	Style {n}	30+n*6+5	Style {n}.

4.11.2. Element of the form (FormEl)

Primitive is intended to provide the standard form elements to the user. The general list of attributes depends on the type of element. A list of additional properties/attributes of the primitive is given in Table 4.11.2.

Table 4.11.2. A set of additional properties/attributes of primitive FormEl

Id	Name	Number	Value
elType	Element type	20	Type of element (Line edit, Text edit, Check box, Button, Combo box, List, Slider, Scroll bar). On its value it is depended 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	Config	23	Configuration of the line. The format of the value of the field for different types of lines: Text - the input template is indicated in the format of library QT. Combobox - contains a list of the values of the editable combobox. Integer - contains the configuration of input field of integer in the format: <Minimum>:<Maximum>:<Step of change>:<Prefix>:<Suffix>. Real - contains the configuration of input field of real in the format: <Minimum>:<Maximum>:<Step of change>:<Prefix>:<Suffix>:<The number of digits after the decimal point>. Time, Date, Date and time - to form the date following the the template with parameters: d - number of the day (1-31); dd - number of the day (01-31); ddd - acronym of the day ("Mon" ... "Sun"); dddd - the full name of the day ("Monday" ... "Sunday"); M - number of the month (1-12); MM - number of the month (01-12); MMM - acronym of the month ("Jan" ... "Dec"); MMMM - the full name of the month ("January" ... "December"); yy - last two digits of the year; yyyy - full year; h - hour (0-23); hh - hour (00-23); m - minutes (0-59); mm - minutes (00-59); s - seconds (0-59); ss - seconds (00-59); AP,ap - to display AM/PM or am/pm.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Text edit:
value	Value	21	The contents of the editor.
wordWrap	Word wrap	22	Automatic division of text by the words.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Check box:
name	Name	26	Bame/label of the checkbox.
value	Value	21	Value of the checkbox.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Button:
name	Name	26	Name, the inscription on the button.
value	Value	21	The value for the settled button.
img	Image	22	The image on the button.
color	Color	23	Color of the button.
colorText	Color:text	27	The color of the text.
checkable	Checkable	24	Sign of functioning as a settled button.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Combo box:
value	Value	21	Current value of the list.
items	Items	22	The entries of the list.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
List:
value	Value	21	The selected list value.
items	Items	22	The entries of the list.
font	Font	25	Text font in the full record {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Slider and the scroll bar:
value	Value	21	Slider position.
cfg	Config	22	Configuratio of the slider in the format: <VertOrient>:<Min>:<Max>:<SinglStep>:<PageStep>. Where: VertOrient - sign of a vertical orientation, the default is the horizontal orientation; Min - minimum value Max - maximum value; SinglStep - the size of a single step; PageStep -the size of the page step.

4.11.3. Text element (Text)

This primitive is designed to display the plain text used as labels, and different signatures. With the aim of creating a simple frequent decorations the primitive must support the surrounding of the text by frame. A list of additional properties/attributes of the primitive is given in Table 4.11.3.

Table 4.11.3. The list of additional properties/attributes of the primitive Text

4.11.4. Element of visualization of media materials (Media)

This primitive is designed to play different media materials, ranging from simple images to the full audio and video streams. Taking into the account the variety of ways and libraries for playing a full audio and video streams as well as a serious laboriousness of implementing of all of these mechanisms in this widget, it was decided at the initial stage, only to realize the work with images and with simple animated images and video formats. A list of additional features/attributes of the primitive is given in Table 4.11.4.

Table 4.11.4. A set of additional properties/attributes of primitive Media

4.11.5. Element of constructing diagrams/trends (Diagram)

This primitive is designed to construct various diagrams, including graphs/trends showing ongoing process and archive data. At this time, the following types of diagrams are realized:

• "Graph" - allows you to build a one-dimensional graphs of the values of parameters of subsystems "Data acquisition" in time, as well as direct use of historical data to graph. It supports the tracing of current values and the values of the archive modes. It supports also the possibility of building the graphs of the parameters which have no archive of values.
• "Spectrum" - builds the frequency spectrum of values from the subsystem "Data acquisition". Window of the data of frequency spectrum is formed on the basis of the size of the widget horizontally, in pixels, and the available data of the parameters imposed on the horizontal grid size. In this regard, the minimum frequency is determined by the value of the attribute tSize (1/tSize), and maximum frequency of allocated frequencies is determined by half-width of the graph in pixels multiplied by the minimum frequency ( width/(2*tSize) ). It is supported the formation of the spectrum in the tracing mode.

The process of access to archive data is optimized, by means of an intermediate buffer for the display, as well as the package of traffic data in the query. A list of additional properties/attributes of the primitive is given in Table 4.11.5.

Table 4.11.5. A list of additional properties/attributes of the primitive Diagram

4.11.6. The element of building the protocols based on the archives of messages (Protocol)

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. A list of additional properties/attributes of the primitive is given in Table 4.11.6.

Table 4.11.6. A list of additional properties/attributes of the primitive Protocol

/Home Page En / Doc / VC Aconcept / part 4 / part 11 / doc  :: (edit)

Features of the primitive "Document":

• Flexible formation of the structure of the document based on Hypertext Markup Language. This will provide support of wide formatting opportunities of documents with the subsequent implementation of the GUI form of the document formation.
• Formation of documents on command or on a plan into the with the archive with the subsequent viewing of the archive.
• Document formation in real-time mode, fully dynamic and based on the archives for the specified time.
• Using the attributes of the widget to pass values and addresses to the archives in the document. Allows you to use the widget of document as the template for generating reports with other input data.
• Provision of an opportunity to place the data input elements on the document. It'll allow you to create self-tuning and self-configurable documents.

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. 4.11.7.1.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.

Fig. 4.11.7.1.a The block diagram of the primitive "Document".

It i provided the work of 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 made 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 command of values:

• aCur<0 - Moves the archiver cursor for the following position, thereby leaving the previous document in the archive and clearing the document under the cursor.
• vCur==-1 - Select of the next document to be displayed. The selected document is copied to the attribute <doc>.
• vCur==-2 - Select of the previous document to be displayed. The selected document is copied to the attribute <doc>.

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 4.11.7.1.a) are reserved.

In addition to special attributes in XHTML template tags and tags' attributes of special assignment are reserved (Table 4.11.7.1.a).

Table 4.11.7.1.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: mTime - message time; mTimeU - message time, microseconds; mLev - message level; mCat - message category; mVal - message value.
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 and in accordance with the level of (1) and template of request (PLC*). For this tag in the process of multiplication the following attributes: mTime, mTimeU, mLev, mCat and mVal are defined.
*.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!

/Home Page En / Doc / VC Aconcept / part 4 / part 11 / doc  :: (edit)

4.11.8. Container (Box)

Primitive container is used to build composite widgets and/or the pages the user interface. A list of additional properties/attributes of the primitive is given in Table 4.11.8.

Table 4.11.8. A list of additional properties/attributes of the primitive Box

4.12. Using the database to store the library of widgets and projects

All the data of the VCA conception should be stored in the DB. This would allow flexibly to distribute and use the VCA data, choosing the most suitable database from the list of supported by the OpenSCADA. The projections of the main tables we'll write as follows:

• Libs( ID, NAME, DSCR, DB_TBL, ICO ) - Libraries of widgets <ID>.
  ID - identifier;
  NAME - name;
  DSCR - description;
  DB_TBL - DB with widgets;
  ICO - coded (Base64) image of the icon of the library.
  
• LibWigets( ID, ICO, PARENT, PROC, PROC_PER, USER, GRP, PERMIT, ATTRS, DBV) - Widgets <ID> of the library.
  ID - identifier;
  ICO - coded (Base64) image of the icon of the widget.
  PARENT - address of the basic widget /wlb_originals/wdg_Box ;
  PROC - internal script and script language of the widget;
  PROC_PER - frequency of the computation of the script of the widget;
  USER - owner of the widget;
  GRP - users group of the widget;
  PERMIT - rights of access to the widget;
  ATTRS - list of attributes of the widget, modified by the user;
  DBV - DB version.
  
• LibWidgetIO( IDW, IDC, ID, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) - Work attributes <ID> of the widget <IDW>.
  IDW - identifier of the widget;
  IDC - child widget identifier;
  ID - identifier of the IO;
  IO_VAL - value of the attribute;
  SELF_FLG - internal flags of the IO;
  CFG_TMPL - template of the configuration element based on this attribute;
  CFG_VAL - value of the configuration element (link, constant ...).
  
• LibWidgetUserIO( IDW, IDC, ID, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) - User attributes <ID> of the widget <IDW>.
  IDW - identifier of the widget;
  IDC - child widget identifier;
  ID - identifier of the IO;
  NAME - name of the IO;
  IO_TP - type and main flags of the IO;
  IO_VAL - value of the IO;
  SELF_FLG - internal flags of the IO;
  CFG_TMPL - template of the configuration element based on this attribute;
  CFG_VAL - value of the configuration element (link, constant ...).
  
• LibWidgetIncl( IDW, ID, PARENT, ATTRS, USER, GRP, PERMIT, DBV ) - Included into the container <IDW> widgets <ID>.
  IDW - identifier of the widget;
  ID - Identifier of the copy of the embedded widget;
  PARENT - address of the basic widget /wlb_originals/wdg_Box ;
  ATTRS - list of attributes of the widget, modified by the user;
  USER - owner of the widget;
  GRP - users group of the widget;
  PERMIT - rights of access to the widget;
  DBV - DB version.
  
• LibWidgetMime( ID, MIME, DATA ) - Audio, video, media and other resources of widgets of the library.
  ID - identifier of the resource.
  MIME - Mime data type of the resource (in the format - <mimeType;Size>).
  DATA - Resource data coded with Base64.
  
• Project( ID, NAME, DSCR, DB_TBL, ICO, USER, GRP, PERMIT, PER, FLGS, DBV ) - Projects of visualization interfaces <ID>.
  ID - identifier of the project;
  NAME - name of the project;
  DSCR - description of the project;
  DB_TBL - Database with project pages.
  ICO - coded (Base64) image of the icon of the project;
  USER - owner of the project;
  GRP - users group of the project;
  PERMIT - rights of access to the project;
  PER - frequency of the computation of the project;
  FLGS - flags of the project;
  DBV - DB version.
  
• ProjPage( OWNER, ID, ICO, PARENT, PROC, PROC_PER, USER, GRP, PERMIT, FLGS, ATTRS ) - The pages <ID> which are hold in the project/page OWNER>.
  OWNER - project/page - owner of the page (in the format - "/AGLKS/so/1/gcadr")
  ID - identifier of the page;
  ICO - coded (Base64) image of the icon of the page;
  PARENT - address of the basic widget of the page in the format: /wlb_originals/wdg_Box ;
  PROC - internal script and script language of the page;
  PROC_PER - frequency of the computation of the script of the widget;
  USER - owner of the page;
  GRP - users group pf the page;
  PERMIT - rights of access to the page;
  FLGS - flags of the page;
  ATTRS - list of attributes of the widget, modified by the user.
  
• ProjSess( IDW, ID, IO_VAL ) - Project table <IDW> for data storage of the sessions, performing project.
  IDW - the full path of the element of the project;
  ID - attribute of the element;
  IO_VAL - value of the element.
  
• ProjPageIO( IDW, ID, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) - Working attributes of the pages. The structure actually corresponds to the table LibWidgetIO.
• ProjPageUserIO( IDW, ID, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) - User attributes of the pages. The structure actually corresponds to the table LibWidgetUserIO.
• ProjPageWIncl( IDW, ID, PARENT, ATTRS, USER, GRP, PERMIT ) - Enabled widgets on the page. The structure actually corresponds to the table LibWidgetIncl.

4.13 API of the user programming and service interfaces of the OpenSCADA

4.13.1. API of the user programming

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 projects and sessions.
Parameters:

Presence of the node (NodePresent)
Description: Check for the presence of the node, including widgets, attributes and others.
Parameters:

Attributes list (AttrList)
Description: Returns list of attributes of the widget. If <noUser> is set then only not user attributes are returned.
Parameters:

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:

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:

Session user (SesUser)
Description: Return session user by session's widget path.
Parameters:

4.13.2. Service interfaces of the OpenSCADA

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 sharing within OpenSCADA, implemented through weak ties, and standard exchange protocol of OpenSCADA.

Access to the values of attributes of the visualization elements (widgets)

In order to provide uniform, group, 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 command of the attributes' values are provided: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> and <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/>. Attributes of these commands, which provide the various mechanisms of the request, are presented in the Table 4.13.2.a.

Table 4.13.2.a. Attributes of commands of get/set of the the attributes of visual elements

Group access to the values of attributes of the visualization elements (widgets)

In order to optimize network traffic by eliminating 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 embedded elements. For this request the service command "/serv/attrBr". 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:

Access to the pages of the session

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 of the list of open pages are 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 is returned the list of changed, since the moment of the specified value of the counter, widgets of the open page.

Signaling (alarm) management

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 information for the sound signaling. Additional information by sound signal is provided by the current resource, a sound file, for playback and it provides monitoring of the sequence of signaling and quittance of individual files of sound messages.

Request for the quittance performs quittance of the specified widget, attribute <wdg>, in accordance with the template, attribute <tmpl>.

Manipulation with the sessions of the projects

To provide a uniform mechanism for manipulation of the sessions by the visualizers of VCA in the module of the VCA engine (VCAEngin) are provided: the service function "/serv/sess" and 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. Attributes of these commands, which provide the various mechanisms of the request, are presented in Table 4.13.2.b.

Table 4.13.2.b. Attributes of commands of the mechanism of manipulation with sessions

The group request of the tree of widget libraries

In order to optimize the performance of local and especially network interaction the service function "/serv/wlbBr" and command of the query of the tree of widget libraries: <get path="/UI/VCAEngine/%2fserv%2fwlbBr"/> are provided. The result of the query is the tree with the elements of the libraries of widgets, tags <wlb>. Inside the tags of libraries of widgets are included: icon tag <ico> and widgets library tags <w>. Widgets tags, in their turn, contain the icon tag and tags of the child widgets <cw>.

4.14 Copying elements

To speed up the process of developing of the user visualization and control interfaces it is necessary to provide the copy function of the elements. To provide the support of the various options for copy lets list them:

• "Widgets library (wlb_SrcLib)" -> "Widgets library (wlb_NewLib)" -- Parameters of the library are copied, as well as all the widgets/frames contained in it..
• "Project (prj_SrcPrj)" -> "Project (prj_NewPrj)" -- The project's parameters, all pages in the hierarchy, as well as widgets/frames, contained in the active pages, are copied.
• "Progect's page (prj_WPrj.pg_SrcPg)" -> Progect's page (prj_WPrj.pg_WPg.pg_NewPg)" -- Copying of the the page's parameters, embedded pages and embedded widgets
• "Widgets library frame (wlb_Lib.wdg_SrcWdg)" -> "Widgets library frame (wlb_LibN.wdg_NewWdg)" -- Copying of the widget's parameters and embedded widgets.
• "Element of the frame/page (prj_WPrj.pg_WPage.wdg_SrcWdg" -> "Widgets library frame(wlb_Lib.wdg_NewWdg)" -- Copying of the widget's parameters and embedded widgets.
• "Element of the frame/page (prj_WPrj.pg_WPage.wdg_SrcWdg" -> "Element of the frame/page (wlb_Lib.wdg_WWdg.wdg_NewWdg)" -- Copying of the widget's parameters.

4.15 Projecting functional features

Here are the features that can provide VCA constructed on the basis of this project:

• three levels of difficulty in the formation of the visualization interface, which allow organically to develop and apply the tools using the methodology from simple to complex:
  1. formation from the template frames by assigning the dynamics (without the graphical configuration);
  2. graphic formation of the new frames by the using of elements of the visualization from the library (mnemonic schemes);
  3. formation of new frames, templates' frames and visualization elements to the library.
• building the visualization interfaces of virtually any complexity ranging from simple flat interfaces for monitoring and ending with full-fledged hierarchical interfaces used in SCADA systems;
• providing the different ways of forming and configuration of user interface, based on different interfaces of graphical representation (QT, Web, Java ...) or the same through the standard control interface of OpenSCADA system;
• changing the dynamics in the process of execution;
• construction of new template frames at the user level and the formation of specialized, under the scope, library of frames (eg the inclusion of parameters frames, diagrams and other elements linking them to each other), in accordance with the theory of recycling and accumulation;
• formation щof the specialized, under the scope, the library of frames, in accordance with the theory of recycling and accumulation;
• description of the logic of new template frames and user visualization elements as by the simple links as well by the compact and full-fledged user programming language;
• the possibility of inclusion to the user's visualization elements the functions (or frames of functions' calculation) of the object model of OpenSCADA, practically linking the presentation with the algorithm of computation (for example, visualizing the library of the instruments of TP models for subsequent visual TP model's building);
• separation the data of the user interfaces and presentation interfaces of these data, allowing to build the user interface in the one environment, and execute in many others (QT, Web, Java ...);
• opportunity to connect to the executing interface for monitoring and correction of actions (for example, operator training and control in real time for his actions);
• visual construction of various schemes, with the imposition of logical links and the subsequent centralized execution in the background (visual construction and execution of mathematical models, logic circuits, relay circuits and other procedures);
• providing the functions of the object API to the OpenSCADA system, can be used to control the properties of the visualization interface from the user procedures;
• построение серверов кадров, элементов визуализации и проектов интерфейсов визуализации с возможностью обслуживания множественных клиентских соединений;
• simple organization of client stations on different bases (QT, Web, Java ...) with the connection to the central server;
• full-fledged mechanism of separation of authorities between the users, allowing you to create and execute projects with different access rights to its components;
• flexible formation of rules of alarms and notifications, with the support of various methods of notification;
• support of custom formation of the palette and font preferences for the visualization interface;
• support of the user forming of the events maps under various control equipment and user's preferences;
• support for user profiles, allowing the identification of various properties of the visualization interface (colors, font features, the preferred card of events);
• flexible storage and distribution of libraries of widgets, frames and projects of visualization interfaces in the databases, supported by the OpenSCADA system; virtually user only need to register the received database with the data.