There are 3 different versions of the IoT

We talk about the IoT like it’s a monolithic thing, but I’ve realized that in my head I often break it down into three different components, each with different characteristics. There’s consumer IoT, enterprise IoT, and industrial IoT. I suspect many others have a similar breakdown that they haven’t defined, but like obscenity, they “know it when they see it.”

So let’s start working on the definitions and characteristics. I’ll offer the caveat that consumer IoT can make its way into the enterprise and that enterprise IoT will likely overlap somewhat with industrial IoT. And I’d love to hear from y’all on this topic as well. Now, on to the definitions!

Consumer IoT: I have an elevated sense of what a consumer IoT device is. A few days back, a number of you alleged that if a thing is connected to the internet it’s an IoT device. That doesn’t make sense, however, because it would mean that my smartphone, printer, and computers are IoT devices, while my Bluetooth light bulbs and Z-Wave sensors are not (they connect to a phone and to a hub, respectively). So, I am going to posit that for consumer tech, an IoT device or a “smart” device is one that connects to a network, gathers data, and then uses that data to provide insights or take an automated action.

Consumer IoT devices need an interface via an app, website, or screen on the device; they should moreover provide a service as opposed to simply remote access. (I suppose the ability to turn down my thermostat from my couch is a service, but I want to see the data gathered by the device put to use.) So a Wi-Fi-connected oven that I can turn on or pre-heat from an app isn’t really consumer IoT unless it also has the ability to gauge my food’s temperature in order to better cook it, or if it can share its energy consumption data with the grid to help adjust the demand for energy in my home or in my neighborhood.

That’s an ambitious definition, and it doesn’t address real problems such as how we secure connected “dumb” devices like printers or the oven that has Wi-Fi for remote control. But I’m sticking to my guns here. And given this framework, consumer IoT has unique challenges that companies need to address. For example, consumers have relatively unsophisticated networks, so getting devices online should be easy. The traffic between the devices and the Internet should also be encrypted because consumers aren’t savvy when it comes to data protection. Given the number of potential connected devices in the consumer home, we’re probably going to need robust networks that can handle packet loss and occasional interference. This means TCP makes sense and local control of devices should be offered.

Because consumer IoT requires consumers to do the purchasing, budgets are important. Weird technologies that don’t benefit from economies of scale are less ideal. They also mean consumers will need hubs to handle translations between networks, which add cost and complexity. Consumer IoT needs to be built securely, with network redundancy, and at a low cost. Luckily, the technology is probably not going to have to stick around as long as industrial IoT, so companies can probably anticipate shelf lives of anywhere from three to 10 years. Yes, even for a connected light switch or thermostat.

Enterprise IoT: This category contains multitudes. Anything that connects to the internet, intranet, or LAN should be considered, if only because older, “dumb” devices on the network can still act as a point of vulnerability for network attacks. But outside of security and device management, I think of enterprise IoT more specifically as devices connected to an intranet or the internet which gather data and then provide insights based on that data, similar to the consumer world. Also like consumer IoT, enterprise networks can be chaotic and change often as devices move on and off the network. But unlike consumer IoT, these networks might also co-exist with other wireless or wired networks, such as those for fire and safety or environmental controls.

For enterprise IoT, documentation is probably one of the most important elements. Companies need to understand what a device is running and what it connects to so they can ensure it stays secure. There will also be more sophistication in the network, with prioritization schemes and perhaps separate networks for different devices. That sophistication should stretch to both the wireless and wired network. Encryption is important and so is lower latency, for some applications. Device management also needs to have a larger role in any app. Reducing the need for IT staff to physically have to touch a device is important, too. Decommissioning, commissioning, and management should be done in bulk and from a web-based or app-based platform.

Access control is also essential. Not all employees should have access to every device or its data, nor should they have the ability to change the settings. And enterprise IoT devices are expected to tie into existing enterprise applications. That means such devices should have ways to display what data, exactly, they are sharing and who they are sharing it with. Any APIs associated with enterprise IoT devices should also follow best practices around API documentation and change notifications.

Industrial IoT: The biggest question I have about industrial IoT is whether or not I should consider including it in the same category as older industrial protocols such as SCADA, PROFINET, or HART. None of them connect to the internet, but rather to a special controller that automates or alerts workers to problems. It is old-school, machine-to-machine communication. But in the last few years, we’ve seen the addition of IP devices that use Wi-Fi or Bluetooth to connect to machines that speak those protocols. Usually, they are monitoring the machines and communicating back to a gateway. And the internal SCADA traffic never comes in contact with the IP traffic.

But currently, the goal is to put more industrial traffic on IT networks. To that end, we’re seeing adaptations to Ethernet, such as Time-Sensitive Networking, which tries to reduce latency on IP networks. Security is also important for industrial IoT because of the potential for catastrophic failures in equipment, or even the loss of life if machines get hacked. In most cases, the networks are air-gapped and never connect to the public internet. Workers are trained specifically on ways to avoid bringing in devices that could create a vulnerability. Enterprise IoT could probably learn and thing or two from industrial IoT networks.

And finally, industrial IoT networks should be designed for the long haul. Factories and the equipment inside them are 20-to-50-year investments. The communications and computing equipment associated with industrial IoT has to be rugged and modular so it can be upgraded easily. But even easy upgrades don’t mean that those upgrades will happen often. Think instead in terms of annual patching and 10-year update cycles.

These are incomplete ideas and definitions, but I would love to hear from you all about where I’m missing elements or outright wrong. I look forward to having this conversation.