See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224089609

IEC 61499 Function Block Model: Facts and Fallacies

Article  in  IEEE Industrial Electronics Magazine · January 2010

DOI: 10.1109/MIE.2009.934788 · Source: IEEE Xplore

CITATIONS READS

34 542

1 author:

Kleanthis Thramboulidis
University of Patras
136 PUBLICATIONS   1,691 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

UML4IoT - Industrial Automation Thing View project

Cyber-Physical Microservices View project

All content following this page was uploaded by Kleanthis Thramboulidis on 01 June 2014.

The user has requested enhancement of the downloaded file.

 Facts and Fallacies in the IEC61499
Function Block Model1
Kleanthis Thramboulidis
Electrical & Computer Engineering
University of Patras, 26500, Patras, Greece
thrambo@ece.upatras.gr

Abstract—Control and automation systems in factory automation are developed using the
procedural and the device centric paradigms. The always increasing complexity of systems in this
domain, as well as the need for agility, flexible plug-and-play extensibility and evolution, impose the
need for new paradigms to effectively address today’s requirements. The Function Block (FB) model
introduced by the international Electrotechnical Commission (IEC) 61499 standard is an attempt to
exploit current software engineering practices and the application-centric paradigm in the system’s
development process of this domain. In this paper, the current status of the standard is described and its
drafting process as well as its validation prior to implementation is commented. Facts and fallacies on
the 61499 FB model are presented and properly discussed to alleviate the confusion about the semantics
of the IEC 61499 FB model, which is one of the most important reasons that the industry has not yet
accepted the standard.

Index terms—IEC 61499, Function Block Model, Factory Automation, distributed control applications,
IEC61499 execution environment.

1. INTRODUCTION
The centralized control approach is the most commonly used in industrial systems
nowadays. The market is dominated by a small number of large corporations, which supply
97,5% of the market [1]. Their products and the corresponding proprietary tools used to
exploit these products are closed, with proprietary interfaces that do not support tool
integration not even the exchange of development time artifacts. Reuse across different
platforms is not supported.
The decrease of the hardware cost along with the increase in processing and
communication power makes the application of the distributed approach attractive. This
allows the distribution of intelligence on a network of interconnected processing nodes with
many potential advantages such as reduction in wiring, ability to build in additional fault
diagnostics and autonomy into the distributed elements. However, the design of new
distributed fault tolerant systems, represents a significant technical risk, which largely
originates, according to [2], from the increased level of complexity in the adoption of a
distributed system solution. It is also claimed that this increased complexity is perceived by
industry as higher development costs for a distributed system. Thus in order to make the
system affordable more emphasis is required on the utilization of Commercial Off-The-Shelf
technologies.
Even more, according to a survey on European companies reported in [3] the
development process of embedded systems, “is unsatisfactory and many years behind their
desktop counterparts.” It is also claimed that “currently used development technologies do

1
An extended version of this paper has been accepted for publication.

1/15
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

not take into account the specific needs of ESs development”. It has also been accepted that
currently used technologies in the PC market cannot be utilized in the industrial systems
domain without properly specializing them.
The IEC61499 standard [4] is an attempt of the International Electrotechnical Commission
(IEC) to address the above issues, to open the industrial systems market and meet among
others requirements such as interoperability, portability, distribution, agility, run-time re-
configurability, higher availability and reliability. It is supposed to: a) facilitate exchange of
design information between designers and fabrication houses, and b) allow designers to
integrate competing vendors’ tools and reduce the risk of relying on proprietary languages
and data formats. Designers do not want to “be locked into a single vendor, nor do they want
products that tilt against or are insensitive to the benefits of free-market competition” [5].
However, even though the standard has been officially accepted by the year 2005 it is not
yet adopted by the industry [6,7] and its status in the academic research community is
questionable.
In this paper, the current status of the IEC61499 is examined. Its drafting process as well
as its validation prior to implementation is commented. An attempt is made to counter a
number of incorrect statements made in the literature about the way that the IEC61499
Function Block (FB) model should be implemented. Fact and fallacies are presented and
discussed, and solutions to various open problems are proposed to alleviate some of the
confusion about the execution semantics of the IEC61499 FB model, which is one of the
most important reasons that the industry has not yet accepted the standard. Motivations for
some of the design decisions already taken in our implementation of the standard are also
given. Our implementation which adopts the embrace-and-extend strategy [8] elaborates the
standard by adding extra functionalities.
The remainder of this paper is organized as follows. In the next section background work
is presented. Challenges in the system’s development process are presented and a brief
introduction to the IEC61499 function block model is given. Section 3, presents the current
status of the standard adoption process and focuses on the paradigm shift that is imposed by
the standard. In section 4, facts and fallacies on the 61499 FB model are presented and
properly discussed with more emphasis on the programming in the large support, location
transparency and run-time environments. Finally the paper is concluded in the last section.

