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

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 

6 Implementation

The implementation will be done in the phased manner, in the direction from the functions in the concept to its implementation on the QT library, and so on until the last component. Such an approach allow to get results between stages, analyze it and take into account the peculiarities in the following stages. For step by step implementation lets divide the whole problem into logical parts and put them in the light of one another in the implementation.


6.1 Widgets and Libraries -- Done


The objectives of this phase are:


As the result of our work the modules of the data model (UI.VCAEngine) and visualization (UI.Vision) was created. At this stage, the modules implement the mechanisms of UI elements formation. At next stage these elements will be used to form the full-fledged visualization and control interfaces.


Lets consider the results of the each stage's implementation:

The implementation of the basis of architecture "Data model" - "Presentation(visualization)"

In accordance with the static class diagram (Fig.4.10.1) and general requirements there have been implemented the modules "UI.VCAEngine" and "UI.Vision" for the OpenSCADA system. The "UI.VCAEngine" module implements the VCA data model and is the source for subsequent presentation of these data by different mechanisms of visualization. The "UI.Vision" module provides the means of presentation(visualization), based on QT library of version 4 of the Trolltech company.


Connection between the modules of the data model and presentation(visualization) is organized by direct calls (strong links). This method of connection is selected for preliminary abstraction of features of interaction and for concentration on core problems of implementation. Later it is planned the unification and construction of these links through the control interface of OpenSCADA system (weak links). As the result it will be achieved the opportunity of separation the data model and presentation(visualization), with possibility of simultaneous maintenance of different presentation(visualization) mechanisms with the single VCA data model. In addition, it will be possible to estimate the influence of the connection's(link's) type on the performance of the VCA.

Implementation of the basic functions of the VCA data model in the UI.VCAEngine module

The module of the data model(engine) of the VCA contains the container of widgets/frames library. The module provides the predefined library of basic widgets (primitives) with the primary realization of their own properties and processing logic of these properties.


Storage of the widgets' data and widgets' libraries is implemented in the database available in the OpenSCADA system. The database is organized on data ownership to the library. Ie the separate library is stored in the separate group of tables of the one or different databases. The list of libraries of widgets is stored in the index table of the libraries with the name "VCALibs" and with the structure "Libs", of the DB section. A copy of this table is created in each database, which stores data of this module, with the list of libraries contained in the given database. The structure of the tables of the belonging to the library widgets includes:


To control the widget library and the individual widgets the configuration scripts were written on the language of control interface of ~OpenSCADA. Currently, these scripts are designed to perform only the functions of the central configuration of the VCA engine elements, but later there is plans to expand them and give them the functions of processing requests to the data model from the presentation(visualization) modules to organize the "weak links" between the "Data model" and "Prepresentation(visualization)".


The basis of virtually all elements of the engine has become an object of the abstract visualization element (VCA::Widget). At its, abstract, level the object has the following properties:


For the presentation of thelibrary of widgets the class (VCA::WdgLib) is implemented. Its main function is to maintain the library of widgets, storage and loading them from the database, providing an access to the resources(Mime-data), as well as the separation of access.


Especially for the inclusion in the library of widgets the class of the library widget (VCA::LWidget) was created, which is based on an abstract widget's class (VCA::Widget) and provides additional functions: storing the widget data in tables of the library, the redefinition of the access to the resources on the table with the mime-data of the library and storage of the embedded container widget (VCA::CWidget).


In its turn, the class of the container widget (VCA::CWidget) provides the following functions: the storage of the container widget's data in the tables of the library, the redefinition of the access to the resources on the table with the mime-data of the library and the forced mode of the simple link for all container widgets.


On the basis of the library widget's class (VCA::LWidget) it was formed an abstract class of the terminal widget (VCA::PrWidget). And on its basis the implementations of primitives of basic widgets are formed, which form the library of basic widgets, which is created by the module at initialization. The values of the properties of the basic widgets, also can be stored in the database (tables of the widget's library), forming the desired templates. In addition, the basic library of primitives can improved by the extended primitives from the modules of the presentation(visualization) interfaces, for which the basic ones are not enough. But in this case it must be taken into account that such action - the way to an incompatibility between the modules of the presentation(visualization) interfaces!

