Simplified remote access

Fact Auto May-Jun Main fig 1
Remote monitoring and control systems using modern data collection techniques deliver improved performance and security, along with simpler implementation and lower costs

By Benson Hougland

Data collection from industrial facilities and plants provides a number of benefits to end users, system integrators, and machine and process skid builders. End users can monitor their facilities and plants worldwide from any location with cellular network or Internet access, and system integrators can do the same for their projects. Original equipment manufacturer (OEM) machine and process skid builders can monitor their products and systems wherever they are installed, even at remote customer sites.

Data collection by OEMs can be especially useful for both the OEM and the customer. Data can be acquired for analysis and remote monitoring, and data can be sent to machines and process skids for remote control. This two-way remote access provides:

  • remote monitoring to quickly alarm and alert personnel
  • predictive capabilities to anticipate problems before they occur
  • remote control to respond to issues and problems
  • improved overall equipment effectiveness: better uptime, throughput, and quality
  • cost savings by eliminating most trips to the field

In addition, OEMs can:

  • log usage data for billing or maintenance
  • gain insight into customer needs
  • analyze data to improve future product or process designs

Although most OEMs need remote access to provide the quality of service their customers want, the barriers are high and include security issues, technical difficulties, and costs.

Cybersecurity is a major concern for both OEMs and their customers. Busy information technology (IT) departments may not have the time, resources, or technical skills to set up remote access to automation systems and equipment.

As a result, older methods like opening ports through firewalls and creating virtual private network (VPN) tunnels are falling out of favor. Newer methods of remote access, particularly those using the Message Queuing Telemetry Transport (MQTT) protocol in publish/subscribe communication models, can be a major improvement, providing the data and access OEMs need without burdening their customers (sidebar).

Industrial hardened edge programmable industrial controllers (EPICs) address these and other remote access requirements with local computing, multiple programming options, local control, and sensor input and output interfaces.

Edge processing

Edge processing encompasses at least three functions. The first is to collect, process, view, and exchange data where it is produced-at the edge of a network. This function requires a powerful processor and an open operating system, such as Linux. The processor filters out anomalies, sorts relevant data, and creates exception-only reporting.

The second function is securely storing and sharing data among databases, cloud platforms, Web services, and programmable logic controllers (PLCs) using modern communication methods. Sharing data with this wide range of hardware and software requires support for multiple communication options at both the hardware and software level.

At the hardware level, multiple communication ports are a must. Minimum requirements for modern systems include multiple gigabit Ethernet, USB, and serial ports. At the software or protocol level, many protocols should be supported, including different variants of Ethernet, Modbus RTU and Modbus/TCP, and MQTT.

Many industry offerings now include embedded support for multiple connectivity methods in their EPICs, including Ethernet and Modbus protocols, plus OPC UA drivers and MQTT/Sparkplug. These methods give support now, and also provide for the future, as vendors are constantly updating their protocol support options.

The third function of an edge processor is to bring data visibility to authorized personnel in several ways: on an integral touchscreen, on a local human-machine interface (HMI), and from any device capable of hosting a Web browser (figure 1). Many OEMs will find an integral touchscreen, and an HDMI port for optional connection to an external display, a significant benefit.

If the touchscreen is sufficient, then the OEM can save the expense of purchasing and installing an external HMI. If the vendor includes an HMI development tool as part of the EPIC software package, a low-cost graphics monitor can simply be connected to the HDMI port to provide an external HMI. In that case, there is no need for an external PC-based HMI, which is very expensive due to the high costs of industrial PCs and PC-based HMI software.

Factory Auto May-Jun fig 1

Figure 1. Local monitoring, control, and adjustments are greatly facilitated by providing built-in HMI on the edge controller.

Programming options

Multiple programming options are required for any modern EPIC. Some of the more popular languages are flowcharting with scripting options for sequential machine and process skid control, and the suite of IEC 61131 languages. These two options will be sufficient to support most real-time control needs, but some OEMs may require or prefer more flexible and powerful programming languages, such as C/C++, Python, and Java. These and other languages can be most easily used if the EPIC provides secure shell access, a common feature when a Linux operating system is used. And all of these languages can be used together, with data passing among them internally within the EPIC as required.

