September 2007

Hybrid control identity crisis

What is in a name?

By Samuel Herb

In the marketing world, everyone wants to make a clear distinction for his or her product. That is certainly wise. Nevertheless, semantics can often confuse even the conscientious buyer.
 
Defining a small process control network is not as easy as it sounds. Just try to find one on the internet as I just did.

Hybrid control in the 1980s meant connecting programmable logic controllers (PLCs) to distributed control systems (DCSs), which was an expensive proposition because of the needed engineering to overcome a configuration nightmare. 

Compatibility of hardware, software, communication, and common operator interface was a major issue. These had to configure the PLC and DCS portions separately and were often complex and expensive.

Why can’t there be a process controller that has the functions of a DCS at the price and simplicity of a PLC? 

“Manufacturers today seek multi-domain functionality, including logic, motion, drives and process on a single automation platform, along with a multi-discipline development platform, which incorporates common tagging and a single database with common software tools, and open, modular architectures that employ de-facto standards for network interfaces, languages, etc. This is driving the marketplaces’ growing demands for programmable automation controllers (PACs),” said Craig Resnick of ARC Advisory Group.

The differences in history 

In the 1980s, I developed the “Understanding Distributed Control” course for ISA. For the ensuing two decades, they badgered me to develop a course in configuring those DCSs. They reasoned they had courses to program PLCs, so why not do the same for DCSs? 

I explained to them most PLCs (in the U.S.) were programmed in ladder logic, which allowed a single course to benefit buyers of most PLCs. PLCs at the time were used in discrete applications, replacing banks of relays in manufacturing operations, primarily on automobile assembly lines. 

They usually involved one work area (cell) for each PLC with little need for rapid communication between. Operator interfaces were generally on/off switches; there was little or no need to connect them to other PLCs; and graphic interfaces were not common, if at all. The factory floor environment, although in need of rugged equipment, at least had to also be suitable for humans.  This was the domain of the PLC suppliers who dealt with a commodity business of making large quantities of an assortment of controller sizes with only some modifications of functions between them. 

They usually relied on the customer or local system integrators to install them to the specifics of each manufacturing plant, usually an assembly line or packaging operation. The same functions in each plant that may have used the same PLC supplier could easily reconfigure for the same results, especially at the hands of different programmers. Further, if different suppliers were used even more differences occurred because PLC architectures were not open—at least mechanical and electrically.

Each DCS, however, was uniquely proprietary because there was no “standard” configuration language among the different suppliers. The functions needed varied widely between many diverse industries—cement, steel, power, petroleum, water, paper, plastics, food, pharmaceuticals, etc. The operating environment for the controllers was often NOT suitable for humans, far too harsh and often quite corrosive for normal electronics. Interacting control loops clustered around a unit process. 

Operator interfaces were not just for on/off, but much more a navigational “adjust until …” These actions were often in conjunction with activities of other unit processes not in the same vicinity, requiring rapid communication between them. 

Suppliers had to design their own controller and operator interface to accommodate the intended industry. This in turn required unique communication techniques where the “standards” of the time just could not meet the requirements for process control.

The suppliers of process instrumentation, when dealing with each industry, had to relate more specifically to the unique functions of each. Suppliers tended to gravitate toward a set of industries that could take advantage of these built-in functions. There was not high volume for these more specialized controllers, which drove the price up. Because of this, DCSs were typically supplier installed, project-engineering companies, or a more limited set of specialized system integrators. 

Allowing for the specialized needs of each industry led to unique designs, which in turn caused proprietary systems. Thorough redundancy, for example, is important in most DCS-type applications, as is real-time communications and solid alarm management schemes beginning in the controllers themselves. All of the above required unique configuration languages for each supplier to accommodate these many considerations.

Climbing out of proprietary

As technology advanced, many of the barriers causing unique designs began to drop away. These barriers could not drop any faster than permitted by the new changes … and customer acceptance of technological change. 

