IEC Standard 61131: the benchmark for industrial controllers, Part 1

Omron Electronics Pty Ltd
By Harry Mulder, Engineering Manager, Omron Electronics
Wednesday, 13 June, 2012

There can be little doubting the profound effect the IEC 61131 suite of standards has had on industrial controller product offerings over the last 25 years. Virtually all PLC vendors have adopted if not sections of the standard, then at least some concepts or its general philosophy. In fact, many vendors of other industrial control devices, such as IPCs (industrial PCs) and embedded controllers, have also taken note. Here’s why.

Few would argue the almost universal acceptance industrial controllers have gained since their introduction in the late 1970s. Their appeal derives from their high reliability and years of trouble-free service. Continued market penetration through the decades has seen them used in a wide variety of industries, such as manufacturing, food and beverage, power generation, water treatment and a host of others. They now control everything from entire water treatment plants or factories, individual machine cells and right down to very small devices that were once the domain of dedicated controllers.

Beginnings

Since their inception, vendors have taken widely divergent approaches in the design of industrial controllers, particularly in the area of programming. A range of different programming techniques had been developed, some using high-level languages like BASIC, C, Fortran; others using graphical techniques. All were propriety and no standard existed.

One language called ‘ladder logic’ gained particularly widespread acceptance because its graphical notation made it intuitive and easy to learn. It was also a straightforward transition for electricians, who were already well versed in electrical diagrams for hard-wired circuits.

While ladder diagrams are still used today, this methodology has a number of drawbacks:

Weak facilities for software structure
Low levels of software re-use
Poor data structure
Limited support for sequencing
Limited execution control
Cumbersome arithmetic operations

Moreover, each vendor’s implementation, while appearing similar, used its own unique dialect containing significant variances, often in subtle details. Also, as a number of limitations of ladder programming became evident, and as each vendor sought to address them, ever-widening variations of implementation resulted.

These differences led to considerable human resource costs, such as training. They also created enormous confusion, with potentially disastrous results. The problem was exacerbated by the users coming from differing backgrounds, such as technicians, maintenance personnel, system designers and programmers. These factors highlighted the need for a standard which, if implemented properly, would ensure the future of the industrial control industry and widen their application base.

A new approach

Like so many industries, a degree of maturity is reached whereby certain techniques or approaches start to emerge and are seen as being superior or otherwise desirable. They become the ‘standard’, be it de facto or official. The PLC market reached such a point in the early 1990s.

Fortunately, the need for a new standard was recognised and the IEC established the first working group in 1979. Others followed, along with various specialist task forces, and after much deliberation most of the 1131 standard suite was released in the early 1990s. Its name was later changed to 61131. Table 1 shows the complete suite of the IEC 61131 standard. An updated edition of part 3 was released in 2003, which included amendments and a corrigendum.

Part	Title	Contents
IEC 61131-1	General information	Definition of basic terminology and concepts
IEC 61131-2	Equipment requirements and tests	Electronic and mechanical construction and verification tests
IEC 61131-3	Programming languages	Software structure, languages and program execution
IEC 61131-4	User guidelines	Guidance on selection, installation and maintenance of controllers
IEC 61131-5	Message service specification	Software facilities to communicate with other devices using communications
IEC 61131-6	(Reserved for future use)
IEC 61131-7	Fuzzy logic and control programming	Extension of Part 3, to include Fuzzy Control Language (FCL) elements
IEC 61131-8	Application guidelines	Guidelines for the application and implementation of programming languages

Table 1: The IEC 61131 standard suite. While Part 3 (pertaining to programming) is the best known, the other sections define other aspects of industrial controllers.

In 1992, the PLCOpen trade association was formed by a number of interested parties keen to see the advancement of the IEC standard, particularly in the area of product compliance. PLCOpen is a not-for-profit, vendor-independent organisation, trying to raise awareness of standards so that the efficiency of industrial systems is increased and productivity boosted. As a standard is only as good as its number of users and how closely they adhere to it, PLCOpen’s TC3 (Technical Committee 3) provides certification facilities where vendors can have their products evaluated by an independent body and certification published. While 61131 - particularly Part 3 - remains at the core of what they do, PLCOpen has since branched out into other complementary standards.

The aims of IEC 61131-3

The main objective of IEC 61131-3 is to widen the understanding of PLC programming for all who may come in contact with it. In doing so, many of the issues mentioned previously would be resolved. Moreover, once programs are better understood, overall software quality tends to improve. The standard defines improved software as having enhanced capability, better availability, greater usability and superior adaptability.

What IEC 61131-3 offers

The IEC standard is best known for formally defining five of the most commonly used programming languages; two textual ones: Structured Text and Instruction List and three graphical offerings: Ladder Diagram, Sequential Function Chart and Function Block Diagram. The main reason for having five languages, each with differing strengths and weaknesses, is to present choices to the programmer. This allows them to select the most appropriate language(s) for the programming task at hand and to ultimately improve the final program.

