Selecting the right hardware for embedded development of open-source protocol adapters

With Apache PLC4X we are currently able to access almost any industrial PLC from the Java world. 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.

Also we didn’t intend to only provide drivers for Java. Otherwise we would have named the project PLC4J.

Fortunately I met Michiel from NLNet.nl when attending the European Commission Open-Source Workshop in November 2019. NLNet is a public good charity giving developers the chance to help improve the internet by making it safer, faster, more robust. Currently they are operating as a kind of European Research Funds proxy for individuals and small companies: entities which usually don’t have a chance to access any of the big research funds out there. Michiel suggested that I apply for NLNet funding when I mentioned on the workshop how hard it is for individuals or small companies to get access to such research funds, while the big companies usually have large departments doing nothing else than produce research fund applications.

The application process was super easy and took me only a handful of hours to prepare. And guess what – I got accepted and will be working on securing PLCs via embedded open source protocol adapters for the next 6 months or so.

Embedded development: Goal of the PLC project

The goal of this project is to secure the communication with inherently insecure PLCs.

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 is to port Apache PLC4X drivers to native C and build a gateway based 100% 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

Even if 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.

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.

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:

https://cwiki.apache.org/confluence/display/PLC4X/Creating+a+version+of+PLC4X+drivers+that+work+on+Apache+MyNewt

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.

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 above socket, 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.