Structuring Program Development with IEC 61131-3
Eelco van der Wal, Managing Director PLCopen (email@example.com)
General trendsThe role of software has changed. It plays an ever increasing factor in the quality of the product. Software errors can have dramatic effects, even ruining the overall investment of money and time sense. The requirements of industrial control have grown, extending the software code by factors from 100 lines of code to 10,000 now. This is not only prone to errors but makes 100% testing impossible. Creating this software is not a one-man-job anymore: the conventional programmer is now part of a multidisciplinary team.
With the ever increasing requirements, installation, maintenance, upgrades and improvements have become an essential part of the life cycle of the controls, and software plays the crucial role in it.
IntroductionModern programming methods provide tools to improve the intrinsic quality of software, i.e. its correctness in the sense of reliability, robustness, integrity, persistence, and safety. The international standard IEC 61131-3 provides such a tool, dealing with the programming, installation and maintenance phases of software development projects in industrial control.
Basically, IEC 61131-3 consists of two parts, i.e. Common Elements and Programming Languages.
The structuring tools within IEC 61131-3 are focused on the common elements, although clearly links to the programming languages are needed.
This article shows that by using IEC 61131-3 in a consistent way, one generates software code that is understandable, reusable, verifiable and maintainable.
The essence of structuringThe above mentioned trends require a different approach. An approach through structuring provides advantages like:
Overall, structuring is done via dividing the problem into smaller parts, which again can be sub-divided. There are limits to this: it is not practical to continue to an endless fine granularity, since the effort is then moved towards the integration of these parts.
Within IEC 61131-3 there are two co-operating ways, which for clarity sake we name:
Modularity principlesWithin the modern software development methods there are five principles associated with modularity. These are:
These will be explained in more detail below. Functions We all know functions like add, square root, sin, cos, Greater Than, etc. IEC has a enormous set of these defined. In addition, you also can create your own functions like this simple_function:
FUNCTION SIMPLE_FUN : REAL
Once defined, you can use it over and over again, within the same program, other programs or even other projects.
Function Blocks, FBsThe same is valid for Function Blocks: there are standard defined Functions Blocks and FB's added by the supplier. You can also create your own Function Blocks and add them to your own Function Block Library. All these Function Blocks are highly re-usable within the same program, new programs or even projects. You can use them with any of the IEC programming languages, giving you a clear separation between different levels of programmers, or maintenance people.
This re-usability increases your efficiency, and reduces the number of errors.
Let's look at an example:
The Function Block above (on the left side) is represented here in the programming language Function Block Diagram. The Function Block has the name Hysterisis. It has three inputs on the left, named XIN1, XIN2 and EPS, all of datatype REAL. It has one output, on the right, called Q, of type BOOL.
Internally, the FB contains body code, as shown on the right side. In this example, the body code is written in the Structured Text, ST, language. The first part deals with the data structure, the second part with the algorithm, which uses the inputs, does some calculation, and sets the outputs. The algorithm is hidden to the user of the Function Block, who sees only the functionality of the block as shown on the left. This creates a different level of access, showing the encapsulation as referred to in point 5 of the modularity principles.
Names used within a function block are local to that FB. No matter which name is used in a FB for local data, there will be no conflict if the same name is used in a different manner in another function block or elsewhere in the program.
Programs : hierarchical networkWith these Functions and Function Blocks , you can look at a program as a network of these basic building blocks. In this way complex programs can be broken down into function blocks, which can again be broken down into smaller function blocks. This helps you increase your efficiency .
Decomposition: how does it look in IEC 61131-3 ?As decomposition tool, IEC 61131-3 provides Sequential Function Charts (SFC). SFC describes graphically the sequential behavior of a control program. In this way it structures the internal organization of a program by decomposing the control problem into manageable parts, while maintaining the overview. This makes it very suitable for diagnostic purposes.
SFC consist of Steps, linked with Action blocks and Transitions (see picture below).
Each step represents a particular state of the system. Steps are linked to Actions, performing a certain control function.
A transition is coupled to a condition, which, when true, causes the previous step to be de-activated and the next step to be activated.
Each action block or transition can be programmed in any of the IEC languages, Ladder Diagram, Function Block Diagram, Instruction List and Structured Text, and even including SFC itself for further decomposition.
SFC supports alternative sequences and parallel sequences, such as commonly required in batch applications. For instance, one sequence is used for the primary process, and a second for monitoring the overall operating constraints. And this occurs within the same overview and structure.
Structuring: 7 steps to successStructuring within IEC 61131-3 is presented here as the combination of Modularity and Decomposition. The following 7 steps provide a road to success for the structuring of software:
IEC 61131-3 helps you especially in the last steps 4 - 7, where the translation into software occurs.
An Example: Fermentation control system
An example tells more than 1000 words
, so let us look at a fermentation process and its control, as shown below.
|The software development process has changed|