Implementation of basic functions of the development framework of the user interface in the presentation(visualization) module UI.Vision

Interface of the user interfaces' development of the module is based on MDI (Multi Document Interface) interface. This approach allows you to simultaneously edit multiple frames of various sizes. The following arrangements for managing the development are used: the toolbar, menu and context menu. Most actions are duplicated in the different mechanisms, so you can quickly find the tool by the preferred method. Navigation interfaces are implemented by the attachable windows. The configuration of toolbars and attachable windows is saved on exit and restored at startup that lets you to configure an interface for yourself.


One of the elements of the user interface, implemented as the attachable window is the browser of the widget's library. With the browser you can quickly find the widget or the library and do the necessary operations on them. The following operations are implemented: addition, deleting, configuration of widgets and libraries, as well as visual editing of the widget.


For easy management of the properties of widgets/frames the inspector of attributes(properties) of widgets is implemented. Inspector of the attributes is implemented as the attachable window, which is activated when you select the frame or widget. Window of the inspector of attributes can be conveniently positioned by attaching it to one of the sides of working window. Inspector of attributes supports the group configuration of several widgets, as well as the grouping of similar properties.


For visual editing of the frames the primary support for editing of widgets and frames is implemented. In the editor the following functions are implemented:


Example of the development window is shown in Fig. 6.1.1. At the figure you can see: the toolbar, navigator of widgets, inspector of attributes, editing window of the frame and status bar.


 (123 Êá)
Fig.6.1.1 Development window of the UI.Vision module

