“I knew I was an unwanted baby when I saw that my bath toys were a toaster and a radio.” – Joan Rivers
It just wouldn’t be a technology conference without hours of discussion about “the cloud.” And so it came to pass, in the city of Santa Clara (on a cloudless day, hallelujah), that the word came forth, from exhibitor and visitor alike, that the cloud was nigh. And it was good.
There were clouds in the booths, clouds in the PowerPoint, and clouds on logos, on name tags, and in product releases. There were clouds from Finland, British clouds, and big ol’ American clouds. Clouds from every direction – dark clouds and light clouds, and boy, did they blow a lot of wind.
The host, owner, and chief proponent of said conference even brought its own cloud: ARM now offers mbed Cloud, a new cloud service to partner with its in-house embedded operating system, mbed OS.
The new mbed Cloud is like AWS (Amazon Web Services) for nerds: a cloud service for connecting and managing IoT devices. In something of a break from ARM tradition, mbed Cloud is sold as a subscription, not a one-time license or purchase. It is, in fact, an SaaS: software as a service. You subscribe to the portions of mbed Cloud that you want and pay as you go.
So why is this different from just setting up your own server somewhere and tunneling into it remotely? Well, inasmuch as all cloud services are the same, you could do that. But what mbed Cloud offers is preconfigured drivers and RTOS middleware that get you connected, keep you connected, and do various smart things while you’re connected. So yes, you could write all of that yourself, just like you could design your own CPU and create your own RTOS by yourself. But why would you want to?
Out of the gate, mbed Cloud comes with drivers for the mbed operating system, naturally. ARM isn’t saying so officially, but versions for Linux, FreeRTOS, and all your other favorite embedded operating systems are also on the way. ARM repeatedly pointed out that mbed Cloud isn’t just for mbed OS users. In fact, it’s not even restricted to ARM microprocessor users. The company will be quite happy to let you connect your x86-based, Windows-running, MIPS-accelerated hybrid system to its cloud. The cloud is agnostic.
As far as those smart things that mbed Cloud includes, the ARM spokesmodels rattled off acronyms like CoAP and LWM2M as examples of what it offers. The former refers to the Constrained Application Protocol, an industrywide standard-in-the-making that allows “constrained” devices (that is, those with limited intelligence, power, and sophistication) to communicate over existing global, standardized networks (i.e., the internet) without bringing down property values in the whole neighborhood.
LWM2M (Lightweight Machine-to-Machine) is a similar effort to reduce bandwidth requirements, and hence the power consumption, for simple IoT devices chattering amongst themselves. Part of the intent is to cut down on unnecessary traffic, such as when remote sensor devices have fairly slow-moving readings that don’t need to be polled frequently. The two standards are complementary, not antagonistic, and can be used together.
ARM also promises that mbed Cloud will include security features to slow down baby-monitor hackers, and failsafe features that should make remote firmware updates less of a crapshoot.
Since mbed Cloud is a service only and cares nothing for network topology, it was greeted with some enthusiasm by other members of the embedded-networking community. Mesh network, ring, bus, star, hypertree – mbed Cloud doesn’t care what your network looks like; only that it connects back to ARM’s servers somehow.
That may or may not be good news for Wirepas, a Finnish startup that works on low-power mesh networks. Wirepas doesn’t make network hardware. Instead, they’ve developed mesh-network firmware that works with your radio hardware to implement a mesh network among devices.
Most network vendors like to brag about their wireless range: “We can place nodes up to 100 meters apart!” In contrast, Wirepas stuffed about a hundred networked devices into a fishbowl to show how closely packed they can be and still work reliably. That turns out to be a problem with other mesh implementations, especially if you’re using them for inventory tracking, where items often get thrown together in a box or on a shelf. The minimum range, as well as the maximum, is important.
Wirepas also demonstrated its completely headless topology. Even though the identical firmware was running on a number of different vendors’ hardware, there was no “head” to the system; no controller or manager to oversee the configuration of the network or the transfer of data. Instead, the network is entirely egalitarian. Every node is as capable as every other node, and they all negotiate amongst themselves to hash out configuration, power levels, and data transfers. In the fishbowl demonstration, dozens of nodes all came to the independent conclusion that they could ratchet down their power levels to the absolute minimum and still be heard. Thus, the network reduced its own power consumption without any central authority commanding it.
If you’ve got your wireless hardware picked out but haven’t yet got around to coding the networking firmware, a long-distance call to Finland might be in order. And, if you’re planning to deploy a lot of devices, a detour to mbed Cloud might be worthwhile, too. Every rainbow has two endpoints.
