Should PLCs be networked?
The decision of whether to put a PLC on a network depends on interrelated factors that you define by evaluating your requirements. You must weigh what you want to get out of PLC networking against how much you want to pay for it.
Networking a PLC should not be done just because it can be done. If you are to connect PLCs to a network, there should be sound business and technical reasons for doing so.
Industrial network configurations
A network comprises two or more devices that are linked, can communicate with other devices, and can share resources. Typically, when we hear “network” in an industrial automation context we think local area network (LAN). An office LAN usually has PCs, printers, servers, hubs, switches, and lots of cable in its lineup. The de facto standard for office LANs has become Ethernet.
It’s no secret that Ethernet has made its way onto the plant floor. However, industrial Ethernet has requirements beyond office LANs to ensure determinism, data integrity, security, network reliability, and sufficient speed for the application.
Initially, you must determine if your plant uses an industrial network, its type, configuration, and inherent constraints. From there, determine what — if anything — must be changed to achieve your goals.
Many plants already have PLCs on industrial networks (Fig. 1). Those of you who have networked PLCs know its challenges and benefits. Whether proprietary fieldbuses, PLCs from multiple vendors, or increasingly popular industrial Ethernet, the technology exists to successfully use networked PLCs. There must be some advantage to this; otherwise plants would not have overcome the challenges to do so.
Many configurations exist for PLC networking. There is no universal architecture. The diversity in configurations is directly proportional to the diversity in plants, applications, equipment, and processes. How to accomplish PLC networking depends greatly on your existing network infrastructure and how it is required to change. Take advantage of your existing infrastructure as much as possible. There’s no need to reinvent the wheel.
Generally, PLC network configurations can be categorized as PLC-to-enterprise or PLC-to-PLC. The PLC-to-enterprise configuration connects PLCs to other devices or systems that provide data to decision makers throughout the company, or enterprise. Typically, a PC pulls data into a human-machine interface (HMI), supervisory control and data acquisition (SCADA), manufacturing execution system (MES), or enterprise resource planning (ERP) system. Read-only configurations allow process or machine visualization. Read-write configurations enable the enterprise system to make adjustments to the process or machine, allow recipe management, and accommodate troubleshooting.
The PLC-to-PLC (peer-to-peer) network configuration connects two or more PLCs together — most often within the LAN or subnet — to exchange data among multiple controllers to further optimize a larger controlled process or group of machines.
Reasons to network PLCs
With managerial empowerment comes accountability and responsibility. Automation intelligence and the sophistication of decision making are getting lower into system architectures. But the visibility and accountability of these decisions spread throughout the enterprise.
Commerce is getting closer to the production line, which mandates corporate and fiscal accountability and responsibility. Plant engineers are becoming the agents for real-time information in manufacturing companies and the arbiters of using real-time data to affect change.
Manufacturing processes and operations require metrics. To remain competitive, decision points are becoming more fine-tuned. This means that increasingly, manufacturing and maintenance decisions must be made in real time.
Used to be, plant personnel collected data during rounds. These hand-written data were painstakingly interpreted from printouts, gauge and instrument readings, and data from chart recorder traces. The resulting values were included in reports about how machines and processes were behaving. However, the speed of this data extraction process did not even approach real time. And these manual methods provided plenty of opportunity for errors. The need for data has not gone away. However, the means by which these data are acquired have evolved since those days.
It takes time, money, effort, purpose, and commitment to make automation happen. There must be specific reasons to network PLCs. For example, some plants must verify periodically that PLC programs have not changed. It isn’t necessary to network PLCs to comply with this requirement. But doing so makes it a lot easier — especially when you have a large number of PLCs in your plant.
Some plants have operational or contractual obligations that dictate specific data requirements. For example, your plant operation may require accurate parts counts 4 times daily from each manufacturing line. This can be done without networking PLCs. But PLCs can do it so easily — and without human error. Connecting the PLC to a network ensures these data are provided in real time.
Remote monitoring is another reason to network PLCs. Instead of jumping in the golf cart and heading to that isolated building at the other end of your large plant just to take equipment or process readings, you can pull the readings off the PLCs over the industrial network. Even better, you can automate the data extraction process.
PLC networking enables automation systems to extract critical data from controlled processes and equipment, and direct them throughout the enterprise (Fig. 2). Having these data in real time allows users to make critically timed adjustments to processes or machines to increase efficiency and reduce downtime and labor overhead compared to previous methods of collecting data.
Peer-to-peer networking reduces hard wiring among multiple controllers. Traditionally, PLCs were interconnected for machine interlocking or data exchange using multiconductor cables between each PLC. When networking two or more controllers, an industrial Ethernet link can be used much more easily and cost effectively than hardwiring several signals.
Peer-to-peer communication via industrial Ethernet enables PLCs to share information from one part of your process to the next. Sharing data among PLCs enables optimal data flow, data synchronization, and in many cases allows users to eliminate a PC.
Networking multiple PLCs allows you to program or maintain multiple PLC programs simultaneously. Most PLC programming software now supports online changes over networked PLCs so users can troubleshoot multiple PLCs from a remote location, saving significant time and service expense.
Some plants use networked PLCs for recipe management. There is increasing demand to make decisions in real time based on data provided directly from the process or machine status via PLCs connected to a network. Information fed into an MES or ERP system can facilitate just-in-time manufacturing or production decisions. Recipes can be verified periodically to ensure product integrity. Extracted data can facilitate electronic reporting and regulatory compliance.
If there are problems with a manufacturing line, process, or system, networked PLCs can facilitate troubleshooting. With the proper hardware and software tools, a technician can examine problems with a system without leaving the shop. Usually, the PLC or the program is not the problem. However, by examining I/O, machine status, and PLC registers, a technician can compare what is expected to what the actual system is telling him or her via the network.
Whether manufacturing or maintenance, some plants require fiscal and process accountability. Audit trails are commonplace in some industries. Electronic signatures and time stamping requirements virtually necessitate process intelligence that can be communicated throughout the enterprise.
Reasons to not network PLCs
If you have a small system, such as a stand-alone machine or process, or if you have little or no need to get data from a PLC, you may not find it cost effective to network. Simple applications requiring minimal peer-to-peer communication may get by with running a cable connecting available I/O between a couple of PLCs. Applications requiring 8-16 signals, less than 38 kb of data, or a multiconductor cable run of less than 50 ft may present a hard choice and the results could go either way. Small and limited applications can actually be hard-wired without affecting significantly the PLC scan time. Generally, the cost of labor and wiring make it prohibitive to go beyond these parameters. There comes a point of diminishing returns, beyond which connecting a PLC to a network becomes more attractive.
If you have only one PLC, the only reason to put it on a network is to extract data. Then the networking decision rests on the cost to do so compared to the payback. There is a minimum cost for this process, which is different for every plant, process, machine, PLC, and network. It’s up to you to determine if the return on investment (ROI) justifies the expense.
Another reason to examine your reasons, goals, and cost-effectiveness of networking is having PLCs from multiple competing manufacturers. Most PLCs communicate through proprietary protocols. So far, this has been problematic for getting data from them and onto an industrial network. While the protocols are open, each manufacturer’s PLC dictates user configuration or programming approaches.
OPC overcomes proprietary problems
Vendor-specific software interfaces are used as programming front ends for Ethernet or fieldbus protocols. However, using OLE for process control (OPC), data can be understood and used among PLCs and devices from multiple vendors, regardless of proprietary protocols (OLE is object linking and embedding, a feature of Microsoft Windows).
Many major automation vendors have adopted OPC because its interfaces can be used with industrial Ethernet and fieldbus-based systems. Each automation vendor (that adopts OPC) provides an OPC server file that gets loaded into the PC. You can link PLCs, control devices, and individual functions to specific network addresses.
From there, you can create screens with buttons, dials, bar graphs, and other dashboard elements that reflect the different device functions and how they interrelate in your manufacturing environment. OPC allows these screens to display data from different vendors’ devices — even from a mix of fieldbus and Ethernet networks.
PLANT ENGINEERING magazine extends its appreciation to AutomationDirect; GE Fanuc Automation; ILS; Microsoft, Manufacturing Industry Unit; Omron; Phoenix Contact; Schneider Electric; and Rockwell Automation for the use of their materials in the preparation of this article.