MAY-JUN 2018

Issue link:

Contents of this Issue


Page 23 of 53

24 INTECH MAY/JUNE 2018 WWW.ISA.ORG FACTORY AUTOMATION T here are two main methods for imple- menting network communication in a data collection or remote access application: request-response and publish-subscribe. In the request-response model, a client computer or software requests data or ser- vices, and a server computer or software re- sponds to the request by providing the data or service. In industrial remote access appli- cations, the client is typically a laptop, PC, tablet, or smartphone. The client requests data from the server, usually a controller, such as an EPIC, PLC, or PAC. A different way, which is often preferred for remote access applications, is for de- vices to communicate on a network called publish-subscribe, or pub-sub. In a pub- sub architecture, a central source called a broker (also sometimes called a server) receives and distributes all data. Pub-sub clients can publish data to the broker, sub- scribe to get data from it, or both. Clients publishing data send it only when the data changes, often referred to as report by exception. Clients subscrib- ing to data automatically receive it from the broker/server—but again, only when it changes. The broker does not store data; it simply moves it from publishers to subscrib - ers. When data comes in from a publisher, the broker promptly sends it off to any client subscribed to that data. MQTT is a popular and open transport protocol used with the pub-sub architec- ture. MQTT is extremely lightweight. It takes up almost no space in a device, so that even small devices with very little com- puting power can use it. But MQTT does not define how the data is packed or un- packed, so another standard is useful, such as Sparkplug that encodes the data payload and defines how the data is packed before it is sent by the publisher and how it is un- packed at the subscriber. Data sent over MQTT with Sparkplug is compressed and efficient. MQTT messages packed with the Sparkplug definition must also be unpacked with Sparkplug, so both publishers and subscribers must use it in or der to get the data delivered. MQTT with Sparkplug also has an efficient way to track the state of clients to make sure clients on a tenuous connection can still deliver and receive data. In systems with multiple servers and clients, typical in many remote access applications, the volume of traffic in a request-response model can quickly become a problem. This is because each client is individually connected to each server it needs to request data from, and each connection may be opened, que - ried, answered, and closed—over and over. In contrast, a pub-sub architecture sim- plifies communications (sidebar figure). Direct connections and repetitive requests for data are not needed. The web of links is replaced by a single link from each device to the broker/server. The connection between client and bro- ker is kept open and is lightweight. Only two things travel over this connection: changed data and a tiny heartbeat to let the broker know that the client is still there. A pub-sub model, therefore, works well for systems with many servers and many clients that need to share data and services, which is typical in remote access applica- tions implemented by OEMs. In these ap- plications, a controller in a machine or pro- cess skid serves information to clients. An OEM may have hundreds of machines or process skids installed worldwide, so there are many servers. Multiple OEM and OEM customer personnel may require remote ac cess, and each device used is a client. Because the broker is the central clear- inghouse for data, individual servers do not have to strain to serve multiple clients, and clients do not have to connect to mul - tiple servers. In addition, network traffic is reduced overall, because data is published and sent on a report-by-exception basis— that is, only when the data changes— rather than at regular intervals. Pub-sub can also make sense when it is difficult to set up a direct connection be - tween a client and a server, or when the network is low bandwidth, expensive, or unreliable—for example, when monitor - ing equipment in remote locations, com- mon to many OEM and remote access applications. Most importantly from a security standpoint, all MQTT/Sparkplug commu - nications are outbound connections from the client to the broker. Because firewalls typically allow outbound connections, that means IT does not need to open ports in the firewall or create VPNs to move data securely. For OEMs with ma - chines or process skids at customer loca- tions, the ability to access data remotely without having to involve customer IT departments is a major plus. Request-response versus publish-subscribe As shown on the left diagram, communications among many clients and servers is complex with request-response methods, but greatly simplified with pub-sub and MQTT, on right.

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - MAY-JUN 2018