The Standard

The IEC61499 architecture represents a component solution for distributed industrial automation systems aiming at portability, reusability interoperability, reconfiguration of distributed applications. The IEC 61499 Standard provides a generic model for distributed systems. This model includes processes and communication networks as an environment for embedded devices, resources and applications. Applications are built by networks of Function Blocks.


The industry is moving from centralized systems towards a more distributed paradigm. Large systems with a central intelligence controlling everything are transformed to distributed systems. In the distributed system, individual parts have intelligence and can communicate with each other smoothly, so the system acts as one whole. IEC 61499 defines a domain-specific modeling language for developing distributed industrial control solutions. IEC 61499 extends IEC 61131-3 by improving the encapsulation of software components for increased re-usability, providing a vendor independent format, and simplifying support for controller-to-controller communication. Its distribution functionality and the inherent support for dynamic reconfiguration provide the required infrastructure for Industry 4.0 and industrial IoT applications.

Two big problems arise with IEC 61131-3. One is caused by feedback connections in the application. In a Function Block Diagram like the one illustrated above, but with added feedback, the behavior of the system depends on the implementation of the underlying software. Secondly, in case of combining PLCs from different vendors, the communication between them is not standardized and is normally difficult to achieve.


In other words, IEC 61499 defines a modeling language that is similar to the old FBs shown in the previous section. This new language is however oriented to distributed systems. Therefore, it allows modeling the whole system, even if it is comprised of smaller parts (i.e., the individual PLCs). FBs are used to completely encapsulate functionality since no global variables are allowed. The application is then created by connecting the individual FBs. Additionally, the standard defines a model to represent the devices in a system and their connections. If the application is split to several devices, all FBs in the application can be mapped to their respective devices.


So, without going any further into the concepts, let's look at some images to understand the capabilities and new features introduced by IEC 61499.

Main parts of IEC 61499

FB Interface: The image shows the appearance of the FB in IEC 61499. The function block encapsulates the desired functionality. Similar to IEC 61131-3, the inputs are on the left and the outputs on the right, but now the interface differentiates events and data. The events on the top part of the FB are shown as red lines, and the data on the lower part as blue lines. The events trigger the functionalities of the FBs, which then use the data that are available at the data inputs. Events and data connections are not compatible, meaning that you cannot connect them in any way. It is allowed to fan out data connections. A fan-out describes an output that is connected to several inputs of the next stage. This means that several data inputs of the next stage can be connected to the output. On the contrary, a fan-in of data connections is not allowed. A fan-in is the connection of several outputs of the previous stage to an input. Therefore, a FB would need to choose its input value from the data connections. For event connections, both a fan-in and a fan-out are possible.


In the graph, each event input is connected to several data inputs via lines and small squares. Similarly, each event output is connected to several data outputs. This connection defines which data inputs/outputs are refreshed when an input/output event occurs. The behavior of the function block depends on its Event Execution Control (ECC). The ECC is a state machine, which receives the input events. Based on the current state, the ECC executes a certain part of the encapsulated functionality.

FB Internal Sequence: The image shows how a FB is triggered to execute its functionality. A sequence of steps is executed when an event arrives at the FB.


  1. An input events arrives at the FB.
  2. The data inputs related to the incoming event are refreshed.
  3. The event is passed on to the ECC.
  4. Depending on the FB type and execution control, internal functionality is triggered for execution.
  5. The internal functionality finishes the execution and provides new output data.
  6. The output data related to the output event are refreshed
  7. An output event is sent.

Step 4 to 7 may be repeated several times. Although an output event can be triggered, this need not be the case.

Distributed Application: We defined now FBs and their behavior. In the next image, an example for an application created according to the IEC 61499 is shown. You can see that data and events are not connected to each other.



As the standard allows modeling of distributed systems, the application need not run on only one device. Instead, it can be split and deployed to several devices (PLCs). You can even have many applications, which are then distributed over many devices. The System Model view helps the user to design this distribution. It is illustrated in the following figure. A device may comprise several resources, which can be imagined as threads within a device. To be precise, the FBs are actually loaded onto a resource, not the device itself.




The image shows that not all FBs of an application are run on the same device. Additionally, a device can run many applications or many parts of applications at the same time. CAUTION: A FB cannot be split to several devices.

Broken Connections: While it's nice that you can split the application over several devices, the data and events need to be sent to the next device in order to maintain their flow. Yes! That's why you fix these connections with special FBs to publish information and subscribe to it as shown in the image below. Since these new FBs are not part of the full application, they are only visible in the resource view.



Types of Function Blocks

Basic Function Block (BFB): In the BFB you can define a state machine using the Execution Control Chart (ECC). The ECC decides which algorithm is executed based on its state and the input events. The graph below shows a FB with an exemplary ECC. The gray boxes (Alg1-Alg3) in the ECC are the algorithms encapsulated inside the Function Blocks. These algorithms are written by the user, using for example Structured Text, which is one of the programming language defined in IEC 61131. The pink boxes (EO1, EO2) are the output events that are triggered when the state is accessed. Transitions between the states (brown boxes) are shown as arrows. They are connected to a certain event, unless the transition is named as "1", in which case no event is needed and the execution control jumps directly to the next state. For example, if the FB is in the START state and an EI1 event arrives, the FB jumps to State1, executes Alg1 and outputs an EO1 event.


Some transitions include an expression between square brackets. These expressions are conditions that need to be fulfilled when the event arrives. Only when the conditions hold, the execution control switches to the next state. An event is consumed only once. If the transition from State1 back to START was again at E1, no infinite loop is created. Only when a new event E1 arrives, the state jumps back to START. These kinds of loops do occur with "1" on the transition, since only events are consumed.

Composite Function Block (CFB): The CFB simply has an internal network of other FBs.

Service Function Block (SFB): SFBs are FBs that are needed to access specific parts of the hardware. As seen above, the same application can be deployed to several devices. Then, the application needs to access inputs or outputs and, to communicate, even specific hardware. For that, SFBs are needed. They are used for anything that needs to access the platform, which BFBs or CFBs cannot do. These types of FBs are activated not only by an incoming event but also by the hardware. Therefore, a Responder FB can trigger an event every time a packet arrives.