2. BACKGROUND WORK
2.1. Challenges in the development of industrial automation systems
The always increasing complexity of today’s industrial automation systems imposes the
need for more effective development processes and toolsets. Current software engineering
practices and technologies can be exploited to address a number of challenges in the
development process that among others include the following:
• Distribution
• Interoperability
• Portability
• Reuse
• Move from the device-centric to application-centric paradigm.
To address these challenges the IEC has accepted the 61499 standard that defines the
Function Block construct as the main design level artifact for the specification of industrial

2
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

systems. It also defines the concept of the Engineering Support System (ESS) that is a
toolset to assist the control engineer in the development process of this kind of systems.

2.2. A brief introduction to the IEC61499

The 61499 FB was defined as an extension of the 1131 FB to address today’s challenges in
industrial automation systems development. The new model introduces a paradigm shift
from the procedural approach that is the basis of the 1131 function block model and also
imposes a shift from the device to the application centric approach. The FB is defined as a
design level construct to encapsulate industrial algorithms and the data that these algorithms
operate on. It is more than an object, as defined in the object-oriented approach, since it
defines a specific way of capturing its dynamic behavior. A specific kind of statechart that is
called Execution Control Chart (ECC) is used to specify the dynamics of the object. The
head of the FB type is used to capture dynamics in terms of ECC and the body is used to
capture the functionality of the FB type in terms of algorithms, as is shown in Fig. 1. The
head accepts event inputs and generates event outputs, while the body accepts data inputs
and generates data outputs. When in a state the FB instance executes the associated EC
actions. For each EC action the algorithm is executed and the EC event is issued. Transitions
leaving the current state are next examined.
An application is defined as a network of interconnected FB instances which accept
inputs from the mechanical system, through sensors, and generates outputs that are sent to
the mechanical system through actuators. Fig. 2 shows part of the FBN of the Festo MPS
application developed using CORFU ESS [9]. Festo MPS is a laboratory system used by
several universities and institutes for research and development purposes. It is also used to
demonstrate the applicability of the FB paradigm (http://seg.ece.upatras.gr
/seg/dev/FestoMPS.htm).

(a) Function Block type (b) Execution Control Chart (ECC)

Fig. 1. Graphical representation of the FB design level construct.

3. THE CURRENT STATUS OF IEC61499 – THE PARADIGM SHIFT

If we look at the current status regarding the adoption of IEC 61499 FB model we can see
both a promising and a disappointing view. The promising view is the Academic view while
the disappointing view is the Industry’s view.

3
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

Fig. 2. An application is defined as a network of interconnected FB instances.

3.1 The Academic view

Many researchers from universities and research institutes are working last years to exploit
61499 in industrial automation. The research and development process is supported by
several prototypes or under development IDE’s [6,7,10]. Several prototype run-time
environments were developed, and example applications were presented to demonstrate the
applicability of the specification. However, the number and the complexity of the example
applications are not sufficient to demonstrate the maturity of the new technology. There are
also a great number of publications but this is not definitely an advantage. In fact, the great
number of publications with many contradicting statements on the FB model make very
difficult for the reader to clearly understand the technology and identify its advantages. It is
difficult even for members of the 61499 community to discriminate between facts and
fallacies, between facts and myths.

3.2 The industry’s view

