IEC 61131-3 is the first real endeavor to standardize programming languages for industrial automation. With its worldwide support, it is independent of any single company.
The third part of the IEC 61131 family, it is a specification of the syntax and semantics of a unified suite of programming languages, including the overall software model and a structuring language.
Another elegant view can be seen by splitting the standard in two parts—common elements and programming languages.
Common elements—data typing
Within the common elements, the data types are defined. Data typing prevents errors in an early stage. It’s used to define the type of any parameter used. This avoids for instance dividing a date by an integer.
Common data types are Boolean, Integer, Real and Byte and Word, but also Date, Time_of_Day and String. Based on these, you can define your own personal data types, known as derived data types. In this way you can define an analog input channel as data type and reuse this over and over again.
Variables are only assigned to explicit hardware addresses, such as. inputs and outputs, in configurations, resources or programs. In this way a high level of hardware independence is created, supporting the reusability of the software.
The scope of the variables is normally limited to the unit in which they are declared—for example, local. This means their names can be reused in other parts without any conflict, eliminating another source of errors. If the variables should have global scope, they have to be declared as such. Parameters can be assigned an initial value at startup and cold restart, in order to have the right setting.
Common elements—configuration, resources and tasks
To understand these better, let’s look at the software model, as defined in the standard (Figure 1).
At the highest level, the entire system required to solve a particular control problem can be formulated as a configuration, including the arrangement of the hardware, memory addresses for I/O channels and system capabilities.
Within a configuration, you can define one or more resources. You can look at a resource as a processing facility that is able to execute IEC programs.
Also read: The Case for PackML
Within a resource, one or more tasks can be defined. Tasks control the execution of a set of programs and/or function blocks. These can either be executed periodically or upon the occurrence of a specified trigger, such as the change of a variable.
Programs are built from a number of different software elements written in any of the IEC-defined languages. Typically, a program consists of a network of functions, such as ADD, ABS, SQRT, SINus and COSinus, and function blocks, which are able to exchange data. Function and function blocks are the basic building blocks, containing a data structure and an algorithm.
Function blocks contain data, as well as the algorithm, so they can keep track of the past. They have a well-defined interface and hidden internals, such as an IC or black box. In this way they give a clear separation between different levels of programmers or maintenance people.
A temperature control loop, or PID, is an excellent example of a function block. Once defined, it can be used over and over again in the same program, different programs or even different projects. This makes them highly reusable.
Function blocks can be written in any of the IEC languages and, in most cases, even in C or C++. In this way they can be defined by the user.
A conventional PLC contains one resource, running one task, controlling one program, running in a closed loop. IEC 61131-3 adds much to this, making it open to the future—a future that already includes multi-processing and event-driven programs.
IEC 61131-3 is suitable for a broad range of applications, without having to learn additional programming languages.
Common elements—sequential function charts
A sequential function chart (SFC) describes graphically the sequential behavior of a control program. With this, it structures the internal organization of a program and helps to decompose a control problem into manageable parts, while maintaining the overview (Figure 2).