16 requirements for connected device OS – is OpenWRT fit for it?

Which requirements need to be considered for a connected device operating system?

#openwrt, #linux, #embedded, #8devicesHabanero, #connectivity, #timetomarket, #iot, #edgecomputing

Are you standing before the decision which software to use for connected devices or application? Should you go with a tailor made bare-metal firmware, embedded Linux distribution created from scratch or use a fully-fledged Linux system? What about using OpenWRT for connected devices?

We would like to share with you our knowledge and lighten up the decision-making process than could take you further in the development than expected.

Let us start by defining an example system that consists of wireless, mobile sensors and a mesh of edge gateways that are receiving, processing, and sending the measurements to a central (preferably cloud-based) backend server.

Requirements for an exemplary edge gateway device

We will focus on the edge computing gateways and set additional requirements on them:

MUST

A gateway…

1. must receive sensor data via Bluetooth
2. must receive sensor data via UWB (Ultra WideBand)
3. must allow to build an IP network with gigabit ethernet
4. must allow to build an IP network with WiFi5
5. must allow to build an IP network with PLC (power-line communication) to reduce the cabling / installation costs
6. must be powered via mains voltage and / or PoE (power-over-ethernet)
7. must be equipped with backup battery to be resilient from power blackouts
8. must have enough processing power to receive, process and route over 1000 (?) sensor packets per second to the backend

SHOULD

A gateway…

9. should be easy to upgrade
10. should be easy to maintain
11. should fulfill security aspects for IoT devices
12. should be customizable / allow to run additional software (e.g., to test new functionalities)

COULD

A gateway…

13. could support fiber optic through SFP
14. could allow for simple device configuration
15. could allow for factory reset
16. could allow for A/B update mechanism

What is OpenWRT?

OpenWRT is an embedded Linux distribution and build-system that is designed to be run not only on router devices, but also to build custom systems (since the merge with LEDE project). Compared to other embedded Linux solutions, it allows us to create small and connectivity-oriented appliances that can be tailored to specific needs of the project. Since it is used mostly in router devices it gives a good portion of security by default.

Is it worth using OpenWRT for connected devices like an edge computing gateway?

Let us compare the list of requirements set on the edge computing gateway with functionalities provided by OpenWRT embedded Linux distribution;

• 1 [fulfilled] – Linux has support for bluetooth communication (e.g. bluetooth USB dongle), you must install Bluetooth packages into the default system image to enable it in the system
• 2 [not_fulfilled] – there is no support for UWB builtin, because it is not a one standard (compared to Bluetooth or WiFi), but Linux has support for 6lowpan, which can be used to build network layer around UWB radio
• 3 [fulfilled] – OpenWRT has an excellent support for ethernet networking and embedded switch management, additionally it has support for different mesh/routing protocols
• 4 [fulfilled] – OpenWRT has an excellent support for WiFi, often it is the source of Linux kernel patches that eventually go into mainline
• 5 [fulfilled] – Linux kernel has a driver for QCA7000/5 PLC chip within the network subsystem, it must be compiled it into the system image and then the PLC based network is available as a standard network interface
• 6
  • [fulfilled] almost every hardware platform that supports OpenWRT can be supplied from mains voltage (or DC adapter)
  • [partially_fulfilled] base PoE application does not need a software support, there are no PoE chip management packages available (except of Realtek chips), custom solution must be developed to allow PoE management
• 7 [fulfilled] – Linux kernel has several drivers for battery chargers / fuel gauges available, so battery state can be fully controlled and monitored
• 8 [fulfilled] – OpenWRT has been ported not only for low end devices (like most routers are), but also to multi-core ARM SoC (Qualcomm IPQ4019/29, Marvell’s Octeon TX2  and even x86)

———————————————————————————————————————————–

• 9 [fulfilled] – OpenWRT has a built in system upgrade functionality that can be invoked to flash newer firmware version with or without preserving the current configuration
• 10 [fulfilled] – if we choose hardware platform which is supported by mainline OpenWRT we get security and package updates, because it is an actively updated and maintained project
• 11 [fulfilled] – OpenWRT is built with security in mind, even older platforms are still supported and get security updates
• 12 [fulfilled] – OpenWRT is built around *opkg* packaging system and provides several thousand packages, which can be used to customize the system not only in the build step, but also while it is running

———————————————————————————————————————————–

• 13 [fulfilled] – several OpenWRT maintained platforms have support for SFP port/ports
• 14 [fulfilled] – OpenWRT centralizes the device configuration with command line based Unified Configuration Interface or even web-based interface called LUCI, which both are well documented and extensible
• 15 [fulfilled] – since OpenWRT standard image is build around read-only filesystem with an read-write overlay filesystem, OpenWRT has an already implemented factory reset functionality
• 16 [not_fulfilled] – since OpenWRT is often deployed on devices with limited memory size, it is not recommended to use an A/B update mechanism to save space on the flash memory, but it supports a recovery functionality which starts before the actual system is being set up

To sum it up, using OpenWRT supported platform allows to fulfill all, except for one must have (requirement nr 2), all should have, and all except for one could have requirements by default (from software point of view). To meet all the requirements and integrate it in a product some work needs to be done, especially on the hardware side of the project, but OpenWRT is a particularly good base platform to reduce the time-to-market.

Exemplary hardware platform for edge computing gateway device

With such strong requirements on connectivity, maintainability, and processing power for the edge gateway device, we should consider a hardware platform that is supported by mainline OpenWRT. There are several supported hardware platforms and we should choose one that fits the best for the project.

For example, 8devices Habanero (which is supported in OpenWRT since 21.02.0) is based on a 4 core 32bit ARM processor and supports a variety of connectivity interfaces. Although that platform does not fulfill all of the requirements (lack of Bluetooth/UWB/PoE/PLC/battery support), but it is built around a SoC (system-on-chip) which has several peripherals (like SPI, I2C and USB) that allow for integration and implementation of the missing functionalities.