In Part I of this interview, Zach Shelby, business development guru at ARM, discussed ways that the IoT developers could avoid the pitfalls of the M2M market; the key role played by start-ups in the IoT; and why permissionless innovation was important. In Part II, Shelby speaks directly to embedded developers to make a case for open systems with a modicum of key standards; decoupling of devices from services; and an IDE software development environment in the clouds. What follows is a portion of that interview. -- JB
Blyler: Previously, you talked about the preponderance of start-up applications that are just beginning to appear on the IoT landscape. This trend suggested the need for IoT standards. Why do standards matter?
Shelby: One of the major growth inhibitors of the Machine-to-Machine (M2M) silo era was a lack of useful open standards. The M2M community did embrace the Internet but maintained silos for all other aspects of their business, e.g., services and such. That’s why there was very little real growth in the M2M market and the growth that emerged was linear. M2M remains primarily an enterprise application business for car tracking, vending machine, etc.
One of the major reasons for the limited growth of M2M was a lack of real open standards. This lack hindered the creation of a new value chain of relationships because the technology didn’t allow for it. This time, for IoT, we need to provide standards that allow businesses (startups) to create devices that are decoupled from services.
Blyler: Why must IoT devices be separated from services?
Shelby: It is a proven approach, one that worked well on the Internet and the web. Any web-browser in the world works on any web server, thanks to a few basic HTTP, HTML and image standards. The reason for this success is that web-browsers applications were decoupled from the Internet services. By contrast, AOL and CompuServe were non-standard, proprietary ways to use the services of the internet - that was like the M2M days.
Today’s emerging IoT standards must enable the same kind of decoupling of devices from services. The goal is not to break down every value chain. We don’t want to commoditize (cheapen) all devices and make all the services generic. Rather, devices and services need to be decoupled from a technology perspective. Of course, a given service provider may bundle a cool sensor device with a free service that can only be used with that provider. There will always be these business (promotional) constraints. The point is that, from a technology point of view, the devices/apps should not be tied to the services. That will eliminate the costly need to completely redesign the technology for each company’s service.
Blyler: What standards are needed to help decouple IoT devices from services?
Shelby: At Sensinode, and now at ARM - we’ve made sure that there are Internet Protocol (IP) networks available to do this. 6LoWPAN is an example of one of those standards. [Editor’s note: 6LoWPAN is an acronym of IPv6 over Low power Wireless Personal Area Networks.] This standard ensures that any low power radio can speak to the Internet. That ensures that existing and newer low power radios can talk to the Internet, e.g., 804.15.4, Bluetooth low energy, Z-Wave and DECT Ultra Low Energy. The last two are interesting: Z-Wave is a wireless communications protocol designed for home automation, specifically to remotely control applications in residential and light commercial environments. Conversely, DECT Ultra Low Energy is an older standard that was originally developed for business phones- it is based on old DECT chip architectures.
Blyler: How does 6LoWPAN relate to the existing ZigBee standard?
Shelby: The original ZigBee standard was designed like an automated local bus. 6LoWPAN interfaces to ZigBee when a bus is needed, but extends ZigBee with a low-power interface to the internet. Even the ZigBee Alliance has come on-board by offering standardize 6LoWPAN protocol stacks for 4G, called ZigBee IP (see Figure 2). There is another adoption called ZigBee NAN (neighborhood area network), which is a 6LowPAN stack for outdoor use – sub-gigahertz, for very long range applications. It’s for street lighting and smart meeting applications and we will see some other really exciting things that will be announced later this year.
Blyler: At a physical level (PHY), a low-power connection to the internet seems critical for the evolution of IoT devices. Don’t you also need to provide an associated low-power mechanism at the protocol level (MAC)?
Shelby: Yes, the physical connection is important, but it's one piece of the standards puzzle for IoT. You also need a very efficient, low-power binary web protocol for the internet - that’s why we created a low overhead version of the web protocol called the Constrained Application Protocol (CoAP). [Editor’s Note: CoAP is an application layer protocol that is intended for use in resource-constrained internet devices such as small low-power sensors, switches, valves and similar components that need to be controlled or supervised remotely, through standard internet networks. (see Figure 3)]
The current HTTP Internet protocol is great, but has a large overhead. The M2M community addressed this issue with a proprietary binary protocol. It was the “silo” game again, i.e. always creating a new proprietary thing to address each new problem. To avoid creating these custom protocols every time a new system was needed, we (at Sensinode and ARM) focused on the open CoAP standard.
One the security side, we’ve also helped make the existing TLS-based security standard more efficient for IoT applications. Further, we’ve brought in a device management standard to make devices useable in IoT services. Such a standard helps to decouple the device from the service - that standard is called Open Mobile Alliance (OMA) Lightweight M2M. There is also a OMA-Device Management (DM) standard for low-power IoT cellular devices (see Figure 4).
Blyler: Why is device management important?
Shelby: Device management is needed to manage these devices remotely. For example, cellular device management is used to configure the phone and upload all the operator settings - most users don’t even notice it. This process will be very similar for IoT devices, i.e. getting the device configured for the needed services.
Device management is also needed to secure devices and configure who’s allowed to use the device. When a device gets older, it often goes without needed software and firmware updates. These issues are addressed by the Open Mobile Alliance (OMA) Lightweight standard.
Blyler: How are ARM and the Sensinode group engaged with these standard bodies?
Shelby: We participate in these standards with the ARM ecosystem partners or with a bigger industry group. For example, we are working with the core internet standards body – the Internet Engineering Task Force (IETF). On the device management side, we work with all the operators, telco vendors, and such via the Open Mobile Alliance (OMA). For IoT device semantics, we participate at the IP Smart Object (IPSO) Alliance.
The IoT community now has a good set of standards in place. Now the challenge is how to make these things easily available for developers who are building IoT devices for the marketplace.
Developers have many questions. For example, how will a device work with services? How do you find service and cloud software that works with the devices? Where does one find a service provider to host a device? These are all the kinds of questions we have to solve for the developer.
Blyler: Does this mean that ARM plans to offer technologies or services to address all of these issues?
Shelby: ARM can not do everything. Instead, we focus on the device ecosystem and enabling the cloud. mbed is a web-based development environment for Cortex-M designers. It has a directory-like structure that contains all your projects. GitHub is integrated so you can share projects. A designer simply selects an mbed-supported device from one of 20 or so platforms, secures an online account, imports a project and compiles that project. We supply a free commercial compiler. The end result is an executable binary that is downloaded to the flash drive of the device.
This cloud-based IDE approach is revolutionizing the way people think about embedded development. Compare this cloud-based approach to embedded development of the last decade. Then, the designer needed a specialized compiler that cost anywhere from $5k to $15k. Further, the necessary hardware – e.g. a flashing tool, a JTAG interface and a debugger - were typically locked onto one dedicated PC in the embedded lab.
Blyler: Earlier you talked about all of the open standards supported by ARM. How do those standards actually affect the embedded development process?
Shelby: We are starting to bring all of these open IoT-related standards to the mbed development platform, for the application layer (CoAP), security and device management standard support. There will be even more help in the future.
Blyler: Will most of the coding for future IoT designs be done in the C language?
Shelby: By various estimates, there are around 300 to 400,000 embedded C developers in the world today. Meanwhile, there are a million Java developers. Obviously, we need to make general development a lot easier. That is why we have been adding more support for Java-script on mbed. Look for Java ME support in the future. Our goal is to make IoT development via mbed easier for a larger range of people and start-ups.
Blyler: How will embedded developers incorporate cloud-based services into their device designs?
Shelby: In the past M2M siloed world, developers would have had special servers created and hosted in their own data center or on a cloud server. There was no decoupling of devices.
For IoT, we favor the approach proven by the Internet model where designers build web services out of the web infrastructure. For embedded development, designers can go to an ISP provider to get a web server. Similarly, to access a cloud-based infrastructure, designers can go to Amazon, Rackspace and the like for cloud hosting and related services like load balancers, database applications, etc. Of course designers still need to develop their actual web pages and functionality, business logic, etc - but the base infrastructure is there.