In the last two years, two of the cornerstones of the independent embedded software market have been swallowed whole by IoT companies. First FreeRTOS was swallowed by Amazon to support IoT development for its Amazon Web Services (AWS) cloud platform and last month Express Logic was gobbled up by Microsoft for its competing Azure cloud services.

Various analysts have passed comment about the purpose of these acquisitions. The short summary would be that these behemoths are extending their reach from the cloud to the edge devices that collect and distribute data via the cloud. This seems like a straightforward idea but is it really that simple?

When is an RTOS More Than an Operating System—and Why Does it Matter?

First let’s look at the basics of what we know about the deals. Amazon bought an RTOS (FreeRTOS) that has no middleware. Software support for file systems, networking, USB, etc. are all generally supplied by third parties. Microsoft, on the other hand, bought an RTOS company (Express Logic) that also has a raft of middleware linked to it. So potentially the two investments could have quite different strategies behind them, once we get beyond the take-control-of-the-edge-devices idea.

RTOSes are important but not particularly special anymore – for 95 percent of embedded applications, the choice of RTOS is not significant. The days when small improvements in your context-switch time would materially affect your application have long disappeared as microcontroller performance has improved along with compiler technology, and there are many RTOSes that do this “well enough.”

Middleware, however, can help in two areas when building an IoT device. First, it can provide the communications interface to the cloud, which is clearly a critical element of the strategies of both Amazon and Microsoft.  Second, it can provide the core blocks of the control software to achieve whatever it is your IoT device was built for, such as recording sensor data to a storage device.

Is Controller Standardization the Key?

So, for IoT devices, the key is then the peripherals on the microcontrollers. It is not by accident that MCUs have escaped standardization – there are thousands of new variants released every year. Maybe the core architectures are less varied, but the variation in functionality is ever-growing (as you would expect, considering the pace at which technology continues to advance). And these devices are growing in complexity as a result of the continuous struggle to get more for less: more CPU cycles, more bandwidth, more functionality, more security, less power, less cost, less space, etc.

Because embedded devices are extremely cost-sensitive, standard solutions tend to be replaced by cheaper ones once the volumes rise, which is presumably the markets that the IoT giants want to play in.

There have been attempts to standardize MCU peripheral software interfaces, but the results are not unequivocal. For instance, ARM developed CMSIS as a standard software interface but that is restricted to some ARM architectures. What happens with other architectures such as RISC-V?

Can AWS or Azure achieve standardization by leveraging their new assets? They have the bank balances to do anything they want, of course, but developing a solution that gets control of all edge devices is not an easy thing to plan when you have no idea what the embedded device of the future will look like or what the next killer app is going to be that needs cloud connectivity.

And if Amazon and Microsoft do somehow create complete embedded platforms, does that mean that device developers will have to choose their cloud service provider at the point they start designing their device? Or will there be two open specifications that allow them to choose at the point of deployment? The former is restrictive; the latter makes you wonder why they are doing it. Maybe just to make it easier to create devices that can generate revenue for them. That seems like a huge gamble, although maybe not if the size of these business opportunities is considered.

I have not mentioned security here, a topic worthy of its own book, which is tightly coupled to the development of any connected device. Taking the burden of security away from the IoT device developer would be a huge help – the device developers could return to focus on what they know and love. But silver bullets for security are yet to be found.

What’s Next?

If behemoths like Amazon and Microsoft are going after standardization, then you must ask: what else comes into play? Controlling the compiler is the next layer down, followed by the silicon itself. This may only be the start of a much larger trend.

Or are these investments simply investigative exercises? Platforms for them to learn and better understand the challenges of making edge devices easier to create? After all they have both binned much larger investments.

In the meantime, developers in the planning stages for new products – as well as those who must continue to support and evolve existing products – now have new uncertainties to address.

There are many questions and few answers, but plenty of food for thought. I am not convinced that the RTOS is the key to getting control of IoT device development – there are far greater challenges – which leaves me unconvinced by the many arguments I have heard about this. One thing is for sure: The vast resources of the major IoT players are taking a serious look at how to “fix” IoT device development. It will be fascinating to see how this plays out.