IEC 61131 Cage Match—Prologue

By Jeremy Pollard, CET

The topic was IEC 61131, the international standard for industrial control programming of PLCs and embedded controllers. “This emperor has no clothes,” stated Ken Crater, president of Control Technology Corp., in his remarks at the ISA conference session I organized some 12 years ago, making an analogy to an age-old fable.

Dick Morley, the consensus inventor of the PLC, had mugs made that rather sarcastically read: “IEC 61131 and MAP—Partners in Success.” Clive Smith, then product manager for Schneider Electric, the developers of Concept IEC 61131 programming software, broke one of these mugs with a hammer, suggesting that Morley was old school and off the mark. Schneider Electric had bought Morley’s old company, Modicon, and developed an IEC 61131 programming package for this product line.

In several upcoming columns, I’ll let off a little steam about this “standard” and bust some myths surrounding IEC 61131, particularly what it is, what it isn’t and what it really means to a user.

To read Jeremy Pollard's multiple-part saga on IEC 61131 and other related articles, 
visit our IEC 61131 resource page

One of the first vendor presentations on the subject I witnessed was from a sales guy from what was then Moore Process Solutions. He held up a floppy disk—yep, it was that long ago—and said that a program from any IEC 61131 controller could be loaded into a Moore process system simply by loading the program from the disk.

That was wrong. I knew it, but no one else did.

In that time and place of independent software companies, there were many that grabbed the opportunity to develop and promote IEC-based products, especially in the soft-PLC world. Many product performance claims were made to promote the sales needed to recoup the development costs. These comments made the product seem complete and regularly promoted the future of portability and standardized programming.

Those who had struggled with the transition between Modicon and Allen-Bradley, and maybe ISSC, knew what those advantages could be. But the reality didn’t live up to the claims.

OMAC promoted IEC-based programming for any controllers that were to be used. GM, one of the biggest contributors to OMAC, decided to standardize on Allen-Bradley hardware, and its software was not IEC-based. So much for that.

IEC 61131 is an opportunity for vendors to use words such as compliant and compatible, a marketing tactic to gain some traction. It’s like high school: Even though you can’t dance, you still need to be at the party.

IEC-based software isn’t a requirement in the minds of most end users. Vendors have chosen to support the specification because of perceptions, global marketing and support for multiple hardware platforms. There’s also another important reason: They can buy a third-party development package, tune it to their hardware and have a programming solution without a huge development effort. The success of OPC allows a hardware vendor to develop a communication driver, buy the development environment and have a full software support system without leaving its core competencies.

But do we, the technology consumer, care about having a standard? Is it important to be able to do some things with Siemens software that we can do with Rockwell software?

We are in the same pickle we’ve always been in—attempting to use proprietary software with proprietary hardware.

I think the IEC 61131 specification is not a user-based spec or standard, but a vendor specification for software development. It is a standard much like SQL and UNIX are. While a software method might be called a standard, it really isn’t. TCP/IP is a standard—there’s no waffling from the design.

Who was it that said, “Standards are great. There are so many to choose from.”?