EnglishУкраїнськаРocсийский
Login/New
01.02.2012 17:41 Age: 6 yrs

By: Roman Savochenko

OpenSCADA into programmable logic controller (PLC)

Name: PLC

Founded: October 2008

Version: 1.0.0

Status: GPL

Members: Roman Savochenko

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:

  • Diamond Systems: ATH400-128;
  • Kontron: MOPSlcdLX;
  • «A-TEX» Ltd: iROBO-Fanless;
  • ICP DAS: LP-8781;
  • ZAO ZEO: Tion-Pro270;
  • Segnetics: SMH2Gi.

Materials: ftp://ftp.oscada.org/OpenSCADA/PLC


Single Board PC/104 Computer

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.

OpenSCADA 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 OpenSCADA 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.

1. 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, 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 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.

2. OpenSCADA as runtime of the PLC

System architecture of the OpenSCADA 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, 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 runtime based on unified PC-platforms.

OpenSCADA 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 OpenSCADA 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 (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.

3. 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.

3.1. 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:

git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop

As the basis it was taken the "rescue" template, as the most compact and close to the target PLC.

3.1.1. 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).

3.1.2. 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).

3.2. 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.

4. 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:

# LP-5141

$ cat /proc/mtd

dev: size erasesize name

mtd0: 00040000 00020000 "Bootloader"

mtd1: 00040000 00020000 "Bootloader Param"

mtd2: 00280000 00080000 "Kernel"

mtd3: 03c80000 00080000 "JFFS2 Filesystem"

# TionPro270

$ cat /proc/mtd

dev: size erasesize name

mtd0: 00080000 00040000 "Bootloader"

mtd1: 00400000 00040000 "Kernel"

mtd2: 01b80000 00040000 "Filesystem"

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.

4.1. 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.

4.1.1. 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.

4.1.2. 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: www.pengutronix.de/oselas/toolchain/index_en.html.

4.2. 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.

4.3. 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.

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.


1659