From OpenSCADAWiki
< Documents
Revision as of 13:47, 10 December 2017 by RomanSavochenko (Talk | contribs)

Jump to: navigation, search
Other languages:
Constr.png Common revision and translation

Author: Roman Savochenko

This document is intended to provide the descriptions of recipes (how to) for solving the common problems and tasks of the user. Recipes to be placed in this document may be offered by the users.

1 Transfer of OpenSCADA configurations from one project to another

It is often needed to transfer configuration from one OpenSCADA project to another. And, more often it is necessary to make a partial transfer, for example, the transfer of certain developments that could be useful in the new project.

Generally, it should be noted that any developments with the slightest hint, and the prospect of re-use should be standardized and maintained in the separate, own libraries and databases. It is not recommended to change the default configurations and elements of the standard libraries, and save your own, new libraries and elements in the databases of standard libraries. This will subsequently allow you to painlessly update the standard libraries, and to simply use the developments of your previous projects.

1.1 Easy transfer of the DB with libraries and configuration

If you took into account the above recommendations and all of your uniform developments are contained in the separate database, then the entire transfer process will be to copy the database and connect it to a new project.

The procedure of DB copying is different for different types of databases and you should read about it in the DB documentation. In the OpenSCADA distros it is commonly used the SQLite database, as separate files *.db. Сopying of the SQLite database, respectively, is the simple copying of the the required database file from the database directory of the old project to the database directory of the new one.

Connection is made by creating a new database object in the module of the required DB type of the database subsystem and its subsequent configuration (in details). After the creation, configuration, and the enabling of database you can immediately download the configuration from it by clicking the "Load system from this DB" on the form of the database object.

1.2 Separation of the desired configuration

If the desired configuration is contained in a common database or in the database of standard libraries, you need to move it to the separate database. You can move the configuration either to a separate database with your libraries or to the export database. Export database, unlike a library one, only serves to transfer the configuration and will subsequently be deleted. In any case, you must create a new database for the desired database type, like the connection procedure above. To transfer you should use a database type that you plan to use in the new project. Usually, it is better to use the SQLite database type for the transfer, because of the simple copying procedure for it. However, if you use a network database, the procedure may change to the simple connection of the library or export database to a new project.

Next, you must separate the configuration in unifying or export libraries, if it can not be directly stored in a database. For example, certain templates of parameters or parameters of the data acquisition controllers, visual elements of the widgets libraries etc. You can separate by creating a library of export or by the unification of the element, such as a library of templates, or the controller of the data acquisition parameters, library of widgets etc. For the newly created library as the database should be specified the previously created unifying or export database. Further you should copy the necessary elements from the original library to unifying/export via a standard copy function. After copying the unifying/export library must be saved.

If it is necessary to transfer the configuration element with a separate DB property or the entire libraries the operation of creating an intermediate library and the further copying can be omitted. It is enough in the DB field to specify the previously created a unifying or export database and save the element.

Further actions, namely the simple transfer of the database, are implemented in accordance with the previous section.

When you transfer the configuration by exporting it is necessary to implement the reverse process of copying from the export libraries to the local libraries of a new project and deleting of the export database.

1.3 Low-level copy of the DB contents

To transfer you can make selectively copying of the database tables with the configuration by selecting the tables' objects in the database object, the copy command, the selecting of the object of a new database and insert command (in details). However, it is necessary to know the structure of the database, about which you can read by this link.

2 Cyclic programming into OpenSCADA particularity

Novice users often have question about time intervals hold while programming calculation procedures in the OpenSCADA environment. This question is usually associated with the presence of previous programming experience in linear calculations and lack of experience in programming of cyclic real-time systems.

The so-called tact or cycle of periodical calculations, ie the life rhythm is used in the real-time systems. Some procedure is calculated in each cycle that should not take more time than the cycle. As a consequence, if the cycle procedure stops for waiting, the life of the real-time system stops too. Hence, the using of traditional sleep task functions into such procedures is unacceptable!

The solution of the desired exposure time interval in the real-time systems, within the rhythm of life, is made in two ways. The first way is to decrement the counter value, set to the time interval, in each cycle by the cycle frequency to the value <= 0, for example, in OpenSCADA it is implemented as follows:

if((tm_cnt-=1/f_frq) <= 0)  //Decrement
    tm_cnt = 10; //Set the counter to a value of 10 seconds
    //Other actions with the periodicity of 10 seconds

