Object-oriented design: How an update to a PLC programming standard will benefit automation software programmers

With the release of Edition 3 of the IEC 61131-3 PLC programming standard as defined by PLCopen, automation software programmers now have advanced object-oriented design capabilities at their disposal. This greatly expands the programmer’s options in terms of automation programming and future-forward concepts for advanced machine functionality that can be implemented as a result.

The powerful, modular Function Block POU (Program Organization Unit) type has been extended with new functionalities that expand the possibilities of software implementation. Programmers already designing in object-oriented environments have class and interface constructs that aid in design, reuse and maintenance of object-oriented programs. Now these constructs are available to the IEC programmer, as well.

New keywords in the standard that relate to object orientation are: “interface,” “implements,” “extends,” “property” and “method.” In this article, we will consider the Function Block (FB) as a simple class definition, which includes properties and methods.

The Function Block (IEC 61131-3 Edition 2)

The IEC 61131-3 standard relies heavily upon the FB POU type for modularity of design. An IEC FB is a smart user-defined type. It wraps the data required for a functional element together with its programmed logical sequencing in a reusable, “instantiable” package.

The FB is similar to a user-defined data structure: a data structure is defined when it is necessary to create a new data type, and a FB is defined when it is necessary to define data and logic for control of a new component, device or process.

A user-defined data structure collects data elements of various types together into an application, component or algorithmically significant type. The structure is a useful designer’s tool — it modularizes the software and syntactically imparts necessary information to other designers working on the software system. By reviewing the data type definitions for an application module, we begin to develop an understanding of the module’s functionality.  

The FB is an extension of a user-defined data structure. The data structure defines memory for holding actual values without any inherent access control, and contains no algorithm to evaluate and affect the data.

The FB incorporates access control over its defined data by clear specification using the IEC keywords: VAR_INPUT, VAR_OUTPUT and VAR. These key terms unambiguously determine access control of the FB’s variable memory by other programs in the control solution. Data declared as VAR_INPUT can be written from outside of the FB and not written inside the FB. Data declared as VAR_OUTPUT can be read by other programs in the control solution and written only by the FB. Data declared as VAR is internal and can only be written by the FB, and as a general programming practice should not be read from outside of the defining FB.

The VAR_INPUT data is used to pass necessary status information and command values so that the user-created FB can properly apply its internal algorithms. The VAR_OUTPUT data is used to provide the necessary feedback and status information so that callers of the FB can determine if code has been executed successfully.

The FB will also contain PLC code to respond to input conditions and thereby modify the internal (VAR) and status (VAR_OUTPUT) data. The FB expresses more meaning to the designer, implementer and maintainer of the PLC system than is possible with a data structure definition alone. The input and output data specifies the formal interface of the FB, and provides us with more information regarding the preconditions, commands and status of functional elements of the control context. Reviewing and understanding the formal interface is required to effectively use FB; however, detailed analysis of the logic inside the block is not required.

The FB element is a powerful programmer’s tool because, not only can it be reused infinitely within a solution, but single FBs and collections of FBs can be exported or packaged as libraries and shared between programmers and solutions. As a modular element that encapsulates code and data, the FB does fulfill some of the behaviours central to objects in object-oriented programming paradigms.

The Function Block as a Class (IEC 61131-3 Edition 3)

While the FB POU type does encapsulate the data and logic of an “object,” the Edition 2 IEC FB has no formal specification for data attributes and method behaviours as can be found in modern object-oriented languages.

For instance, the formal interface of the FB in Figure 1 consists only of input (VAR_INPUT) and output (VAR_OUTPUT) data. All of the input data is lumped together, even though the cylinder FB has two data values (simulation flag and timeout value) and six separate functional uses — two extension commands, two retract commands, one centre command and a timed opening command.

FIGURE 1

From a usage point of view, the programmer must take care to use the input data correctly, and it is not always clear which input value set(s) should be used together. In many cases, the more complex control components are, the more logical actions of the FB become unclear. This is particularly true if the logical behaviours and data sets of a component are many or varied.

