Not long ago, the roles of industrial automation devices and systems were a little more straightforward. Most field devices and sensors were relatively “dumb” and were directly connected to controllers, which may have interacted with operator displays, and in rare cases some data may have flowed up to higher level enterprise systems. Today’s smart sensors, clever controllers, and more capable communications have improved upon this scenario, and end users are looking for the best ways to enable the enterprise host systems to access valuable field-level data.
The operational technology (OT) domain of sensors, programmable logic controllers (PLCs), and human-machine interfaces (HMIs) is converging with the information technology (IT) world of PC servers and cloud connectivity. These technologies are more intelligent than ever with a lot of overlapping functionality. This means users have more options for building or upgrading an industrial automation system to deliver integrated data. Applications where OT data is accessed with IT methods are often referred to as Internet of Things (IoT) implementations.
Some of today’s PLCs are speeding end users on their journey to extract data from manufacturing systems and transporting it to enterprise systems so users can make informative decisions on how to optimize operations. IT-friendly additions are making OT-centric PLC platforms more effective for optimizing operations.
Yesterday’s PLC data flow challenges…
Gathering field data, let alone connecting to some higher-level host system, historically has involved several types of challenges. Hardwired sensors were easiest to connect to a PLC, but publishing PLC information up to on-site or cloud-based systems required careful curation of data structures, along with configuring network and communication protocols. PLCs didn’t support all the industrial protocols required to talk with more intelligent field devices, and they had limitations for connecting with host systems. Navigating the architectural hierarchy from the control level, through operations, up to the enterprise systems and the cloud was a thorny problem (Figure 1).
Users needed to generate custom configurations of code to select, arrange and manage data. Then they had to take additional steps to handle extended information like scaling, engineering units and tag descriptions. A lot of parts and effort might be involved: PLCs, gateways, PCs, software packages, network configuration and custom code.
Even when data connectivity could be patched together, it was often at the expense of security. Traditionally, PLCs have not included strong cybersecurity provisions, especially for internet-connected systems.
…are solved by today’s PLC tech
Fortunately, some modern PLCs include all the elements needed to overcome these challenges, eliminating complexity from the task of getting data from the shop floor up to the cloud and enterprise.
PLCs have been an established and reliable platform for edge automation tasks. Instead of creating a new category of device only tasked with data communication duties, some vendors realized next-generation OT-based PLCs could be enhanced with the necessary IT-associated tech to effectively integrate data (Figure 2).
For best results, all data integration elements need to reside natively in the PLC product, providing an off-the-shelf experience for users. End users, especially in the IT field, also are looking for open source-based technologies because they are already familiar with this approach, as opposed to the specialized environments common to OT products.
A PLC bundling data integration protocols bridges OT and IT systems and can create many ways to connect new and legacy factory floor equipment to today’s enterprise systems. Popular serial and Ethernet OT protocols include ASCII, Modbus RTI K-Seq, Modbus TCP and EtherNet/IP (ODVA). Essential IT protocols include SNTP DNS, MQTT, SMTP, SSL and web services.
Multiple PLC integration options
PLCs can enable popular data integration options depending on application needs.
Store data in the PLC and forward via FTP
Today’s PLCs have enough memory to log data locally over a period of hours, days, or weeks—and then forward it to a network- or cloud-connected computer using file transfer protocol (FTP). This form of storing and forwarding data can be effective for bulk transactions, which do not need to be near-real-time, however, it will require the user to configure the PLC for aggregating the data and the host system for parsing the data.
Web server
Sometimes it is only necessary for a PLC to expose limited data for read-only, near real-time remote viewing by users. In this case, some PLCs include built-in web servers, empowering users to develop HTML5 displays of data and information viewable using browsers. No other additional software or licensing is required. A downside to this basic approach is the need for clients to be connected on the same network – or via a firewall and routing – with the proper access privileges.
MQTT over TLS
The messaging queuing telemetry transport (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. This helps avoid firewall and IT management issues. Although MQTT can be implemented without security, best practice is to perform communications using the standard transport layer security (TLS) networking protocol, and to use other security features provided within MQTT.
MQTT communications are processed quickly, but are resilient enough to withstand the kinds of network outages that can occur for industrial and edge-located installations. Users can access the broker data with enterprise and/or mobile clients, or they can implement cloud computing services to connect with PLC-sourced MQTT data directly.
REST API
The previous three methods require users to manage and configure the source data at the PLC. However, if a PLC offers a representation state transfer (REST) application programming interface (API), then external clients can initiate communications and access data residing in PLC memory with a standard request (Figure 3).
This powerful ability makes it easier for users to change polled data tags in the future, as no modifications are needed in the PLC. The client sends a request to the PLC, and the PLC gathers the necessary 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 that are by default (right out of the box) not open to requests from the outside world
- The ability to store username and password credentials on-board (managed by OT personnel using programming 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, users are afforded a world of options for creating safe PLC-based data connectivity.
Applications for modern PLCs
Many IoT clients are remote monitoring applications needing to receive certain items of data. Sometimes developers will configure programming tools that are IT-centric methods for preprocessing, formatting, transforming, and configuring data for consumption by other applications.
Designers can build new systems using a modern PLC able to support these types of connections, 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 here, so developers can focus their efforts on the host applications.
For example, a solutions provider developed a cloud-based IoT application that can access many operational sites, such as pump houses, using MQTT. Before PLCs were available to support MQTT and other methods, it was necessary for developers to add dedicated communication gateways.
PLCs are the future of OT data connectivity
Whereas yesterday’s industrial automation products were often very specialized and somewhat limited in terms of data handling, the processing power incorporated in today’s OT digital devices imbues them with greater capabilities. These new capabilities are addressing end user needs for obtaining timely field data to support IoT and analytical initiatives at the enterprise level.
OT-based PLC technology is already well-proven in the field. The addition of IT-friendly protocols and security features to PLCs makes them ideal as edge devices for accessing raw field data using industrial protocols, processing it into information, and securely publishing or transmitting it to any industrial IoT client or external computing platform.
To learn more about Radwell International's Products and Service Offerings
Listen in at Radwell Automation Nation
View the original article and related content on Control Engineering
