Plethora Of Protocols

Purdue and Information FlowI’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).

OIIE Architecture

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.

Be Sociable, Share!

, , , , , , , , ,

2 Responses to Plethora Of Protocols

  1. Satish March 23, 2016 at 12:45 am #

    Nice summary Gary! Standardization is a double edged sword for vendors and always there is a cautious approach. You know what happened with Real time Ethernet, Field bus & ISA 100 standards. It will take its time to mature when customers demand it and vendors are happy with the ROI. I could see how vendors make money in integration through OPC by supporting the standard but adding cost when it comes to usage of it (fine letter prints?). Probably when automation system becomes COTS system it will be a drastic change – XOM’s project with Lockheed Martin is aimed at it, am not sure!

  2. Jake Brodsky March 23, 2016 at 10:16 pm #

    I often refer to IoT as “SCADA in drag.”

    Standards are great. I think everyone should have one! (I stole that from Andrew Tannenbaum, the creator of minix)

    I tire of these “IT experts” making the same mistakes that Engineers made over 20 years ago, while marketing “NEW!”, “BETTER”, and “WE REALLY NAILED IT THIS TIME”
    They still don’t realize that Engineers have been doing this since before TCP/IP existed. I can cite protocols that were designed, served for decades and died out that were no better than what they’re proposing here.

    Unfortunately, most of these new-comers are discovering this SCADA thingy for the first time, and (God help me) they’re making the same dumb mistakes that people made decades ago.

    I expect most of these protocols to die a slow, painful death. If you want a laugh at what these people are doing with these protocols see the twitter account @internetofshit. You will be appalled.

Leave a Reply


Follow this blog

Get every new post delivered right to your inbox.