OK, I have to admit it. There is nothing on the face of technology today that fills me with the mixture of hope and admiration and disgust and dismay like the Internet of Things. Even the name often annoys me. It brings to mind the notion of my thermostat setting itself up a social network account. The hype on this topic is so extreme, the exaggerated impacts so profound, that I’d despair and call it all a sham were it not for the fact that there is real value here. We’re just so entrapped in crap that we’re not seeing it, and we’ll never prepare for the real parts if we can’t get past the exaggerations.
Home control is a big part of the IoT, right? Suppose that we were to make every light, every outlet, every appliance, every motion sensor or infrared beam in every home a sensor. How much traffic would this add to the Internet. Zero. None. Suppose we were to place similar controls in every business. How much traffic? None. Even if we were to add sensors to every intersection, add traffic cameras, add surveillance video to every storefront we’d add little or nothing. We already have a lot of this stuff and it generates no direct Internet impact at all.
Control applications aren’t about broadcasting everything to everybody, they’re about letting you turn your lights on or off without getting up, or perhaps even turning them on automatically. You need to have sensors to do that, you need control modules too, and controllers, but you don’t need to spread your home’s status out across the Internet for all the world to see. Sensors on sensor networks don’t do much of anything, and most controllers don’t do anything to traffic either.
How about the fact that “home control” can sometimes be exercised from outside the home. There are times when you might want to turn your home lights on from your car as you drive onto your street. There are times when you might want your home to call you (to tell you your basement is wet) or call the police or fire department. The thing is, we do all of this already, and it’s not like your home is going to call you every minute even if it could. The fact is that in a traffic sense the IoT is kind of a bust. Similarly, it’s not going to add to the list of things that need IP addresses; most sensors and controllers work on non-network protocols and those that don’t use private IP addresses that aren’t visible on the Internet anyway. If you call your home from your cell to turn your lights on, you’re likely only consuming a port on an IP address you already have.
Besides being an obviously great yarn to spin, does the IoT actually offer anything then? I think it does, and I’ve blogged about a part of what it might offer in the past. We could expect to see control domains (sensors and their controller) abstracted as big-data applications available through APIs for the qualified to query. We could expect to see some of the real-time process control stuff, which is what self-drive vehicles are conceptually related to, generate “local” traffic that might even get outside our control network and touch online. But traffic isn’t going to be where IoT impacts things, nor will addresses or any of the stuff you always hear about.
The biggest impact of IoT on networking is in availability. If I want to turn on my home lights as I drive up, I don’t need a lot of bandwidth but I darn sure need a connection. If I were to find that most of the time my lights-on process failed, I’d be looking for another Internet provider. If I’m expecting my car to turn left when it’s supposed to and it runs forward into the rear of a semi because it lost Internet connectivity, I’m going to be…well…upset.
The Internet is pretty reliable today, but most home alarm systems don’t use it, they call out either wireline or wireless on what’s a standard voice connection because that’s more likely to work. Unless we want the Internet of Things to be phoning home (or out from home) in our future (how pedestrian is that?) we have to first be sure it can do the kind of stuff that’s already bypassing it for availability reasons. But would we pay enough for that availability improvement?
A second big impact is latency. My car is moving down the street and the sensors around on the corner and lamp-posts tell the Great Something that another vehicle is approaching on the side street. If it takes two or three seconds for the message to get to the controller, be digested, get back to my car, and be actioned, and I’m moving along at 60 mph then I’m a couple hundred feet along before recommended action can be taken. Even a hundred milliseconds is nine feet at my hypothetical speed. I can hit somebody in that distance.
Related to this is the third impact, which is jitter. Whatever the character of a control loop, the worst thing is a lack of stability in its performance. You can design around something or avoid using it if it stays where it is, but if it jitters all over the place you find yourself stopping at the stop sign one minute and hitting the semi the next. That sort of uncertainty wears you down and surely reduces the sale of self-drives.
Home controllers offer what I think is the logical offshoot of all these issues. Why do we have them? You have to shorten control loops where real-time responses are important. Rather than try to create a sub-millisecond Internet everywhere, the smart way is to host the intelligence or the controller closer to the sensors and control elements. So what we need to be thinking about with IoT isn’t traffic on the Internet or addressing or even Internet latency and jitter, it’s process placement.
Network standards won’t matter to IoT. What matters is inter-controller communication, big-data abstraction APIs for raw information access, and the like. My car controller has to talk to its own sensors, to local street sensors, to route processors, traffic analyzers, weather predictors, and so forth. None of this is going to create as much traffic as a typical teen watching YouTube but it will create a need to define exchanges, or we’ll have cars running into areas where they can’t talk to the local control/sensor processes and whose drivers are probably watching YouTube too.
Making stuff smarter doesn’t necessarily mean it has to communicate, or communicate on a grand global scale. What is different about “smart” versus “dumb” in a technology sense isn’t “networked” versus “non-networked”. Being connected isn’t the same as being on the Internet. The key to smartness is processes and the key to extending real-time systems over less than local space is process hierarchies. Processes will be talking to processes, not “things to things” or “machines to machines”. This is about software, like so much else in networking is. It’s about the cloud, and it’s process hierarchies and cloud design that we need to be thinking about here. The rest of the news is just chaff.
Our thermostats don’t need to talk to each other, but if yours has something to say about this feel free to have it call mine, and good luck to the both of you getting through.