Internet of Things (IoT) consultant Christofer Dutz has been hard at work building open-source protocol adapters to secure IoT communications with industrial PLCs (Programmable Logic Controllers) — the computers at the heart of industrial automation applications since the 1970s.
As Dutz — who has been heavily involved in several Apache Software Foundation projects since 2012 — including Apache MyNewt (a lightweight operating system for IoT devices) and Apache PLC4X (a set of libraries for communicating with PLCs using a shared API) — admits, the task is not straightforward.
In this blog, he assesses the challenges of selecting hardware for the task of porting Apache PLC4X drivers to the C language, then creating a MyNewt integration to secure comms with industrial PLCs.
The challenge might seem arcane, but the problem is a very real world one: securing connections to industrial hardware.
Selecting the Right Hardware
With Apache PLC4X we are currently able to access almost any industrial PLC from the Java world, writes Christofer Dutz. This is great, but we do know that there is a world outside of the Java ecosystem. Especially when it comes to embedded development, Java won’t get you far.
We didn’t intend to only provide drivers for Java in PLC4X. Otherwise we would have named the project PLC4J.
After securing funding from NLNet — a charity giving developers the chance to help improve the internet by making it safer, faster, more robust — I have been working further on securing communication with inherently insecure PLCs, using embedded open source protocol adapters.
“Not Built with Security in Mind”
Unfortunately these devices were not built with security in mind. In the 90s the only situation in which someone would have thought of connecting industrial hardware over something like the internet was probably part of a nightmare.
Unfortunately, with all the Industry 4.0 initiatives, this is actually what’s happening today.
I whole-heartedly believe that we can do really great things by using all of our open-source IT knowledge and fantastic solutions to help revolutionize the production industry, but we have to do it in a safe way.
So how can you secure a network device that has nothing to protect itself against attacks from hostile networks? You simply don’t connect it – not directly. Of course you could connect the device via some sort of gateway, but what if that or the network behind it is compromised?
A lot of the gateways out there are closed-source solutions provided by vendors I wouldn’t vouch for. And even if they were based on open-source Linux editions, no one will guarantee all patches are installed and everything is configured correctly.
My Proposed Solution
My proposed solution is to port Apache PLC4X drivers to native C and build a gateway based 100 percent on open source.
This gateway will be running on Apache MyNewt, Apache’s first RTOS built for systems too small to run Linux. On the PLC side we will be using Ethernet connectivity (possibly also serial communication in the future) to exchange data with the PLC and use a secured communication protocol on the other side. This other side however doesn’t have to be another Ethernet connection, but could also be WiFi, Bluetooth (LE) or even LoRaWAN depending on the usage scenario.
Getting an Overview of the Available IoT Hardware
Although I have been interested in the hardware side of IoT for quite some time, I haven’t had the chance to dig deeply into this ecosystem. Raspberry Pis and Arduinos were about as deep as I got, which is only scratching the surface. For this project I needed to dive a lot deeper. So in order to decide which chips and setups I should aim for, I started with the list of devices directly supported by Apache MyNewt.
MCUs + Hardware
The first thing I learnt about MCUs (Micro Controller Units) is: you can’t just buy a MCU and start writing code for it. In order to get code onto your device, to run it on your device and potentially even to debug it, you need additional hardware.
So in order to develop applications for MCUs, you usually start by using a development board. These contain all the electronics for adjusting and supplying the right power (voltages) for the MCU, providing the means to upload your programs onto the MCU and to debugging as well as adding additional peripherals. Also, they make some of the MCU connectors available via sockets, which simplify prototyping greatly (You don’t want to hand-solder cables to the tiny connectors of your MCU directly, trust me). These boards are called development boards.
And this is where it starts getting complicated because every development board is different. They differ in how they are powered, how the MCU pins are made available, what peripherals are included on the board and generally what the focus is. Unfortunately there was no list or comparison table making it possible to compare the features and capabilities of each Apache MyNewt-supported development board.
“The First Task…”
So this was my first task: Go through the list of generally supported development boards and to compile a table making it possible to compare devices with each other. For this I had to track down the specs of every device and the number of columns in my table kept on growing.
In the end I had a list with 49 columns and 62 rows. I think this is the first time such a comparison table has been created and I’m currently working on my first contribution to the Apache MyNewt project by integrating this information into their website. (Until it’s available there, this list is currently live as part of the Apache PLC4X Wiki).
I did feel a little like I imagine Daniel (Karate Kid) must have felt, when he was painting Mr. Miyagi’s fence. But as Daniel, I learnt a lot while doing it. While being a little overwhelmed by all of the available devices, I started to understand a lot of things.
In general there seem to be two major types of MCUs. While there is a large number of devices, these two seem to be used all over the place:
- STMicroelectronics’ STM32 processors
- Nordic’s nRF chips
While STM32 chips in that list show a range of 16MHz – 216 MHz, the Nordic units operate in a more limited area from 16 MHz – 64 MHz. However, while all of these nRF units are listed as Ultra-Low-Power units, only the STM32(L) units are considered in this category.
10 Years, 1 Battery…
To give you an impression on what Ultra-Low-Power means: The ruuvi tag Bluetooth LE environmental sensor, which is powered by a Nordic nRF52832 chip, is specified to run up to 10 years with just one cell battery.
Regarding memory, both provide models in the 16 KB – 512 KB range for RAM and 128 KB – 2 MB of flash storage (the bigger STM32 chips tending to provide more storage).
Selecting the Hardware
Right now I have to admit that I have absolutely no idea of how much speed, RAM and flash I will be requiring, so I asked people in the community for any rules of thumb. The MyNewt Kernel is being advertised with having a size of 6KB, which would leave quite some room for extensions, but I know I’ll not only be needing room for my PLC4X drivers, but also for drivers for ethernet connectivity, Bluetooth driver stacks, LoRaWAN support, crypto-libraries, TLS support, gRPC for the secure communication (probably) and perhaps some of the higher-level features of MyNewt.
So in the end I decided to order four different boards with different MCU types and sizes. Luckily the prices for this hardware for embedded development are pretty decent.
As it’s my final goal to develop a new reference board or have a new one developed containing only the essential parts and have it shrunk into a size you can fit into an industry-sized PLC network connector, I’ll try to use components that allow me to do this rather than use too sophisticated solutions. I want to shrink the device this much in order to reduce the length of the insecure network to almost 0.
In the socket to the left, the length of the unsecured network would only be a few centimeters which is probably difficult to intercept.
However, the ordinary Ethernet Gateway is only one of the scenarios I’m going to be working on.
Right now I’m trying to cover the following scenarios:
> Adding industrial hardware that’s on the shopfloor with the ability to connect via an Ethernet cable: Ethernet (Energy consumption doesn’t matter)
> Adding industrial hardware that’s on the shopfloor without the ability to connect an Ethernet cable: WiFi (Energy consumption doesn’t matter)
> Adding industrial hardware that’s on the factory ground without the ability to connect an Ethernet cable or WiFi: Bluetooth Low Energy (Energy consumption might matter)
> Adding industrial hardware that’s off-site: LoRaWAN (Low energy consumption is probably important)
Even if I could probably also have selected other communication forms like Sigfox, 6LoWPAN, ZigBee and alike, I decided to stick to the infrastructure that I generally have available. This is definitely Ethernet, WiFi, BLE and LoRaWAN (I’m running my own TTN Gateway mounted at my chimney).
For the Ethernet connectivity I decided to go for network devices using the W5500 chip. These seem to be well established and tested devices and seem to handle most of the TCP/UDP network stack internally, hereby keeping the load off the MCU. These chips seem to be able to support handling up to 8 simultaneous TCP connections, which should be more than enough for our use cases.
All communication with the MCU is done using an SPI interface.
I intentionally decided not to use any of the available Ethernet shields (Arduino Uno, Nano, Rasperry PI, …) as for scenario 1, I would be needing two of them and I couldn’t find any allowing me to switch the SPI channel or configure an alternate SPI source-select channel (In SPI multiple devices can be connected to the same SPI bus, but each device must have a dedicated source-select connection to the SPI master).
My hope is also that having to support only one type of Ethernet device will help keep the size of the application smaller. I also didn’t like the idea of sharing multiple devices on the same SPI channel as I currently have no feeling of the amount of data that needs to be transported on it and I want to prevent clogging it. So I decided to rather use Ethernet connectivity boards like this.
These have the Ethernet connector as well as a W5500 chip mounted on one unit, giving me the opportunity to manually connect the SPI pins of the board to whatever SPI channel I want on the MCU or development board. The model I ordered also allows for shutting down the port when not being used, which probably is a good idea when running low-energy in-the-field applications connected via LoRaWAN. In this case, for example, a device could wake up once an hour, turn on the Ethernet device, connect to the PLC, get some data and send it back and then go back to sleep. The Ethernet ports seem to consume a lot more energy than any of the other low-energy peripherals in this sector. Also, I have noticed the specs for a lot of these embedded IoT devices tend to be incomplete quite often, so it could be possible that the W5500 generally supports this form of deep sleep mode.
I encountered something similar when noticing only one or two Nordic nRF development boards mentioned supporting hardware AES encryption even if this is a built-in functionality of the MCU and not of the board. So it is generally advisable to read multiple spec sources.
For the WiFi scenario I decided to use a standard WiFi shield available for the development Nucleo boards I chose. Miniaturization was mostly an issue for me for the double Ethernet connection scenario.
For the Bluetooth Low Energy scenario I’ll be using the on-board BLE hardware of the Nordic nRF52840 MCU I selected so no additional hardware was required
Last but not least, for the LoRaWAN use case, I decided to use a STMicro exploration-board called B-L072Z-LRWAN1, which uses one of the Ultra-Low-Energy STM32 MCUs and brings an on-board LoRaWAN unit.
This also brings up another general difference in the market of development boards.
There’s one big category intended on providing the means to work with a particular MCU.
These are usually not bloated with too much accessory hardware. The main goal for these devices is to use them to start building applications for a given MCU and then use the result in individually built and produced hardware.
Then there are technology experimentation kits like the B-L072Z-LRWAN1, which, for example, bundle a MCU with a given focus technology – in this case LoRaWAN. Other examples are audio-focused development boards, versions for experimenting with E-Paper displays, touch TFT displays and much more.
The probably most interesting category for people wanting to get started in this area are modules I’d call experimentation kits. They usually bundle a MCU with a wide range of integrated sensors and maybe even some actors. Sometimes these even exist in an ecosystem of extensions that allow non-electricians to do a large variety of experiments.
I decided to stick with the pure development boards, as I wasn’t interested in any on-board bells and whistles and only used a technology experimentation kit for the LoRaWAN example, because one very important measure for selecting hardware was a list of fully tested and supported hardware for Apache MyNewt 1.8.0. All boards I selected are listed as fully tested and supported on the MyNewt website.
Bill of materials
So in the end my bill of materials is as follows:
- High performance: Nucleo F767ZI: Development Board from STMicro with an on-board STM32F767ZIT6U MCU operating at 216 MHz with 512 KB of RAM and 2 MB of flash memory.
- Mid performance: Nucleo F411RE: Development Board from STMicro with an on-board STM32F411RET6U MCU operating at 100 MHz with 128 KB of RAM and 512 KB of flash memory.
- Mid performance and low energy consumption: Nordic nRF52840 DK: Development board from Nordic with an on-board Nordic nRF52840 ultra-low-power MCU with 64 MHz, 256 KB of RAM and 1 MB of flash. The MCU has an on-board Bluetooth LE unit and crypto hardware.
- Low performance and low energy consumption: STMicro B-L072Z-LRWAN1: LoRaWAN technology kit with an STM32L072CZ ultra-low-power MCU with 32 MHz, 20 KB of RAM and 196 KB of flash, but with an on-board LoRaWAN and Sigfox unit.
In addition to the base boards, I added the following additional hardware to the list:
- 2x W5500 Ethernet modules for providing ethernet connectivity
- X-NUCLEO-IDW01M WiFi shield for providing WiFi connectivity to the Nucleo boards
I am going to give my best to get everything running on these devices and really hope the memory and computational power will be sufficient. I don’t have any doubts for the first two models, but especially with the last one it could be challenging. I’ll let you know how I get on…
