OpenSCADA into programmable logic controller (PLC)
| Name: PLC Start: October 2008 Version: 1.0.0 Status: GPL Members: Roman Savochenko Translator: Maxim Lysenko Description: The project is devoted to the creation of: runtime if the PLC, the PLC firmware and hardware configurations of the specialized PLC's. Considered embedded systems based on architectures x86 and ARM, and also separated hardware of 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 PCS contains the field equipment (sensors and actuators), as well as programmable logic controllers (PLC). The upper level consists of the system of operational visualization and monitoring of the process — SCADA system. PLC is the responsible part of the APCS, which performs the function of the data acquisition from the field equipment, calculation and making the regulatory, blocking and other effects on the regulating parts of field equipment.Open SCADA is an open implementation of the SCADA system, which is based on the modular architecture that allows to build the ultimate solutions for different requirements. The purpose of Open SCADA are the systems of upper level, but the high degree of modularity and scalability allows to solve the wide range of tasks of the adjacent areas.
Industrial 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.
Hard-programmable PLC are typically based on single-crystal microcomputer or chips of programmable logic. The program of such controllers is flashed one-time, enabling the software of parameterization, or formed with the 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-fledged 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 is not the group of the PLC directly compatible with PC, but the PLC which don't have the integrated runtime and which are often delivered without an operating system. Architecture of the such PLC may be different, ranging from cost-effective solutions and ending with the x86 architecture decisions ARM and MIPS. The runtime 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, Win CE, Vx Works). 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 constructive execution of the PLC can be divided into monoblock and modular. Monoblock 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 monoblock, able to expand its CPI by external CPI blocks connected to one of the standard interfaces such as RS-485.
Open SCADA as runtime of the PLC
System architecture of the Open SCADA allows you to create the final decisions under various requirements and resources through the modular expansion. 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, Open SCADA can consistently extend the functionality of the PLC, while maintaining the continuity with the old solutions. For example, on the basis of the Open SCADA 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 runtime based on unified PC-platforms.
Open SCADA allows the realization of the idea of creating an open platform for the implementation of the runtime of PLC. Already you can make the PLC's runtime slightly inferior to the commercial intellectual controllers, and in many respects superior to them, due to the possibility of integration of functions specific to SCADA systems into the runtime 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.
Here are the functions which are solved by Open SCADA within the runtime 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;
- archiving data, beginning from the temporary buffer in memory and ending with full-fledged 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 (Mod Bus, 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 for architecture x86
The following requirements were pulled out to the implementation of the PLC firmware:
- Compactness. In connection with the direct dependence of prices on industrial flash drives with their volume, as well as the reality of the need for frequent updates, the image of the firmware need to be packed, reaching the level of compactness up to the 8-50MB at runtime PLC in the full-fledged 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 repository of OS package. This will allow for a long time to form renewals and expansions, not maintaining the mediated repository.
- Debugged and simple building procedure. Given the fact that the configuration of 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 recording 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 database 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 journaled file system and ensure that its verification and automatic correction of errors.
- Conditional division of the PLC configuration into two types:
- PLC without the local display, possibly with a simple text display.
- Touch-panels with the PLC function.
Tools and work environments building
Given the above requirements, for the creation of the firmware it was chosen the package's repository of the distributive of OS Linux ALTLinux and the tool for creating the distributions mkimage. mkimage is the tool for building Sisyphus-based system on the basis of the template. As an initial set of templates it was used 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.
Creation
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 "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 features 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 is embedded in the template "plc" on the way: profiles/pls/image-scripts.d/01system. The list of packages is embedded in the template "plc" on the way: 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/ of the type:
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 pass some dialogues.
The file system can be fat or ext2/ext3. In the case of ext3 the root is mounted as in ext2, again because of problems in the initializer. In the case of ext2/ext3 you'll need to use not the syslinux boot, but extlinux, the configuration of which, incidentally, 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/ext3 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 file is created as follows:
In the case of the file system ext2/ext3 on the target disk the "work" file may not be created. In this case, the working data will be placed in the directory root of the target disk. Warning. 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, since it needs to be set, and this is done for different file systems in different ways.
For the file systems ext2/ext3 it is done by the utility e2label. For example: "e2label /dev/sdb1 PLC"
For the FAT file system it is done by the set of utilities that come with mtools as follows:
Now we can initialize the loader:
That is all with the boot and initialization of firmware. If the resulting disc 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 rangeû in strange way the partitions that do not allow them to boot on USB-flash. It is necessary to rescribe 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 stated requirements and it provides:
- Loading for 27 seconds from the 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 "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.
- Time synchronization via ntp.
- OpenSCADA execution with the available network interfaces:
- configuration via Web (10002,10004);
- runtime on the Web (10002,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 dependences 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:
- DBF
- MySQL
- SQLite
- Archiving:
- on the file system
- on the DB
- Data source:
- calculator of the functional blocks
- calculator on the Java-like language of high-level
- controllers of the logic level
- various PLC's on the protocol ModBus (RTU,ASCII,TCP)
- OS data
- remote OpenSCADA stations data
- Transport:
- serial interfaces;
- TCP, UDP and UNIX sockets;
- security socket layer.
- Transport protocols:
- HTTP
- self control protocol of OpenSCADA
- User Interface:
- visual control area engine (VCA);
- Web-based visualizer of VCA;
- Web-based configurator of OpenSCADA.
The current configuration of OpenSCADA runs in demon mode in locale uk_UA.UTF-8 using the local database SQLite, providing the following default network services:
- configuration through the Web (10002,10004);
- runtime through the Web (10002,10004);
- control interface of OpenSCADA (10005).
Implementation details
In this section we'll 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 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 reduce the initialization image size was reduced to the following one:
To the script of tree preparation there were added the following functions:
- change the name of the distribution kit;
- displace the init script to inittab.plc;
- creating the user-admin "admin" and passwords setup by default "123456" for users "root" and "admin";
- initialization of the /etc/fstab;
- setting locale to uk_UA.UTF-8;
- network configuration;
- clock set;
- starting of the necessary services;
- removing of the documentation, help pages and information, icons, RPM-database and apt cache;
- removing of the not needed locales and translations by en_US, ru_RU and uk_UA;
- the code to select only used kernel modules and to delete all the others is added; it is disabled by default and can be enabled to prepare 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.
Initialization script (rc.sysinit.plc) was provided with the following functions:
- remounting the root partition to the RW mode;
- check and connection of the file system (/image/root) of the working user data (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 action the mount table of the resulting PLC tree looks like:
Customizing 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:
iROBO-3000a
iROBO-3000a is a fanless industrial computer with Intel Atom D425 1.8 GHz ñ 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°Ñ. 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 ALTLinux6-OpenSCADA_0.7.2-i586-plcUI_TDE-generic.flash.tar.
Flash and the 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 routine 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) (RUS) 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.
Feature of the ARM architecture is the lack of a compulsory 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 use computing functions of OpenSCADA and other related libraries and software the performance of floating point calculations is very important. Feature of the ARM architecture processor 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 obsolete and met as a hardware implementation in the ARM cores up to the StrongARM family (ARMv4). XScale ARM core families (ARMv5TE) did not have math coprocessor. 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 the table below:
| Equipment | Operation sin(Pi) [in JavaLikeCalc], microseconds | Operation pow(Pi,2) [in JavaLikeCalc], microseconds |
| ARM | ||
| ICP DAS LP-5141 (PXA270, FPA) | 100 [200] | 51 [152] |
| ZAO ZEO TionPro270 (PXA270, SoftVFP, uCLibc-0.9.32.1, -Os) | 22 [51] | 14 [41] |
| ZAO ZEO TionPro270 (PXA270, SoftVFP, GLibC-2.14.1, -O2) | 15 [33] | 12 [31] |
| Segnetics SMH2Gi (ARM926EJ-S, SoftVFP) | 23 [44] | 12 [31] |
| Nokia N800 (400 MHz) | 6 [15] | 6 [17] |
| Nokia N900 (1ÃÃö), N950 (1GHz) | 3 [6] | 2 [6] |
| x86 | ||
| AMD Geode LX800 (500 MHz) | 3 [7] | 4 [9] |
| AMD Athlon X2 3600+ | 3 [3] | 3 [3] |
| AMD Turion L625 1.6 | 3 [4] | 3 [4] |
| Intel Core2 Duo 1.6 | 2 [2] | 2 [3] |
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 the math coprocessor. The performance of math coprocessor is usually not directly connected with the performance and frequency of the processor core.
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 filesystem 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 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 exists.
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 its 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 with more details using 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 the 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 pre-installed 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 the flash memory it was used the ready boot buildings UBoot-1.3.3 (file if the image u-boot-1.3.3_svn886_520mhz_tion_pro270_64m.bin) and the kernel Linux-2.6.22.19. JFFS2 RFS filesystem image was built with the help of "BuildRoot" and "PTXDist", see below.
Flashing the equipment with the help of "OpenOCD" was made from the root by the following command:
The "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.
The received 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, the 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 up successfully with some problems that have been eliminated.
The following list describes the 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 iscreated 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: build succeeds, with some solved problems when starting the OpenSCADA:
(+) The 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 the single thread in the RW-lock functions - the interblocking is fixed in the OpenSCADA.UI.WebVision module, and the function of sessions' check is moved to the service call procedure.
RFS build in the PTXDist
Learning the PTXDist for the building the 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. The result 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 if of 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".
It was created PTXDist "OSELAS.BSP-Pengutronix-Generic" project's clone in the in the directory "TionPro270_RootFS" with the configuration platform "arm-qemu-2011.01.0". To build OpenSCADA the following configuration 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 the the jffs2 image of FS was received. The resulting RFS was successfully loaded onto the board and started. OpenSCADA started up and work correctly as well.
Adaptation
This board contains a number of hardware interfaces interesting for the adaptation for OpenSCADA, so this section will be focused on 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 install 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, the echo package should be dropped and then you should waiting for the direct response.
To solve this problem the OpenSCADA module Transport.Serial has been finalized for this kind of hardware flow control support.
Using this extension, validation was made and the presence of LP-5141 controller's software environment problem was confirmed.
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 build 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:
ftp://ftp.oscada.org/OpenSCADA/PLC/Segnetics-SMH2Gi
Panel controller is supplied by the equipment manufacturer with pre-installed 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 preserve 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.
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" Then OpenSCADA was built the following way:
As a result, the archive of the the OpenSCADA build was formed, which can be loaded to the the panel PC SMH2Gi and unpacked there. The resulting OpenSCADA software environment is configured to start automatically when you start the controller through an init script "/etc/init.d/openscada". OpenSCADA build 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.
PLC solutions
This section contains information about the PLC models actually built or planned to be so on the basis of the developed runtime and PLC firmware.
| PLC components | Price, $ | Notes |
| CPU: Kontron MOPSlcdLX | 430 | AMDGeodeLX800(i686)-500ÌÃö, 0°-60°C, 5Âò, Video |
| CPU: Diamond ATHM500-256A | 1275(1160) | VIA Mark(i686)-500MHz, 256Mb, -40°-85°C, 10W, Video, 16AI, 4AO, 24DIO |
| CPU: Diamond ATHM500-256N | 889(807) | VIA Mark(i686)-500MHz, 256Mb, -40°-85°C, 10W, Video |
| CPU: Rhodeus | ? | AMDGeodeLX800(i686)-500MHz, -20°-70°C, 5W, Video |
| CPU: Tri-M VSX104 | 380 | Vortex x86SX(i486sx)-300MHz, 128Mb, -40°-85°C, 2W, not tested |
| MEM: DDR-SODIM-256M | 15 | for Kontron MOPSlcdLX |
| Flash Disk: Kontron chipDISK/1000-IDE | 100 | 1Gb, 0°-70°C |
| 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-128-XT | ? | 128Mb, -40°-85°C |
| Flash Disk: Diamond systems FD-1G-XT | ? | 128Mb, -40°-85°C |
| Box: PB-300-K | 118(96) | |
| Box: PB-EAP-300-K | 275(248) | |
| Box: CT-4 | 171(162) | |
| Power unit: MMEANWELL DR-4505 | 30 | |
| IO: DMM-16-AT (16AI, 4AO, 16DIO) | 744(597) | -40°-85°C |
| IO: DMM-32X-AT (32AI, 4AO, 24DIO) | 883(742) | -40°-85°C |
| RS485: EMM-OPT4-XT | 396(376) | -40°-85°C |
| ICP DAS LP-8x81 | ||
| CPU: LP-8781 | 945 | |
| IO: I-8017HW (8AI DE, 16AI SI) | 215 | Parallel bus, acquisition up to the 30 kHz |
| IO: I-87019RW (8AI) | 205 | Additional surge protection, support for thermocouples and resistance thermometers. |
| IO: I-87024W (4AO) | 210 | Output of current and voltage. |
| IO: I-8042W (16DI + 16DO) | 125 | Parallel bus |
Links
- Materials for the firmware creation for x86: 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