The second way is based on the astronomical time, ie the comparison with the current time is made in the cycle, for example, in OpenSCADA it is implemented as follows:

if(SYS.time() > tm_to)
    tm_to = SYS.time()+10; //Setting the waiting threshold for 10 seconds more than the current time
    //Other actions with the periodicity of 10 seconds

The second method is more reliable because it excludes the operation delay problem due to the possibility of calculating the cycle procedure over the cycle time. Although in the properly configured systems and tasks, this problem should not occur.

3 Live disk (Live CD/USB)

In order to simplify maximum the OpenSCADA deployment, you can use live builds of boot-able CD and USB disks. Live disk provides the ability to boot directly from it and quickly to obtain the desired working environment. During booting and operating a live disk does not use regular data storages, which means you can not worry about the integrity and safety of data on them. In general, a live disk is a convinient tool with a wide range of necessary software tools, independent from the stationary software environment, and capable to make diagnostics of software and hardware environment, and their restoration in some cases.

Live disk is a packaged image of the operating system and applications with a size of about 700MB, recorded on CD/DVD disk or USB-Flash disk. During the operation the operating system "on the fly" unpacks the files needed to run programs and open documents, and therefore does not use memory more than at its usual installation.

The live disks with OpenSCADA built into several variants based on distributive ОS Linux Debian and ALTLinux (old versions) and allowed for downloading to accorded OpenSCADA version here: Current live builds with OpenSCADA have much more functions than have been planed originally:

  • Saving work changes transparently, on writing to USB-Flash. The feature achieved by creation disk's partition to write, on a free USB-Flash space. The partion mirrored to file system's root and all modifications will write to it. Besides the work data saving to the partition you can install needed program packages from the packages repository Debian, OpenSCADA or ALTLinux.
  • Combination of typical data storage and live Flash-disk. The feature achieved by writing the live disk's image direct to the USB-Flash file system — FAT16 or FAT32, what preserves the typical data storage's functions and appends the live-disk function.
  • The live disk environment installation to stationary data storage. That allow for you do not deeply learning to the operation system Linux on it installation, configuration, and also OpenSCADA deployment. You enough to load from the live disk, to check for all hardware correct detection and all need program work, then, by simple procedure aid from the icon on desktop, or the separated boot menu, to install its to the regular storage. The resulting installation will exactly repeat the live disk environment.

3.1 Combined-hybrid ISO-image of the live disk

Currently here mostly built hybrid ISO-images of the live disks (*LiveCD_USB.iso), which you can write directly to CD/DVD, USB-Flash, and also extract it content for writing to the USB-Flash with the file system FAT or EXT.

The primary variant of the live disk forming is writing to CD/DVD, for what you can use standard tools of the original operating system. But becoming widely it writing to the USB-Flash, what you can do from the environment of Linux, for example, from the environment of this live disc, recorded and booted previously with CD/DVD drive; or from OS MS Windows, by "Win32DiskImager".

At.png Burning the image to the USB-Flash will destroy all the data and make it unfit for usage as a data storage, except the possibility of recording the changes to the storage section of the live disk OS environment that is created when you first boot from the live disk, for ALTLinux, or by an user, for Debian.

Address of the disk for ISO-image recording looks as "/dev/sd{x}", and it can be found by the console command "$ dmesg", immediately after you connect the target USB-Flash drive. From the Linux environment you can write the ISO-image to the USB-Flash like this:

# The ISO-image writing to the USB-Flash:
$ dd if=Debian_8-OpenSCADA_0.9+r2294-TDE_R14-amd64-LiveCD_USB.iso of=/dev/sd{x} bs=4096
# The ISO-image writing directly from the booted CD/DVD disc
$ dd if=/dev/sr0 of=/dev/sd{x} bs=4096

3.2 Live USB-Flash disk with file-system FAT or EXT

Earlier performed special buildings of the images to write its on the file system FAT. Currently the special images build only for Firmwares of several PLCs (*flash.tar). But for the live USB-Flash disks of general-purposes creation you can use hybrid ISO-image, about that see to part before.

The advantage of the live disk on USB-Flash, as it was previously mentioned, is a combination of USB-Flash drive features as a data storage and as a live disc at the same time. Also on the basis you can create compact, reliable and functional solutions of the embedded systems based on OpenSCADA, such as Programmable Logic Controllers (PLC), the panel controllers (with a touch screen), as well as simple SCADA-servers and operator's "quickly made" SCADA-stations, by recording a live disk to the stationary data storage (HDD, SSD or Flash). The reliability of this solution is achieved by placing the main non-modifiable software in the packed file, and operational data on the journaled file system.