In practice, though, nearly all programmers use a series of interwoven POUs (program organisation units - such as functions, function blocks) written in a combination of Ladder Diagram and Structured Text. The functionality of ladder programs has expanded to allow the inclusion of snippets of Structured Text and the interconnection of multiple functions and function blocks within a single rung, effectively amalgamating all three languages. SFC is very occasionally used for very large projects requiring extensive sequence control.

However, the standard goes much deeper and enables features that have been available in higher level computer programming environments for many years. In doing so, it can require a change of mindset in programmers previously used to exclusively programming in Ladder Diagram. IEC 61131-3 establishes numerous programming structures and coding practices that ensure increased quality, time savings and ultimately costs. Some of the new practices are:

Clarification of a software model: This provides both definitions of terminology in hardware (such as configuration, resources, program, tasks and many more) and establishes hierarchy, with the ability for upper layers to abstract (hide away) details from the previous level.
Modularisation: The ability to break down an entire program into functional elements called POUs. Well-structured programming code requires that divisions be able to be made with great flexibility. It must be possible to employ either a top down or bottom up design philosophy. The re-use of code should be encouraged to improve software quality and speed up development.
The formal definition of data types and the enforcement of strict adherence to them: This overcomes a common source of hard-to-find program errors and requires support from the program compiler. The IEC standard also requires support for user-defined data types, such as structures, and multidimensional arrays.
The ability to control execution, by assigning the order and priority of execution to certain tasks or PDOs: This allows certain sections of code, such as time-critical functions, to be run more often or at set intervals. The timing needs to not only be settable but guaranteed. In order for this to be implemented properly, the underlying hardware needs to support true multitasking, not just the operating system.

Function blocks and functions

But perhaps the most powerful precept introduced by the IEC standard is support for function blocks (FBs). FBs can be likened to a ready-made, off-the-shelf component that can be dropped into a program much like an IC in electronic hardware design. FBs encapsulate both data and algorithm into a single self-contained entity that abstracts details from users. When implemented properly, FBs become the basic building blocks of a program; and when they can be saved as individual files, program re-use is encouraged, not just within a single program but also between programs. Many standard FBs are specified as a minimum requirement by 61131-3. They should be callable from both ladder and Structured Text programs.

Functions are similar to FBs except they cannot retain data between calls, hence they do not have instance names. Because of this, they always return the same result for a given data set. Functions are generally simpler internally and are typically used for operations such as arithmetic and trigonometric functions.

Further improvements

A number of indirect consequences have arisen from each vendor’s implementation of the IEC 61131-3 software standard. Although not strictly part of the standard, numerous features have been added as vendors have had to update their product offering for their hardware to comply with the standard.

One is the use of virtual addressing space, where variables, of any data type, can be assigned freely and referenced only by their symbol name (or tag). Attributes like memory retention, constancy and initial values can be enabled in the declaration. Unlike traditional PLC programming, where hardware addressing was always used, hardware addresses are abstract and programmers are usually unaware of the internal memory map and where the variable physically resides. Symbols are then stored in a database within the controller and can be accessed by external devices, like HMIs. IEC does, however, require the ability for an AT attribute to be set, in which case actual addresses can be specified.

Another is the improvement of programming environments for controllers. The need to comply has led vendors to update their program development software. In doing so, the latest developments in the runtime environment of the computer can be utilised (see Figure 1). More advanced programming systems also offer integrated simulation whereby a program can be tested not only off-site (saving any potential damage to equipment) but also without controller hardware.

Figure 1: Microsoft’s Windows Presentation Foundation, show here in Omron’s Sysmac Studio, is an example of the user interface applications available.

What IEC 61131-3 is not

Two aspects that may seem logical consequences of the standard are: interlanguage portability (the ability to convert or transpose a program written in one language to another language) and intersystem portability (porting a program written for one vendor’s compliant hardware into another vendor’s compliant hardware). Although these features may seem desirable, neither is easy to implement, nor were they ever fundamental goals of the standard.

In summary

The fact that the IEC 61131 standard is in active use today, some 20 years after its inception, and that most vendors have based their designs around it, is testament to its usefulness and effectiveness. It is clear the IEC’s original goals for 61131-3 of making programs better understood has improved software quality and thereby increased programming efficiency. This has all been to the benefit of users, who have in turn endorsed the standard.

The activities of the PLCOpen organisation, by not only promoting standards, but by also continuing to seek enhancement to existing and expansions of new standards, should ensure IEC 61131 will remain the benchmark for new industrial controller offerings for most vendors for many years to come.

In Part 2

Industrial controllers, particularly PLCs, have come a long way since the early 1990s, as more and more demands have been placed on them. The IEC standard has been expanded accordingly and we’ll have a look at how the integration of motion control functions has affected the standard and some of the challenges this has presented to hardware vendors.