In complex solutions, it is easy for the FB interface to become very large, with long lists of formal inputs and outputs. The Edition 2 FB syntax, in some situations, does not assist a programmer learning a new software system. Since there is no syntax to indicate which formal inputs serve as commands and which as parameters, and no formal syntax to specify logical behaviour, the code is not self-documenting.

Edition 3 of the IEC standard addresses this concern. Although a FB POU type is implemented in the familiar way, new syntax is available to clearly specify the data (property) and behaviours (method) of a class, and furthermore the data associated with a given method can be unambiguously specified.

Properties – Data members of a class

A property is a data item that is declared as a member of a class. This could be the move timeout value for a cylinder or a motor, a set point or status information. Properties can be defined so that they are only internally accessible to a class object, readable from outside of the object, writeable from outside of the object and, of course, readable and writeable from outside of the object.

Each property is equipped with accessors immediately as a function of the IEC object model. This is an important part of the data-hiding concept in class-based programming. The object always controls the data. These are called the “Get” and “Set” accessors. In modern integrated development environments, the Get and Set templates are created automatically, and the programmer simply fills in a small amount of code to handle the data required in the application.

When data is written from outside the object, the Set operation is automatically called and the data can be verified for correctness before it is copied into the internal variables of the object. Likewise, the Get operation is called when outside code attempts to read a value — again, the data can be manipulated before being passed to the calling code. For instance, temperatures can be requested in Celsius or Fahrenheit or speeds in mm/s or m/s, etc., even if the class always internally uses degrees Celsius or inch per minute.

Methods – Logical behaviours of a class

Methods are the object-oriented construct for implementing the logical behaviour that instantiated objects will provide. In previous editions of the IEC standard, this clear construct did not exist. Only by analysing the formal interface of a FB and using the appropriate input and output data could an object’s behaviour be triggered and monitored.

A method in the IEC 3rd Edition standard is very similar to what we know traditionally as an IEC function. A method has a result type, as well as parameters, and can have its own local variables. In keeping with its behaviour as a function, a method does not maintain an internal variable state, and its input, output and internal variables are set to default values with each PLC scan. However, the method has access to all class member variables (those declared within the FB’s VAR, VAR_INPUT and VAR_OUTPUT data areas), which are retentive between code scans.

Methods are called in code by using the dot “.” operator after the FB instance name in structured text, or after the FB name in the graphical languages. A method call in structured text will always end with parentheses, even when no formal inputs are required. Formal inputs to the method are specified within the parentheses, such as in the following example: ObjectInstanceName.MethodName(input1:=value, input2:= value).

The formal inputs will appear on the left side of the box in a graphical language. Note that in all languages, the formal inputs must be specified. Representing the data element’s name is not optional; however, an actual value need not be supplied if the programmer intends to use the initialized value of the parameter.

For programmers already working in object-oriented languages, the IEC usage of methods and properties will be familiar to implement. For programmers not accustomed to object-based design, a useful exercise is to rethink the most complex FB you have used to date; determine the properties and methods a class version will require; focus on how the usage of the new property and method keywords can make the functional aspects of the class clearer to other programmers; develop some code that implements this as an object and uses the properties and methods; and note how this simplifies working the formal interfaces. If you bring these new features into your comfort zone, object-oriented programming will become a very useful tool in your program development.

The recent extensions to the FB POU type as a class implementation incorporate many new features, and here we’ve considered the use and syntax of properties and methods.

We’ve seen that the interface and use of a class is clearer in terms of intent when compared to the Edition 2 Function Block: behaviours of an object are handled by named methods; methods clarify the functional uses of an object; careful method design focuses program implementation; data elements are defined as properties; and properties have built-in functionality that improve data consistency.

Application code is simplified using these features, which positively impacts design and maintenance. Furthermore, together with additional features, such as interfaces and inheritance, code developed using object-oriented practices becomes increasingly maintainable and future-proof. Programmers who learn about and begin utilizing these concepts in automation programming today will gain a competitive edge over those that rely exclusively on older, more traditional programming languages.

Andy Burleigh is an applications specialist with Beckhoff Canada.

This article originally appeared in the November/December 2013 issue of Manufacturing AUTOMATION.