Improve PLC and DCS programming with a mental model
Engineering and IT Insight: Develop a mental model to address real-time programming, which differs from web development or classical programming. Base real-time programmable logic controller (PLC) and distributed control system (DCS) programs on models of functional programming, encapsulation, hierarchy decomposition, and petri nets. Do not accept unstructured and poorly designed PLC and DCS code.
Use the following advice to improve programmable logic controller (PLC) and distributed control system (DCS) programming. Real-time control system programming is really programming, but it uses languages and models that are not normally taught in programming classes. The real-time languages and models also do not have much in common with modern programming languages such as C#, Java, PHP, Perl, and Python. When writing control programs, engineers and programmers usually have to relearn how to approach problems using either Function Block Diagram programming when working on DCSs or the IEC 61131-3 languages when working on PLCs.
4 languages, 1 structuring element
The latest version of IEC 61131-3, Edition 3.0 dated 2013-02, defines four control languages and one structuring element. The control languages are Ladder Diagrams, Function Blocks, Instruction List, and Structured Text. The structuring elements are Sequential Function Charts. Instruction List (IL) and Structured Text (ST) should be familiar to programmers, but Function Block Diagram (FBD), Function Blocks (FB), Ladder Diagrams (LD), and Sequential Function Charts (SFC) are significantly different from modern programming languages.
The methods that are normally used in business and consumer software design and development do not easily carry over into the real-time programming environment of PLCs and DCSs. Classical programs, which have a definite starting point and ending point and which process files or databases, are not suitable models for real-time reactive programming. Real-time programs usually run continuously and do not sequentially process files or databases tables. Modern event-based programming models, which are used in web development, database stored procedures, and smartphone/tablet development, are also not suitable models for real-time control. Real-time reactive control is not normally based on events but on repetitive scans of inputs and the generation of outputs.
However, do not despair; there are programming models that can be applied to real-time PLC and DCS programming. These models include hierarchical decomposition of problems, petri nets (place/transition network), information hiding in encapsulated elements, and functional programming methods. None of these models are new; petri nets date from before the invention of computers and originally were developed to describe chemical processes. Hierarchical decomposition is a standard engineering model for address complex problems.
Functional programming is the programming model used in the LISP, AWK, and XSLT languages. The most common use today is in XSLT (Extensible Stylesheet Language Transformations), where it is used to create web pages and to convert data into a printable or displayable format. The key aspect of functional languages is that they are organized by rules and not by procedural control. A functional program is made up of a set of rules and associated code.
The rules are evaluated for each input; typically, this is a Boolean or regular expression that evaluates to TRUE or FALSE. In the case of AWK, the rules are evaluated for each line of text in a file. For XSLT the rules are evaluated for each element in an XML document. When a rule evaluates TRUE, the associated code is executed. Once a rule is executed, then the rest of the rules are skipped and the program repeats for the next input.
Ladder Diagram example
Ladder Diagrams can be viewed as a form of functional programming. LDs were originally developed to represent relays and switches in a vertical column format. Each network of connected relays and switches resembled a rung in a ladder, and the term "rung" is used to describe each network. If you consider a rung as the rule set in a functional program, then LD programming can be viewed as a form of functional programming with one special difference: Every rule is evaluated each time unless there is a skip or jump to bypass the following rules. If you view a LD program as a collection of rules and associated code, then you can apply the functional programming mental model to your problem.
Consider each ladder rung as specifying an evaluation rule. If it evaluates TRUE, then execute the following code; otherwise, jump to the next rule rung. For example, a rule rung for valve V1 would implement the logic (automatic_mode=1) and (available_status=1) and (open_command=1). If evaluated to TRUE, then the following logic would implement the code to open the valve. In LD this could appear as the figure shows.
Function Block programming
Within a rule's associated code, the logic that is needed to execute state-based control can be added without any concern about side effects from other parts of the program. Function Block (FD) programming is the same as LD programming, just laid out in a horizontal format, with a method to describe the sequence of network/rung execution. A Function Block Diagram (FBD) can also be viewed as a functional model with mathematical calculations as the associated code. In FBD programming the rule set usually handles mode control (automatic or manual), error checking, or alternate control strategies.
The next two programming models that can be applied to control programming are hierarchical decomposition and information hiding using encapsulated elements. These concepts are the underlying model for Object Oriented Programming (OOP). An OOP model uses the decomposition of big problems into smaller pieces with each piece encapsulating, or hiding, its local information and algorithms. An object exposes only commands and data and hides how it performs its main function. An object may also contain other smaller objects that perform subsets of the main task. The problem is decomposed into a hierarchy of encapsulated objects.
Control programs can follow this model because the model is language independent. The smallest elements are usually called control modules because they encapsulate basic control and provide access to the system's I/O. They typically control one physical device, such as a motor, valve, or pump, or control a collection of devices that must operate together. Each control module implements a relatively simple control algorithm, and the trigger to control execution of the algorithm is a functional program rule as described above. The control module's algorithm can then be programmed in LD, FB, IL, or ST. IL is a form of assembly language, similar to those commonly taught in programming classes. ST is a high-level language, similar to Pascal or C. No new mental models for software design are needed for IL or ST programming.
Higher level objects can then command the control module objects using procedures, which are sequential or parallel sets of commands to control modules. While procedures are difficult to program using LD or FB programming, they are easy to program using SFCs. SFCs are a form of petri nets, and petri nets are a graphical notation for stepwise processes. They provide the capability for choice, iteration, and concurrent execution. Think of SFCs as executable flowcharts that allow for parallel branches. Each step in an SFC contains a set of commands that can start other SFCs (decomposition), or send commands to control modules (encapsulation). The higher level objects typically represent machines or units, which are collections of devices (control modules) and the procedures used to control them.
Avoid poorly designed programs
Developing the mental model required to address real-time programming is difficult if your only experience has been web development or classical programming. However, you can base your real-time PLC and DCS programs on the well-known and understood models of functional programming, encapsulation, hierarchy decomposition, and petri nets.
As you bring new engineers and programmers into your environment, encourage them to approach their control problems using these well-developed structures. There is no reason to accept unstructured and poorly designed PLC and DCS code simply because the programming languages are different from modern programming languages.
- Dennis Brandl is president of BR&L Consulting in Cary, N.C. His firm focuses on manufacturing IT. Edited by Mark T. Hoske, content manager, Control Engineering, email@example.com.