OpenSCADA into programmable logic controller (PLC)
| Name: PLC Founded: October 2008 Members: Roman Savochenko, Maxim Lysenko (2010-2012) Description: The project is devoted to creation of: runtime environment of PLC, PLC firmware and hardware configurations of specialized PLC's. Considered embedded systems of based on architectures x86 and ARM, and also separated hardware of the embedded systems:
|  |
Introduction
Modern system of automatic process control (APCS) are quite complex. Conventionally, the hierarchy of PCS can be divided into two levels: the lower and upper level. The lower level of the PCS contains field of equipment (sensors and executive mechanisms), as well as programmable logic controllers (PLC). The upper level consists of a system of operational visualization and monitoring of the process — SCADA system. PLC is the responsible part of the APCS, which performs function of the data acquisition from the field of equipment, calculation and making the regulatory, blocking and other actions on the regulating parts of the field of equipment.OpenSCADA is an open implementation of the SCADA system, which is based on the modular architecture that allows you to build the end-user solutions for different requirements. The purpose of OpenSCADA are the systems of the upper level, but the high degree of modularity and scalability allows you also to solve wide range of tasks of adjacent areas.
Programmable logic controllers
PLC market is saturated with wide range of products with different architecture and design. Architectural PLC can be divided into three groups:- hard-programmable PLC and modular computer-process interfaces (CPI);
- highly intellectual commercial PLC;
- PC-compatible PLC with the free access.
Hard-programmable PLC are typically based on a single-crystal microcomputer or chips of programmable logic. Program of such controllers is flashed one-time, providing the software parameterization, or formed with a specialized environment endowed with functions of binary firmware compilation of the runtime with the user program, such as
ISaGRAF and LabView. As an example of such PLC can be the modules of distributed PCI of Advantech company.Highly intellectual commercial PLC typically are based on more powerful hardware architecture and are close to full-featured PC-computer. The main difference from standard PC-compatible PLC is the closed software, and often the hardware architecture. The program software of such controllers is usually based on real-time operating system, which is planning several user threads with separation of their priorities. User programming of these PLC is made working in the corporate software which forms, as a result, the binary code of the PLC thread. As an example of such device it can be the PLC of S7 series of
Siemens company.PC-compatible PLC with the free access is not the group of the PLC directly compatible with PC, but the PLC which don't have the integrated run-time and which are often delivered without an operating system. Architecture of the such PLC may be different, ranging from cost-effective solutions with the x86 architecture and ending decisions ARM and MIPS. The run-time of the such PLC is usually formed from the software of the same with the hard-programmable PLC class, the result of which is an executable binary file into one of the most common, scalable, or specialized operating system (DOS, QNX, Linux, WinCE, VxWorks). Frequently the specialized solutions for the problem can be met. As an example of this class it can be the PLC of
PC/104 form factor.Variants of the constructive implementation of the PLC can be divided into mono-block and modular. Mono-block PLC provides the fixed configuration of the CPI, specialized for the limited range of tasks. Modular design provides an easy extension of configuration of CPI for the appropriate task. There are also the hybrid design which is the mono-block, able to expand its CPI by external CPI blocks connected to one of the standard interfaces such as RS-485.
OpenSCADA as run-time of PLC
System architecture of OpenSCADA allows you to create the final solutions under various requirements and resources through the modular extension. This feature is useful in the light of resource constraints of PLC. Moreover, given the constant development of hardware, as well as continuous improvement of integration and efficiency of modern microprocessor solutions, OpenSCADA can consistently extend the functionality of the PLC, while maintaining the continuity with the old solutions. For example, on the basis of the OpenSCADA system can be built the solutions with minimal requirements on the level: CPU 100 MHz, memory and flash ROM of 30 MB.As noted above, the resources of modern PLCs can fluctuate in quite a large range, and the PLC of fixed type, built on single-chip microcomputer, further and further forced out into the narrowly specialized fields with the advanced PC-architectures. This trend makes increasingly interesting the possibility of creating the unified open platform for the implementation of the PLC run-time based on the unified PC-platforms.
OpenSCADA allows the realization of the idea of creating an open platform for the implementation of the run-time of PLC. Currently you can make the PLC's run-time nothing inferior to the commercial intellectual controllers, and in many respects superior to them, due to the possibility of integration of functions specific to the SCADA systems into the run-time of the PLC, enhancing the functionality and user characteristics of the PLC and leading him to unified with SCADA code base, as well as optimizing the cost of the final solution.
List functions which are solved by OpenSCADA within the run-time of PLC:
- data acquisition of various range of devices in the synchronous, asynchronous or block mode;
- user data processing and making the control actions procedures on the Java-like high level language and formal language of block schemes (Soft-logic);
- archiving data, beginning from the temporary buffers in memory and ending with full-featured archives on the file system or database of varying rate and depth;
- integration into the APCS infrastructure through the implementation of standard protocols of interaction (ModBus, SNMP, OPC UA ...);
- integration with the DBMS for the data export, storage of the configuration or archives;
- free configuration and administration of the PLC network through an operational interface of the administration station and through the Web-interface;
- the possibility of implementation the operator's panels with the control interface for integrated Touch-panel;
- providing the Web-interfaces of operational and supervisory control.
Firmware and PLC program environment creation of architecture x86
The architecture x86 recently was positioned as embedded and it's real solutions into this industry rarely have resources (< i386), which is not enough for full-featured OS and advanced environment execution. For this reason and by reason of big the architecture unification the individual assemblies of kernel Linux and main programs of the OS environment performed rarely enough, and that typical mostly for the architecture ARM. More interest and practical for x86, for wide the hardware circle, it is assembling firmwares with compressing a root file-system (RFS). But still possible individual assembling by aid of the build systems as "BuildRoot" or "PTXDist", bottom. And also here possible direct installing a Linux distribution.
Instruments for assembling the firmware environments with the compressed RFS, based on distributive ALTLinux
The following requirements were pulled out to the implementation of the PLC firmware of the section:
- Compactness. In connection with the direct dependence of prices on industrial flash drives with their volume, as well as the reality of the needless for frequent updates, the image of the firmware need to be packed, reaching the level of compactness up to the 8-50MB at a runtime PLC in the full-featured OS.
- Uniform source repository. Since the firmware is not something unchangeable, not expandable and finally fixed, then it must be based on the real, developing-supporting repository of OS package. This will allow for a long time to form updates and expansions, not maintaining the mediated repository special.
- Debugged and simple building procedure. Given the fact that configuration of the firmware can be for some time be stabilized and in addition in the operating system's components and in OpenSCADA too it will be detected and eliminated the bugs, the procedure of building of the firmware should not be burdensome, but on the contrary — easily adaptable.
- Clear implementation of the writing mode in the OS tree. Although the firmware means the creation of packaged not modified image of firmware, but the characteristics of the PLC runtime involves the modifying of the databases and archives. In addition, the possibility of correction of the initial configuration is an important requirement.
- Reliability and stability to the sudden shutdowns. The specificity of exploitation of PLC is usually the inability to properly shutdown, as well as the practical reality of the situation instantly and unpredictable power outage. PLC in these situations must keep working, i.e. to contain the journaling file system and ensure that its verification and automatic correction of errors.
- Conditional division of the PLC configuration to two types:
- PLC without the local display, possibly with a simple text display.
- Touch-panels with the PLC function.
Given the above requirements, for the creation of the firmware it was chosen the tool for creating the distributions mkimage of ALTLinux. mkimage is the tool for building Sisyphus-based system on basis of template. As an initial set of templates it was taken the set of templates of formation of ALTLinux distributions at git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop by the command:
As the basis it was taken the "rescue" template, as the most compact and close to the target PLC.
Firstly building performed basing on the package base of the distributive ALTLinux 5.1, there is present the realtime kernel from XENOMAI. For obtaining some specific packages you need to connect the repository of packages "ALTLinux 5.1" from the OpenSCADA project:
rpm ftp://ftp.oscada.org/ALTLinux/5.1 openscada main
Assembling
Firstly it was created the configuration of PLC without local display in mind of the availability of this type of equipment and lack of equipment for the Touch-panels.
New PLC template was named "plc", it was tested on the boards of PC/104 form factor MOPSlcdLX of Kontron company, ATH400-128 of Diamond Systems company and modular PLC LP-8781 of the ICP DAS company. The archive of the resulting mkimage tree with the "plc" template can be downloaded here ftp://ftp.oscada.org/OpenSCADA/PLC (templates and materials of individual controllers are placed in their own directories).
The key points of the configuration of new template was the writing of the new init-script (rc.sysinit), the script of the after installation configuration of the firmware's image and the list of packages in the image of firmware.The first script is designed as the package "startup-plc". The second script was embedded in the template "plc" on the way: profiles/pls/image-scripts.d/01system. The list of packages was embedded in the template "plc" on the path: profiles/pkg/lists/plñ.in.
The procedure of creating the firmware from the image is the following:
The result is an output directory in the "profiles/out/" have look:
Installation
It is possible to download the firmware to: USB-flash, IDE-flash and HDD. However, in the case of the USB-flash there is the problem with waiting for initialization of USB-subsystem and you'll have "to run" some dialogues.
The file system can be FAT or EXT2/3. In the case of EXT3 the root is mounted as in EXT2, because of problems in the initializer. In the case of EXT2/3 you'll need to use not the syslinux boot, but extlinux, the configuration of which is almost the same one.
Next, lets mount the medium and place the files from the output directory on it as follows.
In the case with FAT and syslinux:
In the case with EXT2/3 and extlinux:
To ensure the reliable operation of the operating data stored in the file "work" with the file system EXT3. The file-system of this file is checked for integrity at the initialization. This file is created as follows:
In the case of the file system EXT2/3 on the target disk the "work" file can not be created. In this case, the working data will be placed in the directory "root" of the target disk.
This is an unreliable solution because the root file system of the target disk is not static and its check is not possible, because of earlier mounting in the "ro" and the potential unreliability of the check of the file system, mounted at "ro", as well as because of the inability to remount as EXT3.
The next step is the configuration and initialization of the loader. To configure the loader it is necessary to edit the file "syslinux/syslinux.cfg" or "extlinux/extlinux.conf" as follows:
In the case of selection the identification of the bootable partition by the identifier you can get the ID of our partition with the command: blkid.
In the case of the label it is a bit harder and this is done for different file systems in different ways.
For the file-systems EXT2/3 it is done by the utility e2label. For example: e2label /dev/sdb1 PLC
For the FAT file system it does by the set of utilities that come with mtools or with parted, easier. With mtools you can do it as follows:
Now we can initialize the loader:
That is all with the boot and initialization of firmware. If the resulting disk is not loaded:
- The bootable flag is missing at the bootable partition.
- The incorrect or damaged "MBR". To check and restore it is possible by usage of "ms-sys" utility.
- Sections of the media are created or recreated with the help of parted. This utility align in strange way the partitions that do not allow them to boot on USB-flash. It is necessary to repartition the media with fdisk.
- Boot can also be not working on the old systems that do not know how to boot from USB-HDD. For them it will be necessary to adapt the geometry of the disk being arranged to USB-ZIP or something like that.
Result
The result is the firmware with the size from 30Mb to 100Mb, satisfying all announced requirements and it provides:
- Loading for 27 seconds from the controller's switch on and including the initialization of BIOS.
- Checking and restoration of the working file system in the "work" file.
- Storing the user data and changes of the firmware in the "work" file.
- Automatic network configuration with DHCP (or 192.168.0.1).
- Access to the controller via SSH and user-friendly interface of working, including mc. The passwords by default (root:123456; admin:123456).
- Time synchronization via NTP.
- OpenSCADA execution with the available network interfaces:
- configuration and runtime environment via Web (ports: 10002 and 10004);
- control interface of OpenSCADA (10005).
OpenSCADA
As the PLC runtime system the OpenSCADA is used. For this case we'll take the building with separate packages for each module and indicate to install the virtual package openscada-plc, which contains all the dependencies on all the OpenSCADA packages, typical used for this configuration. The package of gd2 graphics library has been rebuilt without the support of xpm graphic file format and library was called libgd2-noxpm. All this was done in order to avoid the heavy dependencies on the libraries of GUI XOrg.
The result is the runtime of the PLC with support:
- DB:
- Transport:
- Transport protocols:
- Data source:
- Archiving:
- User Interface:
The configuration of OpenSCADA runs in demon mode in locale "en_US.UTF-8" (also available "ru_RU.UTF-8" and "uk_UA.UTF-8") using the local database SQLite, providing the following default network services:
- configuration and execution environment through the Web (ports: 10002 and 10004);
- control interface of OpenSCADA (port: 10005).
The implementation details
In this section let examine the details of the OS tree of the firmware, the initialization script rc.sysinit.plc and the script of preparation of the OS tree of the firmware.
To build the PLC firmware it was used the following list of packages:
List of the modules of the loader's system kernel with the purpose to reducing the initialization image size was decreased to the following ones:
To the script of the tree preparation there were added the following functions:
- changing the name of the distribution kit;
- replacing the init-script to "inittab.plc";
- creating the user-admin "admin" and the passwords setting by default to "123456" for users "root" and "admin";
- initialization of the /etc/fstab;
- setting locale to "en_US.UTF-8";
- network configuration;
- clock setting on the whole and the time-zone setting to "/usr/share/zoneinfo/Europe/Kiev", for changing what you need replace the file "/etc/localtime" to need zone;
- enabling of the necessary services;
- removing of the documentations, help pages and information, icons, RPM-database and apt cache;
- removing of the not needed locales and the translations; left for presence only the locales: en_US, uk_UA and ru_RU;
- selection of only used kernel modules and deletion all the others is added; it is disabled by default and can be enabled to preparation the final firmware for specific equipment;
- the directory with the kernel (/ boot) is deleted in connection with its moving to the root of the boot partition.
The initialization script (rc.sysinit.plc) was provided with the following functions:
- remounting the root partition to the RW mode;
- checking and connection of the file system (/image/root) of the working user data (the file "work");
- reflection of the modifiable directories of the PLC tree (/etc, /var, /root, /home, /mnt and /lib) to the file system with the user's working data (/image/root) through the file system "aufs" or "unionfs".
As the result of these actions the mount table of the resulting PLC tree looks like:
Setting of the GUI
One option of the firmware is built with a graphical interface, which, however, necessary to configure for automatic startup with the visualization area of OpenSCADA. In addition, it should be noted that the firmware with a graphical interface does not contain all the drivers and you may have to rebuild it under the right equipment.
After downloading and logging to the console it is necessary to configure the XServer, automatic graphical login, start of the graphical environment and automatic startup of OpenSCADA from the IceWM environment:
Packages base of ALTLinux T6
Next stage of the firmwares creation was moving to the package base of distributive ALTLinux T6. On the whole firmwares creation concept saved, with bits changes, but there were added some improvements and expansions:
- Used the new function of "propagator" (the system of pre-initiation of hardware, searching and starting to the firmwares on FS) for searching/creation a partition of EXT2/3/4 with the label "alt-live-storage" for the "root" partition forming and it's modification possibility. The function provides a feature of installing packages direct from the distribution repository, and updating packages packed to the firmware, exclude the kernel and some system's services.
- Added the possibility of creation the firmware as combined ISO-image, which you can (besides it writing to CD/DVD) direct, at aid of the utility dd, write to USB-flash, HDD, SSD and get a work environment with the partition "alt-live-storage", the "root" reflection, on the storage's free place.
- For the possibility to creation of new firmwares to "LP-8x81" from ICP DAS was done moving the real-time kernel "rt-up" from the repository "ALTLinux 5.1" to "ALTLinux T6". The kernel "rt-up" was successfully adapted and get the working firmware based on the packages base "T6" for "LP-8x81".
During the possibility of a free additional installation of needs packages direct from the repository gone needs to the separated built of the firmware with GUI. That is you can easy install the desired window manager (WM) or desktop environment include needed drivers, than create a separated firmware with a limited list of the drivers.
The script "startup-plc" was turned spare into the new firmwares besides the "root" FS remounting to writing does early on the initial sage. The script "profiles/plñ/image-scripts.d/01system" renamed to "profiles/plñ/image-scripts.d/init1-PLC", but it changed and expanded. The packages list of the firmware was left into "profiles/pkg/lists/plñ.in" and some changed.
For get the some specific packages you have to connect the repository "ALTLinux T6" from the OpenSCADA project:
rpm ftp://ftp.oscada.org/ALTLinux/t6 openscada main
The firmware creation procedure mostly left unchanged:
# Creation of the configuration script "configure"
$ ./autoconf
# The builder configuration for the disk's images generation. The key "--with-imagetype" you can set to "iso", or pass
# for creation the combined ISO-image
$ ./configure --with-distro=kdesktop --with-branding=altlinux-kdesktop --with-version=6.0 --with-language=en_US --with-imagetype=flash
# The image assembling
$ make plc.cd
The output folder's content with the image and the firmware installing process to file system FAT and EXT2/3/4 different only by renaming the FS archive's file from "plc" to "live". Installing the ISO-image to USB-flash, HDD, SSD performs by the command dd:
$ dd if=LP8x81-ALTLinuxT6-OpenSCADA_0.8.0.6-i586-plc.iso of=/dev/sd{x} bs=4096
Instead the file "work" you should create partition EXT3 with the label "alt-live-storage", if it is not the ISO-image. The new partition creation you can do with the help of fdisk, if the FAT partition was not created to all allowed the storage space, or with help of parted where the FAT partition you allowed to change. To the details about a partition creation the reader will send to the documentation on fdisk or parted.
Configuration of files "syslinux/syslinux.cfg" and "extlinux/extlinux.conf" were not changed, besides the FS file archive's name changed from "plc" to "live".
At the result we get the firmware with size from which provides:
- Loading for 25 seconds from the controller's switch on and including the initialization of BIOS.
- Checking and restoration of the journal of the working file system "root" into "alt-live-storage".
- Storing the user data and changes of the firmware, also new and updated packages, in the partition "alt-live-storage".
- Automatic network configuration with DHCP (or 192.168.0.1), for the first interface.
- Access to the controller via SSH and user-friendly interface of working, including mc. The passwords by default omit and the user "root" allowed for connection to it via SSH.
- Time synchronization via NTP.
- OpenSCADA execution with the available network interfaces:
- configuration and runtime environment via Web (ports: 10002 and 10004);
- control interface of OpenSCADA (10005).
For the PLC firmware assembling used next packages list:
The Linux kernel modules list of the initial stage was some changed and include:
To the script of the tree preparation "profiles/plñ/image-scripts.d/init1-PLC" performs the functions:
- changing the name of the distribution kit;
- enabling login from the user "root" via SSH, without a password;
- setting locale to "en_US.UTF-8";
- network configuration for use DHCP or set to "192.168.0.1" for the first interface;
- clock setting on the whole and the time-zone setting to "/usr/share/zoneinfo/Europe/Kiev", for changing what you need replace the file "/etc/localtime" to need zone;
- enabling of the necessary services;
- removing of the documentations, help pages and information, icons;
- removing of the not needed locales and the translations; left for presence only the locales: en_US, uk_UA and ru_RU;
- selection of only used kernel modules and deletion all the others is added; it is disabled by default and can be enabled to preparation the final firmware for specific equipment; it was unified for the modules list setting by groups of the kernel subsystem’s and specified for hardware;
- the directory with the kernel (/ boot) is deleted in connection with its moving to the root of the boot partition.
Real-time kernel
For a series of tasks are important, often also critical, criteria of the environment is the real-time handing level, then it is possibility of working the tasks according to the real-time priorities and provision of a reaction to events by that priorities.
The Linux kernel of itself provides POSIX real-time scheduling policies "SCHED_FIFO" and "SCHED_RR" with the priorities range (0...100). But the important criteria is "Timer frequency and the reaction to it" up to version of Linux kernel 2.6.24 was too low, for criteria of the real-time systems. In modern kernels of Linux (> 2.6.24) provided support for timers of the high-precision resolution (HPET), what decreased the reaction time to a timer up to 100 microseconds, but that time stability is not guaranteed. To ensure stability of reaction to a timer on level 60 microseconds, and also series of the other criteria of real-time, at the moment you need to assemble a kernel with one real-time extension.
On the ALTLinux distributions observed the kernel 2.6.29-rt-up, which assembled with the real-time extension of real-time is XENOMAI. Into other distributions, for example OpenSuSE, observed also the solutions with it extension.
For now higher criteria of the real-time ensured of the extension The Real Time Preempt Patch, on enabling here full it's features by (CONFIG_PREEMPT_RT), The patch assembling to Linux kernels process and it's work result will trace into this section.
For the real-time level testing on different kernels will use the utility "Cyclictest", which typical call command line and it's arguments looks: "$ cyclictest -t1 -c1 -p 80 -n -i 200 -l 100000". Where:
- -t1 — single testing thread;
- -ñ1 — using the clock of real-time CLOCK_REALTIME;
- -p 80 — priority of the testing thread;
- -n — using the function "clock_nanosleep";
- -i 200 — pulling interval of the testing thread: 200 us, as closer to the average value 50 us;
- -l 100000 — testing iterations number.
Pair of measurements for Linux kernels of the wide purpose:
- ALTLinux T6 distribution standard kernel (3.0.79-std-def, LP8781):
- loading 0%: Avg: 37 us; Max: 152 us
- loading 100%: Avg: 37 us; Max: 191 us
- ALTLinux T6 distribution kernel (3.4.45-un-def, LP8781):
- loading 0%: Avg: 53 us; Max: 217 us
- loading 100%: Avg: 40 us; Max: 183 us
kernel-image-rt-up-2.6.29
The kernel originally presents into the distribution ALTLinux 5.1, and it is also moved to the local repository of the project OpenSCADA for ALTLinux T6. The kernel assembled with the extension XENOMAI and AUFS, allowing it using into the firmwares and packed root FS, that was done for the PLC LP-8x81.
Results of the kernel testings:
- LP8781 (XENOMAI)
- loading 0%: Avg: 26 us; Max: 136 us (there observed jumps up to 1 ms, like to instability the source clock "tsc", at that the "acpi_pm" worse here)
- loading 100%: Avg: 24 us; Max: 3655 us
- LP8781 (CONFIG_PREEMPT_NONE)
- loading 0%: Avg: 29 us; Max: 71 us
- loading 100%: Avg: 28 us; Max: 117 us (there observed jumps to continuous the measured value rising)
- LP8781 (CONFIG_PREEMPT_RT)
- loading 0%: Avg: 29 us; Max: 64 us
- loading 100%: Avg: 29 us; Max: 82 us
- AMD Turion Neo X2 L625 (CONFIG_PREEMPT_RT)
- loading 0%: Avg: 57 us; Max: 74 us
- loading 100%: Avg: 57 us; Max: 78 us
As you can see from the testing results the patch XENOMAI does not ensure proper level of the real-time on using the standard mechanisms of the POSIX real-time scheduling, at the same time as the kernel version 3 even without the specific real-time extensions ensures the clearly better result.
Necessity for assembling same that kernel with the patch/parameter CONFIG_PREEMPT_RT is actual by presence a number of binary modules from ICP_DAS, for "LP8x81". Also here is actual a question of building the kernel 2.6.33 at the same reasons but for "LP8x81 Atom". The preliminary assemblies of the kernels 2.6.29 and 2.6.33 reveals series of problems which will described here. Solving also a variant to build a modern kernel with CONFIG_PREEMPT_RT and next to request for building these binary modules from "ICP DAS".
Assembling and testing process:
- Patches CONFIG_PREEMPT_RT and AUFS of days of 2.6.29 are conflict on the function "debug_mutex_set_owner()", into CONFIG_PREEMPT_RT it removed — replaced to "mutex_set_owner()".
- On the assembling here detected series of problems for "# typedef void irqreturn_t;" — replaced to "#include <linux/irqreturn.h>".
- The first start with CONFIG_PREEMPT_RT, but without AUFS, was successful — the results above.
- The starting with AUFS was reveal a problem into memory allocation by AUFS into "aufs_mmap()" — the working code of AUFS was taken from the preliminary assembling "rt-up-2.6.29.alt2".
- It starting with AUFS was reveal a problem of hanging on the FS root into AUFS, like to possibility of cycling/blocking a RT-task — setup CONFIG_PREEMPT_NONE, on LP8781 and "AMD Turion" any problem does not observed (possible the problem due the HPET missing on PLX8).
- At the first look the kernel works fine, but observed jump to continuous growing the measured value of the delay time.
- There finished adapting of the kernel to a binary compatibility for the modules "slot" and "icp" from ICP_DAS. The module "8250_linpac" crashes at it's loading, and "icpdas_8250" has more unresolved symbols — the modules need to reassemble or to try the interfaces > COM2 initiate through setserial — the modules was reassembled by the help of Golden Wang (technical support of ICPDAS).
- The new kernel set to high loading by the project configuration ACS ball drum mills:
- network with the driver "via_rhine" halted, after 4 days of successful working — the halt expected, assembled the driver "rhinefet", testing continued.
- on the driver "rhinefet" the system on loading had work three weeks. But here observed the interrupt 11, on what hangs mostly all standard hardware (USB, Ethernet and may be something), had disabled and the network continued to work into "Pool" mode, which is slower. Possible that interruption disabling occurs also with "via_rhine", and it can not work in the mode "Pool", why packages into the network do not go. The problem reason linked to halt and generation the unhandled interruptions from one of hardware on the interruption 11.
- The problem fixed by preventing the interruption disabling at help the Linux kernel parameter "noirqdebug".
- The adapting successful finished and the firmwares based on the kernel ready to the production implementation!
- 01.03.2015: Instead function EnableWDT() used EnableSysWDT(), by limit to 30 seconds and cyclic reloading if the system was not loaded in 30 seconds (up to three reloadings).
- 17.03.2015: With assist the ICP_DAS support service was fixed a problem into the serial interfaces driver for more to COM2 which causes to Linux kernel "freeze" (like to interruptions block) after closing one port and activity on some other.
- 29.07.2015: Detected one more problem looks like by the symptoms to the interruption 11 disabling, but: the interruption 11 is not disabled and all other devices on it works. It reproduced only on configurations with using that both network interfaces, at that possible "braking" for one of its. The problem resolved only by reloading "the braked" network interface, by the command: ifdown eth0; ifup eth0. To detect it and the reloading performs we recommend on the OpenSCADA level append the traffic control and same reloading of the interface on the traffic lack.
- 21.11.2016: Driver "rhinefet" has been adapted to prevent the interrupts lock and the interrupt vector disable but SHARE mode using. For now it works but 19.12.2016 also there was observer the two adapters network slowing after about two week working.
Then the hardware is broken for two adapters work and for the PLC you can use only one for stable work!
Result kernel, which renamed to "kernel-image-rt1-up-2.6.29.alt1", you can use for PLC with HPET or a high precision timer, and also into "LP-8x81" and "LP-8x81 Atom" (only single kernel)!
kernel-image-rt-up-2.6.33
Kernel version 2.6.33 assembling with the patch CONFIG_PREEMPT_RT needs for PLC LP-8x81 of firm "ICP DAS" and LP-8x81 Atom (main and original kernel) by reason of presence for it the binary drivers of "ICP DAS".
Testings results of the kernel:
- AMD Turion Neo X2 L625
- loading 0%: Avg: 65 us; Max: 86 us
- loading 100%: Avg: 57 us; Max: 72 us
- LP8781
- loading 0%: Avg: 37 us; Max: 88 us
- loading 100%: Avg: 34 us; Max: 108 us
- LP8781-Atom (original assembling of the kernel 2.6.33.7-rt29-ICPDAS)
- loading 0%: Avg: 17 us; Max: 50 us
- loading 100%: Avg: 12 us; Max: 32 us
Assembling and testing process:
- Assembling of the kernel from sources of "ICP DAS" (2.6.33.7) and configuration it inherited from kernel 2.6.29 (the source code has suspiciously more of *.rej files, and also "staging/comedi" impossible to build) — it started and mostly works; modules "ipic" and "slot" loaded; module "8250_linpac" crashes into function "platform_device_add"; series of programs hangs into FS operations, with the message: "task openscada:2153 blocked for more than 120 seconds".
- AUFS replacing to the version from 2.6.29-rt1 — crashes into rtmutex on starting; replacing to official version from git looks same result, at the begin used patch "aufs+sqfs4lzma-2.6.33.patch" from DLink.
- Assembling the original kernel with patches CONFIG_PREEMPT and AUFS — a problem again into AUFS, but now it at the finish can not look "/sbin/mingetty".
- Assembling the original kernel 2.6.33.9 with patches CONFIG_PREEMPT and AUFS — same problems.
- Assembling from sources of "ICP DAS" (2.6.33.7) for SMP — the module DAQ.JavaLikeCalc of OpenSCADA crashes at an unknown reason.
- Assembling the original kernel with patches CONFIG_PREEMPT and AUFS for SMP — same problem as without SMP but it is not immediately and about five thread.
For now the kernel 2.6.33 links with CONFIG_PREEMPT_RT and AUFS is non-working. Then if you need to work on "LP-8x81 Atom" then we recommend to use the original Linux-environment, building and installing the OpenSCADA here. Diamond Systems ATH400, DMM32
The boards from "Diamond Systems" were a first on which OpenSCADA had tested and stabilized. First board here was single-board computer 
ATH400 of the form-factor PC/104, shown on the image bottom. On the computer a OS environment early was installing in traditional method and for now by the presented conception of the firmwares assembling.
Hardware specification of the board:
| Central processor: | VIA Eden 400-660MHz |
| Operational memory: | 128MB, soldered to the board |
| Permanent memory: | IDE (44) port with UDMA-33 |
| Video subsystem: | S3 Savage 4 Chipset with extension of 3D/2D video; supported flat panels, CRT and LCD |
| Audio subsystem: | present |
| Interfaces/ports: | 10/100Mbps Ethernet; 4 RS-232 serial ports; 4 USB 1.1 ports; PS/2 keyboard and mouse |
| Power supply: | +5VDC ±10% @ 2A |
| Operating conditions: | -40 ... +85°C |
| DAQ: | 16AI (16 bit, 100 kHz), 4AO, 24DIO, 2CNTR |
First task of the board and OpenSCADA was implementation of function of high-frequented (10 kHz * 8 channels) signals archiving of a gas compressor for learning the surge phenomenon on Anastasievskaja GLKS.
Second task was the PLC prototype of power substations nodes. Already for this task the firmware had assembled on base of new package base. Into the task Data acquisition module of boards of the "Diamon Boards" was unified for support all boards of the manufacturer.
Second board was one board of the interface to the object DMM32-AT, shown on the image bottom. The board used for creation of mockups and emulators of field of technological programs. The board has specification:
| Power supply: | +5VDC ±10% @ 200mA |
| Operating conditions: | -40 to +85°C |
| DAQ: | 32AI (16 bit, 200 kHz), 4AO, 24DIO, 2CNTR |
Analysis of noise properties of high-impedance inputs of boards from Diamond Systems in different conditions placed to table bottom:
| Conditions | External PS: Noise level, mV [Hz] | Internal PS: Noise level, mV [Hz] | Notes |
| (10 kHz, ±0.625 V, 20 us), Grounded-32 | 0.08 [-] | ||
| (10 kHz, ±5 V, 20 us), Grounded-32 | 0.5 [-] | 0.35 [-] | |
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading ∞ | 5 [50, 270] | 18 [50, 150] | |
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading 1mOm | 10 [50, 270] | ||
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading 100kOm | 7 [150, 50, 270] | 7 [-] | |
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading 10kOm | 4.5 [100] | 6 [-] | |
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading 1kOm | 0.9 [150] | 1 [-] | |
| (10 kHz, ±5 V, 20 us), Grounded-31, Loading 100Om | 0.5 [-] | 0.5 [-] |
Kontron MOPSlcdLX
MOPSlcdLX is single-board computer of form-factor PC/104, shown on the image bottom. The computer had attracted attention by some low price, by ordinal conditions of the exploitation and then lower heating.
Hardware specification of the board:
| Central processor: | AMD LX800™ 500 MHz, fanless |
| Operational memory: | DDR-RAM-SODIMM socket |
| Permanent memory: | IDE (44) port |
| Video subsystem: | built-in graphic with support output to flat panels, CRT and LCD |
| Audio subsystem: | no |
| Interfaces/ports: | 10/100Mbps Ethernet (Intel® 82551ER); 2 RS-232 serial ports; 2x USB 2.0; PS/2 keyboard and mouse, Floppy, LPT |
| Poser supply: | +5VDC ±10% @ 1A |
| Operating conditions: | 0 ... 60°C |
The board had used for testing of creation operator stations/panels with OpenSCADA into like environment. Latter there had occur problems series with the board:
- The clock's battery lack then it needs to setting the time at any starting or setting the external battery. At that the BIOS settings stored not in CMOS but in FLASH, it is kind good but if the BIOS configuration reset impossible then it is too bad.
- A problem into the interruption scheme which cause to block all or mostly adjacent interruptions at the module "geode_aes" loading.
- In some time the video-card or it's video-output burned but the configurations of BIOS stored into FLASH and there impossible to return its, for fix possible disabled the video into the BIOS. Also the BIOS do not support of forwarding self interface to a COM-port. Will try use CRT here, when it emerged.
- The high-precision counter (HPET) lack, that surprisingly and make this board unusable for real-time systems but ordinal counter can provide lag about 4ms.
For now base on this board preparing "The program oscilloscope" why it was successfully downloaded by the modern firmware with kernel "std-def" and addition board DMM-32X-AT installed, about that see above.
Tri-M VSX104
VSX104 is single-board computer of form-factor PC/104, sown in the image below. The computer had attracted attention by the reason of low price and low power consumption (< 2W) and followed low heating. But by using the processor "Vortex86SX-300 ÌÃö" here needs specific points to forming of the OS environment, but here used CPU instructions set of i486 and the mathematical coprocessor lack.
Hardware specification of the board:
| Central processor: | DM&P SoC Vortex86SX-300 MHz |
| Operational memory: | 128 ÌÁ DDR2 RAM, soldered to the board |
| Permanent memory: | slot CompactFlash Type I, microSD and 2 ports EIDE (Ultra DMA 100) |
| Video subsystem: | no |
| Audio subsystem: | no |
| Interfaces/ports: | 10/100Mbps Ethernet; 4 RS-232 serial ports; 2x USB 2.0; PS/2 keyboard and mouse, LPT, Redundancy, SPI |
| Power supply: | +5VDC ±10% @ 370mA |
| Operating conditions: | -40 ... 85°C |
| DAQ: | 1 port 16-bit GPIO |
For now there is not a solution based on the board but planed to assemble for it a environment, possible for an autonomous control resources system.
Force redirection of the BIOS interface to a COM-port possible to enable by grounding the 10 pin of the COM-port.ICOP VDX-6354D
VDX-6354D is single-board computer of form-factor PC/104, sown in the image below. The computer builds on the processor "DM&P SoC CPU Vortex86DX- 800MHz", which more productive to "Vortex86SX-300 ÌÃö" into above section, but the power consumption for this board already not 2 but 4 Watts see details on the project page (RU).
ICP DAS LP-8x81
Industrial controllers of family LP-8x81 of firm ICP DAS are a first product from series LinPAC built on x86 compatibility processor, early created controllers of this family based on processors of ARM family. Besides the x86 processor these controllers have significant resources of the operative memory and main storage's space. All that had allowed see to the controller as first candidate from products of ICP DAS for OpenSCADA adapting as environment of execution see details on the project page.
Avalue Sensor panel FPC-1701
Firm Avalue in accordance with Russian firm ElTech provide wide range of panel PC which you can use starting from ordinal mono-blocks and ending by industrial sensor panels into the frontal protection class IP65. By a standard hardware using here you can start and work in OpenSCADA without a problem see details on the project page (RU).
iROBO-3000a
iROBO-3000a is a fanless industrial computer with Intel Atom D425 1.8 GHz with VGA, 2xGb LAN, 4xCOM, 4xUSB, 1GB RAM, 1x2.5" SATA HDD 120GB, Mini-PCIe, 4x4 DIO, CF slot, SIM Card slot, Audio, WDT on board, operating temperature range -5...+55°C. Performance of this computer is enough to run the functions of data acquisition, monitoring and control server, as well as the visualization station's functions. However, because of usage the non-productive Atom processor family, the implementation of mathematical models of processes will require almost all of the CPU resources. For example, during the performance of the AGLKS mathematical model, the CPU is loaded at 86%. The controller has been certified by "UKRSEPRO" that may be important for many users in the territory of Ukraine.
OpenSCADA operating environment for this computer was based on the packets base of the ALTLinux T6 distribution, as well as freshly-builded Trinity (TDE) desktop environment. Building of the environment was made using the above described conception with an updated profile of "mkimage". The "plc" objective has been added to the new profile, but its nature has changed in fact and has become a copy of the "live" target, which became possible thanks to the implementation in primary initialization stage the transparent mount of the partition with the "alt-live-storage" label as a reflection of a packed file system with random access to the modification. In general, it made possible to create the fixed core of the firmware with the basic set of software environment with the size of 300MB and with the possibility of free expansion by installing the necessary packages from the distribution.
The Trinity was selected as the desktop environment because of the presence of background artefacts problem in conjunction with XOrgServer 1.10 + Qt4, as well as because of TDE low-resource with high maturity and stability.
Archive of the build profiles of the new environment is called 
mkimage-profiles-6-kdesktop-plc.tgz, and the latest build of the firmware ALTLinux_6-OpenSCADA_0.8.1-TDE_3.5.13.1-i586-flash.tar.
Advantech PCA-6753, PPC-L126
Firm Advantech produces wide range of hardware for automation, start from panel PC and finish data acquisition modules ADAM.
In the project Data acquisition system of boiler ¹1 CHP (RU) to hands we get panel PC PPC-L126 and industrial PC on chassis IPC-6608 with processor board PCA-6753.
The industrial PC "PCA-6753" has next specification:
| Central processor: | Low-consumption NS GXm-200 MHz (fanless) |
| Operational memory: | 64 ÌÁ DIMM SDRAM |
| Permanent memory: | SSD DiskOnChip® 2000, IDE (40 pin, UDMA 33, 256ÌÁ IDE Flash) |
| Video subsystem: | CX5530 VGA/LCD and 18-bit LCD TFT |
| Audio subsystem: | no |
| Interfaces/ports: | 10/100Mbps Ethernet (RTL-8139); RS-232 + RS-232/422/485 serial ports; 2 x USB 1.1 (host), IR port; LPT; Floppy |
| Power supply: | +5VDC ±10% @ 1.54A |
| Operating conditions: | 0 ... 60°C |
The controller is some old and has a low-performance for modern programs but for the tasks of execution environments of PLC it is suitable enough and on it was successfully downloaded firmware based on ALTLinux 5.1 packages base. At that about a real-time no a speech was by the high-precision timer (HPET) lack.
The panel PC "PPC-L126" has next specification:
| Central processor: | VIA Eden 667 MHz |
| Operational memory: | Two 168-pin DIMM sockets (128 MB) |
| Permanent memory: | CompactFlash type I/II, IDE (44 pin, UDMA 33/66/100, 10 GB) |
| Video subsystem: | VIA Savage4 2D/3D/Video, sensor display 12.1", frontal panel: IP65/NEMA4 |
| Audio subsystem: | AC97 Ver. 2.0 |
| Interfaces/ports: | 10/100Mbps Ethernet (RTL-8139); 3 x RS-232 + RS-232/422/485 serial ports; 2 x USB 1.1 (host); PS/2 keyboard and mouse; LPT |
| Power supply: | 19VDC @ 3.3A |
| Operating conditions: | 0 ... 40°C |
The panel PC also has small resources for start modern environment then for installing on it was using the distribution "ALTLinux T6" with the actions to optimization:
- storage drive performance — for the data storage used the IDE hard-drive which ensure 10 MB/s, more then allowed CompactFlash;
- all spare services disable;
- the desktop environment TDE usage as lesser demanded to resources but more advanced; into the reserve has IceWM;
- building OpenSCADA without libraries Phonon and WebKit which too demanded to resources.
These actions allow fit the system to 128 MB of operational memory and get at that an advanced and productivity graphical environment. For the sensor display ELO configuration had using the driver "elographics" — "xorg-drv-elographics". To the configuration file "xorg.conf" added section:
Firmware and creation of the PLC software environment for the ARM architecture
Widespread in embedded solutions the ARM architecture obtained due to its relatively high productivity coupled with low power consumption and cost. In order to perform planed task to provide the hardware multiplatform the OpenSCADA system was adapted to the building and operation on the equipment of ARM-architecture. Thus, the following projects were made Building the OpenSCADA project for the mobile devices of the Nokia company (N800, N900, N950) and Building the OpenSCADA and firmware for the ARM-based controllers from ICP DAS (LP-5141). The purpose of this section is to systematize the procedures and track he problems of creating the OpenSCADA buildings and software environment firmwares as a whole for a variety of embedded ARM-architecture hardware.
Specific of the ARM architecture is the lack of a necessarily hardware-dependent software system of the basic initialization and configuration of equipment, which is characteristic for the x86 architecture — BIOS, and the structure of hardware configuration typically includes: CPU, integrated operational and flash memory, as well as a number of built-in equipment on a standard system-level buses. The flash and RAM are placed in general address segment. Initialization of the such system with the software environment is made by downloading executable code directly on the built-in flash-memory.
To working of computing functions of OpenSCADA and other related libraries and softwares the performance of floating point calculations is very important. Specific of the ARM architecture processors is the ease of its core and availability of optional extensions such as math coprocessor. As a consequence, the performance on floating point operations is highly dependent on the specific processor, and on the emulation type of the floating point coprocessor if it is absent at all. There are two formats of floating point in the ARM-architecture processors: FPA and VFP. FPA format is obsoleted and met as a hardware implementation in the ARM cores up to the StrongARM family (ARMv4). XScale ARM core families (ARMv5TE) did not have a math coprocessor at all. And the ARM core, starting with the ARM11 family (ARMv6) are equipped with VFP format math coprocessor. At the same time the ARM processors with the ARMv5 architecture are still widespread, and thus the question of performance of mathematical calculations for them comes down to the performance of the FPA or VFP format emulation. In the case of the Linux environment the emulation of FPA is usually done by the Linux kernel by the CPU exceptions handling when calling FPA commands. Software emulation in the math library is usually found with the VFP format which requires the rebuilding of all programs. The FPA emulation by means of exceptions is much worse than the performance of software VFP emulation. You can compare the performance of floating-point calculations on different architectures, processors and ways of emulation in appendix 1.
The typical software environment based on the Linux operating system for ARM based hardware is: Loader UBoot, Linux kernel and root file system (RFS). UBoot loader is loaded into the zero sector of flash memory, and its settings are stored in the first one. From the second sector the kernel code is loaded, and immediately after it - the RFS. RFS is usually uses as basis the JFFS2 or UbiFS file system, which are optimized to work on block devices — flash memory with a limited resource of records. Examples of partitioning a block device (flash memory) for LP-5141 and TionPro270 are presented below:
The root file-system contains a typical UNIX-tree with work programs, libraries and other files. The basis of any program or library are the system libraries GLibC or UClibC. OpenSCADA is adapted for building and operating with "GLibC" version >= 2.3. "UClibC", created as a lightweight version of "GLibC" for embedded systems, contains a number of limitations and has not yet been implemented or has errors in the implementation of a number of functions.
RFS and a software environment based on Linux can be supplied with the ARM-equipment and contain closed binary libraries, Linux kernel modules, etc. In this case, an independent building and replacement of the original software environment is impractical task because it leads to the loss of original functionality. However, it often happens the delivery of the ARM equipment without the source (original) software environment, or with an environment that does not contain closed code and which can be replaced. An example of the first case is the controller LP-5141 and similar of the "ICP DAS" company, which contain the binary building of the specialized equipment API library (libi8k) and Linux kernel modules for its initialization. An example of the second case is a single board computer Chion-Pro270, the software environment creating and OpenSCADA building for the ARM architecture of which will be considered below.
Building tools for the Linux kernel and working environments for different target architectures
Linux RFS can be formed on the basis of ready packages of the existing binary distribution, source package of the current distribution, as well as to build from the original sources through the ToolChain in one of the building systems.
Building of the programs or of an entire RFS for architectures other than x86 and x86_64, is usually made using the Cross Compilation tools (ToolChain) for building, linking and debugging for the target ARM architecture. To automate this process a number of tools to build the ready RFS created.
BuildRoot
This building system is a part of the project for creation an alternative library of functions of "C" language UClibC, so basically aims to build environments with "UClibC", and with appropriate restrictions. BuildRoot is well in the work on the host systems of different versions, and allows to build the software environments based on Linux without too much troubles.
It is possible to get the BuildRoot archive of the correct version by the link http://buildroot.uclibc.org/downloads. Further it should be unpacked to the home directory of the simple user and the configuration, setup and building should be done:
The build process can cause following problems:
- Inability to download the programs archive.
- Programs' building errors.
PTXDist
Universal tool fro the building of kernel's, ToolChain and software environments based on Linux from the "Pengutronix" company. PTXDist is a powerful and flexible tool, but it's older versions have problems in the modern host systems, which complicates the task of building the software environments for relatively old but still prevalent hardware platforms. For example, now (2012) can be found new hardware with the ARM XScale, ARM9 (ARMv5) processors of the 2003 year. However, newer versions of PTXDist support the old platforms, what can be learned from the support table by the link: http://www.pengutronix.de/oselas/toolchain/index_en.html.
To build the software environment (RFS) using PTXDist it is necessary:
- to get the builder's tool archive (along with the next versions projects, http://www.pengutronix.de/software/ptxdist/download), compile and install it;
- to get archive of source files (the same or similar version as PTXDist, http://www.oselas.com/oselas/toolchain/download) and build ToolChain;
- to clone-create and build the RFS project.
Now detailed, in commands:
Tion-Pro270
Single-Board Computer "Tion-Pro270" is a highly integrated computational-control system, based on the Marvell PXA270 processor with XScale ARM core from the ZEO company. This card was given to the developers of the OpenSCADA project by the Alex Popkov in order to adapt OpenSCADA for it.
All materials on building the programming environment with OpenSCADA and ready builds for Tion-Pro270 board can be obtained at: ftp://ftp.oscada.org/OpenSCADA/PLC/TionPro270
The board is supplied by the equipment manufacturer with preinstalled software environment based on Linux™ or Windows CE©. Besides all the source materials of the software environments are available in Wiki-resource of the manufacturer.
We got the board with the minimal software environment for which it was not possible to build OpenSCADA, so the new software environment has been fully loaded to the board. Download the software environment to the flash-memory was made with the help of JTAG-adapter OLIMEX ARM-USB-OCD and OpenOCD program of version 0.5.0, building of which should be configured with the "--enable-ft2232_libftdi" parameter.
For downloading to board's flash memory it was used ready boot buildings UBoot-1.3.3 (file of the image is u-boot-1.3.3_svn886_520mhz_tion_pro270_64m.bin) and kernel Linux-2.6.22.19. JFFS2 RFS filesystem image was built with the help of "BuildRoot" and "PTXDist", see below.
Flashing of the equipment with help of "OpenOCD" was made from root by the following command:
"tion270.cfg" script of the flash and image files of the software environment specified in the flash script "tion270.cfg", should be placed in the current directory. The flash script "tion270.cfg" includes:
Building of the RFS in the BuildRoot
In order to avoid multiple build problems associated with the build from the beginning, the configuration "buildroot-2009.08" was taken directly from the Git-repository of the equipment manufacturer: http://zao-zeo.ru/media/files/linux/buildroot-2009.08.git. In order to build in the "BuildRoot" environment the configurations were created in the directory "./package/" for the "LibGD" library and OpenSCADA.
Result RFS was loaded to the flash memory of the board and started successfully. However, at start it became clear that the "uCLibs" version 0.9.30.3 does not implement the function clock_nanosleep(), as well as crashes in the function timer_settime() for the type of notification SIGEV_THREAD. The the clock_nanosleep() function can be replaced by nanosleep(), but it is impossible to solve the problem of the timer_settime() function within this version of "uCLibs".
Next, an image of the current version of the "BuildRoot" on 16.01.2012 was taken, and the building of OpenSCADA with "uCLibs" version 0.9.32.1 were made. The building was successful after some adaptation of the building environment. OpenSCADA started successfully with some problems that have been resolved.
Following list describes problems encountered during building and operation of OpenSCADA on uCLibC of different versions:
- There is no implementation of the usleep() and msleep() functions in the typical configuration — it is created and widely used the system-wide function for OpenSCADA sysSleep() with the implementation based on nanosleep().
- < 0.9.32: it can't be built due to the lack of a number of functions, as well as OpenSCADA can't start:
(-) 0.9.30.3: crash in the timer_settime() function for the SIGEV_THREAD notification type — Actual.
- 0.9.32: building was done successful, with some solved problems when starting the OpenSCADA:
(+) Family of printf() functions incorrectly circumvent the problem of hanging characters '%' — line of the message is fixed "Last: %s. Load: %3.1f% (%s from %s)".
(+) Different from the GLibC processing of the interblocks within a single thread in the RW-lock functions — the interblocking is fixed in the OpenSCADA.UI.WebVision module, and function of sessions' check was moved to the service call procedure.
RFS build in the PTXDist
Learning the PTXDist for building environment on TionPro270 was made using the experience of the following link http://www.emb-linux.narod.ru/tion-pro-270/index.html. However, the article was written a long time ago and it was used the ptxdist-1.1.1 version for building, which actually doesn't work on the modern software environments, and also part of the libraries needed for OpenSCADA can't be built there easy. At end it was based on version ptxdist-2011.11.0 and the building was made using this version.
Before the building of RFS the ToolChain configuration for this board was created arm-xscale-linux-gnueabi_tion270.ptxconfig on the basis of the existing arm-xscale-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig with the following programs' versions:
- GLIBC_ENABLE_KERNEL="2.6.19", because the actual kernel is 2.6.22 version, and to work with him GLibC should be given less than or equal version;
- KERNEL_HEADERS_VERSION="2.6.30.5", kernel version for the headers;
- CROSS_GCC_VERSION="4.5.2".
Next was created PTXDist "OSELAS.BSP-Pengutronix-Generic" project's clone in directory "TionPro270_RootFS" with the configuration platform "arm-qemu-2011.01.0". To build OpenSCADA following configuration files was created openscada.in and openscada.make, which were placed in the local configuration directory of the project rules/. It was adapted the configuration of the udev program, which version was very big for the original version of the kernel Linux-2.6.22, ie it was used the udev of 141 version. New configuration files of udev were also placed in the directory rules/, thus defining their usage instead of the original configuration.
The RFS was successfully built and jffs2 image of FS was received. The resulting RFS was successfully loaded onto the board and started. OpenSCADA started and work correctly as well.
Adaptation
This board contains a number of hardware interfaces interesting to adaptation for OpenSCADA, so this section will be focused on the adapting process.
The board contains a chip converting signal levels from RS232 to RS485, which, however, is not clear to send requests from the software. Namely:
- to send a request you need to set the RS232 interface signal "RTS" at zero;
- it is necessary to read interface for waiting the echo package of the request, after receiving of which the RS232 signal "RTS" should be set to true, the echo package should be dropped and then you should waiting for direct response.
To the specific solve the OpenSCADA module Transport.Serial has been improved for this kind of hardware flow control support.
Using this extension, validation was made and presence of LP-5141 controller's software environment problem was confirmed.
ICP DAS LP-51xx
Firm ICP_DAS long enough releases controllers on processors the ARM architecture within preinstalled OS Linux environment, as into the LP-5141 variant, that makes interesting to creation an assembling or a new firmware with OpenSCADA details on the project page.
Nokia N800, N900, N950, N9
Firm Nokia is one of worldwide leaders into manufacturing and marketing of mobile telephones. Into year 2005 the firm Nokia released the pocket personal computer (PPC) N770 based on featured Linux environment with proper environment of desktop (on GTK+) — Hildon with main the project name Maemo. Later base on the platform Maemo was released yet three mobile devices — two PPC "internet-tablet" N800, N810 and smart-phone "internet-tablet" N900. In 2010 the firm Nokia joined forces to work on the Maemo with the project MobLin of firm Intel, creation the project MeeGo. On the platform MeeGo in 2011 year was released two smartphones N950(prototype) and N9, details on the project page.
SMH2Gi
Freely programmable panel controller "SMH2Gi" is a highly integrated computational control system with the iMx27 processor based on the ARM926EJ-S core of the Segnetics company. Adaptation and building of the OpenSCADA for this controller was needed as part of the Automated control system for the vacuum process unit project.
All materials on building the programming environment with OpenSCADA and ready builds for the panel controller can be obtained at the link: ftp://ftp.oscada.org/OpenSCADA/PLC/Segnetics-SMH2Gi.
The panel controller is supplied by the equipment manufacturer with preinstalled environment based on Linux™, and its own runtime of the controller - "SMLogix". The role of OpenSCADA for this controller was seen as enhanced programming environment of the controller, integrated and programmed from the top level station on the basis of OpenSCADA. To preserve the possibility of visualization and control of data obtained in OpenSCADA on the integrated display, while minimizing the effort required for the adaptation, it was decided to save the original runtime environment "SMLogix" for the task of data visualization on the internal display, and to transmit data to/from it via a local ModBus/TCP connection. Afterwards, to optimize certain tasks, there created a module of data source to OpenSCADA DAQ.SMH2Gi with functions for direct SMH2Gi modules MC and MR acquisition, and also for variables exchange with process "logix", by the shared memory.
To build the original software environment the developer used previously discussed tools PTXDist of version 1.99.12. It was not necessary to build ToolChain, guessing the profile used to build the original software environment, because full building environment is available at the manufacturer's web site, packaged up as the Linux image for the VMWare virtual machine. The ready ToolChain profile was obtained from this image gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized. Since it was not required to build the full RFS, it was decided to build OpenSCADA, using the ready ToolChain, separately. To build OpenSCADA the following libraries were previously built: "pcre-8.12" and "sqlite-3.7.6.2". Later, under building modules UI.WebCfgD and UI.WebVision task have built the libraries: "png-1.2.49", "jpeg-8a", "expat-2.0.1", "freetype-2.3.11", "fontconfig-2.6.0" and "gd-2.0.35". Then OpenSCADA was built in following way:
As a result, the archive of OpenSCADA assembling was formed, which can be loaded to the panel PC SMH2Gi and unpacked there. The resulting OpenSCADA software environment is configured to start automatically when you start the controller through init-script "/etc/init.d/openscada". OpenSCADA assembling was successfully launched.
With regard to the software environment of the panel controller SMH2Gi in general it is necessary to make some remarks. The controller uses the Linux 2.6.29 kernel with the hard real-time extension that allows you to hold periodical intervals up to 100 microseconds. In addition, all critical system threads run with the real time planning management policy. In this case, although the processor does not have a math coprocessor, emulation is performed optimally in the form of SoftVFP. All this makes it possible for OpenSCADA to perform highly determinate control tasks at regular intervals up to 100 microseconds and with an acceptable computational performance.
AS-9260
Board AS-9260 is controller based on chip AT91RM9260, core ARM9(ARMv7), with peripheral devices set. The board targeted for development (maketing) projects based on microcontrollers with core ARM926EJ-S production by corporation Atmel, also that can be used for master controller of the target system.
To the board placed sockets USB2.0 (1 Host, 1 Device, Full-speed, 12Mb/s), DBGU, RS-232, RS-485, two 12-pins sockets for placing Ethernet 10/100 Mbps interface module, besides that have place for set two 80-pins sockets type PLD-80 for connect external modules with additional interfaces.
The boards AS-9260 peripheral with processor AT91sam9260 is minimal:
- sockets for interface USB type A and B;
- socket DRB-9 for interface DBGU (RS-232);
- socket PLS-3 for addition interface RS-232;
- socket PLD-20 for connect JTAG-emulator (ATSAM-ICE, AS-JTAG);
- chip ROM series DataFlash AT45DB642D-TU (case TSOP28);
- 2 chips SDRAM total capacity 32 or 64 MB;
- socket for external module Ethernet PHY connection.
Loader and kernel you can be found here http://www.at91.com/linux4sam. To U-boot let's set loading RootFS from USB-flash:
The flash will format to FS EXT2 and to it will write RootFS Debian Lenny. Run the system and configure the internet connection nano /etc/network/interfaces:
Into /etc/inittab let's set autologin:
Set repository for updating, into /etc/apt/sources.list
After upgrade let's download OpenSCADA sources and resolve dependencies. Natively compile SCADA fails by lack of memory. Some from the situation resolving solutions are next:
- Build image of RootFS:
- Start QEMU with RootFS image:
- Compile with next configuration:
- Write image with SCADA back to flash.
- Load and use.
The described method is far not the best then working to improve it. Similarly SCADA is installed to board AS-9200 with processor AT91RM9200.
Raspberry Pi, Pi2, Pi3; OrangePi Zero
"Raspberry Pi®" is a singleboard computer created for charity purposes. Designed to teach basic computer science in schools, positioned as a low-cost solution for novice developers. Developed by "Raspberry Pi Foundation". First board of Raspberry Pi was got to assembling and adaption of OpenSCADA from Maxim Lysenko. The board Raspberry Pi2 was purchased for tasks of OpenSCADA and adapting it to work with generic buses like I2c, SPI, 1Wire with different sensors on its. The board Raspberry Pi3 was purchased and sponsored by Proviron Holding NV for some debug and technical support.
The board has features:
| Parameters: | Raspberry Pi | Raspberry Pi2 | Raspberry Pi3 | Orange Pi Zero |
| Hardware platform: | ARM11 (ARMv6) | ARMv7 | Cortex A53 (ARMv8) | Cortex-A7 (ARMv7) |
| Central processor: | Broadcom BCM2835, 700 MHz ("turbo-mode" up to 1GHz) | Broadcom BCM2836, 900 MHz, 4 Cores | Broadcom BCM2837 64bit, 1.2GHz, 4 Cores | H2 Cortex-A7 H.265/HEVC 1080P, 1.2GHz, 4 Cores |
| Memory: | 256/512 MB, integrated to CPU | 512 Mb or 1Gb, integrated to CPU | 1Gb, integrated to CPU | 256MB/512MB DDR3 SDRAM |
| Solid memory: | flash card MMC | flash card MicroSD | flash card MicroSD | µSD, optional SPI NOR Flash on board |
| Video subsystem: | integrated video core Broadcom | integrated video core Broadcom | integrated video core Broadcom | Mali400MP2 GPU @600MHz |
| Audio subsystem: | integrated to CPU | |||
| Electrical power: | microUSB, 5V, from 700 mA | microUSB, 5V, from 700 mA | microUSB, 5V, up to 2.4A | DC 5V DC-IN via µUSB or pin headers or PoE |
| Interfaces: | 2xUSB, Ethernet 10/100M, HDMI, video RCA, Stereo Jack 3.5 mm, UART, JTAG, SPI, I2C, DSI, CSI | 4xUSB, Ethernet 10/100M, HDMI, video RCA, Stereo Jack 3.5 mm, UART, SPI, I2C, DSI, CSI | 4xUSB, Ethernet 10/100M, WiFi 802.11 b/g/n, Bluetooth 4.1 LE, HDMI, video RCA, Stereo Jack 3.5 mm, UART, SPI, I2C, DSI, CSI | 3xUSB Host, 1xUSB OTG, Ethernet 10/100M POE, WiFi 802.11 b/g/n, TV out, microphone, stereo line-out, 3xUART, 2xSPI, 2xI2C |
| Weight: | 45 g. | 45 g. | 45 g. | 26 g. |
| Size: | 85.6 × 53.98 × 17 mm | 85.6 × 53.98 × 17 mm | 85.6 × 53.98 × 17 mm | 48 × 46 × 17 mm |
Raspberry Pi
For working the board used special distributive Raspbian "Wheezy". Building OpenSCADA was done for LTS version 0.8.0.5 and Work version 0.8.1 direct on the board. For building had to expand swap memory size to 500 Mb due more memory need for some modules of OpenSCADA building by modern compiler (GCC 4.7) and with optimization (-O2). Result packages successfully installed and operation.
Graphical desktop environment into selected distributive built on LXDE 0.5.5, displayed in full resolution of the display through HDMI, or in resolution 640x480 through composite video-output. OpenSCADA successfully have started and have worked into graphical mode, but its performance insufficient for normal dynamic models of OpenSCADA execution.
Raspberry Pi 2 and 3
For working with the boards there also used a special distributive Raspbian "Wheezy". OpenSCADA has built for Work version 0.9 direct on the board and allowed memory here enough for this operation but it has 1MB and more, the building there allowed on all four threads. The building of OpenSCADA performs in packages which then placed into proper repository of Debian 7 from time to time of the buildings. Also for Raspbian "Jessie", mostly for the generic architecture ARMHF, there performs regular building of OpenSCADA by the OpenSCADA automatic builder into the cross-compiling environment and the result packages are placed into proper repository of Debian 8.
The typical graphical desktop environment into the selected distributive built on LXDE 0.5.5 (Wheezy) and 6 (Jessie) but it's replaced to TDE R14 for more features with low hardware demands. For remote access there was configured VNC access in display resolution 1024x768. OpenSCADA is successfully started and worked into graphical mode and the performance here enough already by the multi-threading.
For more free handling to the board was connected a WiFi adapter and on RPi3 it presents already.
To allow for operations with GPIO directly in OpenSCADA there was created a module DAQ.BCM2835 based on the library bcm2835. For now the module provides access to "Raspberry Pi" GPIO (0...31) as OpenSCADA DAQ's parameter attributes, static and dynamic functions, which the comparing information of performance shown here.
To the board there was connected a 16x2 text display 1602A and a program like to the original Python one was wrote into OpenSCADA by using the static functions of the module DAQ.BCM2835. As a result the program works fine and some faster to the Python original one.
To the board there were directly connected sensors DHT 11 and AM2303 (humidity and temperature) and a program like to the original Python program's C-language driver part was wrote into OpenSCADA by using the static functions of module DAQ.BCM2835.
To allow creation derivative DAQ templates with their configuration the dynamic linking to static external functions was added into DAQ.JavaLikeCakc, like this:
To allow operation in OpenSCADA with devices on bus I2C the output transport "Serial" was adapted to the bus by selection the bus and a slave device's address (first byte of the sequence) set by IO control command I2C_SLAVE. In this way now to OpenSCADA there were connected:
- The 8-bit A/D and D/A converter chip PCF8591. Through the chip PCF8591 were connected sensors LM35 and LM335.
- The 8DIO converter chip PCF8574, which also adapted and tested for connection to 1602A.
- The barometric pressure/temperature/altitude Sensor BMP180.
- The memory chips AT24CXX by calls through the proper protocol.
The tracing task of the work out opened here.
Orange Pi Zero
For working with the board there used a special distributive Armbian "Jessie". As builds of OpenSCADA there have used the packages repository, mostly for the generic architecture ARMHF, for which performs regular building of OpenSCADA by the OpenSCADA automatic builder into the cross-compiling environment.
The board provides more low level buses (3xUART, 2xSPI, 2xI2C), despite its small size, and restricted GPIO in 16 pins which mostly used by the buses. The buses are standard but GPIO are some specific ones for which we need implement special support into the presented module DAQ.BCM2835 making it more unified one. Then there planed next tasks:
- connect a device to the I2C bus;
- connect a device to the Serial bus,
- try to adapt 1Wire (DS9097) to the Serial buses;
- the specific GPIO support implement for OpenSCADA;
- WiFi driver fix/update.
Asus Nexus 7 II
"Asus Nexus 7 II" — tablet computer of 2013 year edition with four-cores ARM-processor and sensor screen 7", released in conjunction of Asus and Google. Purchased for tasks of OpenSCADA and adapting it to work into the environment of OS Android and hardware of modern multicore CPU of ARM-architecture.
Image. OpenSCADA in Web and Qt5 for the native building.
Key specification of the tablet:
| Hardware platform: | ARM Cortex-A15 [ARMv7] |
| Central processor: | Four-core Qualcomm Snapdragon APQ8064-1AA 1500 MHz |
| Operational memory: | 2 GiB DDR3 |
| Permanent memory: | 32 GiB |
| Video subsystem: | 400 MHz quad-core Adreno 320 |
| Screen: | IPS, 1920x1200 px (323 ppi) |
The tracing task of the work out opened here.
Assembling and starting OpenSCADA into the environment of OS Android
Installing of full-featured OS Linux and OpenSCADA starting
For different OS installing you need to unlock the loader and for original Android saving you need ensure multiboot.
The loader unlock and ROOT, from a Linux environment:
- Enable the debug mode of Android: "Configuration" -> "About the device", five times click into item "Building number".
- Set debug through USB: "Configuration" -> "Developers parameters", set proper property.
- Install the utility "adb" (Android Debug Bridge).
- Check for connection to the tablet: connect USB-cable to PC, call command "$ adb devices".
- Unlock the device:
- Enable the tablet with connection to PC by the USB-cable and holding by buttons "Power" and "Sound lower" up to the bootloader screen appear.
- Check for the boot-loader visibility: "$ fastboot devices".
- Unlock: "$ fastboot oem unlock".
- Load and flash "TWRP recovery": load here, then flash it by command "$ fastboot flash recovery /Path-to-TWRP.img"
- Enter to the "Recovery" mode of the loader and provide access ROOT: select "Reboot" -> "Recovery" -> "ROOT", then "Reboot" -> "Sytem".
- Next, installation "SuperSU" for you will be proposed.
To provide the multiboot let install "MultiROM Manager" from "Play Market".
Appendix 1. Performance measurement for processing systems
| Hardware | Enter into JavaLikeCalc, us** | Operation sin(Pi) [into JavaLikeCalc], us | Operation pow(Pi,2) [into JavaLikeCalc], us | Model AGLKS [Vision, main mnemo], %(core) | Extra tests and notes |
| ARM | |||||
| Segnetics SMH2Gi (ARM926EJ-S, 400 MHz, SoftVFP, 199 BogoMIPS) | 3.4 | 11.1 [14.9] | 4.4 [7.9] | - | |
| Router 3G TELEOFIS RTU968 (ARM926EJ-S), 400 MHz, OpenWrt, uCLibC, SoftVFP, "-O2", 226 BogoMIPS) | 2.45 | 7.2 [9.75] | 2.02 [5.45] | - | |
| ICP DAS LP-5141 (PXA270, 520 MHz, FPA) | 100 [200]* | 51 [152]* | |||
| ZAO ZEO TionPro270 (PXA270, 520 MHz, SoftVFP, uCLibC-0.9.32.1, -Os, 519.37 BogoMIPS) | 22 [51]* | 14 [41]* | - | Minimum power consumption: 1.27 W | |
| ZAO ZEO TionPro270 (PXA270, 520 MHz, SoftVFP, GLibC-2.14.1, -O2, 519.37 BogoMIPS) | 5.92 [8.26] | 1.74 [4.08] | - | Last update: 30.10.2013 | |
| Nokia N800 (TI OMAP2420, ARMv6, 400 MHz, 397 BogoMIPS) | 2.32 | 2.93 [6.29] | 2.11 [6.98] | - | |
| Raspberry Pi (BCM2708, ARMv6, 700 MHz) | 1.15 [4.57] | 1.28 [4.60] | - | ||
| Nokia N900 (TI OMAP3430, CortexA8, 600 MHz, 598.9 BogoMIPS) | 1.23 | 1.55 [1.9] | 0.932 [1.38] | >100 | |
| Nokia N950 (TI OMAP3630, CortexA8, 1 GHz) | 0.90 [2.02] | 0.552 [1.81] | >100 | Last update (Turbo N900): 02.11.2013 | |
| Raspberry Pi 2 (BCM2836, ARMv7, 1 GHz, 4 Cores) | 0.525 | 0.615 [0.955] | 0.41 [0.875] | 85 [154] | Minimum power consumption (on 600MHz): 1.02, 1.14 (+Eth), 1.33(+WIFI) |
| Orange Pi Zero (Allwinner H2(+), Cortex A7, 1.2 GHz, 4 Cores) | 0.483 | 0.497 [0.757] | 0.33 [0.627] | - | Minimum power consumption (on 240MHz): 0.89, 1.02(+Eth) |
| Raspberry Pi 3 (BCM2837, ARMv8, 1.2 GHz, 4 Cores) | 0.379 | 0.43 [0.496] | 0.295 [0.389] | 75 [130] | Minimum power consumption (on 600MHz and indifferent to enabled WIFI or Bluetooth): 1.14, 1.39(+Eth) |
| HTC Desire 820G (Octa-core, Cortex-A7, 1.7 GHz, 8 Cores) | 0.416 | 0.237 [0.315] | 0.236 [0.342] | - | |
| Asus Nexus7 II (Qualcomm Snapdragon APQ8064-1AA, Cortex-A15, 1.5 GHz, 4 Cores) | 0.497 | 0.161 [0.306] | 0.126 [0.341] | 54 [82] | armv7-a, Soft, VFP. Extra tests. |
| x86 | |||||
| Cyrix Geode(TM) (232 MHz) | 7 [44]* | 11 [52]* | - | ||
| VIA Nehemiah (400 MHz) | 2.9 [5.8] | 2.4 [5.8] | - | ||
| AMD K6-2 (504 MHz, 1008 BogoMIPS, BUS 112 MHz) | 1.136 [4.66] | 1.602 [5.63] | - | ||
| AMD Geode LX800, ICP-DAS LP-8x81 (500 MHz, 1000 BogoMIPS) | 1.04 | 1.27 [1.66] | 2.03 [2.61] | - | |
| VIA Nehemiah (667 MHz) | 2.7 [5.6]* | 2.4 [6.1]* | - | ||
| RDC R3600, ICP-DAS LX-8x31 (1.0 GHz, 2 Cores) | 0.72 (1.52) | 1.14 (2.06) | - | ||
| Intel(R) Atom(TM) CPU Z520, ICP-DAS LP-8x81 Atom (1.33 GHz, 1[2] Cores) | 0.39 (1.14) | 0.53 (1.12) | - | ||
| Intel Atom N270 (1.6 GHz, 1[2] Cores, DDR2-533-1.6GB/s) | 0.217 | 0.306 [0.438] | 0.424 [0.662] | 131 [154] | |
| Intel(R) Celeron(R) CPU 847 (1.1 GHz, 2 Cores) | 0.23 [0.675] | 0.25 [0.76] | 50 [64] | ||
| AMD Phenom(tm) 9600 Quad-Core (2.3 GHz, 4 Cores) | 0.17 [0.45] | 0.14 [0.35] | - | ||
| AMD Athlon 64 3000+ (2 GHz) | 0.15 [0.43] | 0.16 [0.49] | 23 [31] | ||
| AMD Athlon X2 3600+, (2 GHz, 2 Cores) | 0.145 [0.42] | 0.153 [0.46] | 25 [47] | ||
| Intel(R) Celeron(R) CPU N2840 (2.16GHz, 2 Cores) | 0.175 [0.389] | 0.165 [0.385] | 33 [60] | ||
| Intel(R) Pentium(R) 4 CPU (3 GHz, 1[2] Cores, DDR-400) | 0.198 | 0.152 [0.206] | 0.157 [0.253] | 45 [77] | |
| Intel(R) Core(TM)2 Duo CPU T5470 (1.6 GHz, 2 Cores) | 0.179 | 0.143 [0.18] | 0.129 [0.197] | 27.6 [54] | |
| AMD Turion L625 (1.6GHz, 2 Cores, DDR2-555-1.8GB/s) | 0.096 | 0.125 [0.251] | 0.096 [0.219] | 28 [50] | |
| Intel(R) Core(TM) i3-3217U CPU (1.8 GHz, 2[4] Cores) | 0.105 [0.277] | 0.148 [0.305] | 21 [26] | ||
| Intel(R) Core(TM) i3 CPU U 380 (1.33 GHz, 2[4] Cores, DDR3-1333-4.8GB/s) | 0.104 [0.257] | 0.0985 [0.244] | 36 [52] | ||
| Intel(R) Xeon(R) CPU E5-2603 (1.8 GHz, 4 Cores) | 0.074 [0.178] | 0.068 [0.173] | - | ||
| AMD Phenom(tm) II X4 900e (2.4 GHz, 4 Cores, DDR2-800) | 0.067 | 0.099 [0.1] | 0.0567 [0.126] | 17 [32] | |
| Intel(R) Core(TM) i5-3610ME CPU (2.7 GHz, 2[4] Cores) | 0.05 [0.132] | 0.0376 [0.122] | - | ||
| AMD A8-6500 APU (3.5 GHz, 4 Cores, DDR3-1866-5.8GB/s) | 0.0581 | 0.0425 [0.0572] | 0.028 [0.0442] | 14 [24] | |
| Intel(R) Core(TM) i7-5600U (2.6->3.2 GHz, 2[4] Cores, DDR3-1600-15GB/s) | 0.0445 | 0.0288 [0.0326] | 0.0266 [0.0306] | 13.6 [20.5] | |
| Intel(R) Core(TM) i3-4330 CPU (3.5 GHz, 2[4] Cores) | 0.03 [0.08] | 0.023 [0.073] | - | ||
** — Enter to procedure on the language JavaLikeCalc means also enter to the critical section and request to read of the RW lock then the time mostly show performance of the operation. The time was excluded from related values into columns with JavaLikeCalc.
The difference in computation time for direct call of the mathematical operation and from the JavaLikeCalc virtual machine is connected with the influence of CPU core frequency (the frequency at which it operates) and who made the part of the command before the transfer of it to math co-processor and with the memory speed. Performance of the math co-processor is usually not directly connected with performance and frequency of the processor core or memory speed.The measure methodology into the table above provides next:
- Time estimation for operation generic lock of the critical section, "sin(Pi)" and "pow(Pi,2)", into second, third and forth columns. sin() and pow() operations selected to represent of estimation the co-processor performance and for overall real-numbers manipulations. Value into square brackets characterizes overhead charges on calculations into the virtual machine of OpenSCADA and performance for integer-numbers calculations about the exemplary operations. I.e. the main value characterizes performance of the processor into the float-point operations (mathematical co-processor or emulation), and into square brackets is the into the integer-operations (central processor), as subtraction of the real-numbers operations. The measure method:
- ensure the central processor frequency stability, in way of setting the policy of its management to PERFORMANCE;
- start OpenSCADA without load, the project by default or with an empty configuration, and within configurator UI.QTCfg, UI.WebCfg or UI.WebCfgD;
- open the function's object "sin()", and next "pow()", by the module of mathematical functions library;
- go to tab "Execute", set "Enable", enter the argument's value for "X" to 3.14159 and "Power" to 2 (for "pow()"), set number of executions to 1000 (to the representativeness rise you can increase the number, by degrees, to overall the operation execution time not more 10 seconds);
- press "Execute" and get the execution time;
- perform the execution into several tries, pressing "Execute", and achieve to minimal value;
- fix the minimal value, which divide to 1000 (number of the executions) and get the main time value of the single execution into microseconds;
- go to the module object of (internal executions OpenSCADA (DAQ.JavaLikeCalc);
- create here an object of library of functions "test", and into it a new function "test", turn it on;
- into the tab "Program" enter the commands text zero, "y=sin(3.14159)", and next "y=pow(3.14159, 2)";
- go to tab "Execute" and do the same things into the list items "d."-"g.";
- the execution result consider for column two and as auxiliary, into the square brackets, for column three and four after them extraction from the column two.
- Complex performance estimation, into fifth column, performs by execution the technological process (TP) model AGLKS on target architecture. The test can be executed only on computing systems with relatively high performance (or with more to one core), which capable for the model execute, and equipped by a graphical information output device (display), the visualization server execution case we will not consider. The main value of the processor loading characterizes only the dynamical model of TP execution, but addition value appends of forming and execution the graphical interface. The measure method:
- ensure the central processor frequency stability, by way set the policy of the management to PERFORMANCE;
- from desktop environment menu start the model AGLKS;
- start a terminal emulator (e.g., "konsole"), where type "top", press Shift+H (for see the process at all) and Shift+P (sort by the processor load);
- read the values in the column "%CPU" against to the process "openscada", select to typical value for several updates and fix it as main value;
- return to the window OpenSCADA and start the visualization environment, and next the project "AGLKS" interface.
- return to the terminal emulator and read addition value, like to the list item "d.".
The results you would send to
electronic mail address for appending to the table!Appendix 2. Performance measurement for storage (built-in, HDD, SSD, CF, SD, ...)
This section contains information about performance of different storage, from and on with worked and working OpenSCADA solutions.| Hardware | Real size, GB/GiB | Read/Write, MB/s | Notes |
| SSD | |||
| PATA SSD, Ver2.M0J (Acer Aspire One 110) | 41.2/15.8 | ||
| SSD: GoodRAM Play 32GB 2.5" SATA2, MLC (SSD32G25S2MGYSM2244) | 238/45 | ||
| SSD: GoodRAM C40 60GB 2.5" SATA3, MLC (SSDPR-C40-060) | 498/467 | ||
| SSD: GoodRAM C40 120GB 2.5" SATA3, MLC (SSDPR-C40-120) | 480/330 | for EXT4 | |
| SSD: GoodRAM CX200 120GB 2.5" SATA3, TLC (SSDPR-CX200-120) | 120/111 | 497/118 | fast overheating on write 30+10 °Ñ |
| SSD: GoodRAM IRIDIUM 120GB 2.5" SATA3, MLC (SSDPR-IRID-120) | 120/111 | 499/201 | heating 33+3/11 °Ñ |
| SSD: TOSHIBA THNSNJ512GCSU 512GB 2.5" SATA3, MLC (JULA0101) | 512/477 | 525/517 | heating 32+4/10 °Ñ |
| HDD. Typical environment: Read/Write: raw 50GB by blocks 1MiB, into end of the hard disk | |||
| HDD 3.5": SAMSUNG SP2004C | 200/186 | 39/38.5 | heating 27+11/13.5/15°Ñ |
| HDD 3.5": TOSHIBA DT01ACA050 | 85.4/84.4 | +18°Ñ | |
| HDD 3.5": WDC WD15EARX-00PASB0 | 43/45.5 | +11°Ñ | |
| HDD 3.5": WDC WD10EZRX-00D8PB0 | 1000/931 | 77.7/77.5 | +9°Ñ, noisely seek |
| HDD 3.5": Seagate ST1000VM002-1ET1 | 1000/931 | 87.1/86.9 | heating 27+7/9/10 °Ñ |
| HDD 2.5": WDC WD5000LPVX-22V0TT0 | 497/463 | 62.1/61.7 | heating 33+5/9/11 °Ñ |
| Internal device's flash | |||
| Flash: ICP_DAS LP-8x81 Internal 4GB | 8/4 | ||
| Card flash (CF) | |||
| CF: ICP_DAS LP-8x81 8GB, MLC | 27/(19...15) | ||
| CF: ICP_DAS LP-8x81 8GB, MLC-N-233x | 44/12.5 | ||
| CF: ICP_DAS LP-8x81 8GB, pSLC | 47/44 | ||
| Flash Disk IDE44: Kontron chipDISK/1000-IDE | 3/5.7 | ||
| SD, MiniSD, MicroSD, MMC. Typical environment. 30°C, Read/Write: raw 1GB by blocks 1MiB. Card Readers: [ Grand X CRX45 USB 2.0 multicard reader; Realtec USB 2.0 multicard reader; Transcend Multi-Card Reader M3; GoodRam MicroSD USDRSGRBL10; Raspberry Pi2 MicroSD for EXT4 ] | |||
| MicroSD: Transcend 8GB Class 2, 378010 | 7.94/7.40 | [14.6/3.4; 9/3.5; 14.3/3.7; 14.3/3.7] | |
| MicroSD: EMTEC 8GB Class 4 | 7.96/7.41 | [18.0/0.8; 12.3/1.8; 17.2/1.8; 17.0/1.9] | early and apparently overheat and hang in long time on write |
| MicroSD: Kingston 8GB Class 4, SDC4/8GB | 7.74/7.21 | [16.7/0.756; 15.1/1.8; 16.4/1.8; 16.5/1.9] | early and apparently overheat and hang in long time on write |
| MicroSD: Transcend 8GB Class 4, A31213 | 7.94/7.40 | [17.8/4; 18.0/4.1; 18.8/4.2; 17.9/3.0] | |
| MicroSD: Transcend 32GB Class 4, 9161BA | 19.7/6.7 | ||
| MicroSD: Transcend 4GB Class 6, 9153BA | 4.03/3.75 | [15.7/6.7; 15.9/7.6; 18.5/9.3; 17.9/9.5] | |
| SD: Team 8GB Class 10, CT8G02XTVCC1118N | 8.03/7.47 | [16.7/10.3; 14.1/12.2; 18.5/14.0] | |
| MicroSDHC: Toshiba 16GB UHS-1 Class 10, SD-C016UHS1(BL5A) | 15.7/14.6 | [16.2/5.9; 16.7/7.4; 18.4/9.1; 17.6/8.8; 16.9/11.3] | |
| MicroSDHC: Toshiba 16GB UHS-1 Class 10, SD-C016UHS1(6A) | 15.5/14.5 | [14.4/6.7; 17.3/8.1; 18.6/9.9; 17.9/10.0; 19.5/13.0] | |
| MicroSDHC/MicroSDXC: Kingston 16GB UHS-1 Class 10, SDC10G2/16GB | 15.5/14.4 | [18.6/6.0; 16.3/6.7; 18.5/10.5; 18.1/10.1; 17.1/8.6] | |
| MicroSDHC: Transcend 16GB UHS-1 Class 10, C93858 | 15.9/14.8 | [17.2/10.6; 18.6/9.6; 18.5/11.1; 17.7/10.8; 22.5/11.1] | |
| MicroSDHC: SP 32GB, SP032GBSTH010V10 | 31.1/28.9 | [18.1/8.0; 14.8/7.3; 18.7/10.8; 17.9/9.8; 19.4/11.1] | |
| MicroSDHC: SanDisk Ultra 32GB, SDSQUNB-032G-GN3MN | 31.1/28.9 | [17.1/7.0; 14.8/7.5; 18.4/11.0; 18.1/10.4; -] | |
| MicroSDHC: Transcend 32GB UHS-1 Class 10, Premium 400x D24035 | 31.7/29.5 | [17.6/14.7; 17.8/9.6; 18.8/9.9; 17.8/14.1; 22.4/10.5] | |
Appendix 3. PLC solutions
This section contains information about PLC models actually built or planned to be so on the basis of the developed runtime and PLC firmware.| PLC components | Price (DDP), $ | Notes |
| PC/104 | ||
| CPU: Kontron MOPSlcdLX | 430 | AMDGeodeLX800(i686)-500MHz, 0°-60°C, 5W, Video |
| CPU: Diamond ATHM800-256A | 1229 | VIA Mark(i686)-800MHz, 256Mb, -40°-85°C, 10W, Video, 16AI, 4AO, 24DIO |
| CPU: Diamond ATHM800-256N | 842 | VIA Mark(i686)-800MHz, 256Mb, -40°-85°C, 10W, Video |
| CPU: Rhodeus RDS800-LC | 414 | AMDGeodeLX800(i686)-500MHz, -20°-70°C, 5W, Video |
| CPU: Helios HLV800-256AV | 772 | Vortex86DX(i486)-800MHz, 256Mb, -40°-85°C, 5.4W, Video, 16AI, 4AO, 40DIO |
| CPU: Helios HLV800-256DV | 387 | Vortex86DX(i486)-800MHz, 256Mb, -40°-85°C, 4.5W, Video |
| CPU: Tri-M VSX104 | 380 | Vortex86SX(i486sx)-300MHz, 128Mb, -40°-85°C, 2W |
| MEM: DDR-SODIM-256M | 15 | for Kontron MOPSlcdLX |
| Flash Disk: Kontron chipDISK/1000-IDE | 100 | 1Gb, 0°-70°C, read=3MB/s, write=5.7MB/s |
| Flash Disk: M-Systems MD1171-D1024 | 42 | 1Gb, 0°-70°C |
| Flash Disk: M-Systems MD1171-D256 | 22 | 256Mb, 0°-70°C |
| Flash Disk: M-Systems MD1171-D128 | 18 | 128Mb, 0°-70°C |
| Flash Disk: Diamond systems FD-128R-XT | 82 | 128Mb, -40°-85°C |
| Flash Disk: Diamond systems FD-1GR-XT | 168 | 128Mb, -40°-85°C |
| Box: PB-300-K | 108 | |
| Box: PB-EAP-300-K | 250 | |
| Box: CT-4 | 156 | |
| Power unit: MMEANWELL DR-4505 | 30 | |
| IO: DMM-16-AT (16AI, 4AO, 16DIO) | 581 | -40°-85°C |
| IO: DMM-32X-AT (32AI, 4AO, 24DIO) | 689 | -40°-85°C |
| RS485: EMM-OPT4-XT | 396 | -40°-85°C |
| RS232->RS485 | 10 | |
| ICP DAS LP-8x81 | ||
| CPU: LP-8381 | 974 | AMDGeodeLX800(i686)-500MHz, -25°-75°C, 14W, 4GB flash (R/W: 8/4 MB/s), 8GB CF (R/W: 29/19 MB/s), 1GB SRAM, Video, 2xEthernet, 2xUSB, 3-slots, 2xRS-232, 1xRS-485, 1xRS-232/485 |
| CPU: LP-8781 | 1025 | AMDGeodeLX800(i686)-500MHz, -25°-75°C, 16W, 4GB flash (R/W: 8/4 MB/s), 8GB CF (R/W: 29/19 MB/s), 1GB SRAM, Video, 2xEthernet, 2xUSB, 7-slots, 2xRS-232, 1xRS-485, 1xRS-232/485 |
| CPU: LP-8781-Atom | 1438 | IntelAtomZ520-1.3GHz, -25°-75°C, 18W, 8GB flash, 1GB DDR2, Video, 2xEthernet, 4xUSB, 7-slots, 2xRS-232, 1xRS-485, 1xRS-232/485 |
| IO_BOX: I-87K9 | 155 | IO box for 9 modules series I-87k accessible by DCON |
| IO: I-8017HW (8AI DE, 16AI SI) | 230 | Parallel bus, acquisition up to the 30 kHz |
| IO: I-8042W (16DI + 16DO) | 121 | Parallel bus. |
| IO: I-87017ZW (20/10AI) | 209 | Serial bus. Overvoltage support up to 240V. |
| IO: I-87019RW (8AI) | 213 | Serial bus. Additional surge protection, support for thermocouples and resistance thermometers. |
| IO: I-87024W (4AO) | 204 | Serial bus. Output of current and voltage. |
| IO: I-87026PW (6AI, 2AO, 2DI, 2DO) | 215 | Serial bus. Combined module. |
| IO: I-87040W (32DI) | 121 | Serial bus. Isolated. |
| IO: I-87041W (32DO) | 109 | Serial bus. Isolated. Watchdog function for communication. |
| IO: I-87057W (16DO) | 82 | Serial bus. Watchdog function for communication. |
| Segnetics SMH 2Gi | ||
| CPU: SMH 2Gi-0020-31-2 | 335 | ARM9-200MHz, LCD-display, 1xRS-485, 1xRS-232, 2xUSB, 1xEthernet, 3DO |
| IO: MC-0402-01-0 (8AI, 4AO, 9DI, 10DO) | 176 | Single MC RS-485 serial bus. |
| IO: MR-120-00 (12DI[opt]) | 92 | Multiple MR RS-485 serial bus. |
| IO: MR-800-00 (8DO[rel]) | 103 | Multiple MR RS-485 serial bus. |
| IO: MR-810-00 (8DI[opt,~]) | 82 | Multiple MR RS-485 serial bus. |
| IO: MR-061-00 (6DO[sim,opt]) | 84 | Multiple MR RS-485 serial bus. |
| IO: MR-602-00 (6DO[rel], 2AO[opt]) | 120 | Multiple MR RS-485 serial bus. |
| IO: MR-504-00 (5DO[rel], 4AO[opt]) | 120 | Multiple MR RS-485 serial bus. |
Links
- Materials for the firmware creation for x86 platform and other PLC: ftp://ftp.oscada.org/OpenSCADA/PLC/
- The notice on loader errors (propagator): https://bugzilla.altlinux.org/show_bug.cgi?id=17416
- Materials for the program environment and the firmware creation for different ARM devices: TionPro270, SMH2Gi