The Internet of Things – in which ordinary objects get smart and connected, making possible all sorts of new services – promises to give us smarter cities, fewer traffic jams, a cleaner environment and a Series victory for the Cubs. (OK, maybe not that last one.)
Trouble is, while lots of technologists and technophiles talk about the Internet of Things as if it were already here, there really isn’t any such thing. Not in any true sense of the term.
To be sure, there are plenty of smart gadgets out there that are wired up and broadcasting data to other devices – home alarms, for instance. Cameras. Heat sensors and hydrometers. But as you might have already noticed, we’re still a long way from the day when your refrigerator sees that you’re out of milk and orders a new gallon, or when your suitcase checks your calendar for out-of-town meetings and makes sure your travel clothes have been washed and folded.
Here’s why.
No Lingua Franca
In its most basic sense, the Internet is just a network that connects any given device to any other given device. That connection alone, however, doesn’t mean that these gadgets will know how to talk to one another, much less that they’ll have anything to say.
When devices can communicate, it’s generally via one or more “protocols,” or specialized languages for handling particular tasks. You’ve almost certainly encountered the most popular protocol on the Internet – the HyperText Transfer Protocol, or HTTP. (Yes, that’s the “http://” you sometimes see leading off Web addresses in your browser.) HTTP allows computers of all sorts to send files, images and videos to one another across the Web.
Like HTTP, many other commonly used protocols handle specific communication tasks. SMTP, POP and IMAP, for instance, are all e-mail protocols. FTP handles basic file transfers. And so on.
Special-purpose protocols like these generally work just fine, since Web, mail and FTP servers don’t normally have a lot to say to one another. (When they do, simple translation software handles the job.) As the Internet has evolved, it’s been easier to keep using a bundle of simple and stable single-issue protocols than to try to bundle them into anything more sophisticated.
You’re probably starting to see the problem. Devices on the Internet of Things may have to handle a bunch of different tasks. And there is very little consensus on which protocols to use. In other words, what we’ve got here is failure to communicate.
“All of the technology is undefined,” says Holger Reinhardt, a product architect at the cloud-management startup Layer 7. “The Internet of Things is an amorphous philosophy and terminology.”
A Tower Of Babble
So instead of talking directly to one another, devices on today’s nascent Internet of Things now communicate primarily with centralized servers controlled by a related developer or vendor. That works, after a fashion, but it also leads to a bunch of balkanized subnetworks in which devices can communicate perfectly well with each other – but can’t actually talk to devices on any other balkanized subnetwork.
Take cars. A Ford Focus, say, can communicate perfectly well with Ford service or data centers when sending data about itself over the Internet. If a part needs replacing, the car’s systems can report back to home base, which in turn generates a service notification to the car’s owner.
But say you wanted to create real-time traffic alerts based on information from cars currently on the road. Now you’ve got trouble, because your Ford is probably only set up to talk to other Fords – not Hondas or Porsches or Teslas. This is because they don’t speak a common language. So, for instance, there’s no easy way to let vehicles daisy-chain warnings that there’s road construction ahead or that an idiot driver is roaring up the shoulder at 90 mph.
Some of these issues are simply problems of network architecture – that is, deciding whether devices will communicate via, say, Bluetooth or NFC. Those are relatively easy to fix.
The protocol issue, by contrast, is a direct obstacle to the Internet of Things, because a bunch of siloed devices talking only to the companies that own them does not an Internet make. (Though maybe you’d end up with the CompuServe of Things. Catchy, no?)
Too Many Regional Dialects
Now, even competing car companies will eventually figure out that a common data protocol will be good for business. But that doesn’t solve the protocol problem – it just makes the silo bigger by including all new cars. There are still plenty of other devices that would like to talk to cars, but can’t – like, say, toll gates and gas pumps. They each speak a regional dialect the others can’t understand.
To consider this a little more closely, consider a “smart” living room featuring three devices connected to the Internet: a Nest thermostat, a Spark-enabled light and Makita automated drapes. Each device gathers data and sends it back to its manufacturer, and can take a handful of limited actions. If the room gets too warm, the Nest will turn on the air conditioning. If it’s dark outside, the Makita controller will close the drapes. If someone’s in the room and it’s dark enough, the Spark could turn on the light.
See what’s not happening? The Nest isn’t talking to the Spark, which isn’t talking to the Makita, which isn’t talking to the Nest. At best, you might be able to get a hub-style home-control system that could manage each of these devices. But such controllers often suck the same way universal remotes for your home TV setup do.
Note also how little it matters that these gadgets are connected to the Internet. The fact that they’re online only means you can control them – individually – from your smartphone. Big deal.
We can blame the exuberance of engineers. New technologies encourage a Wild West attitude among developers who want to pursue their own approaches instead of agreeing on common standards. As a result, we have an insane alphabet soup of protocols that govern how machines talk to each other: IBM’s MQTT, OMG’s AMQP-based DDS, RESTful HTTP, XMPP, CoAP, NanoIP and SSI.
To be fair, there can be good reasons for some of those different protocol dialects. HTTP, for instance, works great for always-on Web servers, which can easily handle the two-way, real time “request and response” style of Web communications.
But not all devices on the Internet of Things will be set up for that kind of inter-machine conversation. Gadgets whose batteries can run down, or which have to deal with spotty or weak signals, can’t always respond to real-time HTTP-like requests. That’s why they tend to rely on other protocols – ones that, for instance, pass messages from device to device opportunistically. (As in, for instance, the PubSub category of protocols, which includes MQTT.)
Still, the dialects present yet another challenge to the Internet of Things.
Show Us The Money
The only way a true interconnected Internet of Things will work, experts like Layer 7’s Reinhardt argue, will be when economic incentives push device makers to share access to their controls and to the data their gadgets generate. Right now, those incentives mostly don’t exist.
See, it can take a lot of effort to get smart things to talk to each other in meaningful ways. Reinhardt offers the example of a smart trash barrel in a public park. If a trash contractor wants to receive data from the barrel (i.e., is it full?), the barrel maker first needs to make sure it can talk to the trash contractor’s systems. Then it needs to give the contractor permission to access the barrel’s data.
These days, that first step can take a fair bit of time and trouble. In turn, that expense puts a damper on how frequently the barrel owner is willing to go through the process. It also makes data acquisition more costly to the trash contractor, who might just decide to have an employee walk past the barrel instead.
Now assume the barrel starts off able to communicate with the trash contractor’s systems. Now the barrel manufacturer could push a button and deliver its data to anyone with little pain or labor overhead. Once the process of allowing that kind of data sharing becomes easier to replicate, then device makers will be more interested in sharing data to generate revenue.
Connected Silos Or An Internet Of Islands?
Ultimately, the Internet of Things will take one of two shapes. If present trends continue, data to and from devices will largely be trapped within centralized silos, a la the home automation example above. Eventually, companies and vendors will interconnect those silos, rendering protocol differences all but irrelevant. And then economic incentives start to line up, too.
Data, however, would remain more difficult to share than it should be, given the need to keep building new links between silos. It would have to travel farther and might be subject to congestion at hubs, slowing down services. And the centralization of data could raise security and privacy concerns. Still, this setup would be much closer to a real Internet of Things than what we have now.
Alternatively, stronger and more widely used protocols used by more devices could create an “Internet of Islands,” in Reinhardt’s turn of phrase. Devices within a room could communicate directly with each other, the home and then their neighborhood. Data would stay in these smaller domains, speeding services and bolstering privacy.
This latter network represents a much more flexible and responsive Internet of Things. Once you’ve empowered different devices to communicate freely with other machines, automated systems can start to learn what’s going on in the world around them and adapt to human needs. Too bad current technology trends and near-term economics aren’t exactly paving the way for it.
Lead image of an automated home courtesy of Sony