1

Quick start
This chapter is a primer in the basic concepts of system development using IEC 61499 function blocks. An
example of a distributed automation system (FLASHER) is used to highlight the key issues in the new
standard. No background in industrial automation systems and/or software development is assumed.

System modelled with function blocks

This chapter illustrates some concepts of the IEC 61499 function block architecture using the example of a
system that has been specified, modelled and implemented within the IEC 61499 architecture. This example
will be re-visited in several subsequent chapters. Although the system might look primitive to some readers,
its simplicity clearly illustrates several important features and includes sufficient detail for the reader to
understand it.
The system consists of four lamps blinking according to a required mode of operation as shown in
Figure 1-1. Operation modes vary and include commands such as “blink all lamps together”, or “chase the
light left or rightwards”, and so on. The lamps are “controlled” by a “black box” controller with four output
control signals, each connected to a lamp and serving as a switch, which turns a lamp on and off.
Now we will consider a function block model that simulates this system working under automatic control.
Later we will see that with minor changes the same model program can be used to control the physical device.

Step 1 Open a system configuration file FLASHER_TEST.sys in the Function Block Editor as shown
in Figure 1-21. For that click on the Open button in the Menu bar and browse to the folder
/src/doc. (Note that the files with extension *.sys contain system configurations). Next, click
on the resource RES1 in the navigation tree area (upper left side of the window) and you will
see a screen similar to the one illustrated in Figure 1-2. This editor’s screen is divided into
three areas:
· A navigation tree on the left shows the system’s structure.
· The worksheet on the right (the largest one) shows the “content” of system elements. Thus,
in Figure 1-2 it shows the content of the resource RES1 in device FLASHER.
· The text area in the bottom contains textual description of the system configuration, either
in eXtensible Markup Language (XML), or in plain text (in tab “SRC”).

Figure 1-1 FLASHER controlled by a “black box” controller.

1
2 Quick start

The menu bar on the top contains several buttons that allow you to Open, Create or Save/
Compile function blocks or structures built thereof, as well as to Run and to Terminate them.
For more detail about the available actions refer to the FBEditor documentation (discussed in
Chapter 6).
Step 2 · Start the system using the Run button ( ) in the Menu bar. A new window frame will
appear on screen as shown in Figure 1-3. You can experiment with it by trying the follow-
ing actions: Change the time delay of t#250ms to some other value;
· Explore the pull-down menu, and
· Change status from STOP to RUN,
For example, you can select the “FLASH_ALL” option in the pull-down menu, and then press
RUN.
This system configuration operates as follows: Blinking the four lamps following one of the five different
patterns (flash all, count up, count down, chase up, and chase down) and with a different frequency deter-
mined by the time constant set by default to 250 milliseconds.

Figure 1-2 FLASHER_TEST system configuration opened in the function block editor.

(a) (b)

Figure 1-3 Output window produced by the FLASHER_TEST:

(a) before the RUN button is pressed; (b) the lamps are flashing in the FLASH ALL mode.
 System modelled with function blocks 3

Let us see how the system is organized internally. First, a system configuration is more than just a pro-
gram. It describes a distributed system composed of several communicating devices and resources. In this
particular example, the system consists of one device (FLASHER), which has just one resource (RES1).
The resource is populated by the network of function blocks that are software components invoking
each other and passing data between each other. In this case, the network of function blocks implements
the FLASHER model. In the context of IEC 61499 such a network is called an application.
At this stage, consider the following to further your understanding:

· The network is composed of instances of function block types. The types have to be created and
stored in a library prior to creating an application. The name of the type is written inside the func-
tion block image; the name of the instance—immediately above the function block. Thus, the func-
tion block START is of type E_RESTART.
· Function blocks have inputs and outputs of two sorts: events and data. If the output of one block is
connected to the input of another, this means that the block-source can pass an event or data to the
other. In FBDK, event connections are green lines, while data connections are blue lines. The data
inputs of function blocks can also be assigned with constants.
· A function block can be activated only when an event input arrives. Otherwise, the block remains
idle. This is true for all kinds of function blocks except for the service interface function blocks that
may get activated by the hardware. In this example, all the blocks are service interface function
blocks except for the FLASHIT block.

