Moving toward PACs

Years ago, it was easier to delimit the scenarios that mandated use of a programmable logic controller versus those of some sort of PC-based control.

By Matt Mekschun, Schneider Electric April 15, 2008

Years ago, it was easier to delimit the scenarios that mandated use of a programmable logic controller versus those of some sort of PC-based control. PLCs handled the hardware I/O control quickly and efficiently, often at the machine interface level. PC-based control often was used when integration into some sort of enterprise process, such as information acquisition into a database was required. One was essentially the domain of the hardware engineer or maintenance person, while the other was the domain of software or information technology personnel.

The continued trend of smaller, more powerful computing technology has not been lost on the automation industry. Emerging from this trend is the concept of the programmable automation controller. The PAC blurs the traditional PC vs. PLC control argument in the following ways:

Increased functionality — Expanded capability from handling traditional PLC functions such as discrete and analog I/O control scenarios, to include heightened serial network and expanded data storage. PLCs originally were designed as a replacement to traditional relay-based applications. The PLC would interface with discrete and analog I/O, using a control program to adjust outputs based on inputs. A PAC can easily perform this same function but goes far beyond, using modern data networking to interact with distributed I/O, drives, other PAC devices, enterprise-type entities, SCADA systems, HMIs and more. Advances in memory technology allow a modern PAC to have extended data storage capability far beyond a traditional PLC. In addition, the PAC often provides inherent algorithms for tackling modern control scenarios such as PID and process loops.

Cross-segment use — Moving beyond the typical realms of PLC-like machine control and into data acquisition, process control, remote monitoring, etc. The conventional realm of the PLC is an industrial automation environment such as manufacturing. PACs have the ability to take a much more expanded role. Remote monitoring and data acquisition, for example, are now easily accomplished using a PAC’s networks, expanded memory and processing power. The modern processor technology and integrated features of most PACs allow them to be used in applications far beyond the facility of a traditional PLC.

Networkability and open standards — Establishing network communications with enterprise infrastructure, other automation components and even other vendor’s equipment. Closely coupled is the idea of open standards such as TCP/IP to facilitate this ease of integration. Modern data communication networks are one of the biggest catalysts leading to the creation of the PAC concept. While PLCs also used data networks, often they were closely tied to the vendor’s proprietary offering. The PAC is designed to be easily networked — not only with automation devices, but with existing enterprise infrastructure. Ethernet TCP/IP is obviously the cornerstone of this concept since it is an established open standard.

Open standards are important since they facilitate development beyond the scope of the creating entity. In theory, any programmer with the inclination can take the open specification and develop an implementation to interface with their particular application.

Multi-task capabilities — Seamless ability to handle multiple tasks, thus maximizing the processing time available at any given moment. The PLC is a very dedicated and linear device. It continuously scans its I/O map, feeds this data to its program and then repeats. In order for the PAC to accomplish its mission, it must have and use a multi-tasking operating system. Multi-tasking takes the various tasks that the PAC must accomplish and time-slices between them. Not only does this allow for efficient use of the PAC’s processor, but makes possible the response times necessary in multi-network and control environments.

This multitasking support also is available to the developer. From within a development environment, the application developer can create independent autonomous tasks. These tasks can be completely different in function, but use the same I/O structures. This is a true departure from the traditional linear type, processor-scan based programming of a PLC.

Modularity — Logically mapped I/O within the PAC, which assists in quickly adding, removing and modifying interface components on demand. The PAC is by nature an expandable device. This expansion can be of the conventional PLC-type rack module, or of the networkable device such as a distributed I/O block. Also, the PAC itself can be part of this modularity by introducing the possibility of distributed intelligence within a system using networked communication. The PAC’s development environment uses logical I/O mapping to abstract hardware details from the program. Hence the addition, removal, modification or even replacement of a PAC-linked device should not require program modifications, only tag database modification.

Integrated development environment (IEC61131 languages) — Integrated multi-language approach with a centralized tag database that is easily exportable. Referred to previously, the development environment is a key component of the PAC concept. For better or worse, the PLC will always be linked with symbolic ladder logic programming. With the open standard IEC 61131-3, five languages are defined for automation: ladder diagram, sequential function chart, instruction list, structured text and function block diagram. These languages can be mixed and matched within the development environment, facilitating readability, efficiency and debugging of a program. In short, the IEC 61131-3 languages provide the flexibility necessary to decrease development time while increasing the quality of the final program.

The PAC development package must support the concept of a centralized tag database. This tag database should be easily exportable to all data consumers. Integrated development environments are critical for the PAC to be used in the expanded roles previously outlined.

The future

As the trend of integrating additional processing technology into smaller devices continues, the PAC will become even more modular and powerful. More complex and faster integrated networks and services will become the norm, and the PAC processing will keep pace. Resident memory will increase to the point that internal databases will become feasible for even more robust data collection. Hence, the PAC concept will expand further, providing more opportunities and new applications.

Author Information
Matt Mekschun is a field application engineer at the OEM Technology and Solutions Center of Schneider Electric’s North American Operating Division. He has more than five years of experience in engineering. Mekschun received a Bachelor of Science degree in electrical engineering and computer science from the University of Wisconsin-Milwaukee. He can be reached at matt.mekschun@us.schneider-electric.com .