We get pressure from customers to provide control software compliant with the IEC 61131 standard. We see the commonality benefits, but we don't find the portability argument very persuasive. We get what we need with the development software from our current PLC supplier. Can anyone tell us that the standard-based software packages really do help with portability?
—From August '10 Control Design
Not Much Help
You are correct. The portability argument is not very persuasive. While it is a long-term goal, making programs that are portable is somewhat limiting as manufacturers are permitted to add functionality that goes beyond the IEC 61131 specification. The specification details base-level functionality, extended functionality (the specification has been revised several times) and vendor-specific functionality. As soon as a vendor adds some operational features that are unique to them, which most vendors have done, the possibility of portability disappears. If we limit the discussion to programs using only base and extended features, there is the possibility of portability, but there has not been any momentum to make that happen short term.
The more important argument for IEC 61131 is that program structuring is the same across vendors, and once you have familiarity with one IEC 61131 editor and product, you can move to other editors and products with minimal or no additional training. This is a major benefit in that training costs are much reduced. A plant can have IEC 61131 products from many vendors, and engineering and maintenance people will be able to support them, whereas that is difficult when every brand has proprietary programming software.
Charles Schiller, Ph.D., chairman
Ormec Systems, www.ormec.com
It's About What "Is" Is
The dictionary definition of portability reads, "Able to be transferred from one type of computer system to another." One might want to believe that this means the same software developed for any compatible IEC 61131 controller can be loaded into any other one. Of course, this is far from the truth. I don't know of any vendors that can make this happen.
Now, if it is understood that "able to be transferred" merely means that the software used to develop the code is developed with a language that is consistent from vendor to vendor, then, in that sense, IEC 61131 code is transportable.
However, the main advantage machine builders get by offering IEC 61131-compatible code is that they can avoid issues regarding code interpretation because the format of the code is basically the same from vendor to vendor. In addition, the customer argument about needing to retrain their personnel to understand the programming environment used by the machine builder also is countered easily. This in itself is a reason to offer IEC 61131.
Vendors always look for ways to differentiate their software product from everyone else, so even though IEC 61131 is a necessary option and an advantage to the machine builder for the reasons stated, most vendors count on the things that make their software unique to sell their hardware.
Joe Rizzolo, controls sales manager,
Standardization of software tools not only helps with portability, but also helps cut the learning curve when you switch to a new system that uses a different development tool. Having standardized languages with common syntax, variable data types and basic functions makes a transition from one system to another easier when, for example, you don't have to learn again how to implement a simple timer-on function.
Importing code from one IEC 61131-compliant system to another also is an advantage, though there often are limitations that require manual rework because IEC 61131 only specifies very basic functions and also allows quite a bit of flexibility for every manufacturer in how to handle language-specific details, like EN/ENO in ladder. Most applications require more complex functions that aren't standardized, so manufacturers implement their own functions to use a system effectively.
In recent years, however, some trends emerged beyond IEC 61131 that are widely adopted. One example is the PLCopen organization, which specifies functions for motion control as well as programmable safety to permit programming of motion control and safety without having to relearn every manufacturer's specific command set. Another example is using OPC for communication between controls and SCADA/ERP systems. OPC provides a standardized and manufacturer-independent communication between those systems without the need to develop custom communication drivers. Beyond that, industry-specific standards are becoming more popular, e.g. in packaging, semiconductor, printing and commercial laundry applications. These standards allow data exchange between machines and ERP systems, and are tailored to industries' specific needs.
Using software packages that comply with IEC 61131, and readily support the above mentioned standards will not just help with portability. They will minimize engineering time to implement connectivity standards that are necessary for data processing and diagnostics in a continuing quest to improve productivity in modern manufacturing.
Robert Muehlfellner, director, automation technology,
B&R Industrial Automation, www.br-automation.com
Portable When Simple
The short answer is that standards-based software packages do help with portability—but only if you're programming fairly basic applications. However, the IEC 61131-3 standard defines only a limited number of instructions, such as simple math functions, timers, etc. The standard doesn't provide instruction sets for higher-level applications, such as motion or process control. As a result, if programmers were to stick with only those instructions that are defined in the IEC 61131-3 standard, they would end up with code that was portable from one vendor's platform to another. However, they and their customers would not be able to leverage the full power of their automation system. For more complex applications, using the instruction sets included in the programming software provided by your vendor will help you to reduce programming time and costs, and ultimately deliver your machine to your customer more quickly. This multidiscipline capability also can help eliminate separate safety, motion, process and robotics hardware platforms and their associated proprietary programming, which rarely abides by the IEC 61131-3 standard at all.