Why such a headline? Spoiler alert: original version of this blog was written in Slovak language. And unlike English, a term for raspberry pie (“malinový koláč”) has no visible connection to a Raspberry PI.
D2000 and Linux
Currently, a new version of the D2000 is to be released and it will run also on Linux. As in the past with OpenVMS and HP-UX platforms, D2000 server processes were ported on Linux. And, as in the past, it is a 64-bit D2000, capable of handling data-extensive and performance-critical applications.
However, we and our OEM partners also deploy D2000 in smaller applications - ranging from hundreds to thousands of tags, one or two human interfaces (HIs), a few communications. Examples are various operator’s centers of heat exchange and distribution, emission monitoring, PMToolkit applications, production monitoring SCADAs. Relatively low-cost applications, which are often installed on regular workstations and other commodity hardware.
D2000 and a compiler
As you may know from previous blog "Choosing a programming language for realtime systems", D2000 is written in Ada languaged and compiled using the GNAT compiler from AdaCore, which strictly implements the Ada standard according to ISO/IEC 8652:2012 and thus supports high portability between platforms.
In 2015 the GNAT GPL 2015 compiler was released also for the Raspberry PI2 platform. A year later, the compiler was updated as GNAT GPL 2016.
What is a Raspberry PI? A single-board computer being produced since 2013 - the third generation of PI3 is currently in the market. The basic version costs about $ 35, has 1 GB of RAM, a Broadcom BCM2837 quad-core processor clocked at 1.2GHz (ARM7 architecture). It supports operating system Raspbian (Debian based Linux distribution) or multiple alternatives.
So - inspired by one of our OEM partners - we began to investigate whether Raspberry PI could be used as a communications computer.
Use case? Small Raspberry PI located somewhere in a plant, communicating with local devices - via LAN, serial RS-232 or RS-485 or via its digital/analog inputs/outputs. Upwardly communicating with the D2000 Server - via LAN, WiFi or a mobile network. In case of loss of connectivity, the KOM archive feature would be used to allow the KOM process to start and run standalone, and to store the values obtained from the communication into a file buffer. Once the communication is restored, the data can be sent automatically or at operator’s command to the D2000 Server process, so in such an architecture, a loss of network connectivity to D2000 Server does not mean data loss.
In addition to Raspberry PI's basic configuration, there are companies that supply various industrial versions - DIN-mounted, containing various inputs and outputs (analog, digital, relay), real time clock modulesor GSM/GPRS/3G cards. An example is IonoPi or NPE X500 (a web configurator enables to configure various peripherals including CAN bus, RS232/485 interfaces, ZigBee, and mobile networks). Of course, such industrial versions with peripherals no longer cost $ 35, but about € 200 and above. Also Moxa manufactures the UC-8100 industrial ARM running Debian Linux operating system, for which the D2000 KOM could be compiled.
D2000 and a PI
So we installed a compiler (it is a cross-platform compiler running on x64 Linux and generating binaries for ARM architecture) and after a few days and overcoming the minor problems we had a compiled and functional KOM process running on Raspberry PI (at the time, we had an older PI2 available). The most serious problems were with Ada runtime of GNAT GPL 2016 which did not have an atomic operations library implemented on ARM platform, so we had to emulate it.
Subsequently, we launched KOM against an application server with an application that had over 7,000 input and output points (I/O tags).
As we did not have the chance to run real communication, we tried at least the replay mode in which KOM replayed the values recorded and stored in the files.
The entire KOM process with a configuration of more than 7,000 I/O tags and replaying tens of values per second consumed according to the utility “top” approx. 200 MB of RAM and about 10% of CPU performance (the utility “top” considers 100% to be a full load of one core, so values above 100% can be displayed and maximum available performance is 400% for PI3 quad-core).
Which communication protocols are available? Basically, all those which use for communication the serial line, TCP/IP or UDP protocols or eventually, communication over files. So Modbus, M-Bus, IEC101, IEC104, ICCP/TASE2, OPC UA, BACnet ...
Of course protocols that use Windows technology (OPC, DDE ..) and protocols requiring libraries from manufacturers (LonTalk, AMiT ATOUCH32 DB-Net, L & G PROFIBUS ..) are not available on Raspberry PI. A list of all protocols implemented in D2000 and on which platforms are available is provided in the documentation.
As a second step, we tried to compile also other D2000 server processes and install them on older PI2 and latest PI3 (on 16GB or 8GB SD memory cards). We used PostgreSQL for the configuration and monitoring databases (although D2000 also supports starting fromXML files in a static configuration of application).
Both Raspberry were connected into redundancy group and running approximately 5000-tag application TLFC (a copy of load & frequency terminal).
Then we connected a 320GB 2.5 "external hard drive via a USB to the Raspberry PI3 , moved the configuration and monitoring databases to it, created an archive database, and started the archive. So PI3 served as a complete application and archive server. By the way, when the kernel initialized the values of all objects from the replay file, the archive was able to process several hundreds of values per second!
This is the second scenario of using Raspberry PI - as a full-featured D2000 application server, optionally in redundant configuration - with redundant servers and redundant archives to eliminate the risk of failure of one of the machines.
Standard user processes (human interface HI, configurator CNF and graphic editor GR) can be connected to this application server from Windows - using 32 or 64-bit binaries. The D2000 internal communication protocol enables client processes to connect to the D2000 server regardless of the client and server platform.
D2000 and a thin client
Let's move on. Can Raspberry PI handle even more than running a D2000 application server? On a more powerful PI3, we installed Java (in order to avoid a possible licensing problems, we used OpenJDK instead of Oracle Java) and the WildFly web server. We configured the processes necessary for the thin client (tcts, tdldeployer) and were able to display the schemas on a PC in a browser (without any modifications of the schemas).
The window has a suboptimally small size for the sake of making a screenshot.
Raspberry as an .. operator station?
On the older Raspberry PI2, we stopped the D2000 server as well as PostgreSQL database server and installed the "Raspberry Pi Desktop" and Chromium browser. After this installation, approximately 2.4 GB were used on the SD card (including about 200 MB of D2000 files and 100 MB of database files). Subsequently, we started the web browser on this Raspberry and connected it to the PI3 web server.
Thus we created the configuration of a single application server with a web server (PI3) to which a client computer with a web browser (PI2) representing operator station is connected.
Raspberry - are we ecological and economical?
Today's electricity consumption significantly contributes to server operating costs. So how is it with our server? We measured the voltage and current from the USB charger via the KEWEISI USB module. More powerful Raspberry PI3 with attached external drive has a typical consumption of around 0.5-0.6 A, peak (especially when the hard drive is under load) is about 0.8 A. This is another advantage of energy-saving ARM processors.
Raspberry - performance
In the previous paragraphs we have already mentioned the 10% CPU load when replaying the values of a KOM process. But what is the performance, for example, compared to a PC? We tried a simple synthetic test in which we measured the duration of a hundred thousand of cycles in which the local variable is set. It took Raspberry PI3 about 5 seconds. On a ten year old PC (Intel Core 2 Q6600 2.4 GHz processor) this test took about 3.1 seconds. And the current PC (Intel I7 860 2.8 GHz processor) handled it in about 0.6 seconds.
So Raspberry PI will not be sufficient for applications which demand more memory (number of tags, clients, processes) or performance (scripts written in ESL or Java, more demanding and more voluminous communications) due to RAM and CPU limitations.
Raspberry - security
Raspberry PI is not affected by Spectre and Meltdown vulnerabilities, as the ARM1176, Cortex-A7, and Cortex-A53 kernels used in respective generations of PI processors do not use speculative execution of instructions to improve performance(only speculative loading of instructions into the cache).
And, of course, with no management processor, it does not suffer from the recently revealed vulnerabilities affecting Intel Management Engine, Server Platform Services and Trusted Execution Engine.
Another bonus is a lack of viruses and malware for this platform (with the exception of the malware mining the cryptocurrency Monero exploiting default name and password of a Raspbian OS).
Although this is a conclusion of this blog, it is in no way the end of our work with Raspberry PI. On the contrary - this blog can be seen as a first information that such a thing is possible - to pack the D2000 application server into a small, cheap and energy-efficient ARM computer.
Whether this solution wil be used by us or by our OEM partners as a remote communication server, an application server (optionally redundant) implementing a small SCADA system or protocol converter, or even a web server for thin clients - or perhaps as a cheap and simple operator station - this technology will find its place in today's automation industry talking about IoT and Industry 4.0.
Unlike other solutions, the D2000 delivers stability and performance of technology developed and optimized for 25 years - along with dozens of communication protocols, redundancy and other features. Of course - this solution is only usable for small SCADA systems. Several communications, several hundred tags, several users. But if your SCADA continues to grow over time and some day exceedsthe hardware capabilities of a small Raspberry PI, it can grow further - it can be migrated to the x64 architecture and take a full advantage of this platform’s performance. Whether using Linux or Windows operating system - it’s upto our customers.
Between writing this blog and publishing it, colleagues from Inseko showed an interest in the Raspberry PI platform. They consider the possibility to use it as a thin client of PM Toolkit. In this configuration, they would use a Chromium desktop environment running in a "kiosk" mode, which can not be turned off or switched to another application. In the background, the running KOM process would communicate with a USB barcode reader (we tested the LS2208 from Symbol Technologies using Generic User Protocol).