The recording of such image can be done from any operating system (for FAT), but to install the bootloader it is possible only from Linux, for which you can use the CD/DVD disk from the previous section.

The procedure for creating a live disk follow, for the data of the hybrid ISO-disk (Debian and ALTLinux):

  • To simplify the operation of extracting and copying of the ISO-data let perform it into the twin-panels file manager mc. For mc allowing to view the ISO-image you need install utility isoinfo, which ordinary places into package "genisoimage".
  • Take original file of the ISO-image, open it into mc and copy from it to target FAT or EXT file system:
    • Debian: directories "isolinux" and "live"; rename the directory "isolinux" to "syslinux", on the target file system.
    • ALTLinux: directory "syslinux" and file "live".
  • Rename file "syslinux/isolinux.cfg" to "syslinux/syslinux.cfg", for FAT, or "syslinux/extlinux.cfg", for EXT.
  • ALTLinux: Append to the argument "append", of the section "label live" of the file "syslinux/syslinux.cfg", the sub-string "automatic=method:disk,label:MY_LAB" or "automatic=method:disk,uuid:MY-UUID", where MY_LAB and MY-UUID you can obtain, for partition of "the live disk", by the command aid $ blkid.
  • ALTLinux: Replace file "syslinux/gfxboot.c32" to analogous file from current file system (ordinary it placed into directory "/usr/lib/syslinux/").
  • Install boot-loader from the command line, all from the superuser: $ su -
    • Unmount the disk: $ umount /dev/sd{x}1
    • Initialize the MBR of the disk to the correct value: $ ms-sys -s /dev/sd{x}
    • Initialize the boot loader: $ syslinux /dev/sd{x}1

For creating the live disk image on the FAT (ALTLinux), all operation should be done from root: $ su -

  • Connect the target disk and obtain it's address: $ dmesg
  • Mount: $ mkdir /mnt/tmp; mount /dev/sd{x}1 /mnt/tmp
  • Unpack the contents of an archive on the mounted disk: $ cd /mnt/tmp; tar xvf /var/tmp/LP8x81-ALTLinux6-OpenSCADA_0.9+r2302-i586-plc-rt1-up.flash.tar
  • Find out the UUID for the filesystem of the target disk: $ blkid | grep /dev/sd{x}1
  • Modify the file "/mnt/tmp/syslinux/syslinux.cfg" at the end of the line "append initrd=alt0/ live ... disk,uuid:4EB3-0478", where it is necessary to set the previously obtained UUID.
  • Add or modify the file "/mnt/tmp/syslinux/lang" for specify the locale-language of the interface by default, for the Russian language it is necessary to specify "ru_RU", otherwise it will be English.
  • Unmount the disk: $ umount /dev/sd{x}1
  • Initialize the MBR of the disk to the correct value: $ ms-sys -s /dev/sd{x}
  • Initialize the boot loader: $ syslinux /dev/sd{x}1

At.png This method of the live disk creation requires knowledge of Linux and command line interface (console), as well as the basics of the disks partitioning because with an wrong initial partitioning of media the booting may not be passed.

3.3 Working data of the live disk preserving on a partition of the USB-Flash

The Live disk, as mentioned early, allow you full-featured work with saving the working data, and also updating the programs (excluding the system programs and the OS Linux kernel). Typically that possibility has sense only for USB, HDD, SSD storages.

In Debian distribution case a separated partition for the working data storing, with the label "persistence", you need to create especial at anytime, and also into the file "persistence.conf" of the partition you need set the file system or it's part for reflection to writing (for example, "/home"). For reflection to all the file system into the file you need write "/ union". For the partition's file system better use "EXT3", and for it creation you can use a partition management program, for example "gparted".

In ALTLinux (6) distribution case and a hybrid ISO-image direct writing that partition will created at the first start time. During form the live disk on FAT and EXT you need create separated partition with label "alt-live-storage" and the file system "EXT3", that you can do into a partition management program, for example "gparted".

3.4 Booting

To boot from the live disk the computer should be rebooted and then you should press the key to enter the BIOS boot menu at the very start of the boot and choose there our disk (Fig.3.1). The key to enter the boot menu may be different on the different computers and may be one of the following: "F8", "F9", "F10", "F11" or "F12".

Fig. 3.1. Option menu for selecting the boot device in the BIOS.

