In addition, even if it did create compliant code, Rockwell Automation would just need to say where the extensions are and what effect they have on that compliancy, and then they can claim compliance.
To make sure I wasn't being overly biased, I enlisted colleagues on the Automation List at www.Control.com. "The conformance criteria are so general, it is virtually meaningless," says independent consultant Michael Griffin about compliancy.
Also, a published PLCopen document states, "The overall requirements of IEC 61131-3 are not easy to fulfill. For that reason, the standard allows partial implementations in various aspects. This covers the number of supported languages, functions and function blocks. This leaves freedom at the supplier side, but a user should be well aware of it during his selection process." This doesn't help us very much.
The original intent of the specification or standard was to create a common platform for control software development. When the programmable controls industry emerged in the 1970s, all software was written using dedicated hardware and firmware. With the advent of the personal computer, vendors developed their own development environments. It is no different today. The software programs that have been developed support only the vendor's hardware. There is no common platform here. We are no further along than we were 20 years ago.
For instance, using RSLogix 5000 or Schneider Electric's Unity is no different than when we used fixed programming terminals. You can't share programs, although PLCopen is trying to develop an XML transfer specification.
I anticipate that vendors will have import routines, but few, if any, will have export routines.
Likewise, the specification does not cover off-the-scan issues and program-execution methods. Process behavior most likely will change on different hardware platforms, since the software environment is different.
Some of the visualizations of the code are supposed to be close. If you look at ControlLogix5000, which Rockwell Automation states is IEC 61131-compliant, and compare the visualization with that of KW Software, for example, there won't be much similarity.
Tag-based programming is a plus, but even in the 1980s, many products had the ability to use symbols. With IEC 61131, you have to use symbols, but the length of the tag names is variable. You can't use a 40-character symbol with a product that supports only 20.
To me, IEC 61131 is similar to SQL, UNIX or C. They're standard products to some degree, but they're not called standards. The varying flavors don't interoperate, because, before the world went Microsoft, some compilers had very different syntax and ways of doing things.
In fact, Julien Chouinard, managing director of ICS Triplex–ISaGRAF, calls IEC 61131 a compromise.
However, while I think IEC 61131 has fallen short of expectations, this doesn't mean there are no benefits to the specification.
Benefits of IEC 61131-3
Now, make no mistake about IEC 61131-3. We're still in the same environment we were in before its creation. Rockwell Automation, Schneider Electric, Siemens Industry, GEIP and Wago all have their own programming environments. The business of automation won't allow for real interoperability of these competing products.
The main difference from 20 years ago is that there is some form of commonality. There are some good reasons to use an IEC 61131-based product. Tag names permit abstraction of the hardware I/O, so databases from product to product could be maintained externally. All will use tag names-based variable allocation and typically the common elements, such as Boolean, will behave the same. That doesn't mean, however, that all vendors support all the common elements.
Most products will have all five languages. A large benefit of an IEC 61131-integrated development environment (IDE) is access to the function block part of the software. The power in function block programming is tremendous. This is the type of programming the older DCS products had 20 years ago. You can program a very complex part of the application and have it hidden behind a block. Some argue that this improves troubleshooting capabilities.
In return, it requires a better programming skill, as well as a good handle on the project scope and project management. This is foreign territory to many ladder programmers.
A selling feature of the standard is the ability to develop control strategies in the right language. While I agree with this, the plant floor maintenance staff usually doesn't include a structured text guru. This is scary for the controls engineer who develops the application, so oftentimes he'll just use ladder logic. Therefore, one of the major benefits of function-block programming is left untapped as a result.
Proponents of IEC 61131 swear by its training and investment benefits. They say if you use Company A's IEC 61131, and later you have to use Company B's IEC 61131, then you already know how to program the hardware. This is not necessarily so, but there is some truth to it.
Many companies use a development package from 3S, some use a product from Softing, and others create their own. If an OEM used IEC software from four different hardware vendors, and they all licensed their software from one company, the OEM stands a better chance of being able to migrate the learning curve to the new hardware and of being able to reuse the software.
Will the training cycle be shorter? Probably. But from vendor to vendor, there is some level of commonality that can be borrowed, but the impact may be limited.
Will IEC 61131 help the maintenance person trying to solve a problem at 3:00 a.m.? For most user companies that standardize on a single hardware platform, the answer is "no." They'll get used to whatever the software tool is. IEC 61131 isn't important.
It might be important to you if you leave your company and have IEC 61131 on your resume. It surely can't hurt.
If you're a machine builder or a manufacturer with multiple vendors that all use IEC 61131, maybe it helps. There are some inherent similarities that could help getting refamiliarized with a hardware platform or a software troubleshooting tool, but I think this is a personal function rather than a software tool function.
No doubt IEC 61131 is here to stay. Early misunderstandings of the benefits, and resulting misconceptions of what an IEC 61131-based product actually was turned off many potential users.
Open is as open does. IEC 61131 is the same. It is simply a platform for a software product design tool for hardware. It provides some benefits or the OEM and the user, but mainly the vendors benefit, in my perception.
It is no panacea. It can help in our quest for a better automation platform, but we will leave that for IEC 61499, a true standard. As long as we don't screw it up.
Jeremy Pollard has been writing about technology and software issues for many years. He is publisher of "The Software User Online," has been involved in control system programming and training for more than 25 years and was previously North American managing director of PLCopen (www.plcopen.org), which drafted IEC 61131.
To read Jeremy Pollard's multiple-part saga on IEC 61131 and other related articles, visit Control Design's IEC 61131 resource page at www.ControlDesign.com/iec61131