The industry’s view is the disappointing view. Even though the standard was officially
accepted in 2005 there is no indication that the industry is going to adopt the standard. Only
recently ICS Triplex (http://www.icstriplex.com) announced that its product, i.e., ISaGRAF,
provides support for the IEC61499 FB model. An impressive demonstration has been
established and presented at ETFA 2007 (http://seg.ece.upatras.gr/seg /dev/ETFA07-
SS01report.htm). Two applications, a train simulation and an orchestra, were used to
demonstrate the various features of the new technology [11].
From our experience working last years in this domain we can state that there is a
tendency from industry to reject the IEC 61499 standard simply because:
• its learning curve is perceived as being very steep, and
• there is no mature reference implementation to demonstrate the applicability and also
the advantages of the new technology.

4
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

3.3 The paradigm shift

As far as the first reason is concerned the most important issue that has to be addressed is to
find ways to make easier the paradigm shift that is required for the industrial engineer.
Industrial engineers are familiar with the device-centric and the procedural based paradigm
that is adopted by current practices in industrial systems development. These paradigms are
also adopted by the widely used by industry 1131 standard.
It is clear that the FB model is not only a new technology in the domain but it imposes a
paradigm shift. The new technology is based on the application-centric approach and also
adopts the object-oriented approach. This means that a specific strategy should be defined to
make this paradigm shift easier for industrial engineers. This paradigm shift is more difficult
than the one confronted by the software community regarding the transition from the
procedural to the object-oriented paradigm, due to the fact that this shift should also be
accompanied by the device-centric paradigm to the application-centric one.

3.4 Reference implementations

Unfortunately even though a lot of papers have been published on the subject, the number of
actual implementations, even prototypes, is very limited. There is no mature reference
implementation to demonstrate the applicability but also the advantages of the specification.
Several prototype or under development IDE’s exist to support the development process.
FBDK (www.holobloc.com), CORFU/Archimedes (http://seg.ece.upatras.gr), and 4DIAC
(www.fordiac.org/) are currently the most known in the community. There are also several
prototype run-time environments such as FBRT, Archimedes RTSJ-AXE
(http://seg.ece.upatras.gr/mim/RTSJ-AXEpackage.htm), Archimedes RTAI-Linux, Forte
(http://sourceforge.net/ projects/fordiac), etc. A small number of example applications have
been developed to demonstrate the applicability of the specification [12,13], while there are
works in progress in using the FB model for reconfiguration [14].

3.5 The standardization process of IEC61499

The great influence of the 1131 [15] in the definition of the IEC61499 standard can be
easily identified. Even though an attempt was done to exploit current software engineering
practices, the specification has many disadvantages regarding its theoretical basis in
exploiting current software engineering concepts and technologies, such as object
orientation and component based development. This is probably one of the most important
reasons for the many ambiguities that exist in the specification. What Egyedi [8] argue with
regard to the standards development process and specification, namely that “although the
immediate problem usually lies in the way standards are implemented, the underlying causes
are mostly flaws in the scope of standardization, in the standards process or in the
specification itself”, also applies to the IEC61499 standard. Looking at the preparation
stages for standards as defined from IEC [16] there is no concept evaluation stage in the
form of a reference implementation before the acceptance of the standard. FBRT (www.
holobloc.com), the first prototype implementation, could not be considered as a reference
implementation by the time the standard was adopted since it violates a lot of the semantics
defined by the specification. Other implementations were also not used to revisit and resolve
ambiguities in the standard.
Another problem lies in the way that the standard defines the execution semantics of the
FB model. IEC61499 is an example of what is claimed in [8] namely that “many

5
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

standardizing organizations neglect standard implementation issues because this is argued to

be a matter best left to the market.” This is why the author recommends standard
organizations to “shift their emphasis from standard development to a more systematic
inclusion of implementation concerns, both at the technical level of standard committees and
at the policy level of standard organizations.”

4. FACTS AND FALLACIES

The great number of papers on the IEC61499 FB model with many contradicting
assumptions and statements make the adoption of the standard not an easy task. In this
section we present the facts and fallacies in this domain and discuss open issues. We
counter: a) a number of incorrect specifications of the standard, and b) comments made in
the literature about the way that IEC61499 function block model will be implemented. The
objective is to trigger a major revision of the standard that is greatly required in order for it
to be seriously considered by the industry. The main challenges discussed in this section are:
• requirements specification;
• programming in the large;
• location transparency in design space;
• run-time environments.

4.1 Requirements specification

Myth: The FB network can be the first application model in the development process.
The standard defines the FB type as the basic design level construct for the development of
industrial process measurement and control systems. It also defines the application as a
network of interconnected FB instances that accept inputs from sensors and provide outputs
to actuators. However, it does not refer to requirements elicitation and their evolution to
design phase models.
It is widely considered in the IEC61499 community that the FB network can be the first
specification of the application in the development process. According to this, the
development process is considered as an integration process of already existing FB types.
Even though already existing FB types can be used as a starting point, a lot of other function
block types are required to capture the specific application’s logic and the control engineer
has no guidance to this direction.
The hybrid approach [17] that integrates the UML notation with the FB model is our
proposal to address this problem. However, more work has to be done for the better
exploitation of already used by the industry diagrams for the specification of the mechanical
process [18]. Examples of these diagrams are the process and instrumentation diagrams
(PI&Ds) and the Procedure Function Chart (PFC) of ISA SP88.

4.2 Programming in the large

Myth: The FB is a component.
The size and complexity of the embedded software in industrial systems are increasing
rapidly. It is estimated that the software part of these applications roughly follows Moore’s
law, doubling in size every two years. At the same time more quality properties such as
portability, extensibility, predictability, flexibility, reliability and security should be
guarantied by these applications. Developing systems that achieve these qualities is hard

6
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

following the Programming in the small paradigm. In fact as the size and complexity
increase, the design and specification of the overall system structure become more
significant than the choice of algorithms and data structures. By concentrating on the
structure of the industrial system will be possible to overcome shortcomings in current
engineering practices. A well-organized structure of the industrial system will reduce the
complexity; it will provide a better understanding of how the system works and also allow
the analysis of system’s properties without implementing it. A solid software architecture
will reduce complexity and thus will lead to a better understanding of how the system
works. So, the question is if the IEC61499 can be considered as a notation to define the
architecture of the system?
There is currently a trend in the 61499 community to consider the FB type as a
component. In [19] the authors referring to the “component model of IEC 61499” claim that
the “FB possesses the required characteristics of a software component,”. In [20] and [21]
the authors consider the IEC 61499 as a “high level architecture”. In [21] the FB type is
characterized as a “component with event and data interfaces”. It is also stated that “The
concept is analogous to the ideas of component, such as software component from software
engineering”. In [22] the FB is characterized as a “high level concept” and also as a
“component with a state machine inside.” The authors base this statement on the argument
that the FB type is not relying on a particular programming language, operating systems, etc.
However, adopting this argument we can also conclude that the ‘process’ construct of the
well known DFD notation is a component since is not relying on a particular programming
language and operating system.
To better understand the semantics of the FB notation a mapping of the FB type concept
to the well known and widely used in real-time system development DFD notation, is given
in Fig. 3. A detailed description of this mapping is given in [23]. From this mapping it is
clear that the interface definition of the new construct is too low level at least as far as the
data representation is concerned. The concept of the data flow is not adopted in the FB
model and instead of it a detailed representation of the constituent parts of the data flow are
represented, cluttering the design diagram with too much detail.

Fig. 3. Mapping the FB construct to the DFD notation constructs.

If we consider the current use of the FB construct we can see that it is mainly used, as for
example in [21,24], just to represent simple processes or functions. This is the approach also

7
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

adopted for the construction of the basic library of FBDK. The example given in [21] that
uses the FB to represent the operation that calculates the expression X2 – Y2 is misleading
for the objectives of the FB model since it uses a construct defined for object representation,
to represent a function. This example can also be used as representative of the level of detail
that the IEC61499 introduces in specification. This is clear if one just compare this FB with
the method signature of the operation that implements the calculation OUT = X2-Y2, and
the method X2minusY2() of one of the provided interfaces of a component, as shown in Fig.
4. It should be emphasized that both the input and output events and data of the X2Y2_ST
FB type are the equivalent of the specification of just one method of a provided interface of
a component. Moreover, FBs that implement operations as the above mentioned cannot be
considered as components in a component based development. It should be noted that it is
not the graphical representation that makes a design level construct component but its
semantics. This is why the process construct of the DFD notation is not a component.

Fig. 4. IEC61499 FB type vs. class and component.

The interface definition of FB types is usually defined in a way that does not include
semantic information. Instead of it the interface of a component has to define the operation
provided. For example, the graphical interface of the X2Y2_ST FB type, with input event
REQ, data inputs X and Y, output event CNF and output data OUT, provides no information
on the operation represented. The name REQ used also to identify the algorithm has no
information on the specific algorithm. The example implementing X2-Y2 as a network of
function blocks given in [21] further confirms our argument.
The FB type is also used by ISaGRAF, the first commercial implementation of
IEC61499, to represent a process that was traditionally represented by an 1131 function
block. However, for a commercial tool this can be considered as an intermediate step to
simplify the paradigm shift in the industry from the procedural 1131 to the object-based
61499 paradigm. The shift from the purely procedural 1131 to the object based 61499 would
not be possible if such an intermediate level is not provided, since industrial engineers are
not familiar with the concepts of object and component. This problem can be compared to
the paradigm shift from the procedural to the object-oriented paradigm in the PC domain,
where C++ allowed an intermediate level shift. In a first step many programmers used C++
just to program in a procedural way following a smooth shift from the procedural paradigm
to the OO one.

8
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

According to Szyperski [25] a software component has to be a unit of deployment and

thus it has to be an executable deliverable for a (virtual) machine so no human intervention
will be required for its use. It also has to be a unit of versioning and replacement and thus it
should remain invariant in the place of installation as it gets installed onto possibly many
systems. According to [26] a component defines its behavior in terms of provided and
required interfaces.
From all the above it can be concluded that the FB is a construct that supports
programming in the small and thus FB libraries favor reuse in the small. Another construct
is required for the FB model to be able to support programming in the large and allow the
definition of system’s architecture in such a way as to influence its efficiency, its
adaptability and the reusability of its software components. Such an extension should allow
the definition of an abstraction of the system under development that should suppresses all
these details of its elements that do not affect how they use, are used by, relate to, or interact
with other elements. It should allow the definition of the structures of the system, which
should comprise:
• the software elements of the system (components)
• the externally visible properties of those elements (interfaces), and
• the relationships among them (ports and connectors).

4.3 Location transparency

Myth: The IEC61499 FB model is a Platform Independent Model (PIM)

The advantages of the Platform Independent Model (PIM) in the system’s development
process are well known [27]. The PIM should describe the software system, which supports
a part or the whole of the industrial process system, in a highly abstract way that is
independent of any implementation technology. It should model the system from the
perspective of how it best supports the industrial process without including decision on the
type of technology on which the PIM will be implemented. The platform specific model
(PSM) will later describe in detail how the PIM will be implemented on a specific platform
or technology.
IEC61499 introduces the Service Interface FB (SIFB) to be used in the FB network to
implement event and data transfer over the network. The use of the SIFB in the design
diagram complicates the FB network diagram and makes it a PSM. However, according to
[20] an application “completely captures the desired functionality but does not include any
knowledge of the devices and their interconnections;” and it continues “That is why an
application usually does not include function blocks implementing data transfer over
networks, as well as other hardware-dependent functions, like reading of input signals.”
Even though the authors refers to “data transfers”, no reference is done to the event transfer
that is explicitly implemented according to the standard using the SIFB concept that
completely destroys the location transparency, since it makes the design diagram closely
related to the specific hardware configuration. The authors also state that the application
“Potentially can be mapped to many possible configurations of devices.” However, this is
not easy for an FB network containing SIFBs, since a re-engineering of the FB network is
required to fit into a new configuration of the distributed environment. In [21] authors claim
that the FB network “completely captures the desired functionality but does not include any
knowledge of the devices and their interconnections.” Authors also cite the TORERO
project stating that “suitable automatic mechanism to find the best map between FBs and

9
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

devices, in terms of memory consumption and application temporal performance, has been
proposed by the European project TORERO.” However, the proposed FBALL algorithm
[28] is criticized in [29] for its correctness. In [20] it is also claimed that “the TORERO
development environment automatically generates the needed communication.” However,
there is no proof that this environment has been ever developed.
To exploit the benefits of PIM, the design diagram should be defined for a target
technology-neutral virtual machine. This virtual machine that is shown in Fig. 5 is called
IEC61499 virtual bus and is defined as a set of parts and services which should be defined
independently of any specific platform. It include parts, as FB type container and FB
instance container, and services that provide the functionality of SIFB, Management FBs,
event FBs, etc. This virtual machine (bus) will be next realized in platform-specific ways on
different execution platforms. A prototype for this proposal has already been developed and
performance measurements show that it satisfies stringent real-time constraints [30].
It is clear from the above that the component based application approach should be
adopted, in order for the run-time environment to fulfill the objective of the standard that is
to support run-time reconfiguration. However, most of the existing or under evolution run-
time environments adopt the monolithic application approach. For example in [22] for the
implementation of a function-block compliant device a run-time environment is not used,
but the transformation of the FB based specification to the device’s OS is proposed.

Fig. 5. The IEC61499 virtual bus and its realization.

4.4 Run-time environments

Myth: A profile will define the execution semantics of IEC61499 Function Block model.
A profile is a UML term that is used to describe the UML mechanism that permits limited
changes to UML without modifying the underlying meta-model. Profiles permit UML to be
tailored to specific domains or platforms maintaining interoperability across platforms [26].
According to the above it is clear that there is no need for a profile to define the execution
semantics, but just clear definition of the underlying 61499 meta-model at least as far as the
execution semantics are concerned.
An IEC61499-compliant run-time environment should provide the platform specific
implementation of the IEC61499 virtual bus. This means that the run-time environment

10
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

should not influence the design of the FB types and FB network diagrams, or either wise
there is no need for the designer to know the specifics of each run-time environment. The
whole design should be based on the semantics of the virtual machine. This means that the
execution semantics of FB instance and FB network should have been clearly defined by the
standard in a platform independent way. It should have been defined in such a way that the
design models be detailed and precise enough to produce fully executable models and
permit the automatic generation of the implementation models in the form of efficient code
that can be executed on specific run-time environments. The FB design models should be
behaviorally expressive and rigorous as well as intuitive and well structured. Unfortunately
the standard fail to rigorously define the semantics and this makes the development of run-
time environments a very hard task. This is also a source of incompatibility between the
different platforms as far as the execution of applications is concerned.
Since the IEC61499 standard is intended to be used by control engineers in specifying
distributed control systems, clarity and simplicity should be considered as key parameters
for deciding upon execution semantics. The control engineers should be able to understand
how the created models work in a relatively intuitive way. So the semantics have to be rich
enough to support different styles of modeling and at the same time to be simple and
intuitive.
There are several proposals regarding the execution of the FB instance and FB network.
Some of these have already provided a reference implementation; others are just specs
without reference implementations not even a theoretical proof of concept. This makes the
development of run-time environments a very hard task. This sub-section discusses on these
proposals with the objective to identify pros and cons that can be later used to complement
the standard in the direction of execution semantics.
The standard introduces many sources of confusion regarding the execution semantics.
One example is the so called ECC operation state machine that is supposed to define the
dynamics of ECC. Actually this state machine defines the dynamics of the FB instance; the
behavior of the FB instance is defined by the ECC of the corresponding FB type. The ECC
operation state machine is the source of confusion in FB instance execution. In [21] for
example it is claimed that “The execution of the FB_Receiver will be done by invocation of
its Execution Control Chart.” However, before invoking the ECC the FB instance has to
read input data and update event input (EI) variables. Also after the execution of ECC,
actions such as clear EI variables should be executed. The standard describes the dynamics
of the FB instance even though it does not provide any representation of it in the form of a
statechart. The statechart shown in Fig. 6 was constructed to clearly describe the dynamics
of the FB instance, as close as possible to the one described by the standard, for the case that
the FB instance is implemented as ‘active’. An FB instance may be defined at PIM or PSM
as ‘active’ or ‘passive’. An active FB has its own thread of execution, while a passive FB
has not its own thread of execution; it is executed by other threads. In this latter case the FB
instance is usually implemented as a monitor. It is clear that the assumed at the design level
behavior for the FB instance should be the same in both cases. The same behavior should
also be ensured for the case of an event-based implementation or a cycle-based one.
The execution semantics of the FB instance that are considered so far as undefined by the
standard can be classified in three categories:
a) queuing or losing of input events;
b) scheduling function; and
c) event processing policy.