To configure the widgets' objects and their libraries the two dialogues are implemented: the dialogue of the widget's configuration (Fig.6.1.2) and the configuration dialog of the widget's library configuration (Fig.6.1.3). The library configuration dialog allows to set the basic properties of the library and put the mime-data in the database for subsequent using in the widgets of the library. Widget's configuration dialog allows you to set: the basic properties of the widget. individually to set the values of attributes and configure the internal procedure for computing the widget with additional(user's) properties.


 (25 Êá)
Fig.6.1.2 Dialog of the widget's library configuration.

 (32 Êá)
Fig.6.1.3 Dialog of the widget's configuration.

6.2 Visualization interface projects -- Done


The objectives of this stage are:


At this stage, it was added the mechanism of VCA projects formation by means of the building of the visualization pages in the hierarchical form, which corresponds to the logical links in the final VCA interface. During the implementation of this stage, the work was begun on the adaptation of the visualization module Vision to use the control interface of OpenSCADA instead of direct-strong links. These works have led to significant unification of the various dialogues, control structures and user interface in general.


At this stage it is implemented:


6.3 Sessions of the project's execution -- Done


The objectives of this stage is:


At this stage it was added the mechanism of the project's execution in the sessions of the data model of the VCAEngine module, as well as visualization of the project's session, the "RunTime" mode in the visualization module on the QT library Vision with the elements of the data update and interaction with the user.

Formation of the hierarchical final visualization widgets' tree based on the project for which the session is opened.

In accordance with Fig.4.10.1 and Fig.4.10.2 the objects of the project's session are inherited from the abstract object Widget and use the appropriate objects of the project. Thus, the session (Session) uses the project (Project) and forms the expanded tree on the basis of it. The project's page Page is directly used by the session's page SessPage. The remaining objects (SessWdg) are shown in accordance with the hierarchy of page's elements (Fig.4.10.2).


In addition to the standard properties of the abstract widget (Widget) the elements of the page and pages of session get the properties of storage of frame of values of the computational procedure, calculation of procedures and events' processing mechanism. Pages of the session, in addition to all, contain the container of following by the hierarchy pages. The session is calculated with the specified periodicity and in the following sequence:

This policy allows you to pass the page in accordance with the hierarchy, and events in the widgets to rise to the top in one iteration.


The session includes the support for the special properties of the pages:

Container - the page is the container for the underlying pages;
Template - the page is the template for the underlying pages;
Empty - the blank inactive page, this property is used in conjunction with the property Container for the organization of logical containers.

On the basis of these properties the following types of pages are implemented:

Standard -- Standard page (none property is set). Is the full-fledged final page.
Container -- Full-fledged page with the container property (Container).
Logical container -- The logical container which is actually not a page (Container|Empty). It performs the property of intermediate and grouping element in the pages tree.
Template -- The template page (Template). The clean master page is used to describe the common properties and for extending them privately in the embedded pages.
Container and template -- The template and container page (Template|Container). It combines the template and container functions.

Providing the values' frames for the final visualization widgets' calculation procedures.

In the section above, we have already noted that the widget of the session contains the frame of values of the calculation procedures. This image is initiated and is used in the case of presence of the calculation procedure. At the time of the initialization the list of parameters of procedure is created and the compilation of the procedures with these parameters is done in the module that implements the selected programming language and that id encoded with the full name of the widget. The compiled function is connected to frame the values of calculation procedures. Next, the calculation is done with the periodicity of the session.


Calculation and processing of the widget as a whole is done in the following order:

Processing the links on the data sources of OpenSCADA.

At the execution of the widget of the session it is necessary to make the links' processing. At the moment the connection on the links is made at the time of calculation, which is not a quick operation. Implementation of links processing will be reviewed and optimized in the future.


The support for the following types of links is provided:


Currently the first two types of links are implemented. The last will be implemented together with the implementation of the basic widget "Link".

Formation of the window of the project execution (RunTime).

On the side of visualization (Vision module) to visualize the process of execution of the project the VisRun object is implemented. At startup it sends the request to create and initialize the session. Further the request on the list of opened pages is made. Based on the information of the VisRun opened pages and their connections, the resulting interface is formed. Fig. 6.3 shows an example of classical SCADA interface with alarm objects, where the main window contains a page inside which is replaced by pressing the buttons of alarm objects and paging.


 (90 Êá)
Fig.6.3 The visualization of the project's execution window. The "RunTime" mode.

Visualization of the project's frames in the "RunTime" mode with periodic update of the content.

The update of the contents of the opened pages of the visualization interface with the periodicity of the execution of the project's session is implemented. In the update process it is done:
- request of the list of opened pages in the model and checking consistency of the really opened pages to this list;
- requests of the modified data on each page and widget;
- update the content of the pages and their widgets in accordance with the received modified data.


By closing the "RunTime" window the closing of the project's session in the data model is made. It will be implemented the opportunity to connect to the earlier opened session and disconnect from the session without closing it.


The mechanism of the request of the only modified data is based on absolute counter of the session's execution. When you make real changes in the attributes of widgets the remembering of the value of this counter is made, which allows us to identify the modified attributes. This approach allows to increase productivity and reduce the load on the traffic in case of access to the model through the network.

Realization of transfer and processing of events.

The visualizer of the ("RunTime") session, because of its direct contact with the user, collects various events. Some of the events are processed by the images of the basic widgets (Text, Box, Document, etc.), which can form other events. Another part is directly transfered to the data model, where they are processed.


To the data model events are transferred immediately upon their receiption, where they are collected in the attribute "event" of the widget until the next iteration of the session's execution. Further, in the process of data session's calculation, the events are extracted from the "event" attribute and are processed in the procedure of the widget or in accordance with the script(scenario) in the "evProc" attribute. The events which are not processed rise to the higher widget of the model.

The implementation of the mechanism of the switching/opening/replacement/navigation through the pages of the project taking into account the processing scenarios(scripts).

Switching, opening, replacement and navigation through the pages is based on processing the events on the scenario(script) in the attribute of the active widget "evProc". Script of this attribute is written in the form of the list of commands with the syntax of: <event>:<srcWdg>:<com>:<prm>
where:

event -- expected event;
srcWdg -- child widget - the source of the event;
com -- session's command;
prm -- parameter of the command;

The following commands are implemented:

open -- The opening of the page. The page to be opened is specified in the parameter prm as in the direct way and as the template (eg:/pg_so/1/*/*).
next -- The opening of the next page. The page to be opened is specified in the parameter prm as in the direct way and as the template (eg:/pg_so/*/*/$).
prev -- The opening of the previous page. Page to be opened is specified in the parameter prm as in the direct way and as the template (eg:/pg_so/*/*/$).

Special characters of the template is interpreted as follows:

pg_so -- Direct name of the necessary page with a prefix. Requires the compulsory compliance and is used to identify the previous opened page.
1 -- The name of the new page in general way without the prefix. The name of the previous page is ignored.
* -- The page is taken with the name of the previously opened page or substituted the first available page if the previous page is not present.
$ -- Indicates the place on the opened page where it is necessary to look for the next or previous.

To understand the mechanism of the templates lets give some real examples:

Switching the alarm objects:
Command: open:/pg_so/2/*/*
It was: /pg_so/pg_1/pg_mn/pg_1
It is: /pg_so/pg_2/pg_mn/pg_1

Switching of the view:

Command: open:/pg_so/*/gkadr/*
It was: /pg_so/pg_1/pg_mn/pg_1
It is: /pg_so/pg_1/pg_gkadr/pg_1

Next/previous page:

Command: next:/pg_so/*/*/$
It was: /pg_so/pg_1/pg_mn/pg_1
It is: /pg_so/pg_1/pg_mn/pg_2

In conjunction with the above described mechanism on the side of visualization (RunTime) the logic that controls the way of the opening the pages is built. The logic is based on the following attributes of the basic element "Box":

pgOpen -- The sign "Page is opened".
pgNoOpenProc -- The sign "To process the page even if it is not opened".
pgOpenSrc -- Contains the address of the widget or page that has opened the current page. In the case of embedded container widget here is the the address of the included page.
pgGrp -- Group of pages. It is used for the connection of containers of pages with the pages in the same group.

The logic of determining the opening of the pages works as follows:


Combination of all these mechanisms now allows you to build complex, multi-level and multi-window user interfaces.


6.4 Designing and implementing the visualization primitives-- Implementation


At this stage it is planned to implement the data models and images of the Vision visualizer for all the basic elements: "ElFigure", "FormEl", "Text", "Media", "Diagram", "Protocol", "Document", "Function", "Box", "Link".

6.4.1 Elementary figure primitive (ElFigure)

Support of the following elementary figures is provided: lines, elliptical arcs, Bézier curves and fill of the enclosed space with the color and/or image. For the elementary figures the following operations are provided:

The general concept of creating and managing the basic figures.

The figures underlying this widget, containing the points (the start and end ones) that can be connected with the according points of other figures; and the points with the help of which the geometry of the figure can be changed.


It is possible to add the figure using the mouse:

  1. Select the desired figure from the context menu.
  2. Set with the left mouse-button start and end points (for line with the SHIFT key hold its orthogonal drawing is made).

The deleting of the figure(s) it is possible by pressing "Del", having selected figure(s).


The copying of the figure(s) it is possible by pressing keys "Ctrl"+"C", having selected figure(s).


Moving/resizing of the figure it is possible by using the mouse or keyboard:

  1. Select the figure, by clicking on it with the left mouse button.
  2. Drag (with the help of mouse or control keys) the figure or one of its control points in the desired location and release the mouse button (key).

It is possible to move several figures, selected by means of holding "Ctrl" and clicking on the desired figures (this option works when the button Connections (Connections) is disabled) or by mouse selection.


The connection of the figures with each other it is possible by the following way:

  1. Press the Connections button.
  2. Select one of the figures and move its start or end point to the desired start or end point of the other figure so that it will get to the appeared circle, release the left mouse button. Connected figures are moving as well as the individual, the general point is moved for all connected figures, to which it refers(priority is given to the arc, two arcs can't be connected directly with each other ).

To fill the enclosed space from the figures it is possible with the following way:

  1. Press the Connections button.
  2. Create the enclosed space.
  3. Make the double-click of the left mouse button inside of it.

To delete the fill of the enclosed space it is possible from the context menu of the widget; by braking the enclosed space or by double-click of the left mouse button on the already existing filled space.


Rotation of the figure is made around the center of the widget.


Fig. 6.4.1 shows the part of the screen with a frame containing the elementary figures.


 (10 Êá)
Fig.6.4.1 Realization of elementary figures in the Vision.

6.4.2 Primitive of the form element (FormEl)

Support of the form elements on the VCA frames is provided. The following form elements are included:

Line edit - It is represented by the following types: "Text", "Combo", "Integer", "Real", "Time", "Date", "Date and time". All kinds of line editor support the confirmation of entry.
Text edit - It is the flat-text editor with the confirmation or denial of entry.
Check box - Provides a field of binary flag.
Button - Provides the button with the support of: the color of the button, the image of the button, and mode of fixation.
Combo box - Provides the selection field of the element from the list of the items.
List - Provides the list box with the control of the current element.
Slider - Slider element.
Scroll bar - Strip of the scroll bar.

The following modes are realized: «Enable» and «Active», as well as transfer of changes and events to the data model of the VCA (engine).


Fig. 6.4.2 shows a part of the screen with the frame containing the above-listed elements of the form.


 (18 Êá)
Fig.6.4.2. Realization of the form elements in the Vision.

6.4.3 Text primitive (Text)

Support of the text element with the following properties is provided:


Fig. 6.4.3 represents a part of the screen with the frame containing the text examples using various parameters.


 (10 Êá)
Fig.6.4.3. Realization of the basic text element in the Vision.

6.4.4 Primitive of the displaying the media materials (Media)

Support of the element of the displaying of media materials with the following properties is provided:


Fig. 6.4.4 represents a part of the screen with the frame containing examples of viewing/playback of media data.


 (17 Êá)
Fig.6.4.4. Realization of the basic element of the displaying of media materials in the Vision.

6.4.5 Primitive of the construction of diagrams/graphs (Diagram)

Support of the element of the construction of diagrams/graphs with the following properties is provided:


Fig. 6.4.5 represents a part of the screen with the frame containing examples of the trend-diagrams.


 (7 Êá)
Fig.6.4.5. Realization of the basic element of a diagram-trend displaying in the Vision.

6.4.6 Primitive of the protocol formation (Protocol)

Support of the element of the formation of the protocol with the following properties is provided:


Fig. 6.4.6 represents a part of the screen with the frame containing an example of the protocol.


 (34 Êá)
Fig.6.4.6. Realization of the basic element of a protocol displaying in the Vision.

6.4.7 Primitive of the box container (Box)

Support of the primitive of the container concurrently serves as the project pages is provided. This primitive is the only element-container, which may include links to frames from the library, thereby creating the user elements of desired configuration. Primitive implements the provided by the project properties. The properties of this primitive are:

Container - Allows you to form the desired objects by grouping in the limits of the primitive.
Page - Elements constructed on the basis of the primitive may serve as a page of user interface.
Container of pages - Property of substitution of its own contents by another page in the execution process. Used to create frames on the pages of user interface. For example, the main page of traditional SCADA system with alarm objects is constructed in this way.
Background - Supports ability to specify the background as color or image.
Border - Supports the displaying of the border, with the specified color, width and style.

6.5 Visualization themes -- Queued


6.6 Events maps -- Queued


6.7 The implementation of weak links between data model and presentation(visualization) -- Done


During this stage implementation it will be written the additional scripts of the control interface to cover the objectives of the organization of weak links between the model (VCAEngine) and visualizer (Vision). On the side of the visualizer (Vision) it will be complete transition to the weak links with the data model of VCA.


At this stage it was created the missing scripts of control interface and made the full translation of module visualization (Vision) on the weak links. As the result of the operation it was achieved the significant unification of the visualizer and enhance its stability. The question of productivity has remained opened and will be considered later.

6.8 Web-based visualization interface of the project's session -- Queued



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