Plethora Of Protocols
I’ve spent way too much time on the phone and on GoToMeeting over the past several days. So I let the last post on the hierarchy of the Purdue Model sit and ferment. Thanks for the comments.
Well, I made it sound so simple, didn’t I? I mean, just run a wire around the control system and move data in a non-hierarchical manner to The Cloud. Voila. The Industrial Internet of Things. Devices serving data on the Internet.
Turns out it’s not that simple, is it?
First off, “The Cloud” is actually a data repository (or lots of them) located on a server somewhere and probably within an application of some sort. These applications can be siloed like they mostly are now. Or maybe they share data in a federated manner—the trend of the future.
To accomplish that federation will require standardized ways of describing devices, data, and the metadata. I’ll have more to say about that later relative to some white papers I’m writing for MIMOSA and The OpenO&M Initiative.
Typically data is carried by protocols. OPC (and its latest iteration OPC UA) has been popular in control to HMI applications—and more. Other Internet of Things protocols include XMPP, MQTT, AMQP. Maybe some use JSON. You may have heard of SOAP and RESTful.
Will we live with a multiplicity of protocols? Can we? Will some dominant supplier force a standard?
Check out these recent blogs and articles:
GE Blog – Industrial Internet Protocol Wars
FastCompany, Why the Internet of Things Might Never Speak A Common Language
Inductive Automation Webinar — MQTT the only control protocol you need
OPC – Reshape the Automation Pyramid (is OPC UA all you need?)
Interoperability Among Protocols
What we need is something in the middle that wraps each of the messages in a standard way and delivers to the application or Enterprise Service Bus. Such a technology is described by the OpenO&M Information Service Bus Model that is the core component of the Open Industrial Interoperability Ecosystem (OIIE) that I introduced in the last post. The ISBM is actually not a bus, per se, but a set of APIs based on Web Services. It is also described in ISA 95 Part 6 as Message Service Model (MSM).
The MSM is described in a few points by Dennis Brandl:
- Defines a standard method for interfacing with different Enterprise Service Buses
- Enables sending and receiving messages between applications using a common interface
- Reduces the number of interfaces that must be supported in an integration project
Here is a graphic representation Brandl has developed:
These are simple Web Services designed to remove complexity from the transaction at this stage of communication.
