RIOT: The future of IoT

The number of IoT devices powering our daily lives becomes larger every day. On top of that the applications running on these devices become more and more complicated. To keep up with these developments, the developers of such systems need proper tools. An Operating System is an essential part, and provides a lot of basic building blocks. RIOT is such an OS, it’s feature-rich, open-source, adopted by academics and under active development.

The Figure¹ below shows a timeline of relevant developments in relation to RIOT. It shows Linux, which the RIOT community considers as an example for open-source development. A few competing OSes and relevant technical developments are listed to indicate why and how RIOT came about.

This post will explore what RIOT is, what it tries to be and who it is for.

What is RIOT?

RIOT is a real-time embedded operating system aimed at the ease of development and portability of IoT applications. RIOT can be compared to other operating systems aimed at embedded devices like Zephyr, mbedOS, Contiki-NG and FreeRTOS.

While an operating system can provide a lot of useful features for the development of IoT applications compared to bare metal programming, it has to consider the limited resources of IoT devices. Thus, one of the most fundamental features of an embedded OS is its resource management. Another important feature is support for various networking technologies and protocols which would be applied in IoT applications.

RIOT provides support for an extensive list of networking technologies and protocols which are widely used like Bluetooth, LoRa, 6LoWPAN and MQTT and many more. The full list can be found in RIOT’s documentation².

The Figure³ below shows a high-level overview of the structure of RIOT. Important to note is the separation between hardware-independent and hardware-dependent. Development of generic functionality only has to be done once and will work for all supported hardware platforms. This results in a small amount of hardware-specific code, which eases the adoption of RIOT on new hardware platforms.

Another result of this hardware abstraction is that it provides the opportunity to optimize the configuration of RIOT for individual devices. Since each cpu and board have their own configurations, a developer can disable certain unsupported or unused features of the OS. This reduces compile time and more importantly reduces the footprint of the OS on the device’s memory.

Overall, the currently implemented features show that RIOT tries to provide a full-fledged embedded operating system, or as defined in a paper co-authored by some of the main developers of RIOT: “RIOT provides the full set of features expected from an OS, ranging from hardware abstraction, kernel capabilities, system libraries, to tooling.”⁴

End-user mental model

The end-user mental model of a software product is a model to describe the end-users’ cognition when using this software product.⁵ In this section, we would briefly analyze the end-users’ behaviour of RIOT from an architectural perspective.

RIOT is designed to be deployed on mainstream IoT devices. Its target end-users are mainly engineers from IoT or related fields and technology enthusiasts. In other words, we would expect the end-users to have a certain level of professional knowledge of IoT and embedded software. Our end-user mental model is described as below:

• The end-users should understand how to identify the type of board they are working with and they would be satisfied if they could easily locate the compatible version of RIOT with their boards.
• The end-users usually work on low-level hardware programming and they would be familiar with C.
• They would be looking for a short manual when they are trying to set up and give a test run of the RIOT system.
• They would expect RIOT to support wireless communication protocols that are heavily used in IoT development.
• The user would expect basic real-time OS features as IoT devices are often involved in real-time applications.
• The user would need to test multiple instances on a single physical machine and in this case virtualization support may be required.
• Since the end-users also have the knowledge of software development, they may want to contribute to the RIOT project. A guide on how to contribute and the format of contributions may be necessary.

Stakeholders

According to chapter 3 of Lean Architecture⁵, there are 5 major stakeholders: the end users, the business, the customers, the domain experts and the developers. Since RIOT is open-source software, there is much overlap in these areas and some do not really apply at all.

The customer stakeholder area is not really applicable here since Lean Architecture defines the customer more as a middle man who sees the software as a product that passes through their systems. They might repackage it but in the end it is still the same product. Since RIOT is open source it goes from source directly to the end users.

The business stakeholder area is not really applicable here since there is no single organisation working on this product. It is developed by an international community of developers, there are no managers, no board of directors or weekly meetings. A business cares about serving customers and increasing revenue, but since there aren’t really customers or revenue, this stakeholder is not really applicable.

In the case of RIOT, the end user, developer and domain expert stakeholder areas have a lot of overlap. Because RIOT is open source any end user could also be a developer or domain expert or both, and the same for developers and domain experts. Anyone who wants to use RIOT in their embedded platform can be seen as an end user, and the benefits of this system is that RIOT is a low memory use operating system. But in contrast to other low memory use operating systems RIOT allows for application programming with the programming languages C and C++, and offers full multithreading and real-time abilities. Since most developers are likely also end users they get the same benefits out of this system on top of the experience of contributing to an open-source system.

According to Lean Architecture, the domain experts are the folks in an organization who know stuff, but because of RIOT’s open-source nature they fall more under developers than a separate stakeholder area. They do however get the added benefit of being more likely to steer where the product is going or how it is developed because of their expertise.

Another stakeholder area which is not mentioned in Lean Architecture but we find worth mentioning are academic institutes. A lot of RIOT’s early and main developers are from FU Berlin and INRIA, and academic institutes often have a lot a research in IoT devices, sensor networks and other embedded systems. The benefit of RIOT is that it is a nice lightweight open-source platform that might fit the needs of their research.

Roadmap

The development of RIOT started when IoT started to become more and more popular. According to RIOT’s vision document⁶, at that moment the RIOT founders thought that software platforms for IoT applications would go through a similar evolution as smart handheld devices. Expected were multiple closed-source, slow progress, proprietary solutions at the beginning, after which a couple of big players would create new standards, such as openness and interoperability.

At the moment there are multiple software platforms powering IoT devices. Some of those are closed source and for example made by Android, Windows and Huawei. Next to that there are also multiple open-source software platforms for IoT, for example Zephyr, mbedOS, Contiki-NG and FreeRTOS.

This development is in line with the predictions of the RIOT founders, as stated in their vision. Unfortunately the vision hasn’t been updated since 2014, so to give an estimate of the future development, we looked into some task forces⁷, open issues⁸ and the roadmap⁹.

The biggest enhancements RIOT is currently working on is changing the way it is configured by the user, adding more available boards is a high priority and increasing the responsiveness by rewriting some blocking functions.

Furthermore the roadmap provides some specific improvements split in the following subjects:

• Network Stack High layers: Mostly clean up, develop long-term plans and extend CoAP support with blockwise transfer
• Network Stack Low layers: Fully open source support 6LoWPAN over BLE, re-integrate 802.15.4 TSCH, retransmissions by MAC, Point-to-Point Protocol
• Power Modes: integrate generic power management functions in device driver API’s, more advanced LPM concepts
• Peripheral drivers: implement i2c_slave and spi_slave
• Software Updates: no unfinished milestones at this moment
• Documentation: write and publish more RDM’s, revamp RIOT website
• Low-level Hardware Support: improve MIPS support, radio support for multiple components, ST Nucleo support
• Testing: automated network functionality tests, on-board CI testing
• Security: default secure RIOT configuration, 802.15.4 link layer security