A Look at IEC 61499

Oct. 4, 2007
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
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.

This is no different than a PLC-based solution, except the I/O point is really the device itself. It’s also event-based, not scan-based, Christensen points out. Scan-based systems are PLC-based systems.

The real power of this standard and its implementation, is the “scalable, reusable, configurable and distributable code that’s created,” says Christensen. This approach makes the control system implementation less of a hardware-based design implementation and more of a software-based approach.

“IEC 61499 abstracts the sensor or control points as a function block, ultimately combining hardware and software together,” states Christensen. “It’s a micro-PLC all on its own.” The system designer, he says, connects the software dots to create the control system.

In a 61131 control system, the fundamental approach is that of a PLC and software which dictates hardware choice first, and then the control program.

The software used to program a 61499 system is a challenge with the current offerings. The algorithms that support each function block can be created using the programming elements from 61131.

At this point, it’s important to understand that the code in a 61499 function block is nothing like a FB in 61131. The implementation of a 61499 FB is dependent on the function it provides, which in most control systems would be different for System A than it would be for System B. However, it’s the intent of the device vendors to have an inherent 61499 interface with a drop-in FB, “which will result in many saved hours of software design,” says Christensen.

The software environment allows the users to create the necessary types and configurations that each control system might require. These are:

  • data types;
  • function block types;
  • resource types;
  • device types; and
  • system configurations.

The IEC 61499 model is independent from application domains and hardware infrastructure. Its encapsulation concepts, the concept of interface-service FB, provides a high level of abstraction, allowing for dealing directly with automation objects without primarily dealing with the implementation details. Moreover, the concept of encapsulation of functionalities and data into FBs decreases the probability that small changes in requirements or implementation might have fatal effects on the entire software structure. 

Figure 2: This basic function block editor environment shows code and connection points.
Photo courtesy of Holobloc
Christensen has developed a function block editor or FBDK (Figure 2), which is a free download from his website. While it’s a good way to learn, it could be a bit intimidating to some. Users must be sure the Java SDK is installed and running before executing the application. This allows you to create a function block along with some additional system-resource-type FBs. The software platform for this environment is Java, and uses XML as a transport language. It’s because of these open-source languages that the standard has the potential to be all things to all people.

This FBDK exposes the different layers in source code, so you can better understand the 61499 concepts.
ISaGraf 5.x from ICS Triplex, which recently was acquired by Rockwell Automation, is an IEC 61499 editor that abstracts the language issues.

Who Needs It?

Christensen thinks small niche companies, users and vendors alike, would succeed best at implementing the standard. His take on the standard that he helped create is from the angle of competitive advantage. He implores North American companies of all shapes and sizes to embrace the standard, and exploit the advantages to become more competitive.

Julien Chouinard, president of ICS Triplex ISaGraf, agrees. “The OEM challenge has been to select the PLC to use, and build the machine control based on a specification,” he says. “With IEC 61499, that goes away.” Chouinard seems to say that using 61499 design criteria can make a solution more competitive by default.

With Java chip sets widely available and with a free development environment, any company can implement its own distributed control system. As a result, “established market leaders have no interest,” Christensen says, when asked which vendors might embrace the standard. “The smaller more nimble companies can use their attacking advantage to be successful in applying the standard.”

Not everyone thinks this standard will have a big impact. Vladimir Zyubin, senior researcher from the Institute of Automation & Electrometry in Novosibirsk, Russia, prefers other directions that address a similar environment, which include using UML, ESML (extended system modeling language), and DECN (discrete event control network).

“IEC 61499 is an attempt to enhance the 61131-3 standard with the event-driven strategy,” says Zyubin. “The approach is very interesting, but its future is questionable. It seems to me the big [companies] aren’t interested in that development. It also seems there is a big problem when we try to connect the primitive tools—the artificial metaphoric language of Function Block Diagram—with the advanced technique of event-driven strategy. To be more specific, what are priorities of the event-inputs? This question has no clear answer from the 61499 metaphor’s point of view, so it is a problem of the 61499 standard.”

That’s not necessarily a problem, says Armin Steinhoff, founder of Steinhoff Automation.

"FBD is a Turing complete representation of control algorithms, he says. “So FDB can express every thinkable algorithm.” Turing complete languages or machines are those that can express arbitrary computations.

Steinhoff says the input-event priorities Zyubin mentions are implementation-dependent. “An event can be ever-changing data, and the priority of handling such changes depends on the application.”

Steinhoff believes the distributed nature of IEC 61499 is the standard’s biggest real problem. “I think Ethernet-based networks like Profinet, PowerLink, Varan, or EtherNet/IP are good candidates for it, but I think it would be a good idea to remove the networking issues out of the IEC 61499 standard. For the distributed processing—as defined in the IEC 61499 standard—it could use a virtual machine similar to PVM or MPI, in which the network is the controller. This also would simplify the handling of a distributed control system, and would be much better than the use of communication interface blocks.”

Chouinard thinks the standard stands well on its own. “IEC 61499 is a genuine open standard, if we leave it alone,” he argues. While the Internet has allowed for faster information flow, “it might be three to five years before products based on the 61499 standard are accepted.”

Standards come first, and then products based on that standard. He foresees vendor-supplied 61499 function blocks shipped with their hardware products. “There is no issue regarding interoperability,” says Chouinard. “The standard guarantees this. Seamless integration of any system or device using service interface blocks will accommodate the control system’s need for flexibility and robustness. 61499 makes it easy.”

Jeremy rants about iec 61131

Inside ControlDesign.com’s MBF, machine builder forum, Jeremy lets off some steam about why IEC 61131 isn’t all it’s cracked up to be. He wants to have you comment and see if there’s a consensus to be found about the standard’s value to machine builders.

Click on MBF on the home page, and you’ll find Jeremy’s comments in the software section.

Sponsored Recommendations

Engineer's Guide to Advanced Motion and Mechatronics

This guide will examine the remaining differences between stepper and servo motors, new perspectives on motion control, the importance of both gentleness and accuracy with linear...

eBook: Efficient Operations: Propelling the Food Automation Market

For industrialized food production sectors, the megatrends of sustainable practices, digitalization and demand for skilled employees are underpinned by rising adaptability of ...

2024 State of Technology: Report: Sensors, Vision & Machine Safety

Manufacturing rarely takes place in a vacuum. Workers must be protected from equipment. And equipment must be protected. Sensing technology, vision systems and safety components...

Enclosure Cooling Primer

Learn more about enclosure cooling in this helpful primer.