The Future IoT: Building Better Legos
Originally published in IEEE Computer February 2017
The Internet of Things (IoT) is going through a rough patch. High-profile products like Nest home devices, Amazon Echo, and even Google Home are getting mainstream attention, yet a string of security failures (such as Wink and WebCam) is worrying many potential customers. To make matters worse, those who actually try to set up a smart home usually run into numerous problems, ending up with a patchwork quilt of incompatible devices from various vendors and phone apps as well as siloed server accounts. The vision of the IoT burns bright for many of us, but it’s getting off to a rocky start.
The adoption of any new technology is always a bit uncertain. It takes a while to figure out the best use cases and what the core underpinning technology should be. For example, early automobiles used tillers instead of steering wheels simply because tillers were easier to implement. Basic technologies such as rack-and-pinion steering weren’t initially available to make wheels practical.
As an industry, we’re at a similar point today with the IoT: we want a steering wheel, but we don’t have the right underpinning technology. We’re effectively forcing the technology at hand into service, even if it’s not really right for the job. It’s akin to building a Lexus out of Legos: it’s possible, but the end result is far from ideal.
We must back up a bit to gain some perspective and explore new technologies and tools to make this process easier. It’s time that our industry built better Legos. The purpose of this article isn’t to find a solution, but instead to frame the solutions we need.
Mapping Out the Space
As an exercise in perspective, let’s start with a simple 2×2 matrix where the vertical dimension moves from a single device to an ensemble of devices working together. Solo products like smart door locks are at the bottom, and a collaborative space of thousands of devices (such as a smart parking lot) are at the top.
The horizontal dimension is a continuum of control, so it’s a bit more nuanced. It starts with direct control on the left, moving toward distributed control on the right. Direct control would be unlocking a door with your phone or navigating a parking lot with your car — nothing happens until you make it happen. With distributed control, devices monitor and control one another and react autonomously, with no input from you at all. Of course, most solutions fall between these two extremes.
Let’s start in the lower-left quadrant, where the majority of today’s smart devices are (such as light bulbs, switches, door locks, and thermostats). These individual devices have their own remote-control apps and siloed cloud data. They’re the easiest devices for companies to develop as there’s little pressure to standardize, cooperate with other manufacturers, or share data collectively. With these devices, companies can move quickly and try out new concepts. The downside is the resulting fragmentation: these products don’t work well together.
The upper-right quadrant is our aspirational vision of the smart home — a vast ensemble of distributed devices working in concert. You don’t control the ensemble directly as much as it reacts to you. You go about your life and the home keeps you warm, manages your energy usage, wakes you up, and even feeds you. Unfortunately, we aren’t very close to this vision, but it’s nonetheless a huge motivational force for the industry.
Although we aren’t yet seeing any practical examples of distributed ensemble houses, we are seeing larger, more rigid ensembles like smart parking lots (which reside in the upper-left quadrant of direct ensembles). These are usually tightly coupled by fixed rule sets and direct control mechanisms, either through a phone or simple sensors. Much of today’s confusion around the IoT comes from the fact that we don’t really understand the difference between a direct and distributed ensemble of devices. Mostly because a truly distributed ensemble is exceedingly difficult to create and hasn’t been fully realized yet.
There aren’t many practical examples today of the distributed devices in the lower-right quadrant, but these would include physical or virtual devices that monitor sensor data to act and control others. These devices wouldn’t be stand-alone; they would take input from a range of devices as well as control others. Imagine a super-smart independent vacuum cleaner — much smarter than what’s available today — that tracks a home’s “dirt level,” automatically running when needed and even instructing objects to move out of the way when cleaning begins. This might seem a bit futuristic, but given the huge strides in machine learning and the plummeting cost of capable processors, this level of independence seems inevitable.
Layering Legos
We’re making progress by breaking up today’s vague concept of the IoT into “what we’re capable of building” and “what we’d like to build.” However, moving in this direction is a daunting task and we’re stuck using our existing clunky Legos.
One of the reasons the web has been so successful is that it’s open and layered. Everything from lower-level transports to higher-level content are their own open layer, so they can each grow and improve independently. The web has used this approach for more than 25 years, and while it hasn’t always been rapid, it has resulted in quite a bit of trust and growth as no one company or organization owns the entire stack. The IoT could greatly benefit from a similar approach. Imagine one company controlling the API of every smart device on the planet. It’s too vast a space for this to be possible.
How can we break up the IoT into a set of layered Legos? What would radically transform our goal of distributed ensembles? I’ll discuss four ideas that aren’t concrete solutions, but rather an attempt to break things up into more manageable protocol layers. There might be issues with my suggestions, and you might have better ways to solve them. What matters is that we agree the attempt is worthwhile. If we don’t, it seems unlikely that smart devices will take off in any meaningful way.
Lego 1: Smart Setup
Imagine trying to add 100 smart devices to your home today. This thought fills most technology-minded folks with dread. If we believe that the cost of computing will continue dropping, per Moore’s law, we’ll soon be adding hundreds of devices to our homes and businesses. There must be a simple, standardized way for devices to both present themselves to a network and join it securely.
Here’s one aspirational flow:
- Turn on all devices.
- Have an app/webpage on a smartphone that shows all devices at once.
- Review and approve them all with one click.
- Securely add these devices to the network with the correct credentials for encrypted communication.
This is the “magic” approach to the problem — our holy grail. Unfortunately, the world can be a dangerous place, and there are all sorts of ways bad actors could sneak in. The default solution today is to force users to add devices one at a time, typing cumbersome passwords, using encryption keys, or even scanning QR codes. Although clearly more secure, this is impractical for most consumers. So how can we get as close to this magic flow as possible?
Instead of adding new devices with full access to the network, we could separate joining the network from being allowed access. In other words, new devices are added to a separate and isolated network but restricted until their addition is physically confirmed. Depending on the security required, there could be a range of solutions, such as
- simply letting the devices join automatically;
- physically confirming device proximity by pressing a button on the device; and
- using some type of short-range RF exchange, which also confirms proximity.
The problem is that most of the more secure options are done in a way that’s complex and even error-prone. This problem is rarely viewed from a user-experience point of view. If we can figure out a way of implementing these solutions securely and without user interaction, we can unlock the ability to onboard a mass of devices at once, vastly simplifying the setup of larger ensembles of devices.
Lego 2: Semantic Map
The next challenge to setting up a large number of devices is that it’s too hard to map the device on the network to the device in the physical world. Figure 2 shows a sample floor plan with just two types of devices: smart lights and motion sensors. At least, that’s the goal. Assuming you can even get all the devices securely added to the network (the first Lego), what you’re left with is a collection of effectively blank-slate devices with no idea where they are or how they should be organized.
The map in Figure 2a is what we’d like to see, and Figure 2b’s list is the harsh reality. The challenge of this scenario is that once a device is added to the network, the network should then reply and send helpful information back to the device. Information such as the device’s location, the name of the room it’s in, possibly a list of other devices in the room, and even a map of its surroundings should be made available to the device so it can make decisions. A simple example is plugging in a smart lamp and having it automatically turn on when the nearby wall switch is flipped. You can override this, but the goal is for devices to automatically behave in a meaningful way with little user interaction. A semantic map is the first step to making this happen. The current work being done by the BLE Mesh group and their concept of “Rooms” is a great start in this direction.
Lego 3: Standard Descriptions
Devices also need to know what other devices they can talk to. When I wire a standard light switch to an electrical outlet in my home today, I don’t care who makes either one — I just connect them and they work. The same must eventually happen for smart devices. We need a common way for devices to announce their capabilities to the network so it’s clear what devices are available and what they’re capable of doing. This is especially important because these new devices are likely to perform multiple tasks.
Several groups are currently working on this issue, such as the BLE Mesh project and Schema.org, so I’m hopeful that we’ll have a shared, common approach soon. The biggest questions are how long it will take for everyone to agree on this categorization, and whether the capabilities of each device will continually improve so that new functions can be added as new devices emerge.
Lego 4: Centralized Data
Today, each smart device usually creates its own island of data. It’s impossible for one device’s sensor data to be readily useful to other devices. Keep in mind that it isn’t just immediate events that are of interest — historical data is even more valuable, given recent strides in machine learning.
Of course, very difficult questions about privacy and access must be addressed. However, whenever I bring up this issue, the first thing I hear is “no company will ever give up that data.” This is likely our biggest challenge: encouraging manufacturers to allow device owners to control the devices’ collected data.
If we can’t tackle this, how will the increasingly smart devices in these systems reason about their surroundings? How will we unleash the power of machine learning across a range of sensors and devices? It seems critical for future smart homes or factories to have a centralized data source so that all devices (with permission) can reason over it.
Conclusion
There’s so much more to say about smart homes. This article isn’t trying to push any specific solution but instead suggests a more holistic approach: getting us to step back and agree on the shape of the solution we’re looking for. As a community, we must have a shared starting point and these four Lego bricks represent the base networking technologies all smart devices could have. This base would take much of the risk and burden off manufacturers and unlock an entirely new category of devices that could safely be added to homes and businesses.
