IEC 61131-3 by the Numbers

By Jeremy Pollard

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.

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.

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.