IOT – The Elephant in the Room

I’m sure you’ve heard the term “Elephant in the Room”. It’s a common way to refer to a situation or problem that everyone knows about but no one wants to address. The origins of the term are actually pretty recent. Wikipedia lists the first reference to it in print from the New York Times in 1959, though there are a number of older references that you can find that are similar.

Today, I’m going to directly point at and call attention to the elephant in the IoT room. The elephant in the IoT room is the lack of context (metadata) missing from all of the popular IoT solutions.

All the popular IoT solutions being implemented are simply transports. MQTT, DDS, AMQP, HTTP, HTTPS and all the rest are just mechanisms for moving some kind of payload packet from one place on the Internet to some other place on the Internet. Some of them use brokers or intermediate destinations for the packets, but they still just move bytes from here to there.

No Meaningful Connection

It’s like going to a restaurant where you don’t order; rather,waiters and waitresses simply bring you some dish to eat and a glass of something to drink. When it arrives, you have to taste it; the drink might taste like some kind of dark beer, the soup may resemble minestrone. But you can’t be sure because there hasn’t been any meaningful connection between you and the chef.

And that’s exactly what the problem lies with all these IoT protocols. A packet arrives on a protocol like MQTT and it’s seven bytes long. That’s nice. MQTT is sending me seven bytes from the rooftop ventilator at the office building I own. But what are the seven bytes? Do some of those bytes contain the outside temperature? Do some contain the running hours for the unit? Are there alarm bits in there I should know about? Is the data integer? Floating point? Boolean?

The elephant in the IoT room is…there’s no good way to know. This whole problem isn’t addressed by any of these IoT technologies that are so popular and it’s a really important issue. The elephant is HUGE and it’s where the cost lies.

An Expensive House of Cards

Integration costs kill projects. If you are trying to collect data from 50 different devices in a building, and you need someone to look at each of those devices, figure out what byte is what, extract those bytes, convert it to a format you can use, and then program some sort of system to use it, you are spending massive amounts of money. And you are building a house of cards because the next time one of those devices gets new software and adds another byte, the system falls apart.

I don’t really see anyone addressing this issue (Project Haystack is making an attempt in Building Automation) and I don’t know why. OPC UA is the only place with something of a solution. With OPC UA a client device can interrogate a slave, identify what data it wants, and find the data type. The data type information can be located right in the server device, or if it’s a data type created by a third-party organization, there will be some sort of URI which indicates where the data typing information is located.

For example, you might have a variable called oil porosity in an oil and gas system. The data type for that variable is oil_porosity_type. In the UA server you can follow the links to the type and find out that the oil and gas trade association is the creator of that type and that there is an XML definition for that type on a particular website. No elephant in the room in this case.

I’m not sure how all of this is going to play out. The elephant is too big to be ignored. It may just come to a head when everyone starts adding up their IoT integration costs.
I’ll be watching, and if that elephant starts moving around, I’ll let you know. I don’t want you to step in it.