A Look at IEC 61499

ControlDesign.com

The Standard Claims Benefits in Distributed, Event-Driven, Hardware-Independent Programming. Should We Be Paying Attention?

By Jeremy Pollard, columnist

In April 2002, Bob Lewis, author of Programming Industrial Control Systems Using IEC 61131, wrote about 61131’s new “cousin,” IEC 61499. He wrote that, “[IEC 61499] comes from a growing interest in new technologies and architectures for creating the next-generation of distributed systems for industrial automation.” Lewis’s books are published by IEE (now the IET) in the U.K., the equivalent of the IEEE in North America, so standards are a familiar topic to him.

Five years later, you can buy a few 61499-compliant products and tools from a few vendors. While Lewis was ahead of his time then, now is a good time to determine where the standard is today, and why it might be important in our future.

Many users made the same mistake that Lewis did regarding open control in the late ’90s. Some of us thought a big percentage of control systems would be done with open systems by 2000 or so. The marketplace, users, and vendors had different ideas. IEC 61131 is an option that still is largely not well-understood, and hasn’t had the impact in the North American automation space that most of its supporters thought it would.
So could the IEC 61499 standard buck the odds and become a global success?

IEC 61499’s Roots

The standard evolved from a Rockwell Automation initiative called Highly Distributed Control, which attendees might have seen at Rockwell’s Automation Fair in the late ’90s. It demonstrated how an individual photocell or proximity switch could make a control decision to switch a solenoid. There was no PLC or central control component—the devices were executing code on their own. The interface was an AutoCAD-type development system, which used function blocks similar to IEC 61131 and typical DCS systems.

Dr. Odo Struger was Rockwell’s driving force behind new technologies. Stuger is credited with coining the term PLC, and was heavily involved in the development of Rockwell’s automation strategy. He was instrumental in developing the IEC 61131 standard.

Dr. James Christensen is a retired Rockwell Automation engineer with a vast background in automation and standards. He currently is chairman of SC65B/WG7, the IEC 61499 subcommittee and working group. He also was the chair for the IEC 61131 working group and runs the automation resource web site www.holobloc.com.
According to Christensen, Struger led a group of appointed volunteers to move the standard forward, since no one was steering this ship at that time.

Roughly 14 years later, IEC 61499 emerged in 2004 as a published standard, in most cases to rousing silence.
Mark Johannesson of ATS Automation, a company with global presence in machine design and build, says the IEC 61499 specification is new to him. He uses an IEC 61131 programming tool, but ATS designs to customer capabilities. This means using primarily ladder diagram for the control platform.

Johannesson thinks the distributed processing object model is a good idea. One of his primary suppliers’ product, Siemens CBA/IMAP, uses the IEC 61499 design model. But rather than his customers trying things on their own, he thinks users should wait for systems from ATS that use CBA/IMAP designs, if for no other reason than proper support. “What happens when it stops working?” he asks. At present, however, ATS has no plans for serious 61499 implementation.

The Standard Itself

Christensen distinguishes between centralized control (normal PLC-based control system), hierarchal control (distributed I/O, PLC with fieldbus or remote I/O), and distributed control (no PLC necessary).
Typical DCS systems used remote terminal units (RTUs) as a form of distributed control for years. IEC 61499 is an extension of where we’ve been.

The IEC 61499 standard maps out a design-first, implement-second approach for function block (FB) design. There currently are four parts to the standard:

• Architecture
• Software tool requirements
• Tutorial information
• Rules for compliance profiles

IEC 61499 ARCHITECTURE

Figure 1: IEC 61499 defines the function block. Photo courtesy of Pabadis’ Promise

The main component of the standard is the Architecture section. It defines the basic building block, which is the function block (Figure 1). According to Christensen, the object model of these function blocks allows for true encapsulation, reusability and portability between control systems.

This is different than 61131, since the fundamental design of 61499 is hardware independent. While the promise of 61131 suggested portability of code, it has never materialized due to its hardware dependency.
The design of the standard involves a system with independent devices communicating with each other without the need of a central processor. This implies a connectivity network (read fieldbus), function blocks for events and data, as well as specialized FBs for communication.

The function blocks have event connections, data connections, and an underlying algorithm—program—that tells the blocks what to do when they receive certain events, and which data points to use.