The PLC is dead, long live the PAC!

Citation

Piggin, R. (2008), "The PLC is dead, long live the PAC!", Assembly Automation, Vol. 28 No. 1. https://doi.org/10.1108/aa.2008.03328aaa.002

The PLC is dead, long live the PAC!

Contrary to the nay sayers, the PLC continues to evolve, but you would be wrong to think they are the still conceptually same beasts of yesteryear. Although, colloquially we recognize the PLC term, the functionality of some PLCs has changed dramatically. So much so, that the industrial automation analysts ARC used a new term to describe the emerging technology, borrowed from Rockwell Automation. The new term, PAC, originally stood for Programmable Automation Controller. This was used to differentiate the new technology that incorporated much PC-like functionality (Ethernet, web services, OPC, floating point and data structures), inside the skin of the traditional industrially hardened PLC (featuring non-traditional PC like qualities such as stability, “instant on” boot time and high reliability). It seems PAC has become interchangeable with Process Automation Controller. The process industry should not dismiss this as sleight of hand, for it is not. The PAC is increasingly moving into the area occupied by distributed control systems. How could this be?

At the high-end, “state of the art” PACs are object oriented, collaborative, network centric devices that combine all of the traditional disparate control disciplines (sequential, drive, motion, process, batch and safety) into a harmonized engineering environment, with upward linkages directly into IT, SCADA, MES, ERP and LIMS systems. The attractiveness has been the fit and cost structure being more suitable than the traditional DCS model. Conversely, there are still plenty of traditional PLCs to be found without the high-end functionality of a PAC. The more recent mid-range controllers are also encroaching in the process and hybrid space, witnessed by the increasing sales volumes from various “PLC” manufacturers.

In preparing this viewpoint, it became apparent that the terms fieldbus, function block and control platform mean different things to different people. I recall an early draft of IEC 61158, prior to the call to arms, “Let the market decide.” This was just before the out break of the first fieldbus wars, where the resulting multi-headed Hydra still continues to grow, despite removing a few of the monster's heads. The fieldbus definition clearly originated from the process industry, but did equally apply to factory or discrete automation networks; where IEC 61158 and IEC 61784 subsequently grew. However, fieldbus technology and PCs did not mean the end of the PLC, or its network architecture, despite opinion to the contrary. Rather, both the PAC and networks have provided more functionality, options and routes to other networks. Function blocks describe device functionality, and may reside in a device/instrument or a controller, courtesy of the network, depending on your point of view or technical persuasion.

Turning to PLC languages, modular code has become very popular. Modular coding provides an opportunity to utilize a building block approach, creating small reusable/object- oriented components (that may or may not be encapsulated in a function block). These can then be used to build larger unit level control with programs. New technologies facilitate “container” isolation, allowing reuse of objects/tags, within a single controller as opposed to global use throughout a controller. The ability to share tags between controller, drive and HMI and utilize pre-defined “face-plates” (HMI screens representing device functionality) reduce engineering effort. Other features, such as user-definable arrays with description pass-through and tag description concatenation automate the creation of project documentation. The effect of these core capabilities can greatly reduce program development time by improving reuse. This results in shorter commissioning times, because proven solutions are being reused with less need to reengineer and revalidate. This enables OEMs and system integrators to build in more functionality for a given price or offset costs in other areas, for instance, in more expensive hardware components. Whilst automation vendors are now providing modular code with devices, end-users are also making use of best practice “snippets” of code shared and downloaded via internet-based vendor support forums.

Like the control platforms, there is the convergence in the languages. IEC 61131-1 derived from the PLC arena, whilst IEC 61804 was driven by the DCS vendors. Object orientation and function blocks (IEC 61499) are evidence of convergence, facilitating modular program code, encapsulating functionality and offering distribution, configuration and reuse.

Vendors offer various IEC 61131-1 languages to realize program code. Unfortunately, personal experience may lead to unreliable selection of programming tool or technique, reducing programming effectiveness. Is the benefit or impact of these different tools/techniques measured? How do programmers know they have chosen appropriately? Whilst some programmers may consider they have chosen wisely, the early evidence suggests they may have been better served using an alternative.

Richard PigginRockwell Automation, Milton Keynes, UK