Earlier this year, the Zephyr project was launched to a world justifiably skeptical of self-anointed “secure” technologies, jaded by the sloganeering of all things IoT, and seemingly saturated by the proliferation and fragmentation of no-size-fits-all microcontroller RTOS platforms. Given those circumstances it is only reasonable that I find myself asked what we could possibly be thinking in launching a new “secure IoT RTOS platform.” Or, should I say, why are we launching yet another one.

As the NXP representative on the Zephyr Project Governance Board, and as an advocate from the outset of the essential value of this initiative, I’m going to give my take on this question, and on what I think are the key considerations.

The RTOS platform

Since acquiring the RTOS code base in 2001, my WindRiver collaborators at Intel have over the years been building and maintaining a multi-platform RTOS codebase for microcontrollers, with a focus on efficient execution and low-footprint. Over the years this code base has been used in industries like aerospace and defense. Last year, the Linux Foundation was invited to build up a community project around that codebase (released under version 2.0 of the Apache License), and to bring in partners from a variety of horizons to contribute to its development. Thus was the Zephyr project born.

It was perceived, correctly in my opinion, that the microcontroller ecosystem did not yet have a credible multi-architecture and platform-neutral open source solution that could reasonably claim to reproduce the kind of development model we’ve seen on apps processors over the years. (I’m thinking here of operating systems like the Linux and BSD variants, servers and middleware for web, email, databases, and the like, specialized network processing stacks, hypervisors, containers, cloud computing technologies, and so on.)

Scratching that Itch

Indeed, the server and networked technology spaces can boast a number of open-source projects and communities of critical-mass in which everyone can “scratch their own itch” and leverage each other’s work. Yet when one looks at the extraordinary phase of creativity and disruption that the microcontroller world is going through with IoT, the conventional computing spaces (servers, networking) seem relatively stable and mature by comparison. So why doesn’t the microcontroller IoT space have these kinds of projects and communities, given that they are clearly so amenable to innovation and decentralized development?

Indeed, the circumstances would seem fertile for a meritocratic open source project and community around a low-footprint, IoT-focused RTOS. A project where the combined creativity of all interested parties could express itself. This is where the involvement of the Linux Foundation is so fundamental to what we are trying to construct with the Zephyr project, as I hardly need elaborate on their experience and credibility in nurturing open source projects and supporting the community members (from hobbyists to the largest multi-nationals).

It is certainly true of semiconductor vendors such as NXP, and is likely to be true of a great many maker outfits, too, that a project in which everyone can scratch their own itch is appealing. This is the reason, for example, that the Zephyr code and tools are (and will remain) free, easy to obtain, open source, and simple. The common desire here is to ensure that the barrier to entry for anyone wanting to play with and contribute to the Zephyr code be as low as possible. If it works for Linux…

Internet of Things

It’s worth saying a word or two about IoT, if only because the air is so thick with nonsense on the subject that is it difficult to make meaningful progress without some clarification.

To my mind IoT, like its predecessor M2M (Machine to Machine), refers to a progressive co-mingling of two traditionally distinct areas of computing:

One is the world of networked computing, which spans form-factors and use-cases from network switches to servers to desktops to smartphones, and everything in between. It is a world of sophisticated operating systems, vulnerabilities, denial-of-service attacks, CVEs, regular software updates, cryptographic protocols, and so forth.

The other is the world of microcontrollers, which assemble to form the kind of stuff we are now referring to as Machines or Things (in M2M and IoT, respectively). These areas of technology were traditionally non-networked and noteworthy for the high degree of engineering for QA (Quality Assurance) and certification prior to deployment, precisely because they were destined to be static, or as static as possible.