A Look at IEC 61499

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. 

Open-Source ENABLES FBDK

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.