We've talked about some technologies, like edge computing and RESTful APIs, that reduce system architecture complexity for the Internet of Things (IoT) or Industrial Internet of Things (IIoT).
Reducing complexity is essential to making the IIoT work, especially for getting data from existing sensors, equipment, and devices that are functioning fine in the field but have no built-in IoT capabilities.
The ROI just isn't there if you have to install complex middleware and pay for expensive integration work. So our REST API for SNAP PAC controllers reduces that complexity and puts IIoT applications within practical reach.
Another technology that’s helping to reduce IoT architecture complexity is the MQTT (MQ Telemetry Transport) protocol. Let's look at what it does in comparison to something automation professionals are more familiar with: OPC. MQTT and OPC are protocols designed for different applications and tasks, but it's useful to compare what they do and how.
OPC
OPC was designed to connect applications running on Windows operating systems to industrial automation devices for data access.
In 1996, automation vendors Fisher-Rosemount, Intellution, Opto 22, and Rockwell Software formed a task force to develop a standard for industrial device data access based on Windows COM and DCOM, and named it OLE for Process Control, later shortened to OPC.
The major drawback to OPC in its original form (-DA, -HDA, etc.) is that it utilizes a mandatory client-server architecture where a Windows-only server brokers device specific custom drivers and protocols from many different devices up to standard OPC clients again running only on Windows systems.
The recent OPC UA specification attempts to overcome requiring a dedicated Windows PC by removing reliance on COM/DCOM and permitting a server to be embedded into an edge product like a PLC or PAC.
Unfortunately, hardware vendor participation with this approach is meager, and there are few OPC UA software clients available (notable exception: groov). In addition, OPC (and OPC UA) is a large set of specifications spanning more than 13 documents and 1000 pages.
The standard specifies many aspects including transport protocols, security, services, information models, profiles and others. Vendors that choose to embed an OPC UA server into their products should consider development cost and time to market, flash and RAM footprint size, CPU utilization, and ongoing support costs.
When considering OPC for an IIoT application, routers, firewalls, and VPNs (virtual private networks) have to be addressed. All in all, OPC is an excellent solution for Windows software to exchange data with legacy systems particularly on a local area network. However, for IIoT applications where data is being transported among different types of devices with different operating systems and constrained hardware footprints through varying network architectures, an alternative protocol may be a better fit.
MQTT
MQTT is a transport protocol that pushes data using a publish/subscribe (pub/sub) architecture, and offers several distinct advantages in IIoT applications: open standards and suitability for remote or tenuous connections, and for devices behind a firewall.
In a pub/sub architecture, clients subscribe to topics that contain data, which are hosted on an MQTT broker.
In a typical IIoT application where MQTT is used, you might see a PAC (programmable automation controller) at a remote site publishing its I/O status under a given topic to a broker located at a headquarters location. Then other systems, such as HMIs, can subscribe to the topic on the broker and be updated as the state of the I/O changes.
One of the greatest benefits MQTT offers in IIoT applications is that it’s an open protocol and OASIS standard. This means system developers can adopt MQTT as a communication protocol in their designs no matter what OS their systems are built around.
Adding MQTT to a newly designed device is generally easier than embedding OPC UA into a device. MQTT is also an extremely lightweight protocol, which means it uses less bandwidth to send data than other protocols, such as OPC. This is important in IIoT applications where things may be deployed in remote locations with network constraints such as low bandwidth, high latency, data limits, or generally fragile connections.
MQTT’s pub/sub architecture also makes it ideal for IIoT applications because it pushes data to a broker using an outbound connection. Most firewalls block inbound traffic (for example, an external OPC client requesting data from an internal OPC server) but allow outbound connections over secure TCP ports, such as 443 for TLS/SSL.
In an IIoT application, for example, a PAC deployed on a remote oil well could open an outbound connection through a firewall and phone home to report its data to an MQTT broker that resides at headquarters.
Looking Ahead
As the IIoT continues to roll out, applications will become further streamlined and system architecture will become less complex.
Two keys to achieving those goals are leveraging edge computing and MQTT in IIoT applications. And these technologies are available or soon will be in common, off-the-shelf products from Opto 22.
See SNAP PAC controllers with RESTful API and edge computing capabilities.
