Why IoT is Hard — 8 Reasons

What I discovered after working 8 years in the IoT market

IoT architectures are inherently hard to design and implement, there are many reasons, and some of them at not obvious.

Components

  • Microcontrollers, which usually gathered data from sensors directly connected to them, can also control actuators.
  • Nodes, can be a little more capable than microcontrollers but still very limited, usually, they have some sort of extra connectivity (BLE, LoRaWan, etc. support)
  • Gateways, which collect data from other smaller and less powerful devices, can eventually do some serious computation on the edge, also named fog or edge computing.
  • Protocol servers, are where most of the processed data will come to, but can have some extra logic to either send data back to the field or process them again and store them on a database.

They can be virtualized or simulated in some way, but all those components end up running on some kind of hardware.

Photo by Harrison Broadbent on Unsplash

Each group of hardware/components has some specific challenges to be solved. Just to mention a few of them, you can have: microcontrollers with only 2048 Bytes of memory, CPU architectures at 8, 16, 32, or 64 bits. There can be bare metal software, embedded OS (FreeR TOS, MbedOS, etc.), for single processors, real-time Linux of you have some more CPU and memory. Interactions with external interfaces like SPI, I2C, UART, USB, Can BUS. Microcontrollers are often programmed in C/C++, but MicroPython, TinyGo, and Jerryscript are rising too.

This is just for the microcontrollers, the more the hardware is powerful the more options are in the market, you can have GPU doing some ML at the edge in a gateway programmed by using CUDA, Node.js to send data to a third-party service, a local MQTT broker.

There is no standard, so there cannot be good working solutions for every use case.

The radio protocols

With some radio protocols like BLE or ZigBee, you need a gateway in the middle. It has to speak at least 2 protocols, one for reading/sending the data from the nodes, another one to send the data to the cloud service of choice.

Shit always happens, you can take a look at what caused Facebook employees to be locked out of their offices.

Measure units

Photo by William Warby on Unsplash

Gateways

OTA/FOTA Updates

Once you solved this, you still have to deal with concurrent work (running your code while starting the update) in a one-chip environment with interrupts, and sometimes even without an OS to handle that. You could have a radio chip only supporting some protocols, or being in a network not allowing you to use UDP but only HTTP, while your network maybe is not as reliable as a TCP protocol would require, so you usually need to implement a retry strategy, again, with super-limited constraints to write your own logic.

Dashboards

Photo by Luke Chesser on Unsplash

Dashboarding is even more complex for systems having a ton of different elements, such as

  • Multiple geographical locations for the devices.
  • Multiple gateways gathering data from different sensors in the field, and you need a way to localize and identify them all on a dashboard.
  • Multiple sensors and actuators, and usually you would need a way to aggregate them for a specific location, let's imagine an IoT parking lot with multiple locations, you will need to group each parking slot within the same location, see an overview of the free ones each lot and level, and maybe for all the locations to calculate how much money you are making while renting them. It is complex.
  • Multiple widgets: every sensor/actuator could have one or multiple widgets associated with it, so users usually want to group them all and reuse a group of widgets as a template.
  • Templates: not having templates is a huge pain for the users, they do not want to recreate a dashboard every time they add a new set of hardware in the field. They just want them to automatically appear in their dashboard. This is strictly related to the auto-provisioning of your hardware.

Security

Photo by Nolan Krattinger on Unsplash

Most of the time is very easy to physically access an IoT device, because they are active in the field, and there is very little you can do to protect them other than choosing the right components (expensive usually). These systems are as useful as hard to program, or at least, really limited to very professional users (like ARM TrustedZones) so most of the small companies do not implement even the simplest security measures. Secure boot is quite a standard since a few decades already, but still many vendors do not implement it for finished products. This is just as risky as it sounds. In addition, many popular platforms do not even have a chip to properly implement TLS or any other encryption algorithm that requires a source for generating random data. And you know what? Your algorithm is going to be as weak as the predictable source of pseudo-random data.

Another big hole in the security process for a lot of cheap devices, is the supply chain, both on the physical side (many vendors are involved even in the most simple microcontrollers, sometimes even more than a hundred different vendors for each board). It reminds me of one of the most interesting attacks in the last 10 years involving the chip-maker Supermicro.

https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

There are also more subtle supply chain attack on the software side, re-using code written from someone else that is not properly vetted, is going to add yet another attack surface on your product. Be prepared! You could expose critical systems to a world of attackers.

So What?

We should think more at the business problem that at the technical solution.

The best advice I can get is to properly design a device to do only one thing, to be as specific as possible and to use as few elements as possible. The system will be simpler to design, implement, support, and will have a minimal surface for attacks. You could then eventually have more than one device communicating each other.

For everything else, we could just be lucky!

If you want to know more about myself, please take a look at my Twitter account

and write me a private message, or just comment this article.

--

--

Engineering Manager at Jimdo, former CIO at Arduino, DevOps at Cloud9 and PeopleBrowsr. @mastrolinux

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luca Cipriani

Engineering Manager at Jimdo, former CIO at Arduino, DevOps at Cloud9 and PeopleBrowsr. @mastrolinux