The Industrial Internet of Things (IIoT) involves an intensive data exchange and a certain level of interoperability between different kind of devices. The data can be collected locally or sent to cloud-based applications in order to be aggregated, stored, and analyzed. Due to the heterogeneous nature of the environment, some communication standards need to be established in order to facilitate the integration of hundreds, if not thousands of devices. Some protocols have emerged as candidates for the IIoT standard. In this post, we present an overview of three open standards: OPC UA, MQTT and HTTP/REST
The OPC standard has been around for more than a couple of decades and proved to be a good solution to some of the integration issues that are encountered in the industrial sphere. Before the OPC era, industrial applications such as SCADA clients and archiving solutions had to carry their own native drivers in order to communicate with devices made by different vendors. The goal of the OPC standard was to allow a common access to the data as well as widening the spectrum of data sources that industrial applications can connect to
Early versions of the standard, also known as OPC classic, were based on a Microsoft technology called DCOM following a client/server pattern. The client such as an HMI/SCADA connects to the OPC server through a predetermined DCOM mechanism then queries the interfaces to interact with the server
OPC clients use the interfaces acquired from the server to browse the address space, read, write and subscribe for data change notifications
While OPC classic is dependent on a Microsoft technology and hence on the Windows platform, the new version, called OPC UA (Unified Architecture), is platform-neutral which opens the door for embedded implementations of the protocol. In addition, OPC UA puts a strong emphasis on security and information modeling
Before exchanging OPC UA services, the server and client must establish a secure channel based on exchanging certificates, messages signature and/or encryption. In addition, a user authentication is often required when opening a session
MQTT is a client/server publish/subscribe transport protocol. It is lightweight and designed to have a small code footprint and limited network bandwidth consumption, which makes it ideal for IoT applications. By default, it runs over TCP/IP or other protocols that can guarantee ordered, lossless, and bidirectional connections
- Through a broker, the publish/subscribe pattern provides one-to-many dispatching and decoupling mechanism
- The messaging transport is unrelated to the application specific payload content
- Clients send messages to the broker in order to either subscribe for or publish data
- Information is organized in topics and clients can subscribe to specific topics and receive the data once published
After the initial connection handshake, client 1 subscribes to topics of interest. When client 2 publishes data, the broker publishes to all clients that subscribed to the topics
HTTP is a client/server application protocol that was initially developed for the world wide web to transfer hypertext documents. The industry has been using HTTP for applications and devices remote configuration but rarely for data exchange
HTTP/REST uses the GET, POST, PUT, DELETE (CRUD) well-defined HTTP methods to access data as resources, similarly to how a web browser would exchange files, forms data,…etc with a web server. The data format is typically either text, XML or JSON. Due to its overhead, HTTP/REST can be used to read records of data every hour but hardly every 100ms.
Client requests data (e.g. temperature) using an HTTP GET command, the response received from the HTTP server is typically some JSON object.
Finally, the figure below shows a possible deployment case of the three protocols
Possible deployment case: A PLC has generally the resources to implement the OPC UA services while sensors and actuators might use a lightweight protocol such as MQTT. Mobile devices can use HTTP/REST to access information.