Log on to any industrial control discussion forum, and you will read passionate debates about the advantages and disadvantages of programmable logic controllers (PLCs) compared to PC-based control.
Amongst the PLC/PC debates, there most likely were some threads discussing PACs, which begs the question, “What the heck is a PAC?” PAC, a new acronym, stands for programmable automation controller, and it describes a new generation of industrial controllers that combine the functionality of a PLC and a PC. Traditional PLC vendors use the PAC moniker to describe their high end systems, as do PC control companies, in an effort to explain their industrial control platforms. As the technological differences between PC and PLC wane, with PLCs using commercial off the shelf hardware and PC systems incorporating real-time operating systems, PACs further blur the line between different control systems. So is PAC a harbinger to end the PC/PLC debate or simply another contender for control applications? To understand the relevance of PACs, it is important to review the history of industrial control.
PLC’s Early Years
In the 1960s, engineers performed industry control using large banks of mechanical relays. The I/O for a control system was hard wired into electrical cabinets where mechanical relays were wired together to create interdependencies between digital inputs and digital outputs. These systems were complicated, hard to modify, prone to failure, and a large strain on design and maintenance resources.
In the late 1960s, Bedford Associates proposed a new system called Modular Digital Controller (MODICON), which used a central processing unit (CPU) to perform digital logic and interface with digital inputs and outputs. The first PLC, MODICON 084, efficiently performed digital operations and digital control. It also greatly simplified control system design, modification, and maintenance.
By the mid-1970s, manufacturing experts replaced relay-based control with PLCs. These early controllers commonly used bit slice-based CPUs, such as the AMD 2901, and were limited to digital control. For reliability and ease of programming, PLCs employed rigid control architectures and simple instruction sets. Engineers programmed the majority of them using ladder logic, a language created to mimic the original relay diagrams.
“80-20” Rule
During the following three decades, PLCs evolved to incorporate analog I/O, communication over networks, and new programming standards such as IEC 61131-3. However, engineers create 80% of industrial applications with digital I/O, a few analog I/O points, and simple programming techniques. Industry experts estimate that:
– 80% of PLCs are used in small applications (less than 128 I/O)
– 78% of PLC I/O is digital
– 80% of PLC application challenges are solved with a set of 20 ladder- logic instructions
Since a user can solve 80% of industrial applications with traditional tools, there is strong demand for simple low-cost PLCs. In fact, some PLCs still use the original AMD 2901 CPU, and some companies only offer ladder-logic programming for their PLCs. This stability gives engineers the benefit of long life cycles on their control hardware and gradual changes to programming software, making it easier to train technicians and perform maintenance.
Although 80% of applications incorporate simple digital and analog control, engineers creating the other 20% of the applications relentlessly push the capabilities of their control systems. These engineers require higher loop rates, advanced control algorithms, more analog capabilities, and better integration with the enterprise network.
In the 80s and 90s, these “20 percenters” evaluated PCs for industrial control. The PC provided the software capabilities to perform advanced tasks, offered a graphical rich programming and user environment, and utilized commercial off the shelf components allowing control engineers to employ technologies developed for other applications. They now could use Intel floating point processors, high speed I/O busses-such as PCI and Ethernet-non-volatile data storage, and graphical development software tools. The PC also provided unparalleled flexibility, highly productive software, and advanced low-cost hardware.
However, PC-based control was not perfect, so while engineers used the PC when incorporating advanced functionality, like analog control and simulation, database connectivity, web-based functionality, and communication with third party devices, the PLC was still king for control. The main problem with PC-based control was manufacturers did not design standard PCs for rugged environments.
The PC suffered from three main problems:
Stability: Often, the PC’s general-purpose operating system was not stable enough for control. PC-controlled installations were forced to handle system crashes and unplanned rebooting.
Reliability: With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure.
Unfamiliar programming environment: Plant operators needed the capability to override a system for maintenance or troubleshooting. Using ladder logic, they knew how to manually force a coil and patch code to quickly override a system. But with PC systems, operators needed to learn new tools.
Although some engineers use special industrial computers with hardened hardware and special operating systems, most engineers avoided PCs for control because of problems with PC reliability. In addition, the devices used within a PC for different automation tasks, such as I/O, communications, or motion, may have different development environments.
So the “20 percenters” either lived without functionality not easily accomplished with a PLC or cobbled together a system that included a PLC for the control portion of the code and a PC for the more advanced functionality. This is the reason many factory floors today have PLCs used in conjunction with PCs for data logging, connecting to bar code scanners, inserting information into databases, and publishing data to the Web. The big problem with this type of setup is these systems are often difficult to construct, troubleshoot, and maintain. The system engineer often ends up with the unenviable task of incorporating hardware and software from multiple vendors, which poses a problem since the equipment is not designed to work together.
Building A Controller
With no clear PC or PLC solution, engineers with complex applications worked closely with control vendors to develop new products. They requested the ability to combine the advanced software capabilities of the PC with the reliability of the PLC. These users helped guide product development for PLC and PC control companies.
The software capabilities required not only software advancements, but also an increase in the hardware capabilities of the controllers. A positive outcome of the dot com bubble was a dramatic increase in processor speed, network reliability, and communication technology. With the decline in world-wide demand for PC components, semiconductor vendors began to redesign products for industrial applications. Control vendors now incorporate industrial versions of floating point processors, dynamic random-access memory, non-spinning memory storage, and fast Ethernet chipsets into industrial control products. This enables vendors to develop more powerful software with the flexibility and usability of PC-based control systems.
The resulting new controllers, designed to address the “20%” applications, combine the best PLC features with the best PC features. Industry analysts named these devices programmable automation controllers, or PACs. In their “Programmable Logic Controllers Worldwide Outlook” study, industry research firm ARC Advisory Group identified PAC characteristics. The criteria characterize the functionality of the controller by defining the software capabilities:
“Single multi-discipline development platform incorporating common tagging and a single database for access to all parameters and functions.” Because PACs are designed for more advanced applications such as multi-domain designs, they require advanced software. In order to make system design efficient, this software must be one integrated software package instead of disparate software tools.
“Open, modular architectures that mirror industry applications from machine layouts in factories to unit operations in process plants.” Because all industrial applications are customized, the hardware needs to be modular so the engineer can pick components.
“Employ de-facto standards for network interfaces, languages, etc., such as TCPIP, OPC & XML, and SQL queries.” Communication with enterprise networks is critical for modern control systems. Although PACs include an Ethernet port, the software for communication is the key to trouble-free integration with the rest of the plant.
Two Camps
While software is the key difference between PACs and PLCs, vendors vary in their approach to providing the advanced software. Vendors start with their existing control software and work to add the functionality, reliability, and ease-of-use required to program PACs. Generally, this creates two camps of PAC software, either software provided by vendors with a background creating PLC control or vendors with a background creating PC control.
Traditional PLC software vendors begin with a reliable and easy to use scanning architecture and work to add new functionality. PLC software follows a general model of scanning inputs,
running control code, updating outputs, and performing housekeeping functions. A control engineer only designs the control code because the input cycles, output cycles, and housekeeping cycles are all hidden. With much of the work done by the vendor, this strict control architecture makes it easier and faster to create control systems. The rigidity of these systems also negates the need for the control engineer to completely understand the low level operation of the PLC to create reliable programs. However, the strength of the PLC architecture, with rigid scanning architecture, can also make it inflexible. Most PLC vendors who create PAC software work to insert new functionality, such as Ethernet communication, motion control, and advanced algorithms, into the existing scanner architecture while maintaining the familiar look and feel of PLC programming and the strengths in logic and control. The result is PAC software generally designed to fit specific types of applications such as logic, motion, and PID, but less flexible for custom applications.
PC software vendors begin with a very flexible general purpose programming language, which provides in-depth access to the inner workings of the hardware and works to incorporate reliability, determinism, and default control architectures. Although engineers can create the scanner structure normally provided to the PLC programmer, they are not inherent in PC control software. This makes PC software flexible and well suited for complex applications that require advanced structures, programming techniques, or system level control, but more difficult for simple applications.
The first step for these vendors is to provide reliability, which is often not available in a general purpose operating system such as Windows. This action comes by using a real-time operating system (RTOS). These systems provide the capability to control all aspects of the control system.
PAC Extensions
PAC concepts today also extend beyond simple I/O by incorporating higher speed measurements and vision. Many industrial applications collect high speed measurements for vibration or power quality applications. This data allows the user to monitor the condition of rotating machinery, determine maintenance schedules, identify motor wear, and adjust control algorithms. The data is normally collected using specialized data acquisition systems or standalone instrumentation and is incorporated into a control system using a communication bus. Some PACs today can directly take high accuracy measurements at hundreds of thousands or millions of samples per second, allowing engineers to pull data directly into their control systems.
Engineers also can incorporate vision into their control systems. Vision is an area of automation that has gained a lot of momentum in the last decade. In a manufacturing environment, there are many flaws or mistakes you can catch through visual inspection that are difficult to detect using traditional measurement techniques. Common applications include part inspection for manufacturing or assembly verification, such as checking for correct component placement on a circuit board, optical character recognition to examine date codes or to sort products, and optical measurements to find flaws in products or for sorting by quality. Many plants currently use standalone smart cameras that need to communicate to the manufacturing process controller. PACs that incorporate vision or high speed measurements with logic and motion control eliminate the need for engineers to integrate dissimilar hardware and software platforms.
You can see the future of PACs by looking at the latest PC and embedded software. One example is the ability to use software to define hardware. Field programmable gate arrays (FPGAs) are electronic components commonly used by electronics manufacturers to create custom chips, allowing intelligence to go in new devices. These devices consist of configurable logic blocks that can perform a variety of functions, programmable interconnects that act as switches to connect the function blocks together, and I/O blocks that pass data into and out of the chip. By defining the functionality of the configurable logic blocks and the way they connect to each other and to the I/O, electronics designers can create custom chips
without the expense of producing a custom application-specific integrated circuit. FPGAs are like having a computer that rewires its internal circuitry to run your application.
Normally FPGA technology has only been available to hardware designers who were proficient in low-level programming languages like VHDL; however today, controls engineers can use high level graphical development tools to create custom control algorithms that download onto FPGA chips. This advancement enables engineers to incorporate extremely time-critical functions to hardware such as limit and proximity sensor detection and sensor health monitoring. Because the control code runs directly in silicon, it is possible for engineers to quickly create applications that incorporate custom communication protocols or high speed control loops, up to 1 MHz digital control loops and 200 kHz analog control loops.
PLC vs. PC vs. PAC
The “20 percenters” seeking industrial tools that push the boundaries of controller technology are quickly adopting programmable automation controllers. As PAC software evolves to provide more flexibility and ease-of-use, these products will become common in industrial measurement and control applications. The potential of easier programming for real-time operating systems, FPGAs, and digital signal processors also is making machine and skid builders take notice. However, with 80% of applications needing relatively simple control and computers available for a few hundred dollars, PCs and PLCs maintain a bright a future in industrial control. It is evident that PACs do not settle the dispute about the best control platform, but instead add another dimension to the debate.
By Todd Walter
Reprinted with permission from ISA/Intech
Originally Published: June 1, 2007