The Shift to Linux Operating Systems for IoT
Christian DaudtChristian Daudt
As IoT devices become more full-featured, the Operating System that drives them is shifting from Real Time Operating Systems (RTOS) to Linux.
IoT devices are considered embedded devices, which in short means a computer attached to something else, whatever that something else might be. This is in contrast with laptops, desktops, and servers, for which the computer in them is the end and not just the means.
While these terms are not formal terms, a common way to distinguish IoT devices from other embedded devices is by the presence of network connectivity. This means that IoT devices can talk to other IoT devices, or to your desktop, or to some server in the cloud.
Some of these devices are low-cost consumer devices (for example light bulbs and light switches for the home) or are very purpose oriented (such as a fridge or oven, or the Amazon dash button). And others, while not as price sensitive or as single-purpose, have been developed by teams with little to no experience in network, which in turn have not taken full advantage of the networking capabilities of these devices.
The computational power required to implement such IoT devices is quite small by modern standards. And so they have been developed with simple processor technologies — mostly using ARM’s Cortex M architecture and use an equally simple Operating System and software stack.
First a one paragraph primer on Operating Systems: The Operating System is the program at the heart of controlling a computer. It decides how to partition the available resources (CPU, memory, disk, network) between all of the other programs vying for it. It also provides standard programming interfaces that the other programs can use make use of these resources. So for programs to write a file to disk, or to communicate with a server somewhere to store your step count, they rely on the operating system to do so on their behalf.
There are various types of Operating Systems, and pretty much every single computer, embedded or not, will have an operating system controlling it. IoT devices tend to use a type called RTOS, which officially is short for Real-Time Operating System. Unofficially it stands for Not-a-Full-Featured Operating System.
The main draw for using an RTOS is its simplicity and its modest requirements of resources for itself. After all, an operating system is a program and will require some CPU, memory, disk, and network do it its own function. The selection of features required from the operating system is done at the time the image is being built, so as a developer you only pay for what you are using in terms of computational resources.
Using such a lightweight operating system allows designers to design smaller, cheaper, and less power-hungry embedded computers for their IoT devices.
So, seems like it’s all good right? The right tool for the right job. The only problem is the network part of the IoT device definition from above. Once we have networked devices, we slowly want them to do more. And more. And more.
Why can’t my bathroom mirror light tell me how long my commute is? Why can’t the alarm clock start my car? But only if the weather outside is cold enough? And while it’s at it, get the coffee maker going too? Why can’t my TV dim the family room lights when I start a movie or redirect my incoming calls straight to voicemail?
We are starting to see some integrations, but current ones tend to be one-off. One company will demonstrate one of their products integrating with a single product or service from one other company. If you bought anything but the exact combination of products and services that are preset to work together you’re out of luck. Or if you want to set something different you are also stuck. And many of these integrations don’t even make it past the trade show into actual products because they are so clunky and limited.
So if IoT is all about devices talking to each other, what is wrong here?
Look at the history of mobile devices. Cellphones started as very simple embedded computers. The could read the keypad, make calls, send and receive texts, and maybe keep a 50-entry phone book. It was a pain to edit using the dial pad as a keyboard. The fancy phones had a game of snakes in them too.
Those phones were usually built with very simple ARM-based cores with a small amount of memory and low clock rate and without a Memory Management Unit or user/supervisor modes. The operating system of choice for those phones was either some in-house or commercial RTOS.
When cellular data entered the picture, things started changing. Users wanted access to email from their phones. Then they wanted to browse. Then they wanted to access todo lists, online calendars, and more. Then they wanted to do all of this at the same time!
The phone software stack started getting bigger, and the hardware footprint followed suit. Symbian became the operating system of choice, and Cortex-A family of chips became the CPU of choice for phones.
By this time (circa 2005), Linux was widely used in certain computing environments such as servers and was enjoying a steadily increasing footprint for some embedded environments such as TVs. It was quickly seen as a good building block for smartphones, as it brought out of the box a modern full-featured Operating System with very good device driver support, and that was considered both scalable for the new generation of devices and had the added benefit of being royalty free.
There was and still is the fact of its unusual licensing model using an open source license called GPL and that warrants a whole other article. But to summarize here, commercial concerns over using Linux due to the license have gradually declined over the years, being a much bigger issue at present day than it was a decade ago.
Some phone vendors started experimenting with Linux for their phones. My first Linux based phone was the Motorola Ming. Nokia also started experimenting with a Linux based smartphone OS called Maemo, using it first for some early tablets and later for their smartphones. These efforts were all stymied by the phone vendors insistence on locking in their customers, which provided a fertile ground for the arrival of Android.
Android, like the phone vendors at the time, saw Linux as a good solid building block for their mobile Operating System. And when Android was introduced it quickly become the smartphone operating system of choice for all vendors other than Apple, Blackberry/RIM and Nokia, which by then was attempting a revival of Maemo by merging efforts with Intel and Meego. Even Nokia eventually capitulated and starting a move to Android. It was then acquired by Microsoft and abandoned the Linux based platforms.
At present, the mobile OS world is split 80/20 between Android and iOS. Mobile OS users have long since realized that the core Operating System is a costly endeavor that brings little competitive advantage, making Linux with its good support for peripherals, and Open Source distribution model, an excellent choice.
We are arriving at a similar mix in IoT. Customers want ever more connections between their IoT devices and for these connections to be of a more complex nature. Device vendors just can’t keep up with the demand. This demand in the short term is being serviced by having every device hooked up to a vendor-specific cloud account, and having the service-to-service intelligence all done at the cloud level.
I have a handful of cloud accounts created for the sole purpose of hooking up a new device from a new vendor to my Amazon Alexa service. This model presents numerous problems: for starters having to create a new web account for pretty much every device I purchase does not scale. I have no idea how long these vendors will keep their accounts operational if their interest in this market wanes.
I would never use this model for anything that I consider more than toys — can you imagine having to rip out your in-wall light switches because the vendor no longer wants to sell into this market and shuts down their servers? Additionally, nothing works if there is a hiccup in internet connectivity, which is another non-starter for anything but a toy.
Along with the demand-side, the supply-side is also shaping up. IoT devices sell for less than mobile devices, which in turn requires their parts to be lower cost. But Moore’s Law is still alive and well in this area of the industry, with ever more capable processors available at the same price point year over year.
So while the capacity of processors that manufacturers could afford to put in many IoT devices was quite limited, that is rapidly changing. We are already seeing single board computers with multiple GHz-level cores in the $10 range.
Combine these added demands from the consumers with the enhanced CPU capabilities available to designers and we have a fertile ground for an industry shift. This shift will not happen overnight, but we are rapidly approaching the inflection point.
The IoT market is evolving rapidly, and products are being enhanced at an astounding rate. The voice services are shaping up to be one of the first big paradigm shifts to start with IoT. Others are sure to follow. These will demand more capable devices and faster product cycles.
The device capability is being increased regularly as the costs for better and more capable components continue on their seemingly endless downward trend. That will enable smarter and more autonomous devices at the edge, with more features such as audio, voice, and touchscreens available everywhere.
Along with that will come a shift to faster product cycles. Today, many products have vertical hardware and software development — that is, a product is designed both in hardware and software together. This will shift to having an apps model that detaches the software features from the hardware ones, allowing their existence to overlap, and their feature sets to evolve separately. This will both quicken the product cycles as it did for mobile devices, as it will allow software features to not have to be baked into IoT devices at manufacturing as they are today.
And along with all of this, Linux will be there to provide the underlying plumbing for these new classes of devices, bringing to the table a pre-existing rich ecosystem of multitasking, memory protection, wide array of modern languages, simultaneous services and many other operating systems that today’s RTOS will not be able to supply.
There will still be a market for the current type of single-purpose, RTOS-driven devices. A standalone temperature monitor will likely not need any fancy features for a long time. But other devices fuelling the IoT wave will need to become more and more capable.
Now we just need to see what shape these new Linux-based ecosystems will take.
In a follow-up article, I’ll explore Linux ecosystems currently available for IoT solutions and how they compare to each other.
New Podcast Episode
Recent Articles