We all know that computers and other electronic devices—printers, routers, laptops, smartphones, and more—are networked so they can exchange information.

But how does that information get where it’s supposed to go?

How does a spreadsheet get to the printer, a YouTube video get to your smartphone, or—most important for automation engineers—a value from a sensor get to your HMI?

Let's take a look at a couple of models for network communication, and then in part 2 we'll compare them to see which one might be better in certain scenarios. The two we'll look at are request-response and publish-subscribe.

Request and response

The typical model for computers communicating on a network is request-response. In the request-response model, a client computer or software requests data or services, and a server computer or software responds to the request by providing the data or service.

For example, when you send a spreadsheet to the printer, your spreadsheet program is the client. Its request for printer services goes to your company’s print server, which responds to the request and allocates resources for printers on the network. The print server handles all the client requests for printing, making sure your spreadsheet and your coworkers’ print jobs are all completed in an orderly way.

When you want to watch that YouTube video on your smartphone, your web browser or YouTube app is the client, requesting the video over that giant of networks, the Internet. YouTube’s web server receives the request and responds by serving the video page to you, along with the other millions of video pages going to other millions of viewers worldwide.

In automation, the client is typically a PC, and the server is a PLC or PAC. The HMI application on your PC requests data from the PLC or PAC in order to display it on the monitor.

You can imagine request-response as a client sending an empty truck out to be filled with data. The server responds by putting the data on the truck and sending it back.

Request-response and groov View

With an Opto 22 groov® View operator interface, a groov EPIC processor, groov Box, or groov Server for Windows acts as a client, requesting the data it needs for the HMI from the devices it's connected to—the EPIC and SNAP PAC controllers, Modbus® devices, and PLCs via OPC UA. These devices respond with the data needed for the interface.

Meanwhile, the groov EPIC or Box also acts as a web server. At the request of clients like authorized smartphones and tablets, groov View responds by serving the interface pages you’ve created to these clients on the network. 

Publish and subscribe

A different way for devices to communicate on a network is 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 or subscribe to get data from it—or both.

Clients that publish data send it only when the data changes (report by exception, or RBE). Clients that subscribe 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 subscribers. When data comes in from a publisher, the broker promptly sends it off to any client subscribed to that data.

In our truck analogy, there are no empty trucks. A client publishing data sends a full truck to the broker. The broker sees the truck come in but doesn’t unload it; it simply routes it intact to a subscriber (cloning the truck if there’s more than one subscriber). 

In the diagram below, the client on the left publishes data that the clients on the right subscribe to. In addition, the client in the lower right also publishes data needed by other clients not shown. 

MQTT—a pub-sub protocol

MQTT is a fairly well-known transport protocol that uses the pub-sub architecture. MQTT is extremely lightweight: it takes up almost no space in a device, so that even small devices with very little computing power can use it.

MQTT defines the truck and the routes. But it doesn’t define how the load (the data) is packed or unpacked. That’s where Sparkplug comes in.

MQTT with Sparkplug

The Sparkplug open MQTT client specification provides a messaging format appropriate for industrial use.

Sparkplug encodes the data payload: it defines how the data is packed on the truck before it’s sent by the publisher, and how it is unpacked in the subscriber.

Data sent over MQTT with Sparkplug is compressed and efficient. MQTT trucks that have been packed with the Sparkplug definition must also be unpacked with Sparkplug, so both publishers and subscribers must use it in order to get the data delivered.

MQTT with Sparkplug also provides an efficient way to track the state of clients and make sure that clients on a tenuous connection can still deliver and receive data.

• If the client goes offline (breaks its connection with the broker), the broker sends a "death certificate" to clients subscribed to that data.
• When the client comes back online (re-establishes the connection), the broker issues a "birth certificate" with the current status of all data tags.

A certain amount of missed data may also be sent, depending on client configuration.

Comparing request-response and pub-sub

Because these two network communication models work differently, some applications are more suited to one model or the other.

In part 2, we'll take a look at some key differences and when you might choose to use each. Hint: One of these may be better suited to industrial internet of things (IIoT) applications. 

Don't miss a post! Subscribe to the OptoBlog.