Bench Talk

A guy sitting next to me on the plane was studiously inspecting a map of US flight routes in the back of the flight magazine. After about 10 minutes of this, I asked him if he had a geography exam coming up. He smiled and said in a lovely Scottish accent that, no, he was looking at Kansas, where he had just completed a business trip and was returning back to Ecuador. His father had started and still ran a mill where they made yarn and knitwear. It turns out his mother is from Scotland. I bet that has a romantic back story, but we detoured into talking about technology. For one thing, he had never heard about the much-hyped Internet of Things (IoT), which is supposedly going to shower us with riches as soon as every atom in the world has its own IP-address.

We got to talking about open source hardware (OSHW) and IoT. I explained it by asking him what information he would collect for analysis in his factory, if he could know anything he wanted, in order to increase productivity and improve operations and logistics. He said that they had a sensor that tells them when a spindle has stopped. They needed to know when the person manning the spindles stopped reloading them. I suppose you could mount a web cam in the corner, but that would be obvious. I didn’t ask. I said that applying IoT could not only sense when the spindle had stopped, but for how long and it could send a message to his smartphone to tell him about it. And it could be done with OSHW and APIs from sites like MIT’s free Application Inventor for less than $100, most likely. He was shocked at the price and that he could probably do it himself with tutorials online, free software, and low cost hardware. We exchanged emails and I sent him information on projects similar to what he wanted to do and so forth.

The complexity of IoT extends beyond simple projects like this, however. If you were to take all the useful data and manipulate it, you could find patterns that point to changes that can increase productivity, reduce wait times, or point to trends that help improve processes or locate potential failures. Predictive maintenance (PdM) allows you to maintain equipment based on indications, such as motor vibration. Vibration data is collected by local sensors and analyzed either locally or stored and analyzed in a cloud. (A cloud computer is simply someone else’s computer.) As data and what we do with that data gets more sophisticated, we find we need more than microcontrollers. An operating system, especially a real time operating system (RTOS), may be necessary to handle multiple threads, interrupts, and so forth. The more complex the task, the more complicated the device needs to be to handle multi-step, multi-threaded decision-making operations made in the field (by any device.) Devices meant for IoT typically have very low memory, and so a very small RTOS would be in order. Small RTOSes have been in use for years in the automotive industry.

A while back, Intel® bought WindRiver, an embedded software and operating system developer. Recently, Intel released WindRiver’s “nano-kernel” RTOS, formerly called “Rocket,” to The Linux Foundation (LF) and was renamed “Zephyr.” A royalty-free micro- or nano-kernel RTOS is a very big deal. Ostensibly, Zephyr is meant for IoT, but free to use, royalty-free RTOSes have been a very big deal in the embedded world for at least a couple of decades. So a professionally developed, for-profit RTOS was rolled off to The Linux Foundation to maintain and promote. It’s free, it’s maintained by the experts in open source operating systems, and it’s going to change the way IoT unfolds as a technology; probably by accelerating adoption. Zephyr supports the x86 instruction set. This means that the Intel® Quark™ Microcontroller D2000,Intel® Quark™ SE Microcontroller C1000, Arduino 101, Galileo, and others can run the Zephyr OS. Zephyr also supports some ARM instruction sets.

One way to think about this is to look at another use case for small footprint RTOSes: embedded automotive. For years, embedded automotive operating systems had customers in the automotive industry who paid for RTOSes that were developed as closed, proprietary, for-profit enterprises.

The Linux Foundation, a non-profit consortium, has recently released Automotive Grade Linux. At present AGL has targeted infotainment, but it has sights on instrument clusters and telematics. AGL’s unified code base 2.0 was released in July 2016. Like all Linux, members can provide input directly to the open source developer community. Car makers are rapidly jumping on the AGL bandwagon, as embedded Linux has proven to be robust, secure, and offer significant cost savings in the long run.

I can almost hear a sigh of relief. Open source is a model that, although not perfect, can have significant impact on automotive life. For instance, someday in-dash Navigation will operate similarly across all cars that use AGL, much like Android on smartphones. Each carrier has their own splash screens and added features, but settings and other fundamentals like navigation through menus is the same on every Android-based carrier phone, because the basic functions are handled by the OS: Android. Ever been in a rental car, frustrated at the navigation system and how to find what you need? Learning the navigation quirks of each car maker will be a thing of the past, because the way the navigation operates will be familiar and similar across cars that use royalty-free AGL. This does not extend to vehicles that use Apple Car Play, of course.

Security in AGL is also a concern, and with both IoT’s Zephyr and AGL managed by The Linux Foundation, one can hope is that the collaborative spirit will communicate security improvements from AGL to also be applied to IoT in Zephyr, and vice versa.

The development platform you choose may also be influenced by available software and operating systems. The Zephyr RTOS runs on the 32-bit Intel® Quark™ D2000 Microcontroller Developer Kit, which is physically compatible with the existing ecosystem of 3.3v Arduino UNO Shields and with Booster Packs so developers can leverage ready-made peripherals. When I say physically compatible, I mean that the software compatibility of any Arduino shield is not guaranteed, and the user would need to produce the appropriate code (and hopefully share it with the rest of us.)

Zephyr supports Bluetooth, Bluetooth Low Energy (BLE), and 6LoWPAN (802.15.4), and of course other technologies and standards are to come. It has to be safer from an operating standpoint in that cars may someday share a similar OS for human machine interface in infotainment. It makes life easier when you can depend on knowing that the tips and tricks learned on your own car will also work in another one. The last thing you need is to try and figure out how to pull up “settings” when you’re on a dark road in a foreign country trying to find the language settings so you can navigate safely.