Function block diagrams
A picture is worth a thousand words is a familiar proverb that asserts that complex stories can be told with a single still image, or that an image may be more influential than a substantial amount of text. It also aptly characterizes the goals of visualization-based software in industrial control. A function block diagram (FBD) can replace thousands of lines from a textual program.
A picture is worth a thousand words is a familiar proverb that asserts that complex stories can be told with a single still image, or that an image may be more influential than a substantial amount of text. It also aptly characterizes the goals of visualization-based software in industrial control.
A function block diagram (FBD) can replace thousands of lines from a textual program. Graphical programming is an intuitive way of specifying system functionality by assembling and connecting function blocks. The first two parts of this series evaluated ladder diagrams and textual programming as choices for models of computation. Here, the strengths and weaknesses FBDs will be discussed and compared.
|Execution control of function blocks in an FBD network is implicit from the function block position in an FBD.|
FBDs were introduced by IEC 61131-3 to overcome the weaknesses associated with textual programming and ladder diagrams. An FBD network primarily comprises interconnected functions and function blocks to express system behavior. Function blocks were introduced to address the need to reuse common tasks such as proportional-integral-derivative (PID) control, counters, and timers at different parts of an application or in different projects. A function block is a packaged element of software that describes the behavior of data, a data structure and an external interface defined as a set of input and output parameters.
In many ways, function blocks can theoretically be compared with integrated circuits that are used in electronic equipment. A function block is depicted as a rectangular block with inputs entering from the left and outputs exiting on the right. See diagram of typical function block with inputs and outputs.
Key features of function blocks are data preservation between executions, encapsulation, and information hiding. Data preservation is enabled by making separate copies of function blocks in memory every time it is called. Encapsulation handles a collection of software elements as one entity, and information hiding restricts external data access and procedures within an encapsulated element. Because of encapsulation and information hiding, system designers do not run the risk of accidentally modifying code or overwriting internal data when copying code from a previous control solution.
Functions, function block diagrams
A function is a software element that, when executed with a particular set of input values, produces one primary result and does not have any internal storage. Functions are often confused with function blocks, which have internal storage and may have multiple outputs. Some examples of functions are trigonometric functions like sin() and cos(), arithmetic functions like add and multiply, and string handling functions. Function blocks include PID, counters, and timers.
An FBD is a program constructed by connecting multiple functions and function blocks resulting in one block that becomes the input for the next. Unlike textual programming, no variables are necessary to pass data from one subroutine to another because the wires connecting different blocks automatically encapsulate and transfer data.
An FBD can be used to express the behavior of function blocks, as well as programs. It also can be used to describe steps, actions, and transitions within sequential function charts (SFCs).
A function block is not evaluated unless all inputs that come from other elements are available. When a function block executes, it evaluates all its variables, including input and internal variables as well as output variables. During its execution, the algorithm creates new values for the output and internal variables. As discussed, functions and function blocks are the building blocks of FBDs. In FBDs, the signals are considered to flow from the outputs of functions or function blocks to the inputs of other functions or function blocks.
Outputs of function blocks are updated as a result of function block evaluations. Changes of signal states and values therefore naturally propagate from left to right across the FBD network. The signal also can be fed back from function block outputs to inputs of the preceding blocks. A feedback path implies that a value within the path is retained after the FBD network is evaluated and used as the starting value on the next network evaluation. See FBD network diagram.
The execution control of function blocks in an FBD network is implicit from the position of the function block in an FBD. For example, in the “FBD network…” diagram, the “Plant Simulator” function is evaluated after the “Control” function block. Execution order can be controlled by enabling a function block for execution and having output terminals that change state once execution is complete. Execution of an FBD network is considered complete only when all outputs of all functions and function blocks are updated.
|Signals from outputs of function blocks can become inputs to other functions.|
Strengths of FBD
Some FBD strengths follow.
Intuitive and easy to program. Because FBDs are graphical, it is easy for system designers without extensive programming training to understand and program control logic. This benefits domain experts who may not necessarily be experts at writing specific control algorithms in textual languages but understand the logic of the control algorithm. They can use existing function blocks to easily construct programs for data acquisition, and process and discrete control.
Extensive code reuse . One of the main benefits of function blocks is code reuse. As discussed, system designers can use existing function blocks such as PIDs and filters or encapsulate custom logic and easily reuse this code throughout programs. Since separate copies are made every time these function blocks are called, system designers do not risk accidentally overwriting data. Additionally, function blocks also can be invoked from ladder diagrams and even textual languages such as structured text, making them highly portable among different models of computation.
Parallel execution. With the introduction of multiple-processor-based systems, programmable automation controllers and PCs now can execute multiple functions at the same time. Graphical programming languages, such as FBDs, can efficiently represent parallel logic. While textual programmers use specific threading and timing libraries to take advantage of multithreading, graphical, FBD, and dataflow languages (such as National Instruments LabView) can automatically execute parallel function blocks in different threads. This helps in applications requiring advanced control, including multiple PIDs in parallel.
Execution traceability and easy debugging. Graphical data flow of FBDs makes debugging easy as system designers can follow the wire connections between functions and function blocks. Many FBD program editors (such as Siemens Step 7) also provide animation showing data flow to make debugging easier.
Weaknesses of FBD
Some FBD weaknesses follow.
Algorithm development. Low-level functions and mathematical algorithms are traditionally represented in text functions; even algorithms for function blocks conventionally have been written using textual programming. Furthermore, function blocks abstract the intricacies of an algorithm, making it difficult for domain experts trying to learn the details of advanced control and signal processing techniques.
Limited execution control. Execution of an FBD network is left to right and is suitable for continuous behavior. While system designers can control the execution of a network through “jump” constructs and also by using data dependency between two function blocks, FBDs are not ideal for solving sequencing problems. For instance, going from “tank fill” state to “tank stir” state requires evaluation of all the current states. Depending on the output, a transition action has to take place before moving to the next state. While this can be achieved using data dependency of function blocks, such sequencing might require significant time and effort.
IT integration. With businesses increasingly seeking ways to connect modern factory floors to the enterprise, connectivity to the Web and databases has become extremely important. While textual programs have database-logging capabilities and source code control features, FBDs generally are unable to integrate natively with IT systems. Furthermore, IT managers are often trained only in textual programming.
Need for training . Although intuitive, data flow is not commonly taught as a model of computation. In the U.S., engineers are trained to use textual languages, such as C++, Fortran, and Visual Basic, and technicians are trained in ladder logic or electrical circuits. FBDs require added training, as they represent a paradigm shift in writing a control program.
FBDs are a graphical way of representing a control program and are a dataflow programming model. The intuitiveness, ease of use, and code reuse of FBDs make them very popular with engineers. FBDs are ideal for complex applications with parallel execution and for continuous processing. They also effectively fill gaps in ladder logic, such as encapsulation and code reuse. To overcome some of their weaknesses, engineers must employ mixed models of computation. FBDs are used in conjunction with textual programming for algorithms and IT integration. Batch and discrete operations are improved by adding SFCs. The SFC model of computation addresses some of the challenges faced by FBDs and will be covered in the fourth installment of this five-part series.
|Arun Veeramani is product manager and Todd Walter is group manager for National Instruments,|
Programming methods series
Function block diagramming is the third in a series of articles from National Instruments authors exploring different software programming methods. The first article looked at ladder logic (March 2007) and the second covered textual computation models (June 2007). Future articles will cover state chart, and simulation/modeling methods.
Articles are available online at