Now try to understand what each block in the application in Figure 1-2 is doing and how they operate
together to achieve the functionality that we observe. Four of the function blocks in the application are
implementing screen controls, such as radio buttons (RUNSTOP), parameter setting field (DT), pull-down
menu (MODE), and the picture of the blinking lamps (LEDS). These allocations are shown in Figure 1-4.
Strictly speaking, the function block START (of type E_RESTART) does not belong to the application
at all; it is a part of the resource type. This kind of block provides an interface to the hardware of the
device. On restart of the device (e.g., in case of power switch on) the event output COLD gets activated, so
that the block RUNSTOP receives the INIT input event, which “sparks” initialization of the whole net-
work.2
The three remaining non-interface blocks are RS_GATE of type E_SWITCH, PERIODIC of type
E_CYCLE and FLASHIT of type FLASHER4.
Given an event at the event input EI, the function block of type E_SWITCH issues output event EO0,
if the value on its data input is G=0, and EO1 if G=1. Here it is used to recall the current operation mode
(RUN or STOP) and either to stop blinking, or to refresh the timing value and start blinking.
The function block type E_CYCLE is a standard library block that periodically issues events to its
event output EO, as determined by its input parameter DT.
Function block type FLASHER4 contains the main functionality of the FLASHER_TEST system. It
contains the logic setting for the values of four Boolean variables, which are displayed as Light Emitting
Diodes (LEDs). Every moment an event occurs at the input REQ of the FLASHIT, the output combination
of LED0–LED3 is created, and the output event CNF notifies the block LEDs, which then updates the
display.
If the functional mode (determined by the current value of the pull-down menu) changes during the
operation, the corresponding event IND of the block MODE will notify the FLASHIT. Then FLASHIT
will change the pattern that generates its outputs.
4 Quick start

Figure 1-4 Responsibilities of function blocks in the application FLASHER_TEST for the interface ele-
ments in the output window frame.

Function block internals

Here is a more detailed description of the function block type FLASHER4. This is a basic function block
whose behavior is programmed by a combination of a state machine, called Execution Control Chart
(ECC) (Figure 1-5), and algorithms associated with ECC states.
ECC determines how a block responds to incoming events. Each state can have one or several
actions. An action is defined by the algorithms it executes and by an output event to be issued afterwards.
One of the ECC states is designated initial. States are graphically represented by rectangles and the initial
state by a rectangle with a double line border. States are connected to other states by lines that designate
state transitions. State transitions have associated Boolean conditions, which determine when the transi-
tion occurs.
Upon first activation, the ECC of FLASHER4 is in the initial state named WAIT. When the function
block is activated by an input event INIT, the state machine changes its state to the initialization state INIT,
executes the associated algorithm (also named INIT), and issues output event INITO. After that, it returns
to the state WAIT, because there is a transition between states INIT and WAIT with condition “1” that is
equivalent to “always true”.
At the input event REQ, the ECC changes its current state to a state corresponding to a particular mode
of operation as determined by input variable MODE (a number in the interval from 1 to 5). Note that one
half of the algorithms encapsulated in the FLASHER4 are programmed in Structured Text (ST), while the
other half are programmed in Ladder Diagrams (LD), as illustrated in Figure 1-6. This demonstrates the
 Summary 5

Figure 1-5 FLASHER 4: Execution Control Chart.

(a) (b)
Figure 1-6 Algorithms programmed in different languages: (a) COUNT_UP in Structured Text (ST);
(b) CHASE_UP in Ladder Logic.

opportunities to reuse the legacy code in IEC 61499 function blocks and even to combine different pro-
gramming languages in a single software component.

Summary
IEC 61499 is used to model and to implement distributed automation systems. The function block is an
abstract model representing a function that can be implemented by software or even by hardware. Function
blocks are activated only by external events. Function block behavior can be described in different
6 Quick start

programming languages. Writing a program with function blocks involves drawing a network of function
blocks and allocating them to a device for execution.

Review questions for Chapter 1

1. What does an IEC 61499 model of a distributed automation system consist of?
2. List the sequence of function block initialization in the FLASHER_TEST example.
3. List the sequence of function block activation that occurs during operation (while flashing):
a. Value of the flashing interval is changed and “ENTER” is pressed.
b. New operating mode is selected from the pull-down menu.
c. Button “STOP” is pressed.
d. Button “START” is pressed.
5. What is an equivalent to the function block “PERIODIC” in the “black box” controller shown in
Figure 1-1, assuming it is a pure hardwired electric circuit?

Notes
1
See Chapter 6 for details of the Function Block Editor installation.
2 Note that almost each function block in the FLASHER application has event input INIT and event
output INITO. This is not a norm, but represents a good programming practice. Activated by the
event INIT, the block executes specific initialization actions (required in case of first execution)
and gets ready to normal operation. Then it issues the INITO event. By connecting the blocks in a
chain, one can ensure that all blocks are initialized sequentially.