11
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

As far as the first issue is concerned, statechart semantics imply the use of an event-pool
that means that there is no loss of event. The concept of the scheduling function and the
concept of resource are not clearly defined by the standard and this is one of the biggest
problems for the development of a run-time environment. It is clear that the given
definitions are greatly influence by 1131 and are in contrast to the meaning of the
corresponding terms in software engineering. Our proposal is to avoid both concepts [31]
and use a) the term FB container to partially support the assumed by the resource
functionality, and b) the OS scheduler, when scheduling of FB instances is required.

Fig. 6. State machine of the ‘active’ FB instance construct of 61499.

Regarding the event processing policy both the first come order, or the priority based
order can be considered. However, to obtain a more efficient response to safety critical
events the priority based order was adopted. According to the UML statecharts adopted
policy, the state machine processes one event at a time and finishes all the consequences of
that event before processing another event, a policy known as run-to-termination. However,
the FB type definition and especially the definition of event input (EI) variables, and their
use in transition expressions favours a policy influenced by the cycle-based implementation
approach, where all pending input events are candidates for processing. Events from the
event queue will be transferred to the EI variables that are to be consumed based on their
priority.
The problem of the undefined transition evaluation order that rises when the trigger
expressions of two transitions starting from the same state are simultaneously fulfilled, a
situation that leads to non-determinism, can be easily handled by the definition of the
“evaluation-order priority” that explicitly defines the evaluation order on the PSM [31]. The
concept of negated trigger event [32] can also be used to address this problem. The standard
assumes as order of execution the order of transitions in the XML specification but this is a
source of ambiguity.
Many assumptions made last years in the 61499 community in the process of defining the
execution semantics are erroneous, without proof of concept, which could be either a
reference implementation or clear theoretical basis, and thus create confusion in the domain.
A detailed discussion of the above issues can be found in the original paper.

