Control system connectivity update
Many industrial plants and facilities are in the midst of executing asset digitalization projects by incorporating Industrial Internet of Things (IIoT) elements and implementing other Industry 4.0 initiatives. A key enabler for these efforts is connectivity between field devices, such as sensors and instruments, and higher-level computing platforms. Connectivity is usually via company intranets and the internet.
Field devices typically use operations technology (OT) communication protocols and traditional wired signals, while intranets and the internet use IT protocols. A bridge between OT and IT is therefore required in the form of a communication hub, a role well-suited to newer programmable logic controllers (PLCs) and human machine interfaces (HMIs).
Let’s look at how PLCs and HMIs can be used to make connections from OT field devices to company intranets and the internet, as well as examples illustrating these types of applications.
PLCs must connect to a wide variety of field devices and other components to perform traditional control and monitoring tasks. Discrete devices providing inputs to PLCs include limit switches, position switches, photoelectric sensors and other components indicating on-off status. Discrete PLC outputs provide on/off commands to motors, on/off valves and other on/off equipment. Analog devices providing inputs to PLCs include analyzers, instruments, RTDs/thermocouples and other components with varying inputs. Analog PLC outputs drive variable frequency drives, control valves and other equipment operating over a range of speeds or positions, typically scaled as zero to 100%.
These traditional discrete and analog connections are common to most every type of PLC application, with digital communication links added in many instances. Instead of installing a bundle of wires and cables from a variable frequency drive to a PLC, a single digital communication cable can be used to exchange information. A group of drives can often be linked to a PLC via some type of Ethernet-based network, such as Modbus TCP, further reducing required wiring and cabling. Smart instruments and analyzers generate many data points, and for this reason are also commonly linked to a PLC via a network.
Less common methods of communication, but critical in some applications, are serial via RS232C/RS485 networks. Many older field devices, such as weigh scales, may only offer this type of digital communication link. Bluetooth and other forms of wireless connectivity are provided by some PLCs for networking to compatible devices.
Specialized industries and applications such as building automation often require support for the BACnet/IP communication protocol, a feature found in many newer PLCs (Figure 1). J1939 is another specialized protocol, typically used for connections to in-plant vehicles such as forklifts.
PLCs use these methods of communication to gather data for monitoring and control, and this data can also be manipulated and stored. SD memory ports and mini-B USB ports are often provided for expanded data storage, and data stored there or in PLC memory can be exchanged with higher level computing platforms via company intranets and the internet, both typically via Ethernet.
A PLC work wells as a communication hub for applications where only a single controller is used to concentrate many field devices, but applications with multiple PLCs and other controllers are often better served by an HMI.
HMIs typically don’t connect directly to field devices, but instead exchange data with these devices via an intermediate PLC or some other type of controller. For applications with a small amount of I/O, an HMI with real-time control capabilities can be used to provide a space saving all-in-one automation solution.
An HMI is often required to communicate with many different controllers simultaneously, requiring support for a multitude of protocols (Figure 2). Some of the most common types of controllers connected to HMIs via digital data links include PLCs, variable frequency drives and weighing systems.
Modern HMIs typically provide support for over 100 serial and networking industrial protocols, such as BACnet/IP, Modbus RTU Master/Slave and Modbus TCP/IP. Users should look for an HMI capable of supporting multiple protocols simultaneously as this allows ongoing data exchange with many sources and systems.
Not only can an HMI connect to many different sources of data, it can also provide onboard data storage, as well as additional storage via devices plugged into its USB and SD memory card ports.
All this stored data can be formatted for exchange with asset management systems, enterprise resource planning systems and other higher-level computing platforms. These communications are typically via Ethernet for real-time data exchange.
For periodic transfers of accumulated data, file transfer protocol (FTP) functionality enables copying or moving files between local memory, external memory devices or cloud-based files, databases or data storage platforms. FTP provides a convenient and effective remote file transfer method, and is supported by most upper level computing platforms, as well as by some newer HMIs.
Monitoring mobile assets
Many plants and facilities use forklifts, trucks and other industrial vehicles to move personnel, equipment, raw materials and supplies from one location to another (Figure 3). These industrial vehicle assets naturally come with their own automated systems to monitor and control operation. These systems typically provide support for the J1939 protocol, as do some PLCs.
In a typical application, a PLC can be added directly to a vehicle and communicate with its vehicles local control systems via the J1939 protocol. In these instances, it’s often helpful to use a combination PLC/HMI unit so the driver can view operational status details and receive messages.
Interlocks and other programming can be added so only certain types of critical information are displayed while the vehicle is in motion, such as a warning to reduce speed, with other information only accessible while the vehicle is stationary. The PLC/HMI unit can be connected to an asset management system for data exchange via either a wired or a wireless link.
In another type of application, a vehicle would be manually connected to a PLC via J1939 communications at the end of a shift. This would allow the vehicle to transmit its operational status such as mileage, battery life and other operating parameters to the PLC. The PLC would in turn send this information to an asset management system, usually via an Ethernet link. If wireless communications are added between a vehicle and a PLC, data can be sent via the J1939 protocol while the vehicle is mobile, adding another level of functionality.
BACnet for buildings
Commercial and industrial buildings and facilities typically contain a large number of packaged units such as HVAC, air purification, water softener, boiler, chiller, cooling and filtration systems (Figure 4). Each of these units usually has its own local control system, with all the units normally connected to a central control and monitoring system.
Connections from these units to the central system can be hardwired, but this only provides limited data exchange and requires extensive wiring and cabling. A much better approach is to exchange data digitally using BACnet/IP, a protocol supported by most every building automation packaged unit, and by many HMIs and PLCs.
This allows an HMI, a PLC or both to be used for monitoring and control, and for coordination among multiple packaged units. Integrating various systems with this type of solution is a substantial improvement as compared to proprietary building management systems, which typically lack flexibility and features.
As with other applications, the HMI or a PLC can interface subsystems up to higher-level computing platforms, such as a building’s asset management system, usually via an Ethernet connection.
PLCs and HMIs with the right connectivity and communication features are an excellent fit for linking field devices and equipment to higher level computing systems, providing double duty in addition to their regular monitoring and control roles. When used in this fashion, no new communication hardware or software needs to be purchased, installed and integrated, reducing costs and complexity.