For many remote access applications, real-time control is of secondary importance, with data exchange among various controller, HMI, and other platforms the primary goal. For these types of tasks, the browser-based, open-source, flow programming tool Node-RED ( is becoming more widely used by EPIC vendors, and by many other companies in both the commercial and industrial sectors (figure 2).

Using this open-source visual language, developers can cut and paste prebuilt function blocks or nodes to configure various communication paths. Because Node-RED is specifically designed for these types of tasks, it is much easier to use for data handling than languages designed for real-time control, such as flowcharts, or general-purpose languages, such as C/C++, Python, or Java.

Factory Auto May-Jun fig 2

Figure 2. The open-source Node-RED programming tool embedded in edge controllers enables users to easily wire together hardware devices, APIs, and online services.

Industrially hardened

Many of the capabilities mentioned above are in commercial data collection products, specifically PCs with plug-in data acquisition cards. But using these products in an industrial environment presents a number of problems.

First is the difficulty of mounting and protecting commercial components, such as a desktop PC, in an industrial enclosure. Second is the high likelihood of failure after installation due to temperature extremes, shock and vibration, electrical noise, and other conditions common in industrial environments. Third is the lack of certification for use in hazardous locations.

To avoid these and other issues, any EPIC intended for an industrial remote access application should meet minimum requirements, including:

  • DIN-rail mounting
  • operation from about -20°C to 70°C
  • industrial microprocessor
  • solid-state drive
  • certification for use in hazardous locations

One of the most basic functions for any remote access system is connecting inputs to I/O terminals in an efficient manner.

Control and I/O

Connecting control outputs and inputs should be as simple and foolproof as possible, particularly with the larger point counts to support Industry 4.0 and Industrial Internet of Things. Ideally following industry norms, I/O terminations are made to removable and hot-swappable terminal blocks incorporating a quick connect to the edge controllers that have a captive hold-down (i.e., screw). Terminations made to the block should support up to 14 AWG using accepted industry methods, including spring clamps and screws. Supporting the high point counts for Industry 4.0 and Industrial Internet of Things high-density I/O modules should strongly be considered (i.e., 24 channels per module). Multiple discrete and analog input types and at least 20-bit resolution for analog inputs to support the wide range of control and big data applications should be included. Local LEDs indicating the status of each channel enable local users to verify operation at a glance (figure 3).

In addition, I/O configuration should be simple, with individual I/O modules reporting their identities to the EPIC. Ideally, a local touchscreen will have I/O specifications, wiring diagrams, and channel status to facilitate commissioning and troubleshooting.

Factory Auto May-Jun fig 3

Figure 3. I/O modules provide a visual indication of the overall module status, and a touch-sensitive pad activates the display of diagnostic information for each channel on the embedded HMI, simplifying startup, commissioning, and maintenance.

Simplifying edge automation

Remote access used to be a complex undertaking for machine builder and process skid OEMs, with numerous issues related to performance, cybersecurity, and IT details. New automation components and open standards, such as MQTT and Sparkplug, are addressing this issue, making it far easier and less expensive to deploy and support highly secure remote access systems.

 subscribe now jpeg

Fast Forward

  • Many remote access solutions require extensive IT assistance and support.
  • Newer solutions rely on open systems to simplify remote access, allowing it to be implemented by operations personnel.
  • These new solutions provide fast and secure remote access, along with simple implementation, which is particularly important for OEMs and their customers. 

About the Author

Benson Houglandvice president, marketing and product strategy, drives strategy for Opto 22 products, connecting the real world to computer networks. He has 30 years of experience in IT and industrial automation and speaks at trade shows and conferences, including IBM Think, ARC Forum, and ISA. Hougland’s 2014 TEDx Talk introduces nontechnical people to the IoT.

Request-response versus publish-subscribe Factory Auto May-Jun Sidebar img

There are two main methods for implementing 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 services, and a server computer or software responds to the request by providing the data or service. In industrial remote access applications, 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 devices 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, subscribe 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 subscribing 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.

MQTT is a popular and open transport protocol used with 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. But MQTT does not define how the data is packed or unpacked, 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 unpacked 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 order 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, queried, answered, and closed-over and over.

In contrast, a pub-sub architecture simplifies 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 broker 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 applications implemented by OEMs. In these applications, a controller in a machine or process 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 access, and each device used is a client.

Because the broker is the central clearinghouse for data, individual servers do not have to strain to serve multiple clients, and clients do not have to connect to multiple 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 between a client and a server, or when the network is low bandwidth, expensive, or unreliable-for example, when monitoring equipment in remote locations, common to many OEM and remote access applications.

Most importantly from a security standpoint, all MQTT/Sparkplug communications 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 machines or process skids at customer locations, the ability to access data remotely without having to involve customer IT departments is a major plus.

Reader Feedback

We want to hear from you! Please send us your comments and questions about this topic to