12
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

4.5 Discussion on Sequential hypothesis execution model and related postulates

Myth: The sequential model is expected to be immediately applicable, implemented in a
number of software tools.
The sequential hypothesis execution model seems to have a great influence on the 61499
community since it is supported by O3Neida (www.oooneida.org). It is defined in a form of
axiomatic definition based on a set of 6 postulates. This model is disputed in this sub-section
for its correctness and its clear theoretical basis. A detailed discussion on this subject can be
found in the original paper.

5. CONCLUDING REMARKS
The market of industrial systems needs open solutions. Distribution, interoperability,
portability, run-time reconfiguration are open issues that have to be addressed in the
development process of today’s complex industrial process systems. IEC61499 is here to
provide some solutions. However, it is clear that this standard has been influenced very
much from the 1131 standard and fails in successfully exploiting current software
engineering practices. It also has many ambiguities and open issues; the requirements
elicitation phase as well as the architectural design phase have to be addressed. This is why
a major revision is required for the standard to be seriously considered by the industry. A
reliable reference implementation is required to demonstrate the applicability of the standard
and also validate the concepts behind it.
Since the standard attempts to introduce at the same time two paradigm shifts, the one
from the procedural to the object-based, and the other from the device-centric to the
application-centric, a very long time is required for its adoption from industrial engineers.
Experiences from the procedural to the object-oriented paradigm shift in the PC domain can
be exploited to ease this paradigm shift. ISaGRAF that follows a quite similar approach as
the one adopted by C++, that is to allow the developer to apply the old paradigm using the
new constructs may be probably the intermediate step for this steep paradigm shift in
industrial process software systems.

REFERENCES
[1] B. Heck, L. Wills, and G. Vachtevanos, Software Technology for Implementing Reusable, Distributed
Control Systems, IEEE Control Systems Magazine, February 2003.
[2] Thompson, H.A., D.N.Ramos-Hernandez, K. Cartledge, J. Fortune, A. Brown, Flexible control systems
development and integration environment for distributed systems, UKACC Control 2006 Mini Symposia,
Glasgow, UK, 31 Aug. 2006.
[3] Graaf, B., M., Lormans, H., Toetenel, Embedded Software Engineering: The State of the Practice, IEEE
Software, November/December 2003, vol. 20, no. 6.
[4] International Electro-technical Commission, (IEC), International Standard IEC61499, Function Blocks,
Part 1 - Part 4, IEC Jan. 2005.
[5] M. Tiemann, An objective definition of open standards, Computer Standards & Interfaces 28 (2006) 495–
507
[6] K. Thramboulidis, IEC 61499 in Factory Automation, Advances in Computer, Information, and Systems
Sciences, and Engineering, Proceedings of IETA 2005, TeNe 2005, EIAE 2005,
[7] A. Zoitl, T. Strasser, K. Hall, R. Staron, C.K. Sünder, B. Favre-Bulle: The Past, Present, and Future of
IEC 61499, 3rd Intern. Conf. on Industrial Applications of Holonic and Multi-Agent -Systems, HoloMAS
2007, Regensburg, Deutschland.
[8] T.M. Egyedi, Standard-compliant, but incompatible?!, Computer Standards & Interfaces 29 (2007) 605–
613.

13
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

[9] C. Tranoris, K. Thramboulidis, A tool supported engineering process for developing control applications,
Computers in Industry, Volume 57, Issue 5, June 2006, Pages 462-472
[10] T. Strasser, I. Müller, M. Schüpany, G. Ebenhofer, et al., An Advanced Engineering Environment for
Distributed & Reconfigurable Industrial Automation & Control Systems based on IEC 61499, Intelligent
Production Machines and Systems, 2006, Pages 493-498.
[11] J. Chouinard, Lavallée, D., Laliberté, J., Landreaud, N., Thramboulidis, K.,et al. An IEC 61499
configuration with 70 controllers; challenges, benefits and a discussion on technical decisions, Available
on-line: http://www.isagraf.com/pages/documentation/whitepapers.htm
[12] Panjaitan, S., G. Frey, “Functional Control Objects in Distributed Automation Systems”, Workshops on
Intelligent Manufacturing Systems (IMS’07), Alicante, Spain, 23-25 May, 2007.
[13] K. Soundararajan, R. W. Brennan, Design patterns for real-time distributed control system benchmarking,
Robotics and Computer-Integrated Manufacturing, Volume 24, Issue 5, October 2008, Pages 606-615
[14] R.W. Brennan, P. Vrba, P. Tichy, A. Zoitl, C. Sünder, T. Strasser, V. Marik, Developments in dynamic
and intelligent reconfiguration of industrial automation, Computers in Industry, Volume 59, Issue
6, August 2008, Pages 533-547
[15] International Electrotechnical Commission. IEC International Standard IEC 61131–3:2003, Programmable
Controllers, Part 3: Programming Languages, 2003
[16] ISO/IEC Directives, Part 1, Preparation stages for standards, Available on line:
http://www.iec.ch/ourwork/stages-e.htm
[17] K. Thramboulidis, Using UML in Control and Automation: A Model Driven Approach, 2nd IEEE
International Conference on Industrial Informatics, 24-26 June, Berlin, Germany, (INDIN´04).
[18] K. Thramboulidis, S. Sierla, N. Papakonstantinou, K. Koskinen, An IEC 61499 Based Approach for
Distributed Batch Process Control, 5th IEEE Inter. Conf. on Industrial Informatics (INDIN 07), July 23-
27, 2007, Vienna, Austria.
[19] Sunder, C. et al. Usability and Interoperability of IEC 61499 based distributed automation systems, 4th
IEEE Inter. Conf. on Ind. Informatics (INDIN 06).
[20] V. Vyatkin, V. Dubinin, Sequential Axiomatic Model for Execution of Basic Function Blocks in
IEC61499, 5th IEEE Inter. Conf. on Ind. Informatics (INDIN 07), July 23-27, 2007, Vienna, Austria.
[21] V. Vyatkin, Victor Dubinin, Carlo Veber, Luca Ferrarini, Alternatives for Execution Semantics of
IEC61499, 5th IEEE Inter. Conf. on Ind. Informatics (INDIN 07), July 23-27, 2007, Vienna, Austria.
[22] V. Vyatkin, Victor Dubinin, Execution Model of IEC61499 Function Block based on Sequential
Hypothesis, Available on-line at : http://www.ece.auckland.ac.nz/~vyatkin/o3fb/vd_seqsem.pdf Accessed
at 3 Oct 2007.
[23] K. Thramboulidis, A model based approach to address inefficiencies of the IEC61499 function block
model, 19th Int. Conf. on Software and Systems Engineering, Dec. 2006, Paris, France.
[24] J. P. Peltola, J. H. Christensen, S. A. Sierla, K. O. Koskinen, A Migration Path to IEC 61499 for the Batch
Process Industry, INDIN 07, July 2007, Vienna, Austria.
[25] Szyperski, C., Component Technology – What, Where, and How?, 25th Inter. Conf. On Software
Engineering (ICSE’03).
[26] Rumbaugh, J., I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, 2nd edition,
Addison Wesley 2005.
[27] Richard Soley and the OMG Staff Strategy Group, Model Driven Architecture, White Paper, Draft 3.2 –
November 27, 2000, Available on-line: ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf
[28] A. Prayati, C. Koulamas, S. Koubias, and G. Papadopoulos, A methodology for the development of
distributed real-time control applications with focus on task allocation in heterogeneous systems, IEEE
Trans. Ind.Electron., vol. 51, no. 6, pp. 1194–1207, Dec. 2004.
[29] K. Thramboulidis, Comments on “A Methodology for the Development of Distributed Real-Time Control
Applications With Focus on Task Allocation in Heterogeneous Systems”, IEEE Transactions on Industrial
Electronics, vol. 54, no. 2, April 2007.
[30] G. Doukas, K. Thramboulidis, A Real-Time Linux Execution Environment for Function-Block Based
Distributed Control Applications,3nd IEEE International Conference on Industrial Informatics, Perth,
Australia, August 2005, (INDIN´05).
[31] K. Thramboulidis, G. Doukas, IEC61499 Execution Model Semantics, International Conference on
Industrial Electronics, Technology & Automation, (CISSE-IETA 06), Dec. 4-14, 2006.
[32] Von der Beek, A comparison of statechart variants, In Formal Techniques in Real-Time and Fault-
Tolerant Systems, L. de Roever and J. Vytopil, Eds. Lecture Notes in Computer Science, vol. 863, 128–
148.

14
 Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008

[33] OMG, Unified Modeling Language: Superstructure, version 2.1.1, formal/2007-02-03.

[34] K. Thramboulidis, A. Zoupas, Real-Time Java in Control and Automation: A Model Driven Development
Approach, 10th IEEE International Conference on Emerging Technologies and Factory Automation,
(ETFA’05), Catania, Italy, September 2005.

15
View publication stats