After the selection of the the device you should see the boot menu of live disk (Fig.3.2), where it is important to select the boot variant with need language, for Debian, or pre-select your language, by pressing F2 for ALTLinux.

Fig. 3.2. Live disk's language selection menu Debian, ALTLinux.

As a result of booting from the live disc, you'll get a desktop of the TDE (Fig.3.3).

Fig. 3.3. Work desktop of the Live disk.

4 General provisions of the working conception with violations, alarms and notifications

Alarms and their processing in OpenSCADA is implemented in two ways, which is associated with the OpenSCADA structure, ways of its usage, as well as with the nature of alarms.

The first part of alarms, with which the OpenSCADA works initially, and which is most needed, is notifications in various ways. Since the notification is part of the visualization interface, they are implemented in the VCA engine UI.VCAEngine and in the visualizers UI.Vision, UI.WebVision. Currently, notifications and alarms OpenSCADA subsystem implements the following functions:

  • Notification:
    • Light — blinking of the object, the signaling group, the general status with the alarm color.
    • Sound — playing the sound file, or speech synthesis from text, associated with the alarm;
    • Beep — a continuous signal to the system, "Beeper", regardless of the alarm.
  • Quittance of the alarm notification:
    • Full — by clicking on the colored blinking circle of the alarm status (the "ws_alarmLev" event), bottom right:
    • By the notification way — separate the light (the event "ws_alarmLight"), sound (event "ws_alarmSound") and the beep (the event "ws_alarmAlarm"), by pressing a button with the corresponding image, bottom right, or under the buttons of display options;
    • By the alarm object — to the visual presentation image it can be added the quittance command of the notification directly by itself;
    • Alternately with listening — it is character of the sound notification, because every alarm object can provide its own sound notification or the speech synthesis.

During the implementation of the notifications in the visualization area there is no direct rule for the formation of alarm sign because in many situations there is no uniqueness. Currently, on the side of the typified data source templates, it is practiced a method of the formation an "err" error attribute with the code and text of the alarm, and their processing and the formation of notification is made in the visual image of the data object. Sometimes the processing the parameter's borders is made directly in the visual image of the data object.

Subsequently, it became necessary to log and record the actual alarms for the current moment. For the alarms logging it is sufficient the formation of system messages with the specified category and message format, but for the monitoring the ongoing(actual) alarms a buffer is needed. Subsequently, a buffer was added as an add-on of the messages subsystem, and its addressing is made by the inversion of the message level. So, the message record with the level "-2" and the category "TEST" will put the message into the alarm buffer and duplicate it in the messages archive, with the level of "2". At the messages request with the negative level they will be taken from the alarm buffer. Deleting/removing of the alarm is made by writing the messages with the same category "TEST" and the non-negative level.

This concept of accounting the actual alarms allows you to use standard mechanisms for the messages processing to account the alarms:

  • Alarm registration: SYS.message("alCategory", -3, "Parameter: alarm");
  • Removing of the alarm: SYS.message("alCategory", 1, "Parameter: normal");
  • Creating a list of actual (active) alarms by means of the "Protocol" or "Document" elements with the "-1" negative level for all.

Messages registration is best done on the side of the typified data source templates by a special function SYS.DAQ["Modul"]["Controller"].alarmSet(string mess, int lev = -5, string prm = ""), which unifies the category. To call this function from the context of the template you need to add "this" IO of the "Object" type, then the set of the alarm would be of the following form
this.cntr().alarmSet("Parameter: alarm", -5, "prm");. This function is now used in many data sources modules to account the global alarms of the controllers objects. The function creates the alarm with the category: al{ModId}:{CntrId}[.{PrmId}], where:

  • ModId — module's ID;
  • CntrId — controller's ID;
  • PrmId — parameter's ID from the prm argument.

At.png In general, it should be noted that the notification and alarms registration are different mechanisms that can be used individually for simple projects, or together for large complex projects.

5 Modified data storing/restoring into the logic level sources/wrappers

Sometime you can be to need for store and next restore, mostly in restart, some modified data like a hardware working time counters. At all like data source's and hardware's processing you need perform into the logic level of the subsystem DAQ. The task you can do in more ways means storing the data and next it's restoring to some storage but most known ways are:

  • Periodical the template parameter's context saving by the OpenSCADA user API request through cntrReq():
  • If the counter template's attribute is under archiving/historying then you can the last value take from the archive/history at the template start, like that:
