Back the PAC
A programmable automation controller (PAC) is an industrial controller that combines the functionality of a programmable logic controller (PLC) and a PC. Traditional PLC vendors use the term PAC to describe high-end systems. PC control companies do the same thing to explain industrial control platforms. As the technological gap gets smaller between PC and PLC, with PLCs using commercial off-the-shelf (COTS) hardware and PC systems incorporating real-time operating systems, PACs make the differences even hazier between different control systems.
Before the PAC, industries using elements of discrete control and process control had expensive options, most of which included complex hybrid kludges of both systems using equipment from more than one supplier, different operating systems, and all kinds of connectivity problems.
The birth of the microprocessor has transformed industry so the high volume of processor chips forced prices down. The hybrid kludge of functions became practical and no longer a kludge.
Some define hybrid as the partnership of discrete functions, which PLCs and continuous control of distributed control systems (DCSs) made simple and less expensive. Some define hybrid as the capability of batch functions that neither the original PLCs nor original DCSs could perform well without heavy engineering. Some refer to hybrid as the industries in which the systems work and serve, like pharmaceutical, fine chemicals, and food and beverage. And finally, some know hybrid as the architectural melding of the PLC simplicity and cost with the sophisticated operator displays, alarm management, and easy but sophisticated configuration capabilities of the DCS. The last definition fits the product offerings of traditional DCS suppliers and some PLC providers.
Much innovation has emerged in the area of less expensive, but sophisticated, control systems that smaller companies can afford. Systems today vary in control capabilities and degree of redundancies.
PC vs. PLC primer
Historically, the PC has endured the perception of three short-comings: stability, reliability, and unfamiliar programming environment. 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. With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure. 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.
Using a PLC to meet modern application requirements for network connectivity, device interoperability, and enterprise data integration presented other challenges. These types of tasks are usually more suited to the capabilities of a computer (PC). To provide these capabilities in a PLC-based application, additional processors, network gateways or converters, "middleware" software running on a separate PC, and special software for enterprise systems must often be integrated into the system.
On the other hand, a PC packaged for industrial environments can provide many of the capabilities sought in modern applications, particularly those needed for networking and data communication. Similar to augmenting a PLC to accomplish PC-like tasks, however, an industrial PC that needs to perform PLC-like tasks, such as machine or process control, also requires expansion. For example, a PC may be using an operating system that is not optimized for high-performance and deterministic industrial applications. Additional I/O expansion cards or special extensions may need to be integrated into the PC's operating system to provide the high-performance, deterministic, or near-deterministic operation.
PAC 'em in
A PAC is notable for its modular design and construction, as well as the use of open architectures to provide expandability and interconnection with other devices and business systems. In particular, PACs are marked both by efficient processing and I/O scanning and by the variety of ways in which they can integrate with enterprise business systems.
The PAC concept will not replace or supersede the traditional PLC, but it will expand the PLC's role and will play a major part in plant and factory automation today and in the future. The PAC concept provides easy integration for multi-domain functionality such as motion control, process control, and HMI. Demand for controllers based on the PAC concept arises from the need to integrate logic, motion, and process control in many applications.
PACs are attractive to manufacturers as they greatly reduce total cost of ownership by providing single integrated, multi-discipline development environment with common tag names and a single tag database for access by all functions. PACs also provide an open architecture for interoperability with other suppliers' solutions based on interface standards such as TCP/IP, OPC, and XML as well as open communication standards such as EtherNet/IP, Profibus, Ethernet Powerlink, and CAN.
SOURCES: Samuel Herb (samherb@ comcast.net) principal of JAOMAD Consultancy in Pennsylvania; Todd Walter, product marketing manager at Austin, Tex.-based National Instruments (todd.walter@ ni.com); ARC Advisory Group (www.arcweb.com); and Opto-22 (www.opto-22.com).
By Dick Morley
In 95% of all plant floor applications, speed (real time) is not required; a known response holds more importance. Whether the I/O is read by interrupt or sequential scan is immaterial, however I can remember many instances of an asynchronous I/O scan really screwing up application software because a pre-determined state could not be expected. The other 5% of the applications that have the need for speed have off-board controls to interface with the main scheduler.
In 30 years, the discrete applications have not changed much. The design and implementation for these projects have not changed much, and the problems we experience have not changed much. Troubleshooting the systems and the process being controlled still requires a multi-meter, prints, and knowledge of the process regardless of whether it is a machine tool or a distillation column.
The North American support staff for automation lies with the maintenance staff. They do not care about tag names, interrupts, or databases; and they should not have to. A PAC may allow for a design benefit with regards to networking, data access for HMI, and vertical applications such as SAP, but in the frame of mind of process these "features" do not matter.
Most PACs are simply PLCs in a different suit. Some may remember the PLC-3 from Allen Bradley. You could have multi-processors in the chassis, redundancy, and many scanners for I/O and communications; and it was called a PLC-3. The control Logix platform is a multi-processor, multi-scanner (although Ethernet was not around in 1980 in industrial automation), and it is called a PAC. What's different? Methodology, not function.
Control engineers still program in ladder logic because of the maintenance troubleshooter guys. They do not want to be called at 3 a.m. because the process is down. An OMAC survey found that over 80% of control programs use ladder logic. Hardware platforms that use IEC-61131-based programs to generate the application program still use ladder logic, not function block or structured text.
The integration of stuff like vision and motion is easier, and within the same confines of the controller, which allows for easier control. But I am not sure it is better.