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
Answers
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,
Kollmorgen, www.kollmorgen.com
Standardization Simplifies
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.
Clark Case, Logix software product manager,
Rockwell Automation, www.rockwellautomation.com
Portability Is Overrated
The intent behind IEC 61131 was to standardize programming environments in the automation world. The actual standard is the result of taking what was, at the time, the proposed industrial automation languages of the major automation vendors, and putting them into the same basket to create a universal standard. In 2010, although there are five specified languages, we see very few users leveraging Instruction List. The preferred language is Function Block Diagram, and then Ladder Diagram and Sequential Function Chart in various market segments, depending on the region of the world and the ease of use of a language for a given application. Our customers typically use two and sometimes three languages to better describe their application.
Interoperability and portability are a different matter. PLCopen put effort into defining an XML format that all should adhere to for portability. But as we know, vendors are reluctant to provide interfaces to the PLCopen-recommended format because this opens the door for a customer to replace their software with a competitor's software.
Yet, even if you could port a program from one software to another, the specificity of the control application, the performance and characteristics of the firmware, I/O drivers and communication layers would make it very difficult to replace one product with another. When it comes to safety applications, the switch to another software would invalidate the certification of a given system and would, therefore, be very costly and futile.
The emergence of IEC 61499 takes this into account, whereby the focus is more on interoperability than on portability, even though all would understandably dream of portability.
Industrial automation is a science, and the overall design of a given controller is heavily engineered to meet the specific requirements of that controller. In this situation, portability becomes a moot point. In industrial automation, products are expected to have non-obsolescence policies and be supported for 15+ years. The real issues are the reliability, evolution and long-term support of the product.
Julien Chouinard, managing director,
ISaGRAF, www.isagraf.com
With a Little Help
This is a common question surrounding IEC 61131-3-compliant PLC software. Rexroth supplies IEC 61131-3-compliant PLC software that is used in any of our controls, whether they be our PC, controller or drive-based architecture platforms. The single suite is used to program everything we make, and even configure third-party devices to work with our architectures. There have been a dozen or more times that I've shown customers how to port over a program from a competitive IEC-compliant system to ours.
It's done by opening their program with our software, simply by double-clicking. The program is brought in with all the logic, function blocks, tags, etc., which typically represents about 80% of the program content.
Several errors typically are indicated associated with any non-PLCopen functions that were used in the original program. A find-and-replace function is used to replace these functions with our PLCopen-compliant equivalent functions.
After getting the code ported over, you need to address the hardware configuration settings to modify them to match the hardware platform (I/O configuration, parameters, tasks, events, etc.). We offer a wizard that steps through the configuration and fills in settings based on the hardware.
Another portable aspect are the Open Modular Architecture Committee (OMAC) standard guidelines such as Pack ML machine language template and PackTags HMI tags. These are transportable from one platform to the next, and provide a state machine logic template to program in. The idea behind their use is to promote common look and feel across OEM machinery builders to aid inline integration on an end customer's floor at the time of installation, and to allow better MES/ERP integration by IT people for running dashboards.
Here's some friendly advice when programming your machines with portability in mind: Try to use as much PLCopen standard function blocks as possible vs. using manufacturer-specific (proprietary). This will allow greater transportability. Also, pick a manufacturer that offers a scalable hardware so that in some cases you won't need to change manufacturers. Instead, just move the critical intellectual property aspects that determine the performance and quick delivery or long-term support of your machines down to lowest architecture and add a spec PLC "on top of" your existing architecture for a simple up charge. That way everyone—programmer, service person, salesperson, senior management and customer—will be happy.
Keep in mind that you still have HMI interface and tag issues to address. If you use the same HMI and the new hardware has a driver for that HMI, you should be fine.
Another consideration is the interface to the drives (servo or ac frequency drives, typically). How will the program's control loops deal with the drive differently and what is the command interface? Is it SERCOS III over Ethernet, or SERCOS II Fiberoptic, ProfiNet, EtherNet/IP, etc.? These are things to check on and test out.
Dan Throne, technical marketing manager,
Bosch Rexroth, www.boschrexroth-us.com/brc
Rely on PLCopen Conformance
PLCopen offers varying degrees of conformance for the IEC 61131-3 standard. While Base Level Certification defines items such as data types, instruction and graphical representation, the Reusability Level focuses on the exchange of function blocks between two vendors.
Siemens offers all five of the IEC 61131-3 languages in our Step 7 software. We supply the IEC Conformance Tables required by the standard, which verify the degree of conformance with the standard for each programming language and—if required—use only command subsets that conform to the standard.
However, in order for standard-based software packages to help with portability, both vendors need to meet the Reusability Level Certification for the same programming languages and support the same instructions and data types. This means it's possible to exchange Structured Text program code with another vendor. If any of these prerequisites are not met, seamless code exchange is more difficult.
Eric Kaczor, marketing manager, factory automation,
Siemens Industry, www.usa.siemens.com
Makes It Easier
One of the main advantages of IEC 61131-3 is portability of experience from one manufacturer's platform to another. Though actual code may not be portable, the experience is. If a programmer, machine builder or end customer used IEC 61131-3 programming tools with one PLC or control system and then subsequently has to deal with a new PLC or control system that also supports IEC 61131-3, there will be similarities and familiarity with the programming environment. The major benefit of this is obviously the time saved by the shortened learning curve. This is particularly significant for OEMs, machine builders and big system integrators, who might be using different PLC platforms on each job, depending on their customers' standards.
Ben Orchard, application engineer,
Opto 22 (www.opto22.com)
Unique Code Required Anyway
The idea of IEC 61131-3 code portability is not about porting entire projects between vendors. The strengths of IEC 61131-3 are in the commonality of the look and feel of the programming environment across different software offerings and the portability of smaller pieces of code called function blocks.
Beckhoff encourages customers to develop their own function blocks specific to their machine or process. Take, for example, a function block that handles the opening and closing of a valve. This block can have all the functionality to initiate opening or closing and, if there is feedback, will check after a period of time whether the valve is open or closed. This block can be used multiple times on one machine, and then ported over to the next machine without restriction. This idea applies to countless standard machine functions that can be handled with function blocks across different platforms that are IEC 61131-3-compliant. Develop this code well once, and you can use it over and over. For IEC 61131-3 users, the days of completely rebuilding code from the ground up are history. It should go without saying that this can be a huge benefit in cost and engineering time reductions.
Bob Trask, PE, electrical engineer,
Beckhoff Automation, www.beckhoffautomation.com
Limited Help
Portability remains an elusive target for control users. IEC 61131 held the promise of portability and, in fact, delivers when using structured text or Instruction List for most development environments, with some being directly compatible. Graphics-based languages such as function block and Ladder Logic are not. PLCopen defined an XML transfer structure, which is supposed to allow for portable code. I suspect most vendors will be importers, but none will be exporters. It will work well for valve suppliers, who want to provide a function block for diagnostic monitoring.
Just to address the subject of IEC 61131 compliance: There is none since most are not certified. If your customers want access to the different languages, that's different. They might have a legitimate need for the software, which could be simple enough that their maintenance staff will already know how to use it. While it might not be brand new, I submit that a user familiar with Beckhoff or B&R software will not have an easy time using RSLogix5000 from Rockwell Automation.
While I was the North American managing director for PLCopen, I tried to define difference with respect to compliant and compatible. I wonder what your customer means when he says compliant. You can say any software is compliant, so who's going to argue?
Jeremy Pollard, columnist
www.ControlDesign.com
Leaders relevant to this article: