The International Electrotechnical Commission's (www.IEC.ch) 61131-3 international standard "Programmable Controllers—Part 3: Programming Languages" was published in 1993 after 15 years in development and first used for PC-based control programming in the 1990s. Typically programmable logic controllers (PLCs) had their own vendor-developed programming platforms, but in the past decade, major PLC vendors from Europe and North America initiated and supported the new standard with their new programming platforms.
The intent of IEC 61131-3 is to normalize PLC and control systems' programming by standardizing functionality such as program entry, instruction visualization, data types and syntax. The general requirements section includes models for software, communication—external as well as internal instruction and variable parameter passing—and programming. The model functions are as follows:
- The software model introduces the following configuration concepts: resources such as CPUs; tasks such as executable application software; named variables used for storage; and communication paths (Figure 1). An IEC-based hardware "client" could run multiple tasks in one configuration or have multiple configurations.
- The communication model specifies how data is passed to different tasks or configurations or within the same task. Global variables are introduced.
- The programming model is tied closely with the concept of common elements, which enable the use of common data types, variable declaration and data formats such as dates and times. Program organizational units (POUs) also are common elements.
Figure 1: A conventional PLC's software (on the right, in red) consists of one resource, running one task and controlling one program. However, a controller using IEC 61131-3 (on the left) can go beyond PLCs by providing a multi-tasking, real-time environment that can be used in a broader range of applications without requiring users to learn added programming languages. If vendors allow it, this multi-tasking means a function block-controlled task could run along with a ladder logic task with data sharing and global variables. At the highest level, the entire software required to solve a particular control problem is called a Configuration. Within it, one or more resources can be defined. A resource is like a CPU in the system, and it includes one or more tasks. These control the execution of different parts of programs, called functions or function blocks, which are the basic building blocks of data structures and algorithms. All of these can exchange their information via the global or direct variables, even to the outside world via communication functions such as OPC.
These POUs were developed to reduce the often-implied meanings of instructions and blocks. There are three types of POUs defined in the standard. The program POU is the program; no news there. The function-block POU is a program block with inputs and outputs used for tasks such as timers and counters. The function POU lets various program elements extend the instruction set of the configuration. The intent of these POUs is to reduce the programmatic differences between suppliers, so a timer is a timer, regardless of who provides it.
In addition, the standard defines data types, such as Boolean and integer. It also defines the use and format of derived data types and functions, which must conform to the previously mentioned standard data types.
Meanwhile, the programming model extends a PLC-type programming environment with three languages and two graphical representation languages. Ladder logic is most used in discrete applications and is the most widely coded language in automation today. It is mainly used and supported by the North American PLC vendors.
Instruction List, which is a rudimentary, assembler-type language has been a European programming staple for years. The third language is Statement List, which is similar to Pascal.
As a result, the graphical languages are Sequential Function Chart and Function Block. These are graphical representations of processes and have underlying code written in one of the three languages or in an alternate language, such as C++.
Finally, the standard defines the abstraction between the IEC model and the PLC/control hardware by using device tags and not addresses. Similar to programming in a high-level language such as Visual Basic, it allows the programmer to define a memory point, not by address, but by using a descriptive name. The standard defines the characters you can use in the description. The outside world is tied into the model based on the hardware used.
The desired effect of the standard is to reduce the user's learning curve between vendors, and with work beginning as early as 1978, it was developed to meet that need.
What IEC 61131-3 Is Not
The published IEC 61131 standard encourages extensibility, meaning any company that writes an IEC 61131-based product can add things to its "standard" product as long as it tells the user what changes and additions have been made relative to the standard. However, IEC 61131 isn't a standard. It is a specification for vendors that want to develop a control software programming environment according to a set of guidelines.
PLCopen (www.plcopen.org), the global association supporting IEC 61131, says you can't have a standard without certification. However, no one and no company can claim that its ladder logic editor creates compliant code. There's no way to certify it. And yet, one of Rockwell Automation's web pages for RSLogix 5 makes claims about the "RSLogix family of IEC-1131-compliant ladder logic programming packages."
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.
- Structured Software—through use of configuration, resource and function blocks.
- Strong Data Typing—by using languages that restrict operations so they only apply to appropriate data types.
- Execution Control—through use of tasks.
- Complex Sequential Behavior—through sequential function charts.
- Software Encapsulation—through use of function blocks, structures and complex data types.
The standard allows for the creation of programs that are highly structured, yet flexible. It provides tools for creating programs with complex sequences and promotes the creation of reusable modules or function blocks.
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
Leaders relevant to this article: