In our write-up of the ABC Wellsite Automation conference earlier this year we have reported on emerging internet of things-style communications protocols with what appeared to be a battlefront between OPC-UA and MQTT. In an effort to get a grip on the technologies we quizzed the experts at Kepware asking the following:
Oil ITJ - We see that interest continues in MQTT. But also, some talk of OPC-UA. These two protocols have both been touted as being vehicles for the other – i.e. MQTT over OPC-UA and OPC-UA over MQTT? Does either of these ways of using both protocols make any sense – or are they even possible?
Sam Elsner (Kepware) - MQTT is a data transfer ‘framework’ i.e. a combination of a data transport protocol (TCP) and a level of standardized application-layer behavior sets. In MQTT these include username and passwords and client IDs along with sets that specify what MQTT publisher/consumer/server roles should do for message confirmation beyond what TCP provides. MQTT doesn’t define what is transferred, it doesn’t define the data payload, just a way to transfer it. You could transfer pictures, music, video, read commands, write commands, text, binary encoded values – it’s all just bytes to standard MQTT.
There are a few emerging MQTT-based data models. JSON for general purpose, text-based messages, generic, binary protocol buffers for specific use cases (Google Protobuffers, for example), OPC UA data models for OPC UA Pub/Sub (more on that below) and SparkplugB, which is a new, formal specification built on binary protocol buffers, and that includes a number of application-layer behavior sets above and beyond what’s found in standard MQTT. It’s created by the same people that invented MQTT. You would probably want to consider SparkplugB a new, MQTT-based protocol rather than just a data model for MQTT.
In contrast, OPC UA (and most all OPC specifications) define both the data transfer framework and the data payloads, so comparing MQTT and OPC UA is a bit like comparing a basket (MQTT) with a basket of apples and oranges (OPC UA). OPC UA defines that apples and oranges exist in a basket where MQTT just defines that a basket exists.
OPC UA Pub/Sub is a mapping of OPC UA data models onto MQTT (and AMQP, a similar protocol). In other words, OPC UA Pub/Sub actually uses MQTT (or AMQP). More from the OPC Foundation.
Oil
ITJ –
That’s clear. Another question. Where does HTTP and REST fit into this
picture (if at all)? We are curious to know how a protocol
like Energistics Witsml (which is REST-based) fits into the picture.
This, afaik defines both low level protocol and payload.
Elsner
- REST is a client/server protocol design paradigm for Web Services
that is stateless, where ‘stateless’ means that each request contains
the complete amount of information needed for the server to process a
response: authentication information and request details and any other
information that’s required in order for the server to properly
identify the requester and service the request command. The RESTful
client requires no higher level (presentation, application layer) setup
messages to begin sending requests to the RESTful server, and there’s
no expectation by the server of the client issuing subsequent requests.
The data transport protocol can be either TCP or UDP. With TCP, the
higher layers (presentation, application layers) can define that the
TCP socket be maintained but these higher layers do not ‘maintain’ a
connection with the server themselves. There’s a ton of great info on Wikipedia.
This contrasts with a stateful interface where multiple messages are used to construct an active ‘session’ or conversation between client and server before the client can request certain actions to be taken by the server. The server is also given the indication that the client will be using this active conversation for a period of time, so the server should expect additional requests. The paradigm doesn’t make any statements about the actual protocols that follow this paradigm, meaning that it’s possible for a RESTful protocol to define only the ‘data transfer framework’ as I define MQTT above, or the whole transfer framework and the data payload.
HTTP is an example of a RESTful protocol where, native to HTTP’s design, each request contains the total information needed to process its response. There are others, but HTTP is by far the most commonly utilized, so the names REST and HTTP are often used interchangeably. HTTP, like MQTT, does not define a data payload. From Wikipedia I learned that the HTTP 1.1 protocol and the RESTful protocol design paradigm were developed at the same time by the same person, which is probably why the terms are so interchangeable today. Witsml is an HTTP-based and therefore RESTful protocol that also defines a data payload.
© Oil IT Journal - all rights reserved.