Structuring with IEC 61131-3: 7 steps to success

The IEC 61131-3 standard includes powerful structuring tools and can help provide users an excellent way to break a control system down into manageable units for greater overall effectiveness.

By Eelco van der Wal July 6, 2021

Learning Objectives

The IEC 61131-3 programming standard provides a powerful tool for multiple levels of users and usage./li>
Sequential function charts (SFCs) and user-derived function blocks are essential parts.
Identifying, defining and analyzing all the different layers provides structure and clarity to the process.

As needed for a modern software development environment, the IEC 61131-3 programmable controllers, part 3 programming languages standard from the International Electrotechnical Commission (IEC) includes powerful structuring tools. The essential parts for this are sequential function charts (SFCs) and user-derived function blocks. Both provide an excellent way to decompose a control system into manageable units.

These units are easier to use and understand by different people with different backgrounds. It provides the missing links among system engineers, software developers, and installation and maintenance people. In addition, it provides a representation and communication tool for these different groups.

In this way, multi-disciplinary teams can cooperate in larger application programs, generating more easily understandable and reusable code, and providing a separation among different levels of programmers, installation and maintenance people, and users.

Also, the section of error detection and error processing can be dealt with in an early stage of the software development. The alternative, to create these sections during installation – or even during operation – is too expensive for the supplier (in support) as well as the user (in downtime).

Providing structure for control system programming

The advantages of structuring control system code are broad and include:

A better overview of the system, not only important for the original programmers, but also for the installation and maintenance personnel;
A better basis for internal communication within the multi-disciplinary development team;
A clear separation among different responsibilities;
A better focus on the real problem and possible solutions;
A basis for reusable software.

Structuring is done via dividing the problem into smaller parts, which can be sub-divided. There are limits to this: it is not practical to continue to an endless fine granularity, since the effort of the integration of these parts is increased.

The use of modular blocks is associated with five principles:

The programming language should support the modular units.
The units should be composed in such a way and in such number that they have few interfaces and few interactions.
The interfaces should be small, needing little data exchange.
The module interactions require explicit definition, to increase their re-usability.
The modules should provide data encapsulation: the application data is partitioned, and each partition should only be accessible by a proper set of functions, which hide it from undesired uses.

Seven steps to success for structuring programming software

The following 7 steps provide a road to success for the structuring of control system programming software:

Identification of the external interfaces to the control system.
Definition of the main signals exchanged between the control system and the rest of the plant.
Definition of all operator interactions, overrides and supervisory data.
Analysis of the control problem broken down from the top level into the logical partitions.
Definition of the required function blocks.
Definition of scan cycle time requirements for the different parts of the application.
Configuration of the system by defining resources, linking programs with physical inputs and outputs and assigning programs and function blocks to tasks.

IEC 61131-3 provides the right environment to support these steps. Consider this example of a fermentation process and its control system. Shown below is a drawing of the whole system (Figure 1). It should be looked at it as an operational system.

The fermentation process consists of a large vessel, which can be filled (feed valve) with the liquid, can be heated with the heater band (cooling via convection), can be stirred via the motor, and where acid and alkali fluid can be added into the vessel. After the process time we use the harvest valve to get to the result.

To create a control program for this example, go through all of the seven steps as defined above:

1. Identification of the external interfaces to the control system

Feedback from the temperature sensor
Feedback from the pH sensor
Feedback from the valve positions
Feedback from the motor (speed)
Output to the valves
Output to the motor
Output to the heater band.

2. Definition of the main signals exchanged between the control system and the rest of the plant.

In this example, there is no coupling to the rest of the plant, which is not very realistic. For instance, one could need a link to the vessel from which the liquids are pored, and a link to a system for harvesting, like a transportation system for vessels or bottles. There also could be couplings to an enterprise resource planning (ERP) system.

3. Definition of all operator interactions, overrides and supervisory data.

For the operator we define a ‘Start’, ‘Stop’ and ‘Duration’ buttons as input to the system.

4. Analysis of the control problem broken down from the top level into the logical partitions

There are five main functions to this process:

Main sequence, for example, top-level process steps – filling, heating, agitating, fermenting, harvesting, cleaning;
Valve control, such as operating valves used to fill and empty the vessel;
Temperature control for monitoring the temperature of the vessel; modulating the heater;
Agitator control for the agitator motor activated as demanded by the main process sequence;
pH control for monitoring the acidity of the fermentation contents, adding acidic or alkali reagents as required.

5. Definition of the required function blocks

Using the definitions above and adding the (high level) function blocks to it, we can represent these in the programming language the function block diagram. The overview of the fermentation control program could look like this (Figure 2).

The function block main sequence is linked to the operator inputs. It is supported by the other blocks for control, which are linked to the relevant inputs and outputs. These additional blocks could be blocks that are delivered by your suppliers, like the temperature control block, using a PID control loop. Alternatively, these blocks can be created by yourself. For instance, this is the case with the bloc main sequence. Looking closer to this block, we could structure its sequence with SFC as follows (Figure 3):

SFC provides a means for partitioning a programmable controller program into a set of steps and transitions interconnected by directed links. Associated with each step is a set of actions, and with each transition is associated a transition condition.

We start at the top with the Initialization: since we do not know the status of the system when we first switch it on, we must check the position of the valves, etc. Then we start filling till the right level has been reached. The next phase is the heating till the fermentation process starts. When it does, we move to the next phase: the actual fermentation process control part. After completion, we harvest, and after that clean, and we are ready to restart at the top.

This decomposition gives everybody involved a clear overview which sequences are involved, and further modularization into the function blocks which can be programmed in any of the four languages.

The programming work now to be done is at the level of the action blocks. Those could be divided between different people, with different backgrounds. For this, IEC defined 2 graphical and 2 textual programming languages, which are Instruction List, Structured Text, Ladder Diagram and Function Block Diagram, to best suit the needs and the problem at hand. Also, further decomposition of the action blocks can be done via SFC, if needed.

6. Definition of scan cycle time requirements for the different parts of the application

In this example we have in principle only one cycle, which we can run in a continuous mode. Alternatively, we could have it run on a time basis, for instance every 20 msec. The remaining time can be used for additional sequences, for instance checking or controlling the transportation / bottling system during harvesting or checking all kind of boundary and/or error conditions.

7. Configuration of the system by defining resources, linking programs with physical inputs and outputs, and assigning programs and function blocks to tasks

This phase is dedicated to the system involved. It includes the physical mapping of the symbols to I/O addresses. By using symbolic representation, one creates a far better hardware independence. This is especially valid for the creation of the function blocks, which should be hardware independent. By identifying clearly where the physical mapping is done, rewiring in the filed is a lot easier to accomplish. For instance, exchanging the wiring of two digital inputs means that within the physical mapping one has to change only two lines, the rest of the program is still valid and need no changes.

The resources here are mapped, meaning which part runs on which processor in the system. IEC 61131-3 supports multiprocessing environments, although most of the actual systems still use one processor for the programs.

The user also has to map the tasks to the scan cycles and events, as defined in step 6. In this way, one can have multiple programs in one system, for instance the fermentation process as described here, supported by overall checks and control of the supporting environments, like bottling or the levels in the supplying chain upfront.

The IEC 61131-3 programming standard provides a powerful tool for multiple levels of users and usage. Using an SFC at a high level gives an excellent overview on the system under development, resulting in higher readability and transparency. It provides guidance to the modularization of the control problem at hand. In addition, it provides a basis for separating the different development tasks and focuses attention towards creating re-usable software code at the level of the actual coding.

Eelco van der Wal, managing director, PLCopen, a CFE Media content partner. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.