Reader feedback on the 3 types of IoT

A few weeks back, I proposed that the internet of things is not a single, monolithic entity but could instead be broken down into three broad classes: enterprise, industrial, and consumer. It was something I had been unconsciously doing for quite some time, so it felt pretty natural to try to expand on the concept and decide which factors mattered for each class.

After I wrote that article, I got several responses, ranging from thoughtful insights into the security implications of how I tried to break down each type to calls for even more categories. I’d still like to hear your thoughts, but I also wanted to share some of the more insightful responses with y’all, which I have done below.

A few commenters suggested that I bring in other categories, among them military IoT and medical IoT. The primary reasons behind the suggestion of a military IoT category, which could be used to control drones or weaponry, were that we’d need extra security and in the case of drones, the networks would have to cover long distances.

The argument for a separate healthcare category was tied to an increased focus on life and safety. I feel like military IoT probably has many characteristics of the industrial IoT, but wonder if a medical IoT might develop that has feet in both the consumer IoT camp (ease of use) and the industrial IoT camp (a focus on safety and long-lived devices).

Another commenter thought the cultural differences between industrial and enterprise IoT were worth digging into, pointing out that my focus on their respective technical aspects neglected to address why each camp has different priorities when it comes to developing and deploying IoT products.

But perhaps the most thorough commentary came from two Emerson Automation Solutions executives, who sent me an annotated version of my original article. Both Mike Lester, who is a director of cybersecurity strategy, governance, and architecture, and Mike Boudreaux, a director of connected services, offered some new perspectives for all three categories. Below, I have highlighted their most relevant comments regarding what I deemed the enterprise and industrial categories, since that’s where their expertise (and most interesting points) lie.

I wrote: 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.

Michael Lester: I agree with your comments and will add this is evolving beyond documentation methods of the past and more toward the need for automated versions of device management that include audit trail and configuration management capabilities to ensure changes to the enterprise environment are quickly identified and assessed for risk. Larger enterprises will need to employ such automated tools to manage the associated cyber and operational risks. Provisioning and de-provisioning and lifecycle management of anything connected to your network are key to scalability and successful integration.

Based on Lester’s comments, it sounds like the work on digital twins could play an important role in the documentation, provisioning, and lifecycle management, associated with enterprise IoT devices.

I wrote: 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.

Michael Lester: I think you have framed the challenges well in your consideration. I think we need to keep this as one definition because the data being used in this space comes from older devices and systems using older protocols and newer devices using modern protocols. I even see the encapsulation of older protocols to extract data and provide value to the business or operations.

The data consumption model really determines if it is IIoT from my perspective. There are typically three operational areas data live in this model: Safety; Control and Analytics. From an IIoT perspective any data living in the Safety and Control areas should be for monitoring or read only and sometimes data diodes or other security controls are used to ensure this is strictly maintained. The separation of capabilities relative to the operational areas is paramount to maintaining the operational integrity and security in each. In the Analytics area, it is paramount that architectural and operational security be maintained to not allow access to safety or control functions as a primary imperative… or “do no harm”.

In addition to Wi-Fi and Bluetooth, we need to include other technologies like Advanced Physical Layer as connectivity continues to proliferate to enable more advanced capabilities in this space.

Mike Boudreaux: Smart thermostats, smart cars, smart buildings are a relatively new space. In the industrial domain, control systems are decades old and they are not directly connected to the Internet. They use older digital protocols like CANBUS (cars), BACnet (buildings), and standard multi-core wiring on A/C systems. The underlying control systems in the cars, buildings, and A/C systems are still based on these old paradigms. It’s the smart edge interface that is new, and along with that comes the ability to send telemetry data to the cloud, layer on more user-friendly UI interfaces, remotely push firmware updates from the cloud, and embed new data storage and processing software locally in the edge device.

The local MCU on the car isn’t directly connected to the Internet, and it is still performing the same functions that they have been for a while now. The same goes for the building lighting controls and the local embedded A/C system controllers that are connected to fans, compressors, and thermocouples. What’s new is the edge interface that layers on top of the existing embedded control systems technology.

So it seems like Lester is agreeing with me that both the older control systems data and the newer IP sensors are part of one broad industrial IoT category, but encourages me to consider what that data will be used for when I’m trying to establish the rules governing IIoT.

Boudreaux is trying to make a distinction between the old tech and IP tech by focusing on the liminal space between, or what he calls the smart edge interface. It doesn’t sound like he wants the smart edge interface to become a new category, but it’s clear he views it as a new computing concept with rules and best practices that we need to develop. I’m inclined to agree.