Transistors were suspect, cathode ray tubes were suspect, plug-in modules were suspect, (as was plug-in wiring and the like), computers were suspect, microprocessors were suspect, Ethernet was suspect, fiber optic network was suspect, anything “Microsoft” was suspect, and so on. 

There was good reason for these technologies to be suspect when they first emerged. Responsible process control engineers and plant managers are accountable for the stability of continuous operations that are extremely expensive if they shut down even for a brief period.  Safety of people, equipment, and product is equally important. Of course, some of the proprietary effort was for marketing advantage, but most of it was because accepted new technology could only move just so fast.

Today, we are nearly there as so called “open systems” are actually becoming more open due to continuing advances in a variety of technologies. Now the challenges of open have created new challenges of cyber security. Process control engineers and plant managers must embrace new technologies yet be cautious and selective. 

PC controllers

The distinct differences between the PLC and DCS architectures, functions, and environments have diminished during the last decade and a half. 

One factor has been the development and acceptance of the professional (or personal) computer (PC) as a controller. PCs did not have a reputation for their deterministic real-time behavior. 

Although PC hardware vendors and software development vendors offered low prices, they were prepared to offer the time of support, or product longevity, that the industrial user needed. 

Nevertheless, PC control suppliers introduced open, standards-based technology. They pioneered the use of OPC, common tag databases, Windows NT, integrated operator interfaces, Ethernet, and TCP/IP on the factory floor. 

This was behind the attraction of standard hardware, software, and Graphical User interfaces. Like PLCs, PC controls were better for manufacturing applications than process applications—and for the same reasons as PLCs. 

Only recently are PCs beginning to meet the need for rugged specifications and high-level support. The elimination of vulnerable moving disks for hard drives, for example, is a major step forward.

Now for the semantics game

We are beginning to see a hybrid union of PLCs, DCSs, PCs, and remote termination units (RTUs) architectures and functions without compromising the unique features and capabilities of each product. This hybrid amalgam has led to several definitions of “hybrid” depending upon whom you ask.

• There are those who define hybrid as the marriage of the discrete functions, which PLCs handled so simply and economically, with the sophisticated analogue continuous control capabilities of the DCSs. 
• There are those who define hybrid as the capability of batch functions that neither the original PLCs nor original DCSs could perform well without heavy engineering. 
• There are those who define hybrid as the industries in which the systems work and serve, like pharmaceutical, fine chemicals, food and beverage, and others.
• There are those who define hybrid as the architectural marriage of the PLC simplicity and cost with the sophisticated operator displays, alarm management, and easy but sophisticated configuration capabilities of the DCS. 

I have, in the past, favored the last definition. To some degree, that fits what traditional DCS suppliers provide and as well as some PLC suppliers. My background is from the DCS world. ARC however, prefers the industry definition. Then they found the need to identify the control system itself, so they have coined the term programmable automation controller, or PAC.  Some PLC suppliers are beginning to use that term, even if they do not do sophisticated process control. Some do only motion control with PLC functions. DCS suppliers have used the name hybrid control since the time when they had to connect PLCs to their system. 

When the DCS suppliers began to incorporate PLC functions within their systems, they called them, of course “hybrid.” Some suppliers merely refer to a small DCS as hybrid.

I am beginning to understand ARC’s position. This hybrid phenomenon now manifests in a huge diversity of engineering applications, including air traffic control systems, unmanned vehicles, and everyday items like cars and consumer electronics. 

It is the combination and interaction of the discrete and continuous that makes this emerging area a particularly challenging field of research. In the industrial process control world we see much more functions involved, including sequential control as found in so many batch operations. This is likely why ARC decided hybrid was an industry, or more properly an application, not equipment. Before I leave the semantics issues, I have related another issue. “Traditional” supervisory control and data acquisition (SCADA) involves a network of remote control units, or RTUs, that might lose contact with the “supervisory” portion and thus must provide for independent protection in such a situation. It is usually outside the plant and often over great distances such as found in electric transmission and pipelines. There are unique communication needs for such a system. The simple marriage of a PLC to a PC is more correctly a data acquisition and control system, not a true SCADA. 