if(f_start)    prevArchRestore = false;
if(!prevArchRestore && (archEnd=this.cntr.arch().end("FSArch.1s"))) {
    SYS.messInfo("testArch", "val="+this.cntr.arch().getVal(archEnd)+"; "
                            "val1="+this.cntr.arch().getVal(archEnd,false,"FSArch.1s")+"; "
    cntr = this.cntr.arch().getVal(archEnd);
    prevArchRestore = true;
  • Create some specific DB table and write/read the data direct to the table by the SQL-requests through SQLReq().

6 Debugging

If you strongly follow the main instruction, you won't encounter here any problems but if you make some doings for self, you may need also for some debugging for them. OpenSCADA provides wide possibilities to debug and observation for problems of programming into OpenSCADA of the regular user's space and for problems into same OpenSCADA and its parts.

Generic approaches for user space debugging, allowed for both LTS and Work versions, mean:

  • External attributes creation to see for the interim values and to observe for the current execution context.
  • Debug messages creation to see also for the interim values and to observe for the execution sequence.

The present debugging mechanisms were expanded into the Work version in the way:

  • User control for debugging by debug messages category, for the OpenSCADA parts and messages of the user space.
  • Specific debugging and diagnostic environment for some parts of OpenSCADA, that is: DAQ sources (controller objects) and VCA interfaces (VCA projects).

6.1 Current execution context debugging

The debugging method means observing for the execution context by values of the variables, interim values appending include for more details.

Current execution context of DAQ procedures you can observe into a proper page of the object of the execution context, like: the tab "Attributes" of the Logic Level parameter (Fig. 6.1), the tab "Calculation" of the Java-like based calculator (Fig. 6.2) and so on. To append some interim values you can temporary append (or set as an read-only attribute) and link some attributes to the template or append and link some IO to the function.

Fig. 6.1. Tab "Attributes" of the Logic Level parameter.
Fig. 6.2. Tab "Calculation" of the Java-like based calculator.

Current execution context of the VCA procedures (procedures of the widgets) you can observe on the tab "Attributes" of the proper page or widget of the session of the executed now project (Fig. 6.3). To append some interim values you can temporary append and link some attributes to the widget/page.

Fig. 6.3. Tab "Attributes" of a page or widget of the session of the executed now project.

6.2 Execution sequence debugging

The debugging methods means placing and/or enabling debugging messages and next its observing into the generic messages' archiving and observing interface (Fig. 6.4) or into the interface proper to the OpenSCADA part:

  • The tab "Diagnostics" of the controller's object of the data source (Fig. 6.5).
  • The tab "Diagnostics" of the project's object of VCA into the configurator (Fig. 6.6) or of the project's properties of the development mode of UI.Vision (Fig. 6.7).
Fig. 6.4. Generic messages archiving and observing interface.
Fig. 6.5. Tab "Diagnostics" of a controller's object of a data source.
Fig. 6.6. Tab "Diagnostics" of a project's object of VCA into the configurator.
Fig. 6.7. Tab "Diagnostics" of project's properties of the development mode of UI.Vision.

To append debug or other level's messages to self procedures you can use next functions:

  • Generic: SYS.message(), SYS.mess{Debug,Info,Note,Warning,Err,Crit,Alert,Emerg}() — To form generic messages with a custom category, then them mostly allowed to observe from the generic messages archiving and observing interface (Fig. 6.4).
  • Generic: SYS.*.messSys() — To form the system messages with the node path as a category and with the human readable path before the message. The messages will be allowed to observe into the diagnostics interface proper to the OpenSCADA part (Fig. 6.5, 6.6, 6.7).
  • VCA: this.mess{Debug,Info,Note,Warning,Err,Crit,Alert,Emerg}() — To form the system message with the category as the widget path. The messages will be allowed to observe into the VCA diagnostics interface (Fig. 6.6, 6.7).

At.png The same debug messages (the suffix is "Debug" or the level is 0), on Work version, will be allowed to observe only after the debugging enabled, the field "Least level" set to "Debug (0)" (Fig. 6.8), and category(es) of the messages checked (Fig. 6.9), for the details read here! But the debug messages enabling and disabling allows you to include the debug messages permanently into the procedures with the proper category of the place. All other, not debug, messages will show anytime, for levels more or equal to the globally set (Fig. 6.8).

Fig. 6.8. Field "Least level" set to "Debug (0)".
Fig. 6.9. Debug messages checking to debug.

At.png Internal or system parts of the controller's object of the data source enable for diagnostics from self interface by property "Level" set to "Debug (0)" (Fig. 6.5), irrespective.