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
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
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.
Leaders relevant to this article: