Page 8 - AutomationNotebook-Issue46-digital

Cover Story continued
MQTT over TLS
The MQTT protocol has emerged as the common
standard for PLC-to-cloud communications, for several reasons. While it offers two-way communications, the PLC in the field initiates conversations as outbound messages to a centralized broker—which can be on premises or more commonly in the cloud—avoiding firewall and IT management issues. Although MQTT can be implemented without security, best practice is to perform communications using the standard trans- port layer security (TLS) networking protocol, and to use other security features provided within MQTT.
MQTT communications are processed quick- ly but are resilient enough to withstand the kinds of network outages which can be common for indus- trial and edge-located installations. Users can ac- cess the broker data with enterprise and/or mobile clients, or they can implement cloud computing services like Microsoft Azure and IBM Watson IoT to connect with PLC-sourced MQTT data directly.
REST API
The previous three methods require us-
ers to manage and configure the source data at the PLC. However, if a PLC offers a representa- tion state transfer (REST) application program- ming interface (API), then external clients can ini- tiate communications and access data residing in PLC memory with a standard request (Figure 3).
Applications
Typical IoT clients are remote monitoring appli- cations needing to receive certain items of data. Some- times developers will configure programming tools like Node-RED or NiFi, which are IT-centric methods for preprocessing, formatting, transforming, and con- figuring data for consumption by other applications.
Designers can build new systems using a modern PLC able to support these types of con- nections, or they can implement such a PLC on top of an existing system to add IoT capability. Data becomes easily available using one or more of the methods described in this article, so develop- ers can focus their efforts on the host applications.
For example, solutions provider Quantum
This powerful ability makes it easier for users to change polled data tags in the future, as no mod- ifications are needed in the PLC. The client sends a request to the PLC, and the PLC gathers the neces- sary data from its memory and replies with the data assembled into an easy to read and parse JavaScript Object Notation (JSON) format. Messaging occurs via HTTP requests from clients, using traditional and typically open IT ports, like port 80. However, as with the web server option, external clients must be on the same network or permitted through any firewalls.
Security Must Be Built-In
One natural consequence of improved PLC data connectivity options is greater exposure of the PLC to bad actors who could access potentially valuable information. Therefore, new PLCs must include built- in security features, extending far beyond what was offered in previous generations. Users should look for:
• PLCs which by default (right out of the box) are not open to requests from the outside world
• The ability to store username and password credentials on-board (managed by OT personnel using program- ming software)
• Support for IP whitelisting to control which external clients are allowed to communicate with the PLC
• Secure communications over TLS when possible
With the right tools and security, us- ers are afforded a world of options for cre- ating safe PLC-based data connectivity.
Figure 3: AutomationDirect BRX Series PLCs include multiple data connec- tivity options. A REST API enables external clients, such as Node-RED oper- ating on a computing service, to initiate requests to access data residing in PLC memory, so long as proper security credentials are presented.
Cover Story www.automationnotebook.com | Issue 46
continued >>