- Author: Roman Savochenko
Maxim Lysenko (2010-2012) - Video addons:
- An official addon of OpenSCADA 0.8.0 LTS (deprecated,
), Roman Savochenko, 2012 - Video "How to ..." from Sergey Karpesh (), Sergey Karpesh, 2018
- An official addon of OpenSCADA 0.8.0 LTS (deprecated,
- Initially created: in the old Wiki
- Complete revised: 12.01.7532/11.03.2024
OpenSCADA is an extremely modular, flexible and multifunctional SCADA system. As a result, the first acquaintance with OpenSCADA can be quite complicated due to the small chances of matching the previous experience of the user with the approaches of OpenSCADA or complete absence such experience. However, in large part, this is only the first impression since all OpenSCADA power is in the hands of the user and from the variety of which the user may be confused and it may require considerable effort to select the functions needed to solve its task.
For this reason, this document was created for a clear presentation of the general concept of OpenSCADA using. The document, on examples and in a relatively short and visual form, provides a way from installation and startup OpenSCADA up to creating user interface elements. The Frequently Asked Questions and "How to ..." documents can be used as a targeted help in the configuration, implementation and solving typical tasks around OpenSCADA.
The document is intended for OpenSCADA version 0.9 and higher. If you are interested in this document for earlier versions then you can get it from the documentation that goes with the packages with that version of OpenSCADA, or from this old Wiki document.
The document does not contain a detailed description of the concept and deepening to the OpenSCADA details, but provides links to other documents those contain such information, and in the first place that is Program manual.
The document is built synchronously with the examples implementation connected to the demo database (DB) of the simulator "AGLKS" as a data source — PLC. Accordingly, the user must receive the OpenSCADA distribution with this DB as described in more details in the part Installation!
Contents
- 1 Terms, definitions and abbreviations
- 2 OpenSCADA installation
- 3 Initial configuration and starting
- 4 Working with data sources
- 5 Formation the visual representation
- 6 Conclusion
- 7 Links
1 Terms, definitions and abbreviations
1.1 Terms and definitions
- Blocking — conditional border of value the technological parameter at which overcome there performed a preset algorithm to prevent the emergency. In some modes of TP (starting) according to the regulations, you can be needed in disabling the blockings — deblocking.
- Deblocking — process of the blockings disabling on time of TP working in some modes for which the operation reserved in the regulations. Deblocking the technological parameters is strictly reporting operation and it must be performed by the operative personal in an appropriate order!
- Complex parameter-tag or object-tag of the signal — detailed signal of the data source as a complex parameter-tag, which for analog one usually contains:
- signal value in the engineering-real measurement unit;
- name of the measurement unit;
- scale-range of physical changing the signal value — minimum and maximum borders;
- borders of signalling — usually it is the upper and lower boundaries for warning and alarms;
- filter parameters;
- parameters of the scale specifics, determining the authenticity, format of representing and more.
- Data model — organisation and structuring the TP data or other automation object in layer of the SCADA data source, protocol or PLC. By default it means the OpenSCADA data source layer with the structure "Controller object"->"Parameter, Level 1"->...->"Parameter, Level N"->"Attribute of value - signal".
- Generic Storage — primary storage of OpenSCADA (pointed early as "*.*" and next indirectly as "<gen>"), which designed for combination the Configuration File and the work Data Base in single storage of the generic OpenSCADA data. Where the Configuration File is primary for the data already existing there, ie their changes, and everything new is created in the Data Base.
- Project — the term has many meanings and, depending on the context, may imply:
- OpenSCADA project (program) — free software, documentation of which you are reading now.
- Specified set-folder of the configuration and data, which is created by the user of OpenSCADA, where configuration is stored in the configuration file (required) and one or more DB files (optionally and maybe online). For example — demonstration project, simulator of the TP "AGLKS". That is, the author of the project is the user of the program — the engineer-developer or programmer of the SCADA system.
- VCA project — component of area of the visualisation and control (VCA) created in the module UI.VCAEngine through UI.Vision and contains a set of VCA frames.
- Qt — software development tool with which in particular the QTStarter (starter of OpenSCADA modules on the library Qt), QTCfg (GUI configurator of OpenSCADA) and Vision (editor and executant of the working user interfaces of VCA) modules are created. It may be encountered in the form of QT, which is an early entry used by OpenSCADA developers for the Qt library.
- Quietance — process of confirming the fact that operational personnel have paid attention to violations in the TP operation. The process mostly means of take actions for the violation eliminating and pressing to the button of the alarm quieting.
- Alarm setting — conditional border of value the technological parameter which overcoming means as abnormal situation. The following borders are usually provided:
- Upper and bottom alarm borders — borders of alarm values of the technological parameter.
- Upper and bottom warning borders — warning borders — regulatory borders on the technological parameter going beyond the working range.
- Failure — points to the parameter value out the hardware borders of the technological equipment. Usually characterises the failure of the sensor, interruption of the communication channel with the sensor or PLC.
- Signal (in relation to the data source) — element of the data source in the form of measured or calculated value of the technological parameter or sensor. Represents scalar of the discrete, integer or real type, which is often encoded by scaling the parameter scale to the integer dimension. The signal for identification is often simply indexed or encoded at the address of its value on the map of the exchanging protocol and the meaningful name appears in the SCADA data model.
- Signalling — process of notification the operative personal about violation of the technological process or the automation equipment work. The notification methods can be different types of influence to the human senses for take it attention. There often provided next types of signalling:
- Light signalling — it is typically performed by changing colour of the graphical object (blink) for the emerging events and by setting the static alarm colours (red and yellow) for events have quietance-confirmation.
- Sound — it is performed by sound signal out in moment of the event emerge. The sound signal type can be both as monotonic and the speech synth message with information about the violation.
- VCA frame — derived visualisation element, consisting of the basic elements and able to serve functions of the project page of VCA.
- VCA widget — visualisation element of VCA.
1.2 Used abbreviations
- API — Application Programming Interface of OpenSCADA modules or extensions on internal language of OpenSCADA — User API.
- AWP — Automated Work Place. Usually it is system unit of computer system, display, mouse "manipulator" sometimes with keyboard, and other peripheral equipment, which serves to visualise data of the technological process, as well as issuance of control actions on TP.
- DAQ — Data Acquisition.
- DB — Database.
- DCON — name of one of the communication protocols used in industry.
- EVAL — Error VALue, used in dynamic data and the internal language for specifying a specific value-sign of the data missing or error, which is different one for different value types, but they are transparently converted one to other. As a useful synonym to EVAL in the internal language is currently used null.
- FS — File System.
- GPL — General Public License under the conditions of which OpenSCADA distributed and may be used.
- GUI — Graphical User Interface.
- HMI — Human-Machine Interface.
- HTTP — HyperText Transfer Protocol.
- MOD — Matching to Object Device. Number of devices or PLC modules to whose being directly connected signals from sensors of TP for followed converting from analog to digital form and back. The conversion performs with goal of following processing of the technological parameters in PLC.
- ModBus — Modicon BUS is a serial communications protocol, in the variants RTU and ASCII, originally published by Modicon in 1979 for use with its PLCs. Later it was expanded to work over TCP-IP and this variant was named ModBus/TCP.
- OS — Operation System.
- PLC — Programmable Logic Controller.
- QT — look for QT in the list of terms, it is not an acronym.
- SCADA — Supervisory Control and Data Acquisition.
- SO — Signal Object. Letters in the abbreviation have been rearranged to eliminate confusion with the abbreviation OS (see above)
- TP — Technological Process. Whole complex of technological equipment of the technological process.
- TUI — Terminal(Text) User Interface.
- UI — User Interface.
- VCA — Visual Control Area.
2 OpenSCADA installation
Installing OpenSCADA in general can be done in two ways. The first and simplest way is to get ready-made packages for the Linux distribution that you are using. The second is to compile OpenSCADA from the source code.
The installation procedure is highly dependent on the Linux distribution you are using and it is not possible to describe that exhaustively in this manual. Therefore, you may need to get a deep knowledge of the mechanisms of installing the software of the selected Linux distribution in its documentation. In the event that the user does not have such knowledge, skills and preferences for a Linux distribution, it is advisable to choose it according to the availability of OpenSCADA packages and even a packages repository, which provides the simplest and most trouble free installation.
If the user has trouble with installing not only OpenSCADA, but also the Linux distribution, then on the first time, he can use the "live" Linux distribution with installed and ready to work and studying the demonstration and full-featured OpenSCADA. If this environment of rapid availability is suited for you then you can stop on it and install it. At this time, "live" builds based on the Debian and ALTLinux (deprecated) distributions are available as hybrid CD/DVD/USB stamps at the page: http://oscada.org/en/main/download/. For more information see the "How to create Live disk" document.
2.1 Installing OpenSCADA from ready-made packages
Installing from the ready-made packages, in turn, can be done in two ways. The first one is simpler, when OpenSCADA packages are already present in their own OpenSCADA package repositories or the official — additional repositories of the used Linux distribution. Installing these packages is a matter of running a typical distribution package management program with the subsequent selection of OpenSCADA packages. In addition to simple installation, the package repository generally allows you to simply keep the operating system updated, safe and up to date! The second method involves obtaining and installing OpenSCADA packages manually.
You can check the availability of OpenSCADA packages in the repositories of Linux distributions or OpenSCADA, as well as download OpenSCADA packages for manual installation, on the download page of the official OpenSCADA site. Here you can also get the configuration for connecting the OpenSCADA package repositories to the package manager of your Linux distribution.
You must download packages and connect package repositories directly to the version of the distribution that you use, otherwise there may be unresolved dependency problems at the installation process.
2.1.1 Adding a package repository and installing OpenSCADA from that
Package repositories are provided by the OpenSCADA project itself, whose service information is usually located along with the packages themselves and is updated automatically at the building, that is, these repositories are most up-to-date and preferable. Although OpenSCADA packages can still be found in the repositories of such Linux distributions: ALTLinux and distributions based on the package base Fedora, but they rather will be old ones since the packages building to the distribution repositories from the developers is not practiced right now!
Repository addresses and configurations for the repository manager can be found on the same OpenSCADA download page (http://oscada.org/en/main/download/) or in the examples below.
When installing from the repository, we select only the package with the configuration of the OpenSCADA project or the model. Everything else will be selected and installed automatically according to the dependencies. The following packages of this kind are usually provided:
- openscada-model-aglks, openscada-model-boiler — projects of dynamic simulators of technological processes, which together perform the function of demonstrating OpenSCADA;
- openscada-vis-station — template project of the SCADA station, usually run in a graphical interface and without a Web;
- openscada-server — template project of the SCADA server, running in the background — the daemon mode;
- openscada-plc — PLC template project, running in the background — the daemon mode;
- openscada — typical-complete installation of OpenSCADA.
In the case of the Automation Linux Distributive and LTS packages, the suffix "-lts" is added to the main package name — "openscada-lts", since the repository is one and it contains packages of the both branches: Work and LTS.
Installation-update from the repository is simple but specific to the Linux distribution, window manager or separate program for working with repositories and packages, so we will send the reader to the appropriate documentation for the distribution or program that it uses. Here's a brief look at adding a repository and installing OpenSCADA with standard command line tools:
Package repositories based on the package manager APT (Debian, Ubuntu, ALTLinux) — are added by the location of the downloaded file "openscada.list" to the /etc/apt/sources.list.d folder or by editing the /etc/apt/sources.list file by inserting one line:
Debian (LTS and Work, Automation Linux repository): "deb http://ftp.oscada.org/Debian/12/openscada ./"
Ubuntu (LTS): "deb http://ftp.oscada.org/OpenSCADA/LTS/Ubuntu/22.04 ./"
Ubuntu (Work): "deb http://ftp.oscada.org/OpenSCADA/Work/Ubuntu/22.04 ./"
Installing:
apt-get update
apt-get install openscada-model-aglks
ALTLinux (LTS and Work, Automation Linux repository): "rpm http://ftp.oscada.org/ALTLinux/7 openscada main"
Installing:
apt-get update
apt-get install openscada-Model.AGLKS
Adding the signature verification key (the authenticity) of the repository and packages in it (not necessarily and not in all repositories):
wget -P /etc/apt/trusted.gpg.d http://ftp.oscada.org/Misc/openscada-archive-keyring.asc
# or on old Debian systems
wget -O - http://ftp.oscada.org/Misc/pkgSignKey | sudo apt-key add -
Package repositories based on the package manager YUM (RedHat, Fedora, CentOs) — are added by uploading or creating a file /etc/yum.repos.d/openscada.repo with the contents:
[openscada]
name=OpenSCADA
#CentoOs (LTS)
baseurl=http://ftp.oscada.org/OpenSCADA/LTS/CentOs/7
#CentoOs (Work)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/CentOs/6
#Fedora (Work)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/Fedora/12
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=http://ftp.oscada.org/Misc/pkgSignKey
Installing:
yum install openscada-Model.AGLKS
The package repositories SuSE YaST — are added by the command:
zypper ar -f http://ftp.oscada.org/OpenSCADA/LTS/SuSE/15 OpenSCADA
Installing:
zypper in openscada-Model.AGLKS
2.1.2 Manual installation of the OpenSCADA packages
To manually install the OpenSCADA packages you need to download them from the official site or another source. You can usually download two sets of the packages.
The first set is represented by twelve packages:
- openscada — package with all the files needed to launch OpenSCADA in full volume, including all modules;
- openscada-server — contains dependencies, script file and configuration the server project to run OpenSCADA in the daemon-service mode;
- openscada-plc — contains dependencies, script file and configuration the PLC project to run OpenSCADA in the daemon-service mode;
- openscada-libdb-main — main OpenSCADA libraries for data acquisition and other in the SQLite database;
- openscada-libdb-vca — visual component libraries in the SQLite database;
- openscada-model-aglks — DB and configuration of the dynamic real-time model "AGLKS" (Demo: EN,UK,RU);
- openscada-model-boiler — DB and configuration of the dynamic real-time model "Boiler" (EN,UK,RU);
- openscada-doc-en — offline documentation of OpenSCADA in English;
- openscada-doc-uk — offline documentation of OpenSCADA in Ukrainian;
- openscada-doc-ru — offline documentation of OpenSCADA in mRussian;
- openscada-dev — development package of creation separate OpenSCADA modules;
- openscada-dbg — debugging package of debug information to the binary files for report and search for errors in the program.
The second set is represented by about fifty packages with separation of OpenSCADA modules by packages:
- openscada-core — contains the OpenSCADA core, the basic configuration and the executable files;
- openscada-db-* — modules of the subsystem "DB";
- openscada-daq-* — modules of the subsystem "DAQ";
- openscada-arh-* — modules of the subsystem "Archives-History";
- openscada-tr-* — modules of the subsystem "Transports";
- openscada-prot-* — modules of the subsystem "Transport protocols";
- openscada-ui-* — modules of the subsystem "User interfaces";
- openscada-spec-* — modules of the subsystem "Specials";
- openscada — virtual package with dependencies for installing default configuration of OpenSCADA;
- openscada-server — contains dependencies, script file and configuration the server project to run OpenSCADA in the daemon-service mode;
- openscada-plc — contains dependencies, script file and configuration the PLC project to run OpenSCADA in the daemon-service mode;
- openscada-vis-station — virtual package with dependencies for installing typical configuration of OpenSCADA as visual SCADA-station;
- openscada-libdb-main — main OpenSCADA libraries for data acquisition and other in the SQLite database;
- openscada-libdb-vca — visual component libraries in the SQLite database;
- openscada-model-aglks — DB and configuration of the dynamic real-time model "AGLKS" (Demo: EN,UK,RU);
- openscada-model-boiler — DB and configuration of the dynamic real-time model "Boiler" (EN,UK,RU);
- openscada-doc-en — offline documentation of OpenSCADA in English;
- openscada-doc-uk — offline documentation of OpenSCADA in Ukrainian;
- openscada-doc-ru — offline documentation of OpenSCADA in mRussian;
- openscada-dev — development package of creation separate OpenSCADA modules;
- openscada-dbg — debugging package of debug information to the binary files for report and search for errors in the program.
The first set of the packages is more intended for simple-manual installation since it contains only twelve packages. The second set is intended to be located in the Linux repository and then to be installed by the package manager that automatically resolves dependencies, and also allows you to install only the required OpenSCADA components, thereby optimising the work environment.
Manual setup of the first set of DEB packages can be done by command, having previously changed the working directory to the directory with the packages:
dpkg -i openscada-libdb.main_0.9.0-1_all.deb openscada-libdb.vca_0.9.0-1_all.deb openscada-model.aglks_0.9.0-1_all openscada_0.9.0-1_i386.deb
Manual setup of the first set of RPM packages can be done by command, having previously changed the working directory to the directory with the packages:
rpm -i openscada-LibDB.Main-0.9.0-alt1.noarch.rpm openscada-LibDB.VCA-0.9.0-alt1.noarch.rpm openscada-Model.AGLKS-0.9.0-alt1.i586.rpm openscada-0.9.0-alt1.i586.rpm
During the installation process there may be errors related to the unsatisfactory dependencies. When manually installing from packages, they will need to be handled manually just like installing the OpenSCADA packages or through the Linux distribution package manager. Cases of the dependency problems can exist even when installing through the packages manager if the OpenSCADA repository used that does not match the Linux distribution or its version, or the main package repositories of the distribution itself are not connected. In the APT package manager you can use the command to automatically resolve external dependencies that arose when manually installing OpenSCADA:
apt-get install -f
2.2 Installing-building from the source texts
When there is no way to get ready-made OpenSCADA packages for the selected distribution, a variant of the OpenSCADA build from the source texts only remains. This process is described in detail by the document "How to build from the source texts".
3 Initial configuration and starting
For our main tasks with OpenSCADA, within the limits of this document, it is necessary to install a package of DB of the "AGLKS" simulator — openscada-model-aglks, which can be found in details in the previous section. Of course, if you use the Live Disk then you already have everything you need.
Do not consider OpenSCADA installation-building here from the source texts since the requirements of the user's qualification level for this task are much higher than the level of the document as a whole and there inevitably will be mismatches with the manual due to very likely differences in the initial configuration.
The installed DB of the "AGLKS" simulator does not require any pre-set up. If you want to perform a specific configuration, which differs from the base, then use the Program manual. In the process you may need information about typical OpenSCADA accounts and passwords (not related to OS accounts), although simulators and newly created configurations start from a privileged user and you can easily change any of them:
- Superuser (root), password — "openscada".
- User (user), password — "user".
- An example of an individual user (roman), password — "roman".
The OpenSCADA demo, based on the "AGLKS" simulator database, is not the same as that is usually provided by the commercial software vendors to demonstrate the possibilities, but to exclude or to complicate the normal operations by limiting the functions. Demo of OpenSCADA is fully-functional program that provides examples of implementation and configuration of various components. Basing on the "AGLKS" simulator database and other OpenSCADA simulators you can create own projects using the given working out. But after gaining some experience, it is better to create new projects from a clean configuration with standard OpenSCADA libraries, which will be mentioned later; and this is in order not to clutter up the project with unnecessary components, thereby increasing resource requirements and unpredictability during long-term operation!
The dynamic simulator of the compressor station on 6 gas compressors, which is the basis of the demo database, requires significant resources, that is a processor with frequency of more than 1 GHz (x86) and memory up to 200 MB. These computing resources are needed directly for the dynamic simulator and are not a general indicator of the program's resource intensity in the final tasks! Memory requirements, on the contrary, are a typical indicator for a similar graphical AWP station.
The general process of configuration the SCADA system for implementation the functions of the "top level" — operator AWP, can be divided in two stages:
- Configuring the data sources, creating a database (DB) of parameters of these sources, creation of calculating-logical parameters and setting the history.
- Formation of the visual representation of the TP data by creation an interface for the operator in the form of: mnemos, groups of graphs, groups of contours, documents, and others.
Therefore, our final goal and purpose of this document is to build a complete configuration of the local SCADA station, connected the server and with simulation of the data source based on this demo database (Fig.3).
Together we will get familiar with such important roles of OpenSCADA as: server of acquisition, archiving, visualization; PLC execution environment and remote development. But before that we will look at OpenSCADA and its capabilities in general.
3.1 General overview
Start the local execution of OpenSCADA from the DB simulator "AGLKS" you can from the section "Graphics" of the desktop environment menu for the item "Simulator "AGLKS" on the open SCADA system" with a characteristic icon (Fig.3.1.1).
Local starting also can be done from the console by the command:
openscada_AGLKS
After the starting we'll get a window of the OpenSCADA graphical configurator — QTCfg (Fig.3.1.2) with the opened root page. The demo database specially configured so that the first window you'll see after the starting it is the configurator window, you can then open a window for creating graphical user interfaces, as well as run the user interface project for execution.
The program configurator of OpenSCADA is the main and sufficient instrument for configuration of any component of OpenSCADA. Like to many other components of OpenSCADA, the configurator is implemented as a module. Besides the QTCfg configurator there available other configurators those perform the same functions, but implemented on the basis of other technologies. For example, these are the Web-configurators: WebCfgD and WebCfg.
All actions in further we will overview only in the configurator QTCfg although all of them can be done in other configurators.
Structure of interface of the configurator window can be considered in details by the link. It is more important now for us to overview all available interfaces of OpenSCADA, so click next to the last icon in the top on the toolbar, which will open a window of development the user interface (Fig.3.1.3).
Then we can start execution of the "AGLKS" project, to do that select its in list of the projects and run, by clicking on the first left icon on the toolbar, or in the the popup menu. The result will be window of the end interface of the user — the operator (Fig.3.1.4).
Building and executing the user interfaces is implemented by the Vision module of the "User interfaces" subsystem. In addition to this module the other modules of visualization is accessed, for example, OpenSCADA provides the WebVision module, which allows to execute projects, previously developed in the "Vision" interface module, through the Web technologies and by standard Web-browser.
For accessing the Web-interfaces of need host on the Figure 3 you can sequentially try such URL: http://localhost:10002, http://localhost:10003, http://localhost:10004.
All actions in further we will overview only in the "Vision" module interface.
So we ran the OpenSCADA demo and familiarized with main set of the tools. In further we will use them in configuration OpenSCADA to perform the functions of the "top level" — AWP operator and other tasks.
Close the program through the appropriate menu item "File", that must be made obligatory otherwise its further background launch will not be able to open ports already busy by this program.
3.2 Background and remote execution — server, PLC execution environment and remote development
All the console operations you can do in a console terminal, for example, the program "konsole" in the Live Disk environment at the Alt+F2 startup dialog. And the "{HOME}" folder here is "/home/user".
The OpenSCADA project organisation in a separate folder makes it easy to run ready-made projects in the service space — execution in the background, as well as further update and maintenance of this project without direct remote control. In fact, you can develop a project locally by keeping its folder in the user's work folder (typically "{HOME}/.openscada"), and to run in the service space just copy or package, transfer to a remote work device and unpack into the system work folder (default "/usr/share/openscada").
Service-background execution of programs in Linux is serviced by a suitably generated scripts, which are located in the folder "/etc/ini.d" and must be separate for each OpenSCADA project that runs in the service space. To simplify and eliminate the need to create your own scripts, OpenSCADA provides appropriate ones for standard cases-profiles that are typically supplied with the openscada-server and openscada-plc packages (openscada-lts-server and openscada-lts-plc for LTS).
Therefore, to launch the AGLKS library project in the service space, we:
- install the packages openscada-model-aglks (openscada-lts-model-aglks for LTS) and openscada-server (openscada-lts-server for LTS), if they were not installed yet and that is not environments of the Live Disk or the Linux Automation from the Disk installation;
- start the project "AGLKS", for getting its folder in the user's work folder;
- copy the project "AGLKS" folder to the system work folder also renaming to "server", previously stop the background execution of the project "server" and remove its project folder; for example, in that way from the console:
# Connect from the superuser
su -
# ... for the live disk and some other Linux environments
sudo bash
# Stop down of execution of the previous server configuration and remove its folder
service openscada-server stop; rm -R /usr/share/openscada/server
# ... for LTS
service openscada-lts-server stop; rm -R /usr/share/openscada/server
# Copy the project "AGLKS" from the user home folder "{HOME}" also renaming to "server"
cp -R {HOME}/.openscada/AGLKS /usr/share/openscada/server
# Start the server already in the project "AGLKS"
service openscada-server start
# ... for LTS
service openscada-lts-server start
Note, that locally you may not to copy the entire project folder, but only make a symbolic link to it, but you get the risk of double project execution on a shared folder and data, which leads to the crash of one or both executions!
Difference between the project execution in the service-background environment from the user environment of the desktop is actually one, except for the lack of the local graphical interface of course, it is the absence of a locale in the background, ie the interface language will be English. And what can be fixed simply by changing or adding the configuration parameter <prm id="Lang">uk_UA.UTF-8</prm> to the section-tag "station" of the file oscada.xml of the background project.
In this way you will get the demo database (the "AGLKS" project) that works in the background, which, however, we will not see until we try to connect to this configuration, as below. Now, every time you start the computer, it will be launched in this way and run in the background. In general, this is the way tor starting and execution the server configurations, PLC environments and one-board PCs similar to RaspberyPi.
If you still have problems with the console-terminal or you deliberately want the background run in the graphical environment — the so-called "start or close in the system tray", then at this stage you can re-run the demo configuration, as described in this section top (Fig.3.1.1), set the Collapse or startup to the system tray option of the UI.QTStarter module and close the configuration window so that the AGLKS simulator project collapses to the system tray.
3.3 Your own project creation
In the window of the OpenSCADA project manager (Fig.3.3) we will create our own project, which can be called from the desktop environment menu in the "Graphics" section, the general item "Open SCADA system" with the characteristic icon (Fig.3.1.1) or the command from the console-terminal:
openscada
In this window we can also check the background execution of server and demo configurations.
That is, press the corresponding Create-update project button and enter the name of the new project — Start.
When you want to check yourself for some problems or other reasons, you may download backup of the already ready OpenSCADA "Start" project and restore it by context menu in the same window Figure 3.3. You have to place the backup file in directory of OpenSCADA user projects — "~/.openscada/", like to from the console-terminal:
wget http://ftp.oscada.org/OpenSCADA/Projects/Start_QuickStart.backup -P ~/.openscada/
3.3.1 Connecting and using remote and background configurations
Now we can try to connect remotely to the background demo project, look at its configuration and launch the demonstration project on the local execution from the visualization server.
On the page "Transports" (Fig.3.3.1.1) in the User and System mode we will create a connection to our background demonstration "AGLKS" as an OpenSCADA station. We specify there the transport Sockets, the address localhost, the user root and the password openscada. After updating the configurator tree at the context menu command, we have to get a new root item of this connection and we can control the remote background station from this configurator.
When the remote station item appears but displays a lack of connection, then you made a mistake in the configuration above or the remote station is not available, which in our case can mean only that it does not work in the background, so return to the proper section and repeat the operations there.
When everything works, we will save this configuration by clicking the second icon on the left in the toolbar above, because we are going to still use it for direct transferring the data acquisition parameters from the demon project, as PLC.
On configuration page of the UI.Vision visualizer (Fig.3.3.1.2) we will select:
- station of the VCA engine — "AGLKS";
- starting user — leave blank;
- user password of this remote station — leave blank;
- project(s) of their automatic execution — also leave blank, because we want to see the possibility of remote development.
The next launch of the UI.Vision module by the second end icon on the toolbar above should lead the visual development environment to a connection to the visualization project of the background demon project. Where you can perform remote development (fig.3.3.1.3) and run projects from this visualization server for execution (Fig.3.3.1.4).
This configuration of the remote connection to the visualizer server is not necessary to save and the configuration field "Station of the VCA engine" (Fig.3.3.1.2) should be returned to "<Local>" and the station user set to "root" — then save.
The ability to remotely connect and develop is sometimes the only way to develop or correct not only server configurations with the WEB interface only, but also for configurations with the locale visualization, when the locale environment itself is not suitable or limited to execute the development environment of the UI.Vision module, such as smartphones, tablets, and other small screen mobile devices, exclusively with touch input (Android) or restrictions such as the inability to open the system virtual keyboard (Nokia N9). And this remote development can mostly be done in the process of executing a project — the hot development, that is especially relevant for Web interfaces and local interfaces that run only in the execution window. As about remote configuration, that is to one local configurator, as the administration centre, can be collect all the remote stations in the network including the stations in the hidden networks of the first level stations which can be "raised" by the "Level of lifting" argument (Fig.3.3.1.1).
3.3.2 Connecting the standard OpenSCADA libraries
The newly-created OpenSCADA project does not contain any specific configuration, in fact it is empty and provides for the user to create a new configuration in the local SQLite database file "St.db", which is located in its own directory of the project with the same name. It is easier to create a complex project of the SCADA system using libraries of functions of the API of the OpenSCADA object model and libraries of the graphical elements, as well as other OpenSCADA libraries. To use the OpenSCADA libraries you need database files where the libraries are stored: connect-add in the object of the database module "SQLite" (Fig.3.3.2.1), install-select the address and specify the database encoding in "UTF-8" (Fig.3.3.2.2). After what, or when there are already library database entries, you need to activate need ones, read on.
OpenSCADA distributions are supplied with a number of libraries in form the database files "SQLite" (table 3.3.2), which, when started-created a custom project, are located in the "LibsDB/" directory. According to this list we add, or use the ready entries, in the object of the database module "SQLite" for need libraries, we set the sign "To enable" and save. Next, to download the contents of the libraries you can enable the database and click on the button "Load the program from this DB", however, when loaded, a number of new objects are not enabled, so it's easier to exit the new project and run it again.
Table 3.3.2. OpenSCADA libraries included in the distribution.
| Identifier | Name | Address | Languages/charset | Description |
|---|---|---|---|---|
| OscadaLibs | OpenSCADA libraries | LibsDB/OscadaLibs.db | EN,UK,RU/UTF-8 | Libraries of the data sources, services and processing. |
| vcaBase | VCA: Main libraries | LibsDB/vcaBase.db | EN,UK,RU/UTF-8 | Graphical elements' libraries of the OpenSCADA module UI.VCAEngine. |
| vcaTest | VCA: Tests | LibsDB/vcaTest.db | EN,UK,RU/UTF-8 | Graphical elements' tests library. |
| vcaElectroEls | VCA: Electrical elements library of the user interface | LibsDB/vcaElectroEls.db | EN,UK,RU/UTF-8 | Provides the mnemonic elements library of the user interface of the electrical substations and the electricity generation station. |
As a result of adding OpenSCADA libraries you will get an environment ready for adding data sources, defining their history and forming the interface of your own SCADA-system project.
4 Working with data sources
Main function of any SCADA-system is to work with realtime data sources, that is polling of the programmable logic controllers (PLC) and simple modules of MOD. For more details see the document "Data acquisition in OpenSCADA".
Support for a given data source depends on the protocol or API, accordingly to which the source provides its data, and the availability for the protocol-API of the module of the subsystem "Data acquisition" in OpenSCADA or its implementation on the Logical Level by DAQ-Template. The total list of modules of the subsystem "Data acquisition" and documentation on them can be found here and generic list the DAQ-Templates can be found here.
Data from the sources is further processed, archived and used for visual representation of the TP operator.
4.1 Data acquisition from the TP device
As an example let's examine and create the acquisition for the air cooler device. The background demo database, as PLC and data source, contains the real-time model of the compressor station with six compressors. Data for two devices of air coolers AT101_1 and AT101_2 of the compressor station CM101 are available via the ModBus/TCP protocol on 10502 port (by default, this is port 502 if there is access to open it).
We will create an object for the controller to acquire on the protocol ModBus/TCP and get this data. Thus, we actually realise the task of acquisition real data since our configuration will differ from working with real external device only with its address and the addresses of the ModBus registers, and that may also be another physical interface of the interaction — variant of the protocol ModBus. This connection is also a bright example of the ability to implement a data source environment (PLC) based on OpenSCADA.
To acquire data by the ModBus protocol in OpenSCADA, there the ModBus module of the subsystem "Data Acquisition" is provided. To add a new controller object in the configurator, open the module page ModBus "Start"->"Data Acquisition"->"Module"->"ModBus" and press "Add" in the "ModBus" item's context menu (Fig.4.1.1).
As a result, a dialog box (Fig.4.1.2) will appear asking you to enter identifier and name of the new controller object. Identifiers of OpenSCADA objects are limited in size to 20 characters and it is recommended that they be entered with the characters of the English alphabet and numbers. In addition, it is desirable to start the identifier from letter, which will simplify its use in internal procedures. Names of OpenSCADA objects are limited in 50 characters, which can be any. Names are usually used to display and when it is empty, the identifier will be used. In further we can change the name in the object configuration, but the identifier can not be changed directly; however, the object can be cut (Ctrl+X) and then paste (Ctrl+V), renaming it. Enter according to the remarks earlier the ID CM101, the name "CM 101" — "CM101 (CM 101)".
After confirmation we will have the new controller object. Let's select it in the configurator and familiar the settings (fig.4.1.3).
Configuring the controller object is usually specific to different types of data sources and protocols. For details of settings of the controller object of the module ModBus see to the link. We will consider the general and key settings of this module.
Before configuring communication with your controller it is necessary, from the documentation for this controller, to find out the settings of its network interfaces and protocols as well as, in the case of using ModBus, get a table of assigning external and internal signals of the controller to the numbers of the ModBus registers — the registers map.
Using the controller object page, in the "State" section you can first estimate the current status of the controller object and the actual state of communication with the physical controller and also change them quickly. That is, the "Status" field contains error code and text description of the current state of communication with the controller. In our case, the controller object is disabled. We can enable and run it by installing signs in front of the appropriate fields. Enabled controller object initiates parameters, running one launches a task of acquisition (separate thread to the controller object) also and provides the ability to transfer data to the controller through attributes of the parameters. The "Storage" field indicates the storage in which the configuration of the object is stored. We will arrange storage in the Generic Storage, that is, leave this field default.
In the "Configuration" section, the configuration of the controller object is directly located. Set the following ones leaving everything else unchanged:
- "To enable" and "To start" indicate what state to move the controller object when the program is started — set both fields.
- "Acquisition schedule" contains configuration the scheduler to run the data acquisition task. You can get description the configuration format for this field from the tooltip. Single number indicates to periodicity of the execution, in seconds — we'll specify one second.
- "ModBus protocol" refers to variant of the ModBus protocol. Possible variants of the protocol are "TCP", "RTU" and "ASCII". Currently we are interested in the variant TCP, so leave it as it is. The protocols "RTU" and "ASCII" must be installed in the case of communication with the controller through serial interfaces, often it is "RS-485".
- "Transport address" indicates the outgoing transport of the subsystem "Transports", which is used to connect to the controller. In the case of the variant "TCP", we need a transport in the module Sockets, and in the case of the variants "RTU", "ASCII" and serial interfaces we need a transport in the module Serial. About creation the outgoing transport in "Sockets" and "Serial" will elaborate below.
- "Destination node" indicates to node of the data source or controller in the ModBus network. In our case it should be 1.
- "Merging of the data fragments" enables merging non-adjacent registry fragments in one block of the request up to the specified maximum number of bytes instead of generating individual queries, than allows you to reduce total acquisition time — set this option.
Save our changes in the storage by clicking the second left icon on the toolbar.
Now, in the same manner as the controller object, let's create the outgoing transport in the module "Sockets" ("Start"->"Transports"->"Sockets") through the context menu (Fig.4.1.4) and call the transport as well as the controller object "CM101 (CM 101)". Please note, that in the "Item type" field of the dialog of entry identifier and name (Fig.4.1.2) you have to select "Output transport"!
Configuration page of the output transport is shown in Figure 4.1.5. This page also contains section of the status and operational control. In the "Status" field the textual description of the current state of the transport is contained. We can connect it by checking the box in front of the appropriate field. The field "Storage" indicates the object configuration storage — we will use the "Generic Storage".
The "Configuration" section directly contains the main configuration of the transport object, let's set the following ones:
- "Address" specifies: the type (optional), address and mode of connection with the remote station. You can familar the record format in tooltip — set this field to the value "localhost:10502".
Other types of the transports are created similar to the considered for "Sockets" method and their configuration usually differs only in the format of the address and timeouts in the tab "Additional". For converters USB->Serial,Modem that address you may learn in the operation system, for example by the console command dmesg just after its connection.
Let's save the transport object and return to the configuration field "Transport address" of the controller object and select the address "Sockets.CM101". Currently OpenSCADA supports for controller objects of most data source types to specify all transport parameters directly in the field "Transport address" and without need in separated creation any transport objects. That is pointing in the field for "Sockets.CM101:localhost:10502" will automatic create CM101 in the Sockets output transports with the specified address.
Configuration the controller object is finished — enable its by setting the flag "Enabled". The next step is configuration and choosing the data you need to query from the controller. This setting is done by creating a parameter of the controller. The parameter allows you to describe list of data obtained from the controller and to transmit them to the environment of OpenSCADA — the data model.
To add a new parameter we open the page of our controller object and on the popup menu of the item "CM 101" we'll click "Add" — we'll name "AT101_1 (AT 101_1)".
The configuration page of the obtained parameter is shown in Figure 4.1.6. This page contains the section of status and operational control. In the "Type" field it is contained the parameter type, in this case it is the type "Standard". We enable this parameter by setting a sign opposite the corresponding field. The enabled parameter is involved in the process of exchanging with the controller.
The "Configuration" section directly contains the configuration of the parameter. Set the following ones, leaving everything else unchanged:
- "To enable" indicates to need of transfer the object to the "Enabled" mode when the program is started — set this field.
- "Attributes list" contains configuration of the parameter attributes relatively to registers and bits of ModBus, you can familiar the record format in tooltip — set contents of this text field to:
R:100:r:Ti:T input R:101:r:To:T output R:102:rw:Cw:Productivity
In the same way we'll create, or copy from AT101_1, the second parameter "AT101_2 (AT 101_2)" — list of attributes for its we'll establish in:
R:103:r:Ti:T input R:104:r:To:T output R:105:rw:Cw:Productivity
Save both the parameters. Now we can start our controller object for acquisition, for that we'll return to its page and in the section "Status" set the sign "Running". If we do not miss anything, then the exchange will start successfully and in the "Status" field we get similar presentation as shown in Figure 4.1.7.
In the case of the successful exchanging with the physical controller, we obtain also the described data of the controller in the infrastructure of OpenSCADA — the data model. You can see these data in the "Attributes" tab of our parameters AT101_1 (Fig.4.1.8) and AT101_2. Due to the acquisition is done regularly and periodically per one second, then we can observe their change by clicking on the "Refresh current page" button in toolbar.
On this, configuration of the data acquisition is considered complete.
4.2 Processing received data of the TP
Often there is a situation where the input data obtained from the data source is "raw", that is unprepared or inconvenient for the visual representation, therefore it is necessary to carry out this preparing. In our example, we got the data that comes in code from the scale inside the controller and our task is to make calculation of real values from the obtained data. Data processing in OpenSCADA can be done either directly in the visualisation or in the DAQ-Subsystem. However, mixing the process of the visualisation and processing of the input data confuses the configurations, prevents the history of real data, makes the resulting visualisation shapes less suitable for reuse and increases the load on the visualisation thread, thereby reducing its overall reaction. Accordingly, we will prepare the data in the DAQ-Subsystem.
Calculation in the DAQ-Subsystem for obtaining the real data is mostly done via the Logic Level module LogicLev and templates of parameters of the DAQ-Subsystem. The module ModBus is a case where such calculation can be made directly in it, as we will see below. To familiarise with the Logical Level concept you can here.
To perform the calculation, in the Logical Level module you must firstly create a template library of our project and a parameter template of the DAQ-Subsystem in it. To create a template library go to the page of the DAQ-Subsystem and, through the context menu, create a template library start (Start). The configuration page of the obtained object of the template library (Fig.4.2.1) contains the "State" section of the status and operative control, and the "Configuration" section that contains only the default configuration fields and which will remain unchanged. In general we have:
- The section "State":
- mark the library accessible — set a sign opposite the corresponding field;
- specify the storage — leave the "Generic Storage" of the project;
- can control date of the last modification.
- Save the object.
To create a template, open the page of the newly created template library "Start"->"Data Acquisition"->"Templates library"->"Start" and, through the context menu, create an object of the template airCooler (Air cooler). The configuration page of the obtained object of the template (Fig.4.2.2) contains the "State" section of status and operative control, and the "Configuration" section, that contains only the default configuration fields and which will remain unchanged. In general, we have:
- The section "State":
- mark the template accessible — set a sign opposite the corresponding field, the accessible templates can be connected to the data acquisition parameters and the parameters will be calculated based on this template;
- can control number of the objects, that use this template to calculate;
- can control date of the last modification.
- Save the object.
Main configuration and formation the parameter template of data acquisition is made in the tab "IO" (Fig.4.2.3) of the template. Detailed description of the process of the template formation can be found at link.
In the template we will create two IO for inputs ("TiCod", "ToCod"), two for output ("Ti", "To") and one transparent ("Cw"). For the IO "TiCod", "ToCod" and "Cw" we will set the "Configuration" sign in Link, which will allow them to be linked with the "raw" sources. Will set the sign "Attribute" for the IO "Ti" and "To" to Read only, for "Cw" to Full access — to form three attributes in the data acquisition parameter: two is on read only and one on full access.
Set the language of the program in JavaLikeCalc.JavaScript and the program in:
Ti = 150*TiCod/65536;
To = 100*ToCod/65536;
Save the obtained template and establish a sign of accessibility (Fig.4.2.2).
Now we will create objects of the controller and parameters in the LogicLev module of the DAQ-Subsystem. Object of the LogicLev controller and its parameters are created identically to the ModBus module earlier on the page "Start"->"Data Acquisition"->"Module"->"Logical Level". We name them identical to the objects of the module ModBus.
The controller object of the module LogicLev (Fig.4.2.4) has no specific settings and the default ones may not be touched except the "Schedule of the calculation" field, which will install in 1 (one) second. Before adding parameters you must turn on the controller object — set the "Enabled" flag.
Parameter of the controller object of the LogicLev module (Fig.4.2.5) has the specific setting "Type", where you need to set "Logical", and select the template address, we have just created, in the field "Parameter template".
In addition to the basic configuration of the parameter it is necessary to configure the attached template (Fig.4.2.6). Configuration tab of the template appears in the parameter's mode "Enabled". To enable the parameter it is possible by the previously enabling the controller object. The flag "Show attributes" allows you to set apart each link (Fig.4.2.7). Since we in the template forcibly described the links format as "Parameter|Ti", we can establish all three links by simply pointing the address to the parameter in the controller object ModBus. Specify-select the address "ModBus.CM101.AT101_1" and "ModBus.CM101.AT101_2" in the appropriate parameters.
It should be noted that all the fields for entering object addresses in OpenSCADA have a mechanism for selecting the address. This mechanism involves element-by-element selection, during which movement in depth occurs. For example, at the beginning of the address "ModBus.CM101.AT101_1" set we will have an option of choosing the data source type, among which will be "ModBus"; after choosing which controller objects of the ModBus module will be added to the list of available selection elements where "ModBus.CM101" will be; selecting the element "ModBus.CM101" will add controller parameters and so on to the final element according to the object hierarchy. For possibility of returning to the level above, the elements of all the higher levels from the current address value are inserted into the list of choice.
Let's save the created objects of the controller and parameters, after which we will start up the controller object by setting the "Running" sign in the "State" section. If we do not miss something, the calculation is successfully started and in the "Status" we'll get something like to Figure 4.2.8.
In the case of successful processing the template code in the parameters, we'll obtain the processed data in the infrastructure (the data model) of OpenSCADA. You can see these data on the "Attributes" tab of our parameters AT101_1 (Fig.4.2.9) and AT101_2.
On this, the configuration of the data processing is considered complete.
4.3 Complex object-tag of the signal
The previous sections described the mechanism of connecting the data source as an apparatus object — "Air cooler", which involves combining all the signals in one object of the data source parameter. However, the more common approach to large automation is formation the parameter object around an individual signal, for example — "Temperature at the output of the refrigerator AT101_1 (TE1314_1)", which are often called tags.
Creating the parameter object around a signal allows to formalise its description to the templates of analog and digital signals by including to them all necessary processing, alarming and other characteristic information. For simple configuration of the typified analog and digital signals there are the parameter templates in the OpenSCADA libraries and many of the visual presentation shapes are adapted to work and binding with these parameters directly, without going into details on the attributes.
Moreover, unified templates are provided with the possibility of deep processing of input signals by defining in the field "Input processing procedure" for a procedure on the internal language JavaLikeCalc. And even more, in this procedure it is possible to expand the template data model of the parameter with auxiliary dynamic attributes, actually "hanging" on it the elements of the device object, starting from its main signal; that is without creating additional templates for this. Like this for appending an attribute for setting input manually:
if(ctx.f_start == null) {
ctx.f_start = true;
this.attrAdd("setIn", "Input set", "real");
this.setIn.set(0);
}
in = this.setIn.get();
Typically, for creating a parameter based on a template, the LogicLev module is used as described in the previous section. However, a number of modules, including ModBus, provide the ability to immediately create logical parameters based on the template. We will add new parameters by opening the page of our earlier created ModBus controller object and clicking "Add" button on the "CM 101" menu item in the configurator.
We name the analog parameter — TE1314_1 (TE1314_1) (Fig.4.3.1). The parameter type set to "Logical", the parameter template select in "base.anUnif", the description set in "Output temperature AT101_1", set the flags "To enable" and "Enabled". Next, we need to configure:
- The parameter template in the tab "Template configuration", which appeared (Fig.4.3.2):
- the "Input" field set to value of the ModBus-register address of this parameter — "R:101";
- the "Maximum module scale" field set to value — 65535, which corresponds to 100 °C.
- The "Attributes" tab (Fig.4.3.3):
- "Dimension" to — "deg. C";
- "Scale: minimum" to — 0;
- "Scale: maximum" to — 100;
- "Border up alarm" to — 40;
- "Border up warning" to — 30.
- Save the object.
We name the discrete parameter — CB102 (CB102). The parameter type set to "Logical", the parameter template select in "base.digitBlockUnif", set the flags "To enable" and "Enabled". Next, we need to configure:
- The parameter template in the "Template configuration" tab (Fig.4.3.4), which appeared:
- the "Command 'Open'" field set to value of the ModBus-bit address of the parameter — "C:100:rw";
- the "State 'Opened'" field set to value of the ModBus-bit address — "C:101";
- the "State 'Closed'" field set to value of the ModBus-bit address — "C:102";
- the "Time to hold the command" field set to — 0, because the command is not the pulse one.
- The "Attributes" tab (Fig.4.3.5) — make sure the availability of the command and states.
- Save the object.
4.4 Getting for ready data of OpenSCADA — gateway
Having familiarised with the typical mechanisms for obtaining the data, described in the previous sections, you must imagine already the total amount of work on their getting and processing, that is — formalising and obtaining this data in the SCADA-system data model. If you add here the task of creating these data at the PLC level — the data model of freely programmable PLC, and transforming it in the data model of the exchanging protocol, then you should notice a triple data transformation here. About the transformation in the protocol data model — serialisation, this is determined by the physical properties of the communication channels and is carried out automatically, but the formation of the PLC data model and SCADA-system data model is carried out by the programmer of the PLC and the SCADA-system, respectively. Moreover, this work has much in common, especially if performed by one person or organisation, and therefore there should be mechanisms for its unification.
In the case of different origin of PLC and SCADA, greater unification, than layer of the exchanging protocol, is difficult to achieve. On the other hand, the deep unification of PLC and SCADA data models can be found at the same time by PLC and SCADA manufacturers, which, however, only strengthens their monopoly status and in fact reduces the unification benefits through the overall cost of the solution.
OpenSCADA provides for the possibility of such unification through affiliation with PLC. Such affinity can only be provided for PLCs that are completely open, they have open-source software installed, and so you can install OpenSCADA as a PLC execution environment. As an execution environment, OpenSCADA can provide PLC data also by the standard protocols such as ModBus, and to obtain these data directly and without any action on them on the side of the SCADA system, there is the module DAQGate provided, which in fact brings these models together. That is the PLC-programmer, which is a SCADA-programmer also, forms a PLC data model, and at the SCADA-level it is already used as a ready-made, which completely removes the stage and works on obtaining, processing and forming the data model of the SCADA-system. Moreover:
- the discrepancy between PLC and SCADA data models is eliminated when they are changed;
- the configuration data logically and exclusively is stored on the PLC to which they relate;
- violations and other messages are generated on the primary source — PLC, and messages of the intrusions — actions of the operator, are also sent to the PLC;
- provides for a mechanism for storing archive-history on the PLC both fully and as part of the compensation for loss of communication with the SCADA, especially for bad and wireless communications.
In order to demonstrate and familiarise, we will create here a controller object of the module DAQGate to transfer the data of our virtual PLC. It is created identically to the controller objects created earlier in the ModBus and LogicLev modules on the page "Start"->"Data Acquisition"->"Module"->"Data sources gate" and name it "AGLKS".
Controller object of the module DAQGate (Fig.4.4.1) has the following specific settings, which we must accomplish:
- "Remote station" — we will select the previously established connection of the remote station "AGLKS".
- Enable the controller object.
- "List of the remote controller objects and parameters" — in the "Parameters tree" field select "LogicLev.gen" and then "<<Append current>>" above this list.
- Start up the controller object.
If everything is done correctly, then the parameters of the selected controller will automatically be created and we can look at the data on them in the tab "Attributes" (Fig.4.4.2).
4.5 Archiving-history of the TP data
The data obtained early are considered current, that is, those that are periodically updated and characterise the value of the parameter TP for the current time. At the same time, the previously read values are lost when they are overwritten by the current value, that is, their history is missing. In many tasks, the archive-history of the read values of TP parameters is required, for which OpenSCADA provides the subsystem "Archives-History" where we need to create archivers of values and messages, for violations, and specify our parameters for archiving their values there.
If you do not create archivers and do not connect our parameters to archiving by them, then on trends you will not get the history more than its total width and also lose the accumulated during switching, and in the reporting documents you will not get the history at all.
Let's start with the archiving of values, for which it is necessary to create at least one archiver for the required type of storage and the values periodicity. In general OpenSCADA includes two archiving modules — to the file system FSArch and to the database DBArch. Here we will consider only the module of archiving on the file system, as the most universal and effective one. Concerning the value periodicity for the "high-quality" archiver, it is preferable to choose the periodicity of the values of the slowest source of data in our system, which we have one and we specified the periodicity for him in 1 second. To create a value archiver, open the archiving module page "Start"->"Archives-History"->"Module"->"Archiver on the file system" and through the context menu we will create an object of the value archiver "1s". Note the value of the "Item type" field in the creation dialog, which should be the Value archiver! Configuration page of the resulting object of the value archiver (Figure 4.5.1) contains the "State" section of status and operative control, the configuration section "Configuration" and the "Additional options" section of specific settings of the archiver module. In general we have:
- The section "State":
- start the archiver for execution — set the sign opposite the corresponding field, only running archiver performs the archiving;
-
Set last and after the execution of all this list.
- we can control the current and maximum time of the archiving session;
- specify the storage — leave the "Generic Storage" of the project;
- we can control the total archive files size of this archiver.
- The section "Configuration":
- set starting the archiver when the program is started — set the sign opposite the corresponding field;
- set address of the archive folder — "ARCHIVES/VAL/1s", which is by default;
- set period of values — 1 (one) second;
- set the archiving period — 60 seconds, by default and usually it is the same for archivers with any periodicity of values.
- Save the object.
One the "high-quality" archiver is already sufficient for most tasks, but if you plan to build graphs-trends of the values and reporting documents at a great depth (days, weeks, months), then you need to create a couple of archivers with more periodicity of the values, otherwise building the graphics and documents will be long and/or be cut off by the time limits! Typically, such additional archivers are created, and you must create them identically for the "high-quality" archiver above:
- Minute — the identifier "1m", the address "ARCHIVES/VAL/1m" and the value period 60 seconds.
- Hourly — the identifier "1h", the address "ARCHIVES/VAL/1h" and the value period 3600 seconds.
The newly created projects of OpenSCADA contain already for templates of such standard archivers, so you can just enable need ones.
To enable the archiving of the attributes "Ti" and "To" of the AT101_1 and AT101_2 parameters in the previously created controller of the LogicLev module, it is enough on the "Archiving" tab of the configuration page to choose which attributes are to be archived and by what archivers (Fig.4.5.2). We'll choose the archiving of "Ti" and "To" attributes by the previously created archivers FSArch.1s, FSArch.1m, FSArch.1h. The same thing we do for the attribute "var" of the analog parameter ModBus.CM101.TE1314_1 and for "com" of the digital parameter ModBus.CM101.CB102.
As a result of this operation, archival objects for the selected attributes will be created automatically. An example of the archive object for the attribute "Ti" of the parameter AT101_1 is shown in Figure 4.5.3.
Usually the settings of the archive do not need to be changed, but if you need special configuration, it can be done on the aforesaid page. Often you may need to obtain the information about the archive. For example, find out the archive size both in time and on the storage, as well as look at the graph of the parameter (Fig.4.5.4).
The controller objects, as well as individual parameter templates, can generate alert messages, for example — complex signal-tag templates generating messages when output values over one of the borders. Messages of this nature have a specific category and are called violations.
OpenSCADA messages previously come to the message buffer, which acts as the primary archive. However, the buffer has a limit and is stored only in RAM, that is, it is lost when the program is restarted. Role of storing messages in one or another storage is performed by the message archivers, as the value archivers for the values.
Accordingly we will create a message archiver for archiving of violations, for which we will open the archiving module page "Start"->"Archives-History"->"Module"->"Archiver on the file system" and through the context menu we will create an object of the message archiver alarms (Alarms). Note the value of the "Item type" field in the creation dialog, which should be the Message archiver! Configuration page of the resulting object of the message archiver (Figure 4.5.5) contains the "State" section of status and operative control, the configuration section "Configuration" and the "Additional options" section of specific settings of the archiver module. In general we have:
- The section "State":
- start the archiver for execution — set the sign opposite the corresponding field, only running archiver performs the archiving;
- Set last and after the execution of all this list.
- specify the storage — leave the "Generic Storage" of the project;
- we can control the time of the first and last message in the archive of this archiver;
- we can control the total archive files size of this archiver;
- we can control the current and maximum time of the archiving session.
- The section "Configuration":
- set starting the archiver when the program is started — set the sign opposite the corresponding field;
- set category of messages that characterises the violations — "al*";
- set level of archived violations — "Information (1[X])";
- set address of the archive folder — "ARCHIVES/MESS/alarms", which is by default;
- Save the object.
In the same way you can create message archivers of different nature, for example — the operator actions. For which it is enough to define the category of these messages and to form for them a template or regular expression rule. You can obtain the standard categories and their templates, or regular expression rules, on the message archiving page; or can study real messages on the main page of the subsystem "Archives-History", obtain here for information on categories and set up a template or regular expression rule. You can even create an archiver to archive all program messages, but doing so is not recommended because of large archives size and long access to them later.
The newly created projects of OpenSCADA contain already for templates of such standard archivers, so you can just enable need ones.
5 Formation the visual representation
The formation of the visual representation may be performed at three levels of complexity and the user can select any of them depending on demands of the task, level of his knowledge and availability of libraries with ready-made shapes and templates.
THE FIRST LEVEL requires a minimum qualification of the user, but implies the presence of libraries of the template frames, which are needed to solve his task. Within the limits of the first level the user only has to know how to connect the dynamics to pages of the template frames and how to add new pages of the template frames.
THE SECOND LEVEL requires the additional ability — to create new frames based on the finished-complex elements simply by their placement in the frame area. To achieve this qualification level, the user will need libraries of complex elements, needed to solve his tasks.
THE THIRD LEVEL requires that the user is able to use of all the tools of the development environment of the visual interfaces of OpenSCADA, including the creation of new complex elements and developing of the user interfaces in the project.
All actions on the visualisation interface we will make in the environment of the module Vision of the subsystem "User interfaces". To open the Vision interface window you should click the second icon on the right on the configurator toolbar. As a result is the window previously shown in Figure 3.3.1.3.
Interfaces of user-operator are realised in OpenSCADA by the projects of visualisation. In the main elements library of the user interface the typical project template is presented, which based on the concept of the signal objects and views of displaying. The user can start of creation own concept of the visualisation interface by a new project, or can use the specified template.
To implement a new concept of the visualisation project, you will need for knowledge of the third level and significant efforts outside of the consideration of this document. Therefore, we will consider creating a visualisation interface based on the accessible template project.
Copy the project "Signal groups (template)" by first clicking the button "Copy the visual item" on it and then the button Paste the visual item (Fig.5.1). In the dialogue we will call our new project start (Start) and in the project list we will get an item of our new project (Fig.5.1).
Before using and saving the new project (Fig.5.3) you need to change its storage to the "Generic Storage", that we can do on the main page of the properties dialog of the visual element, that is called by the the button "Properties of the visual item" (Fig.5.2). After that we will save our new project by clicking the third button on the left of the toolbar.
The template project (Fig.5.3) contains two branches — "Control panels" and "Root page". The branch "Control panels" contains typical control panels and set of the special frames. The branch "Root page", with the root page basis, contain subbranches for the signal objects "Group 1", "Group 2" and different branch "Result graphics". The signal object's subbranches "Group {n}" have a number identifier and can be expanded by appending up to so many, how many names will fit at the top in two rows. Presence of the grub "Group {n}" is reflected by activating the corresponding button of the signal object of the root page, allowing them to switch. Every subbranch "Group {n}" has containers or templates for display views, typically: "Mnemo", "Graphics groups", "Contours groups", "Groups of overview frames" and "Documents". Presence of pages in containers of the display views enables the selection possibility for the corresponding signal object of the root page. More information about the structure of the root page can be found at the link.
5.1 Adding the template page and connecting the dynamics
Let's examine tasks of the first level complexity, when in the already designed interface conception it is necessary to link the dynamics to the template page. The "Template page" idea means a page on the basis and with the help of inheritance there can be created a lot of final visualisation pages with individual list of the dynamics. Examples of these pages are: "Graphics group", "Contours group", "Overview frames panel" and "Result graphics". In Figure 5.1.1 the template page "Graphics group" is presented in the tree of our project "Start".
The template page "Graphics group" provides an opportunity to link up to eight signals for simultaneous display them on the graphs. Elements at the top will automatically hide for unspecified links.
Let's create a new graphics group in the template container "Graphics group" of the first group of the root page. For that select the menu item "Add visual item" in the context menu of the item "Graphics group" (Fig.5.1.2), then enter ID "2" and name "Graphics 2" — 2 (Graphics 2).
After confirming the name entry, a new page will be created, however, for activation we need to enable it. You can enable this page in dialog of the properties editing of the page (Fig.5.1.3). To open this page it is possible by selecting the menu item "Properties of the visual item" in the context menu of the newly created page. You can create the page in the logical container based on the template by copying the template to yourself, as well as copying another page of this container, but also with links.
After enabling the page you are ready to set links to the early created parameters of the controllers. To do this, without leaving the dialog of the properties edition of the newly created page (Fig.5.1.3), click on the tab "Links" (Fig.5.1.4). On this tab we can see a tree with the elements "el1" ... "el8". Expand any of the element we'll see the branch "Parameter" and exactly in it we have to specify or choose the address of our attributes "Ti" and "To". In general we fill out four elements and during this part of the properties you must specify as constants:
- "name" — "val:AT101_1 Ti";
- "ed" — "val:deg.C";
- "max" — "val:150" (for Ti) and "val:100" (for To);
- "min" — "val:0".
If the template of the controller parameter predicts in advance the attributes presence, specified as constants, then only the parameter can be specified and the attributes are arranged automatically. This can be seen by attaching the previously created complex object-tag of the analog signal ModBus.CM101.TE1314_1.
After completing the linking we can check result of our efforts, to do this we'll close the editing properties dialog and run the project "Start" for execution — about the run button we remember from the previous sections. Next choose the graphics and switch to the second page. With error-free configuration we should see something similar to that shown in Figure 5.1.5. Note that for the parameter of the complex object-tag with the established limits of violations, the output value beyond the boundary is marked by an emergency color. In order to see the violation abroad you can set the value of the fan's performance in 100 (Fig.4.2.9).
5.2 Creating a new frame — mnemonic schemes
Let's raise the level and create a new frame, on which we'll put the basic displaying elements of values of our controller parameters. Such frames are usually called the mnemonic schemes and in addition to the dynamics displaying, and even in the first place, contain a static image of the technological process in the mnemonic representation. We are not going to focus on static creation and will add the dynamic elements and link them to the parameters of our controllers. And we'll put the created frame to the tree of our project.
New frames, destined later to be placed in the project, are to be created and changed in a widget library. Create the new widget library by selecting the vertical tab "Widgets" and in the context menu of the window of the widget libraries select the menu item "New Library" (Fig.5.2.1). In the dialog of entering the name we'll specify — CM101 (CM 101).
Next we'll add a new frame by selecting "... from the Library"->"Library: originals"->"Group of elements" (Fig.5.2.2) in the context menu of the created library "CM 101". In the dialog of entering the name we'll specify AT101 (AT 101). In the basis of any frame and page must lay the primitive "Group of elements (Box)", and therefore we have chosen it.
Immediately after creation the new frame it is necessary to set its basic properties, characteristic to the mnemonic scheme frame. Properties or attributes of any visual element can be specified in the toolbar "Attributes", pre-selecting the desired visual element. Let's select the created frame "AT 101" and set the following properties:
- "Geometry: width" — 900;
- "Geometry: height" — 600;
- "Page: group" — "so", for including the frame into the container of the mnemonic schemes in execution;
- "Background: color" — "#5A5A5A";
- "Border: width" — 1;
- "Border: color" — "black".
As a result we get an empty frame (Fig.5.2.3), ready to add elements to it. To visual edit or review the frame you should select the menu item "Visual item edit" of the frame's context menu.
Now, to the frame we will add elements for displaying the values of the analog parameter for our four signals and the parameter of the complex object-tag ModBus.CM101.TE1314_1. To locate the display element of the analog signal on the mnemonic scheme we need to select it and then select the menu item "Widget"->"Library: Main"->"Analog show" in the menu of the window; after which the cursor will appear with the image of this element, which should be brought into the desired area of the mnemonic scheme and press the left mouse button. At the time of adding, a dialog will appear asking for the name of the new item. Similarly we will add five elements that we call: A1_Ti, A1_To, A2_Ti, A2_To and TE1314_1.
In the same way we add an element of the complex object-tag to the discrete parameter ModBus.CM101.CB102, for presentation of which we will use the library element "Widget"->"Library: mnEls"->"Ball crane" and name it CB102.
To display a list of current violations, on the mnemonic scheme we will place an element of the protocol from the library of primitives "Widget"->"Library: originals"->"Protocol" and name it Protocol. In the attributes inspector we will establish the properties of the protocol:
- "Geometry: width" — 500;
- "Geometry: height" — 250;
- "View columns" — "tm;lev;mess";
- "Level" — -1, display current violations of any level;
- "Size, seconds" — 0, display violations at any depth;
- "Tracing period, seconds" — 1.
You can place the added items as you want by simply selecting and dragging them by the mouse. In the same way you can change their size. Simple size changing will only resize the container widget geometry, that often not required. To change the size of the entire widget's content, it must be scaled by holding down the "Ctrl" key while resizing or by switching the "Resize" status to the "Scale" in the status bar.
After performing all the manipulations we must get the mnemonic scheme with a look similar to Figure 5.2.4.
On this the procedure of creating a mnemonic scheme will be considered complete. We will save the new library of widgets "CM 101" and proceed to the stage of the location of our mnemonic scheme in the tree of the project "Start".
Put our mnemonic scheme to the branch "Start"->"Root page (SO)"->"Group 1"->"Mnemos" by selecting the menu item "... from the Library"->"Library: CM101"->"AT 101" in the context menu of the project page "Mnemos". Identifier for the new mnemonic scheme set to "2" and the name field leave blank — 2.
Next we need to carry out the operation known to us from the previous section, that is — establishment of connections to the previously created controller parameters. To do this we will open the tab "Links" (Fig.5.2.5) of the dialogue of editing the properties of the mnemonic scheme, where we will see the tree with the elements "A1_Ti", "A1_To", "A2_Ti" and "A2_To". Expanding any of the elements we will see the "Parameter" branch in which we have to specify or select the address in the item "pVal" of the values of our attributes "Ti" and "To", respectively. In the process of filling the elements, some of the properties must be specified as constants:
- "pName" — "val:AT101_1 Ti".
As with the group of graphs in the previous section, for the complex parameters of the object-tag ModBus.CM101.TE1314_1 and ModBus.CM101.CB102 you can specify only the parameter and the attributes will be arranged automatically.
Now we can save our mnemonic scheme and look at the result. To do this, close the dialog of properties and launch our project "Start" for execution. Next switch to our mnemonic scheme with the paging buttons and in the case of an error-free configuration we must see a similar to Figure 5.2.6.
Note that the output value of the complex parameter of the tag-object beyond the boundary of violations is indicated by flashing through an emergency color for: the parameter, the alarm object and the yellow circle below. In addition to flashing, in case of violation, a monotone alarm (often a buzzer) and a speech synthesis of the position of the parameter specified in the "spName" link field (fig.5.2.5) are performed, when the corresponding speech synthesizer is available. When the violation is activated, the buttons with the notification type indication are activated, right and right-below, and by clicking on them the corresponding type of notification is quieted. By pressing on the flashing yellow circle right-below all the notification are quieted. Presence of the violation is also displayed by a record in the protocol we added. In order to see the violation abroad you can set the value of the fan's performance in 100 (Fig.4.2.9). More about the concept of work with the violations can be read in the "How to form violations, alarms and notifications" document.
The history of violations can be viewed in the "Protocol of violations" document, which is available when selection the view "Document" (Fig.5.2.7).
The discrete complex parameter of the object-tag ModBus.CM101.CB102, presented by us in the form of a ball valve, is active. That is, it can be selected, than having the control panel on the right (Fig.5.2.6), as well as send commands (open or close). You can transfer the commands from the control panel or through the context menu. All actions of the operator from the control influence are logged and the protocol document can be viewed at selection the view "Document" (Fig.5.2.8).
5.3 Creation a new complex element
Let's start with consideration of the task of the third level of complexity, that is creation a complex element. Creation a complex element, which includes a combination of different basic primitives, can take place in several stages. As an example, consider a task consisting of two stages:
- creation the "Air cooler" widget on the basis of the primitive "Elementary figure";
- creation the final grouped widget "Cooler" based on the primitive "Group of elements".
5.3.1 Creation the "Air cooler" widget on the basis of the primitive "Elementary figure"
We will create the widget in the "CM 101" library created us before. To do this, click the right "mouse" button on the item in this library and select the menu item "... from the Library"->"Library: originals"->"Elementary figure" as it is shown in Figure 5.3.1.1 and we name the new element air_cooler (Air cooler).
After confirmation we will have a new widget with the name "Air cooler", select it in the widget library "CM 101" and open for editing via the context menu of the new element (Fig.5.3.1.2). In the attributes inspector we will set the properties:
- "Geometry: width" — 200;
- "Geometry: height" — 200;
- "Fill: color" — "lightgrey", color can be set as using the color names, and also in the format #RRGGBB (#RRGGBB-AAA).
Now let's draw the visual representation of the widget, which can be done in two ways:
- to draw the desired image by the mouse, using the "Line", "Arc", "Bezier curve" and "Fill"; the corresponding panel "Elementary figure tools" appears after entering the edition-drawing mode; enter this mode as shown in Figure 5.3.1.3 or by double-clicking the left mouse button on the widget's body;
- manually fill the "Elements list" field by entering the list of required items and coordinates of the points.
More information about the editor is available here.
In our example we will use the second method, for what in the "Elements list" field of the attribute inspector we introduce the following list and press "Ctrl" + "Enter":
line:(20|80):(100|20) line:(100|20):(180|80) line:(180|80):(100|140) line:(100|140):(20|80) line:(100|20):(100|140) line:(20|80):(180|80) line:(50|165):(100|140) line:(100|140):(150|165) line:(150|165):(50|165) fill:(20|80):(100|20):(180|80):(100|140) fill:(50|165):(100|140):(150|165)
All the points are indicated statically, since dynamic and coordinate changes are not provided in the execution mode, and all other parameters are left by default. So, our widget will take a look at Figure 5.3.1.4.
Create an icon for our widget, which will be visible in the widget tree of the library "CM 101" (Fig.5.3.1.5).
On this the process of creating the first widget can be considered completed. Let's go on the stage of composition and creation a result widget.
5.3.2 Creation a final-combined widget "Cooler" on the basis of the primitive "Group of elements"
The final widget we'll create in the "CM 101" library, to do this we must click the right mouse button on the library and select the primitive "Group of elements" as it is shown in Figure 5.3.2.1, we will name the new element — elCooler (Cooler).
After confirmation we will have a new widget with the name "Cooler". Select it in the widget library "CM 101" and open for editing. In the attributes inspector we will set the properties:
- "Geometry: width" — 250;
- "Geometry: height" — 200.
Take the previously created element "Air cooler" and drag it — press the left button of the "mouse" manipulator on it and move the cursor to the area of the newly created widget, where we release the button (Fig.5.3.2.2).
As a result, a dialog window appears asking you to enter the identifier and name of the new widget. The identifier and name can be specified arbitrarily, we will enter the identifier air_cooler and leave the name empty and it will be inherited from the parent — the element "Air cooler". Thus, the newly created widget inside the container "Cooler" will inherit the element "Air cooler". After confirming the input of the identifier and the name, the "Air cooler" widget will be added to our widget container "Cooler" (Figure 5.3.2.3). In the attributes inspector we will set the properties for it:
- "Geometry: x" — 25;
- "Geometry: y" — 0.
Next we will unroll the menu item of the library "Mnemo elements", will find there the "Cooler 2" element and drag it to the widget container. This element will dynamically display the intensity of the air cooler. For the new widget enter the identifier cooler2 and leave the name again empty, after which the "Cooler 2" widget will be added to our "Cooler" widget-container. Thus, the newly created widget inside the "Cooler" container will inherit the element of the library "Mnemo elements" — "Cooler 2". In the attributes inspector we will set the properties:
- "Geometry: x" — 75;
- "Geometry: y" — 30;
- "Geometry: z" — 10, raise the element above all you can from the panel "Visibility widget functions";
- "Color1" — "#FFFF00-200", added alpha channel — transparency 200 ("0" — fully transparent, "255" — fully opaque), as it is shown in Figure 5.3.2.4;
- "Color2" — "#FF0000-200", added alpha channel — transparency 200.
Now in the "Cooler" widget add two text fields based on the "Text" primitive, in order to display the input and output flow temperature. To do this, select the "Cooler" widget and, in the visual panel of the "CM 101" library, select the menu item of the primitive "Text" as shown in Figure 5.3.2.5. For the first text field, enter the identifier Ti and in the attribute inspector we will set the properties:
- "Geometry: x" — 5;
- "Geometry: y" — 20;
- "Geometry: width" — 70;
- "Geometry: height" — 35;
- "Alignment" — "Сenter";
- "Font" — "Arial 14 1", you can change the font in the dialog that is opened by pressing the key in the edit field (Fig.5.3.2.7);
- Font Arial can be missing in the dialog, so select one that you like.
- "Text" (Fig.5.3.2.8):
%1 deg.C
- "Arguments number" — 1 (Fig.5.3.2.9):
- "Argument 0: type" — "Real";
- "Argument 0: value" — 300.25, is specified only for clarity and in the execution mode it will be replaced with the real value of the input temperature;
- "Аргумент 0: config" — "3;f;2".
Now, in order to create a similar widget for the output temperature, copy the widget "Ti", insert the copied widget and give it the identifier To (Fig.5.3.2.10). In the attribute inspector, we will set the properties:
- "Geometry: x" — 175;
- "Geometry: y" — 20.
Now add a widget based on the primitive "Form element" (Fig.5.3.2.11), which we will use to select the set-points of the cooler productivity. We will specify the identifier cw (Figure 5.3.2.12) and in the attribute inspector we will set the properties:
- "Active" — true;
- "Geometry: x" — 60;
- "Geometry: y" — 158;
- "Geometry: width" — 60;
- "Geometry: height" — 40;
- "Geometry: z" — 10, raise the element above all you can from the panel "Visibility widget functions";
- "Element type" — "Combo box";
- "Font" — "Arial 14 1";
- "Value" — 200;
- "Configuration":
0 50 100 150 200
To display the productivity dimension of the cooler add another widget based on the primitive "Text". We do the same procedure as for the "Ti" widget. We will specify the identifier dimension (Figure 5.3.2.13) and in the attribute inspector we will set the properties:
- "Geometry: x" — 125;
- "Geometry: y" — 168;
- "Geometry: width" — 80;
- "Geometry: height" — 20;
- "Alignment" — "Center";
- "Font" — "Arial 14 1";
- "Text" — "rpm".
To add the processing logic of the "Cooler" widget, open the dialog for the properties editing of this visual element and go to the tab "Processing". In this tab we will see the attributes tree of the widget and the text field of the attributes processing program. To solve our task we need to add three attributes: Ti, To, Cw (Fig.5.3.2.14); for which you need to unroll the root element ".", select any item inside it and click the button "Add attribute" below.
Next enable the processing of the attribute value of the combo box "cw" as shown in Figure 5.3.2.15. Similarly we will turn on the arg0val attribute for Ti and To, as well as the speed attribute for the "cooler2" element.
Finally we will set up the user programming language "JavaLikeCalc.JavaScript" and write this very program for processing the widget:
Ti_arg0val = Ti;
To_arg0val = To;
for(ev_rez = "", off = 0; (ev_wrk=event.parse(0,"\n",off)).length; )
if(ev_wrk == "ws_CombChange:/cw") Cw = cw_value;
else ev_rez += ev_wrk+"\n";
event = ev_rez;
cw_value = Cw;
cooler2_speed = Cw/5;
Placing or editing the widget program does not directly compile it, that is, there will be no error messages in the program if they have a place to be. This is due to the fact, that the direct execution of the program, and thus its compilation, is carried out in the context of execution and at the moment of starting up of the visualisation project for execution. In this case all errors, that occurred during the compilation, are displayed as OpenSCADA messages and the error widgets are not processed. For details on how to debug user procedures see the "How to debug the OpenSCADA project" document.
Processing the widget in whole and executing its program performed at any event in the life cycle of the VCA project (specified in the "Period of the calculation" field of the "Project" tab, Figure 5.2) and periodically with the widget processing period (specified in the "Periodic processing" field of the "Widget" tab, Figure 5.1.3). By default, the widget processing period is taken from top widget and it is 1000 ms, so when you want faster updating your widget, you can set "Periodic processing" to 250 ms on the "Widget" tab.
The resulting tab "Processing" of the widget "Cooler" of the library "CM 101" will look like shown in Figure 5.3.2.16.
Close the dialog of editing the properties of the visual element, create an icon for our element, close the internal editing window and save those all.
On this the development of the complex element can be considered complete.
5.3.3 Adding the complex element to the mnemonic scheme
To test the operability and to evaluate the results of our efforts, add the created widget to the mnemonic scheme, developed in section 5.2. We perform this operation for two coolers "AT101_1" and "AT101_2".
To do this we will open the frame of the mnemonic scheme "AT 101" for editing, grab our complex element by the "mouse" and drag to the mnemonic scheme, where we drop it in the desired position — enter the identifiers AT101_1 and AT101_2, respectively. Place the added items as convenient to us. After performing these manipulations we must get the mnemonic scheme with a look in Figure 5.3.3.1.
We will save the new mnemonic scheme and close its window. Next go to the project and open this mnemonic in the project tree "Start"->"Root page (SO)"->"Group 1"->"Mnemos"->"AT 101". As you can see, our new elements are appeared here automatically and we only need to connect the links to them, to do this we'll open the dialog of editing the properties of the mnemonic scheme on the tab "Links" (Fig.5.3.3.2). On this tab we see the tree with the elements "AT101_1" and "AT101_2", unrolling any we'll see the branch "Parameter" with the attributes "Ti", "To" and "Cw". Thus we can simply specify in the field "Parameter" the address of the parameter "prm:/LogicLev/CM101/AT101_1" and "prm:/LogicLev/CM101/AT101_2", respectively, and the attributes will be placed automatically.
Let's save our mnemonic scheme and check the result, for what close the dialog of properties, start the project "Start" for execution and switch to the second mnemonic scheme with the paging buttons. In the error-free configuration we have to see a similar image as shown in Figure 5.3.3.3.
On this mnemonic scheme through our complex elements we can not only observe, but also control productivity the coolers simply by changing the value in the combo box. Changing performance we can notice the change in temperature and signalling on the complex analog parameter of the object-trend. We can see and review the history of changes on the graphics group we created in Section 5.1 and the document "Protocol of violations" mentioned in Section 5.2.
6 Conclusion
In this way we received the full-featured typical interface of the technological process (TP) with real data acquisition in a variety of ways and thus got the look and skills of working with OpenSCADA.
When constructing the TP interface we looked at all the three levels of complexity and hence we got the vision of the desired level of SCADA programmer.
Data acquisition and processing have been reviewed and implemented in a variety of ways from the simple-typical one and to the mirroring data model of the PLC built on the OpenSCADA basis. That is, there got the vision of the data sources of the SCADA systems and accessing to them through the network interfaces and exchanging protocols, supported by the corresponding modules of OpenSCADA.
And of course, we reviewed the distribution methods of OpenSCADA, how to install it and get the right environment, such as: SCADA server, OpenSCADA PLC and operator work place (AWP).
Information about OpenSCADA is not limited by this document and you must use in solving specific questions all available documentation and examples of the demo configurations-models of OpenSCADA, using the same benefits of Open Source. Especially we must note here again "Program manual", "How to ..." and "Dynamic real-time simulator AGLKS", as most complete sources of information about OpenSCADA.