With these hybrid controllers combining functions of DCSs, PLCs, and RTUs, I can understand where, confusion continues in this area as well. With more sophisticated control situations today, there are occasions for traditional SCADA applications within the plant as well.

Common configuration approach

Most automation control suppliers are moving toward the IEC 61131 configuration standard. Briefly, the IEC 61131 standard requires a single software package to deliver five languages for programming:

• Ladder diagram
• Instruction lists
• Function blocks
• Structured text
• Sequential function charts

This standard emanated from a consortium of European PLC suppliers, but is incomplete from a process control standpoint. Application software within the function blocks was the creation of the automation control supplier. The IEC committee looked at the function blocks of the DCS fieldbus standard IEC 61158 to determine the enhanced function block standard IEC 61804. 

IEC 61804 from the DCS world and IEC 61131 from the PLC world will converge to the universal IEC 61499. This should meet the needs of the process industries and the discrete industries, and as a result, the hybrid (batch processing with packaging) industries. Now it will be possible for ISA to teach to IEC 61499 and cover most control systems as suppliers begin to convert. Many of the newer versions of DCSs already follow an IEC 61131 approach.

“Whether you are in a discrete industry trying to accommodate the demands of mass customization or in a 24/7 process industry trying to eliminate the consequences of abnormal situations, solving multi-dimensional problems with cognitive, adaptable, and comprehensive solutions can be inherently complex and extraordinarily expensive. IEC 61499 provides a basis for solving these problems that is simple, cost effective, and repeatable,” said ARC Insights, 2007.

Small control systems

Technology has been blazing ahead with larger memory capacity and smaller, faster processors in less space. The volume of quality commercial off-the-shelf digital devices used in so many everyday applications is bringing down the price. 

New Ethernet technologies have made that venerable communication technique practical for process control work. All of this has contributed to much more affordable, small control systems. This has in turn allowed inexpensive but sophisticated control for applications and industries, which previously were not possible or practical.

The new markets that opened up provided opportunities for the process control companies to offer smaller but complete systems. Because many of these systems had the capacity to scale up, they were equally attractive to traditionally larger companies to also “start small, grow large” and try different suppliers without much risk. 

The flexibility of the five IEC 61131 languages and their relative ease of use was attractive to batch-based industries, which often were small batch process units of operation with a packaging line “downstream.” That packaging line was the province of the PLC world. There was pressure (and opportunity) to marry the process and discrete functions in the same control system. Those batch operations were among the earliest to struggle with the need for a hybrid of discrete and process. This no doubt led to the designation of “hybrid industries.” Pressure on the pharmaceutical industries to expand production led the need for “hybrid controls” to also include large system networks. 

Both PLC and DCS suppliers raced to fill the void. Today they can be integral to enterprise control systems, which encompass the business side of the operations, not just the manufacturing. 

Further, systems include optimization at all levels, which include alarm management, predictive maintenance, cyber security, and the safety of people, product, and equipment. 

The ensuing nomenclature

So then, are hybrid controllers really PACs?

It sure looks that way to me. ARC’s definition says PAC consists of multi-domain functionality, including logic, motion, drives, and process on a single platform. It has these attributes:

• Single, multi-discipline development platform incorporating common tagging and a single database
• Software tools that allow the design by process flow across several machines or process units
• Open, modular architectures that mirror industry applications from machine layouts in factories to unit operations in process plants
• De facto standards for network interfaces, languages, and the like, allowing data exchange as part of networked multi-vendor systems

Clearly not all suppliers who claim to have PACs can do process control. Many of these do only motion control and PLC functions. I guess you can say not everyone easily meets this definition of PAC in its entirety, but keep in mind nearly every system is still evolving from its proprietary origins.

ABOUT THE AUTHOR

Samuel Herb (samherb@comcast.net) is a senior life member of ISA, a registered professional engineer, and owns JAOMAD Consultancy. He has worked various engineering and marketing jobs in the utility and process controls industries over five decades. He holds an electrical engineering degree and is a teacher and author.