Journal of Software Engineering and Applications, 2013, 6, 405-415
http://dx.doi.org/10.4236/jsea.2013.68050 Published Online August 2013 (http://www.scirp.org/journal/jsea)
405
IEC 61499 vs. 61131: A Comparison Based on
Misperceptions
Kleanthis Thramboulidis
Electrical and Computer Engineering, University of Patras, Patras, Greece.
Email: thrambo@ece.upatras.gr
Received May 9th, 2013; revised June 10th, 2013; accepted June 18th, 2013
Copyright © 2013 Kleanthis Thramboulidis. This is an open access article distributed under the Creative Commons Attribution Li-
cense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
ABSTRACT
The IEC 61131 standard has been widely accepted in the industrial automation domain. However, it is claimed that the
standard does not address today the new requirements of complex industrial systems, which include among others,
portability, interoperability, increased reusability and distribution. To address these restrictions, the IEC has initiated the
task of developing the IEC 61499, which is presented as a mature technology to enable intelligent automation in various
domains. This standard was not accepted by industry even though it is highly promoted by the academic community. In
this paper, it is argued that IEC 61499 has been promoted by academy based on unsubstantiated claims on its main fea-
tures, i.e., reusability, portability, interoperability, event-driven execution. A number of misperceptions are presented
and discussed in this paper to show that the comparison, which appears in the literature, between IEC 61499 and 61131
is not substantiated.
Keywords: Industrial Automation Systems; Industrial Automation Standards; IEC 61499; IEC 61131; Function Block
Diagram
1. Introduction
Industrial automation systems have been based for many
years on the IEC 61131 standard [1], which was first
published in 1992. The standard, which is considered as
one of the most important ones in industrial automation
[2], defines a model and a set of programming languages
(part 3) for the development of industrial automation
software [3]. Control engineers predominantly use it to
specify the software part of their systems, mainly when
programmable logic controllers (PLCs) are used [4]. The
languages of the standard are also successfully used for
the development of hard real-time systems in the Indus-
trial domain [5]. Research groups, e.g., [6,7], have pre-
sented model based approaches targeting on this standard
to improve the engineering process of industrial automa-
tion systems. PLCOpen [8] provides considerable sup-
port for the use of the language in several domains and
products, i.e., motion control libraries [5]. However, the
standard has been criticized the past few years for not
addressing any more the requirements of today’s com-
plex industrial automation systems and not being com-
pliant with state of the art software engineering practices.
For example, it is claimed in [9] that current software
architectures of industrial process measurement and con-
trol systems (IPMCS), such as IEC 61131-3, do not con-
ceptually support reconfiguration and distribution. In
addition, as claimed in [10], the concepts of 61131 “are
not the state of the art in software engineering anymore”,
even though not explicitly stating which concepts the
standard does not support and which of the supported
ones are not any more state of the art. On the other side,
portability, configurability, interoperability, reconfigura-
tion, and distribution have been identified in [9] as the
high-level demands/requirements for future automation
systems.
To address restrictions as well as new challenges in the
development of industrial automation systems, the Tech-
nical Committee 65 of the International Electrotechnical
Commission (IEC TC65) was assigned the task of de-
veloping a new standard. IEC 61499 [11], which is the
result of this work, has been promoted in the literature as
the solution that would address restrictions and chal-
lenges in the industrial automation development process.
For example: a) In [9], the 61499 is presented with the
following main features: “component-oriented building
blocks called FBs, graphical intuitive way of modeling
control algorithms through the connection of FBs, direct
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
406
support for distribution, interaction between devices of
different vendors, and basic support for reconfiguration,
and it is based on existing domain standards”. b) In [12],
the IEC 61499 is considered to have emerged in response
“to the technological limitations encountered in the cur-
rently dominating standard IEC 61131”. It appears as a
new programming paradigm that is going to replace the
IEC 61131, which is already established and widely used
in industry. c) Several publications in prestigious jour-
nals promote the use of 61499 as an enabler of distrib-
uted and intelligent automation, e.g., [13], or multi-agent
control software architectures, e.g., [14]. d) Modern soft-
ware engineering methodologies have been adapted, ac-
cording to [10], with IEC 61499, to the domain of Indus-
trial automation. More specifically it is claimed that re-
quirements such as flexibility, adaptability, or robustness,
which are not successfully addressed by existing design
methods, are successfully fulfilled by the IEC 61499.
However, as claimed in [4], the IEC 61499 was not
adopted by industry since “industrial deployments are
still in the early phases of experiments and feasibility
studies”. This is admitted even by its supporters. For ex-
ample in [10], it is admitted that “the majority of control
device vendors and users (e.g., control engineers) still
cannot appreciate the advantages of using IEC 61499”,
but this is ascribed to the “many misconceptions of the
standard’s ideas and contradicting conclusions of the re-
searchers on the role and place of the standard in future
industrial automation”. Misconceptions are based, ac-
cording to [10] on one of the first books on the IEC
61499, i.e., [15], which is based on the first draft version
of the standard. In the same paper, even though it is rec-
ognized that there is a lack of comprehensive case studies
comparing the overall benefits and drawbacks of both
technologies, several drawbacks of the IEC 61131 are
presented based on bird’s eye view and IEC 61499 is
promoted as a new paradigm that addresses these draw-
backs. Moreover, the claim that IEC 61499 “combines
several technologies, targeting portability, configurability
and interoperability of automation systems” [13], is not
substantiated.
On the other side, IEC 61499 is criticized, e.g., [16-18],
for its inability to address its objectives, i.e ., the chal-
lenges in industrial automation systems development.
Authors in [18] argue that “the standard is ambiguous
and different implementations of the standard have made
different assumptions to cope with the ambiguities”. This
has as result, according to [18], the same application to
behave differently when it is executed on different im-
plementations, “thus making the applications unportable”.
Moreover, even its strong supporters, including the task
force leader of the corresponding working group of IEC
61499, have admitted that “even stricter and more precise
provisions are required in order to achieve the main goals
of the IEC 61499 standard that are portability, (re)con-
figurability, interoperability, and distribution” [9].
This paper focuses on the arguments used in the IEC
61499 related literature and presents a number of misper-
ceptions that are used in its comparison with IEC 61131.
It is claimed that the positives of IEC 61499 provide mi-
nor contributions compared to the negatives introduced
by the new standard. Based on this study, it is claimed
that IEC 61499 does not provide a solid background to
switch from the widely accepted IEC 61131, since 61499
introduces more problems in the development process of
industrial automation systems than the ones it promises
to address. In this study, the requirements context for fu-
ture automation system defined in [9] and [10] is adopted.
This context focuses on portability, configurability, inter-
operability, reconfiguration, and distribution. Our pres-
entation is based on misperceptions that are used in past
comparisons to promote the use of IEC 61499 based on
restrictions of the IEC 61131. More specifically, the fol-
lowing misperceptions are presented and discussed in
this paper:
1) A misperception related with reuse;
2) A misperception related with portability;
3) A misperception related with interoperability;
4) Three misperceptions related with the event driven
nature of IEC 61499.
Other misperceptions, not addressed in this work, in-
clude among others: The object-oriented misperception,
the architecture-centric development misperception, the
system-level language misperception and the intelligent
automation misperception.
The remainder of this paper is organized as follows: In
Section 2, a brief introduction of the basic concepts of
the two standards is given. In Section 3, the reuse mis-
perception is presented and discussed. Section 4 presents
and discuss the portability misperception. In Section 5,
the interoperability misperception is presented. Three
misperceptions related with the event driven model of
IEC 61499 are discussed in Section 6 and the paper is
concluded in the last section.
2. Basics of IEC 61131 and IEC 61499
Figure 1 presents the Up-Counter Function Block (FB)
as defined in IEC 61131 [1]. The interface of the FB in
graphical notation is shown in (a), while the body is pre-
sented in (b) in textual format. The body of FBs or pro-
grams can also be described in graphical notation using
Function Block Diagram (FBD). Instances of FB types
and Functions are interconnected to form FBDs to
graphically specify the behavior of programs and FBs.
Nodes of the FBD graph are interconnected using one
type of connection which does not specify the type of
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions 407
(a) (b)
Figure 1. Up-counter 61131 function block. (a) Graphical
representation; (b) FB body in ST language.
information that flows from one end to the other. The
direction of the flow is defined from the convention that
outputs are shown on the right side of the FB while in-
puts on the left side. IEC 61131 supports also encapsula-
tion of data and event driven execution of FBs and pro-
grams.
IEC 61499 discriminates between event and data con-
nections. Figure 2 presents the same behavior with the
one captured in Figure 1, expressed as 61499 FB as de-
fined in IEC 61499 [11]. It should be noted that the two
inputs of type BOOL, i.e., CU and R, are handled as
event inputs for the 61499 FB, and two new output
events are added, i.e., CUO and RO. Output events notify
the environment of the FB that the corresponding behav-
ior has been executed and the output values are available.
It should be noted that the event initiating FB is not able
to utilize the result output values of the triggered behav-
ior during the current execution of the FBN. This is valid
even in the case that the event connection would be char-
acterized as synchronous and implemented using method
call, as is the case of FBDK [19].
Input events are used for the definition of Boolean ex-
pressions that trigger the transitions of the Execution
control chart (ECC) of the FB, as shown in part b of Fig-
ure 2, and “may affect the execution of one or more al-
gorithms” [11]. More specifically an EC transition shall
have “an associated Boolean condition, equivalent to a
Boolean expression utilizing one or more event input va-
riables”. Output events are issued on completion of algo-
rithms execution.
The transformation of the behaviors captured as FBs in
61131 has not been re-organized following the OO para-
digm but it has mainly done based on the separation of
event and data interface provided by 61499. An example
of this is the string manipulation FBs of 61131 that have
been converted to corresponding 61499 FBs (see FBDK)
without following the OO paradigm as is the case of
string management functions of C and the corresponding
String class of Java.
The question today, seven years after the publication
of the first version of the IEC 61499, is, if this standard
has successfully fulfilled its objectives. In this paper, it is
claimed that the view provided by the academic com-
munity, i.e., that the standard has successfully addressed
the challenges of reusability, portability, interoperability,
and event-driven execution, is unsubstantiated.
(a) (b)
(c) (d)
Figure 2. Up-counter 61419 function block. (a) Graphical
representation; (b) Execution control chart; (c) Reset algo-
rithm; (d) Count up algorithm.
3. Reuse
Misperception 1: The Reuse Misperception
The design process in most engineering disciplines is
based on reuse, since the development of new products is
based, for several reasons, on modules/components that
have been tried and tested on other systems. Reusability
concerns not only small components but also major sub-
systems [20]. This is also the case for software develop-
ment where reuse is always a major concern since it does
not only reduce the development cost but it may increase
system reliability and reduce the development process
risk. The benefits from the reuse of abstract products of
the development process may be greater than those from
the reuse of code components. Moreover, industrial auto-
mation code contains low-level detail which usually spe-
cializes it to such an extent that it cannot be reused with
different hardware. Design artifacts are more abstract and
hence more widely applicable. Four levels of reuse are
considered in [20]: application system reuse, sub-system
reuse, module or object reuse and function reuse. Reuse
at application level is highly related to portability, i.e.,
the ability of the application to be ported on several dif-
ferent platforms.
All the above are the reasons that reuse is considered
in almost any comparison of IEC 61131 with IEC 61499.
However, there are several misconceptions regarding re-
use and this section attempts to bring some light into this
matter. Arguments used as drawbacks for reuse on IEC
61131 include among others:
a) The support of global data that is provided by IEC
61131;
b) The absence of explicit control on the execution order
of IEC 61131 FBs in an application;
c) The vendor-specific extensions;
d) The vendors’ partial support of the standard.
More specifically, the first two of them. i.e., a and b,
are considered in [10] as the two main drawbacks that
hinder reuse in IEC 61131, even though it is recognized
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
408
that the encapsulation of application parts offered by the
standard helps to modularize control applications and
foster the reuse of application parts. Argument b is also
expressed in [10] by claiming that “the same application
may work differently on different control devices”. Ar-
guments c and d are used in [10] in the author’s claim
that the direct reuse of developed control software ele-
ments is not really possible in IEC 61131-3 due to the
vendor-specific extensions or only partial support of the
standard.
Regarding the first argument, i.e., a, it is claimed that
“there is no global data in IEC 61499” and that “there are
no means to access or change an FB’s internal variable as
it was possible in IEC 61131-3 with the access path me-
chanism”. However, it is the responsibility of the devel-
oper to effectively utilize the language constructs to ob-
tain reusability at module, object or function level. It is
widely known that the use of global data restricts reus-
ability at these levels but it is also known that reusable
objects can be developed in C++ and other languages
which provide support for global data. Moreover, the
public keyword is extensively used in OO languages to
allow direct access to the internal variables of objects;
access is also possible through accessors and mutators.
These features are not an indication that these languages
hinder reuse.
Regarding the second argument, it is claimed in [10]
that “In an IEC 61331-3 control system, the execution or-
der is derived from the connections between FBs, accord-
ing to the rules defined in IEC 61131-3 ([11], p. 249ff.).”
and also that “These rules leave some room for interpre-
tation; therefore, the same application may work differ-
ently on different control devices”.
However, it should be noted that the 61131 languages
allow for the explicit definition of the execution order of
FB instances, with the only exception being the graphical
representation of the FBD. But even in this case, all com-
mercially available tools address this problem by adopt-
ing a notation that allows the developer to explicitly spe-
cify the execution order. Furthermore, the problem can
be addressed in the graphical representation in a similar
way with the one adopted in the graphical representation
of expressions in the C programming language to explic-
itly define the evaluation order (see abstract syntax tree).
Moreover, it is not mentioned that the IEC 61499 stan-
dard completely fails in defining execution semantics and
that the existing IEC 61499 execution environments, com-
mercial and academic, have completely different execu-
tion semantics, making the reuse of any 61499 artifact
impossible on other execution environment. This is re-
ported in [18] where it is claimed that the same applica-
tion behaves differently when it is executed on different
implementations, “thus making the applications unport-
able”. This is also claimed in [12], according to which
the IEC 61499 standard “does not provide formal seman-
tics for the execution of function blocks” but instead it
contains “a verbose description for function block execu-
tion, which has resulted in multiple interpretations”. In
the same paper, it is also recognized that the same design
may behave “differently when executed on the various
existing runtime environments, such as FBRT [4], RTSJ-
AXE [5], FORTE [6], Fuber [7], and ISaGRAF [8]”.
Finally, regarding the last two arguments, i.e., c and d,
it is clear that no one may prevent the IEC 61499 vendors
to implement vendor specific extensions or partially sup-
port the standard, as is the case today with all the existing
execution environments. So, these two arguments cannot
be seriously considered in a comparison.
From all the above it is evident that there are no seri-
ous arguments on the advantage of 61499 compared to
61131 regarding reusability. Moreover, it should be noted
that the upcoming version of 61131 with its object ori-
ented extension provides better mechanisms for reusabil-
ity, through the constructs of class and interface and the
keywords extends and implements [21].
4. Portability
Misperception 2: The Portability Misperception
Portability is defined as the ability of a system to run
under different computing environments, hardware and/
or software. In other words it is the ease with which be-
havior can be moved from one system to another. This
means that portability is a prerequisite for reuse across
different computing environments. It should be noted
that there is a difference between portability at source
code level (edit-time) from portability at executable code
level (run-time). For example, bytecodes in Java provide
support for portability at executable code level.
Several journal publications present the IEC 61499
standard as enabling portability in the industrial automa-
tion domain. For example, portability is considered in
[22] as the first benefit that comes from the use of IEC
61499 to the deployment to distributed embedded targets.
FBs are considered to be “portable and have platform-
independent execution semantics”. It is also claimed that
the standard “provides a portable high-level executable
specification framework for distributed automation”. The
same is claimed in [23] where IEC 61499 appears to of-
fer a number of “flexibility provisions for distributed
control system which are not available in IEC 61131-3
PLCs”. Among them, portability of IEC 61499 function
block-based design is mentioned as a convenient way to
reuse functionalities of nodes. In [24] it is claimed that
IEC61499 “enables encapsulation, portability, interoper-
ability, and configurability”. In [25], it is claimed that it
is not easy to have an IEC 61131 program to “run on a
PLC of some other vendor”, while for IEC 61499 it is
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions 409
claimed that it offers “several semantic and syntactic pro-
visions for portability”. The use of XML to specify the
design artifacts is presented, in the same paper, as the
mean on the syntactic level “which enables easy ex-
change of source files between tools of different vendors,
as well as interaction of tools with devices of different
vendors”.
In this paper, it is claimed that the feature of portabil-
ity of IEC 61499 is unsustainable. Regarding the argu-
ments presented in [25], it is not explained how the fea-
tures of the standard, which are mentioned as semantic
provision of IEC 61499 towards portability i.e., encapsu-
lation of data, the event driven nature of FBs and their
composability, influence portability. Moreover, regarding
the mentioned semantic provisions, it should be noted
that IEC 61131 supports encapsulation of data, and event
driven execution of FBs and programs. It also supports
composability in a similar way with IEC 61499 since a
function block network can be used to specify the body
of a Program or FB [21]. Furthermore, PLCopen XML
allows the generation of portable designs based on 61131
and this is already supported by commercial tools [6]. On
the other side, there are no two IEC 61499 tools available
in the market that are able to exchange 61499 designs,
preserving the same semantics. This is also admitted in
[10] which accepts that the weak semantic-related de-
scriptions in IEC 61499-1, have been interpreted differ-
ently by different execution environments. This has re-
sulted, according to the authors, in having the same ap-
plication to behave differently on different execution en-
vironments. And this was the main reason that O3neida
is currently developing a compliance profile defining the
execution behavior of 61499 run-time environments.
However, this cannot be considered as an argument to
claim that 61499 supports portability.
The absence of formal semantics for the execution of
function blocks is also reported in [12], where the au-
thors claim that the standard contains a verbose descrip-
tion for function block execution, which has resulted in
multiple interpretations. Moreover, author admit that this
“hampers portability (defeating the purpose of a stan-
dard)”. As authors claim in [9] “stricter and more precise
provisions are required in order to achieve the main goals
of the IEC 61499 standard” among which portability.
Moreover, portability is one of the benefits of IEC 61499,
that has not been the major concern of the vendors yet,
even though this feature is “embedded” and hopefully
will be recognized in a short time span, as claimed in
[13]. In the same paper, it is also claimed that the IEC
61499 combines several technologies targeting portabil-
ity, without mentioning these technologies. Portability is
also considered as the main motivation for the event-
driven execution, that is characterized as “the desire to
make the code independent of the sequence of FB invo-
cation in the PLC scan loop”. Strong data encapsulation
into components is considered as another provision for
portability.
From the above, it is evident that portability cannot be
considered as advantage in the comparison of IEC 61499
with IEC 61131. As claimed in [26] the IEC 61499 FB
allows many different semantic interpretations that hin-
ders the portability of the automation software.
5. Interoperability
Misperception 3: The Interoperability
Misperception
Interoperability in its simple definition is the ability of
two or more systems to cooperate at runtime. Based on
[27] the following broader definition can be given for
industrial automation systems. Interoperability is defined
as the ability of heterogeneous devices (PLCs) to interact
towards mutually beneficial and agreed common goals,
involving the sharing of information and knowledge be-
tween them, through the behavior they support, by means
of the exchange of data.
As claimed in [23], IEC 61499 “aims at the flexibility,
interoperability, portability, and reconfigurability which
are not sufficiently supported in the IEC 61131-3 stan-
dard” and in this way it “provides the next generation
systems’ architecture enabling distributed control in au-
tomation industry”. The only argument used for interop-
erability is that “IEC 61499 Function Blocks are stored in
an open XML-based format” which “allows for better in-
teroperability between platforms as well as for greater re-
usability”. And the conclusion regarding interoperability
is that “Interoperability of IEC 61499 devices facilitate
the autonomous reasoning, distributed decision making
and negotiation between nodes”.
The use of XML is also mentioned as a mean for
achieving interoperability in [13] but this solution is con-
sidered as “not appropriate for many embedded plat-
forms” since “XML tools are quite performance hungry”.
It is also mentioned that a solution to this problem has
already proposed based on binary XML but this solution
“impacts on interoperability, as there are several different
versions of binary XML, supported by different user
groups” [13].
In [24] it is claimed that “IEC 61499-compliant de-
vices can easily interface with each other, thus providing
for seamless distribution of different tasks across differ-
ent devices” and since the user “may create his/her own
program using standard FB types”, the IEC61499 archi-
tecture “enables encapsulation, portability, interoperabil-
ity, and configurability”. The definition of interoperabil-
ity is also given as the ability of hardware devices to “op-
erate together to perform the cooperative functions speci-
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
410
fied by one or more distributed applications”. However,
it should be noted that it is admitted, at the end, that “the
industry standards necessary for universal interoperabil-
ity and cost reduction are very early works, which are in
progress”.
In [2] a detailed discussion on interoperability issues
regarding 61131 is given. Regarding IEC 61499, it is
claimed that it “offers the possibility to provide highly
integrated solutions with devices of multiple vendors”
though the mechanism of compliance profiles.” It is
claimed that these profiles, once defined, will allow any
differentiation, but these differentiations will be docu-
mented and consistently defined in the corresponding
compliance profiles. In a similar way, it is admitted in
[10] that the standard does not address the interoperabil-
ity requirement since it is quite natural that “the standard
cannot foresee upfront all the features of devices’ pro-
gramming, configuration, or communication that need to
be standardized. Instead, it defines a flexible and exten-
sible mechanism of compliance profiles” and it proposes
the definition of profiles to address interoperability. It
should be noted that, as admitted in [2], the practice up to
now “showed that the so advantageous sounding proper-
ties portability, configurability, and interoperability are
also not given a priori with IEC 61499”. Moreover, and
since “efforts toward portability, configurability, and in-
teroperability need the common work and specification
of a broad positioned user organization”, O3neida has
“dedicated itself as discussion platform” to achieve the
goals of the standard.
In [13] it is claimed that “The IEC 61499 standard
combines several technologies, targeting portability, con-
figurability and interoperability of automation systems”,
even though it is admitted that “portability and interop-
erability have not been the major concern of the vendors
yet” but as claimed “these features are “embedded” and
hopefully will be recognized in a short time span.
In [9] it is claimed that even though 61131-3 provides
a small basis for common modeling of control programs,
platforms and tools are not able to interoperate. Regard-
ing 61499, it is claimed that the investigation on interop-
erability showed open points in the definitions of the
standard for application modeling when executed on dif-
ferent devices and that “even stricter and more precise
provisions are required” in order to achieve the goal of
interoperability.
Currently there are no two IEC61499 execution envi-
ronments that support interoperability in the context of a
distributed application. From all the above, it is evident
that IEC 61499 does not provide support for interopera-
bility and there are no significant arguments to prove it.
A proposal to obtain interoperability in IEC 61499 based
systems is described in [28] using CORBA.
6. The Event Driven Nature of IEC 61499
Two different approaches to the design of the control me-
chanisms of real-time computer applications can be iden-
tified, depending on the type of triggering mechanism
used [29]:
1) Time-triggered control, and
2) Event-triggered control.
In time-triggered control, all activities are initiated by
the progression of real-time. In event-triggered control,
all communication and processing activities, are initiated
whenever a significant event other than the regular event
of a clock tick occurs. Both approaches can be used to
address a control problem assuming their correct realiza-
tion. As claimed in [17], “the same behavior should also
be ensured for the case of an event-based implementation
or a cycle-based one”, i.e., the design specification of
FB-based applications should be independent of the im-
plementation method used to interface with the con-
trolled process. The suitability of the IEC 61499 model
for event-driven control at the physical device level of
the shop floor is considered in [30] as the primary moti-
vation for its use. However, there are several mispercep-
tions in the IEC 61499 literature regarding the meaning
of event driven execution.
6.1. Misperception 4: Event-Driven vs. Scan
Based
There is a misperception regarding the relationship of the
terms event-driven and scan based execution. Scan based
execution is a term used to refer to time-triggered control
that is widely applied in 61131 based systems. For the
IEC 61499 it is not clear if the event driven nature refers
to the handling of external events or to the handling of
the internal ones. Most of the IEC 61499 journal papers
consider it as referring to the handling of the internal
events. Others relate it to the handling of externals. Both
categories refer the relation or mapping of the event
driven to the scan based.
Authors in [2] claim that “Choosing the event-driven
execution model of IEC 61499 or the cyclic execution
model of IEC 61131 is application-dependent”. Thus, the
event driven nature of IEC 61499 appears to offer a solu-
tion, or to be an alternative to the cyclic scan model
widely used in 61131.
Authors in [9] refer to a mapping from the event-based
IEC 61499 execution to a “cyclic, scan-based” system as
it is used in traditional programmable logic controller
(PLC) systems. The authors claim that: a) this mapping
allows a deterministic preverifiable execution behavior
and response times, and b) that the large overhead intro-
duced by the scan cycle is the main limiting point in scan
based systems and it results in larger overall response
time for the application. The authors also cite a paper that
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions 411
compares an event-based implementation of IEC 61499
with the scan-based execution model, which has been im-
plemented within the commercial tool ISaGRAF, and
shows that “events maybe lost in the event-based execu-
tion model”.
In practice, scan-based is nothing more than an imple-
mentation of polling. But this is also the case of the
61499 FBN shown in Figure 3, which is referred in the
61499 community as event based. Thus, it is clear that
regarding this subject the only difference is that the be-
havior is executed, in the 61131 case, by the thread of the
task to which this behavior is assigned, while in the case
of 61499 the behavior is executed by the thread of the
TankFB. But this later, raises the question of where to
assign the properties of this thread. The solution to define
them in the TankFB reduces its reusability since the de-
cision to implement it using periodic or triggered execu-
tion is captured in the FB. The 61131 approach sounds
more modular and preserves the application design mod-
el from implementation related issues.
6.2. Misperception 5: IEC 61131 Does Not
Support Event Triggered Control
There is a misperception created by many conference and
journal publications that the IEC 61131 does not support
event-triggered control. As claimed in [12] “the IEC
61499 standard has emerged in response to the techno-
logical limitations encountered in the currently dominat-
ing standard IEC 61131”, with one of these being the
cyclic scan model of computation, which is considered as
“severely inadequate to meet the current industry de-
mands for distributed, flexible automation systems”. It is
also claimed that in order to meet challenges, among
which the above, the IEC 61499 “has defined a new
event-driven model for function blocks intended for dis-
tributed execution”. In [9], it is claimed that the IEC
61499 “extends the FB model of its predecessor IEC
61131-3 with additional event handling mechanisms and
concepts for distribution”. In a similar way, it is claimed
in [31], that the IEC 61499 was initiated as an extension
of IEC 61131-3 Function Blocks by adding event driven
execution, to address limitations of the legacy PLC pro-
gramming languages.
Figure 3. IEC 61499 TankFB application with E_CYCLE.
However, the IEC 61131 standard supports both peri-
odic and event-driven execution of tasks and so the time
and event-triggered execution of the group of associated
with the task programs or FBs [32]. Scan-based is a term
used to refer to the use of periodic tasks for the execution
of the POUs that capture the behavior of the application
to an event or a set of events. In particular, Part 1, that is
entitled “General Information”, refers to two execution
control models, i.e., periodic and event-driven execution
of “a series of instructions stored in application pro-
gramme storage”. Part 3, that is entitled “Programming
Languages”, defines the task as an execution control ele-
ment which is capable of calling, either on a periodic
basis or upon the occurrence of the rising edge of a spe-
cified Boolean variable, a behavior expressed in the form
of a program or a function block.
6.3. Misperception 6: The Event Driven
Execution Misperception
It is consider that the objective of the event interface is
the explicit definition of the execution sequence of FB
instances in a Function Block Network (FBN). For exam-
ple in [33], the change from the “data-driven approach”
of IEC 61131 to the “event-driven approach” of 61499 is
considered as the second major change introduced by
IEC 61499. It is claimed that this offers the advantage to
the control engineer to explicitly specify the order of ex-
ecution in IEC 61499 applications though the additional
event connections. In a similar way, it is claimed in [10]
that the event interface “allows for explicit specification
of the FBs’ execution sequence” resulting to “a new level
of flexibility” for the developer, that is not offered in IEC
61131-3. As a result of this, 61131 FBs performing string
manipulations have been converted to 61499 FBs having
REQ and CNF events, as is the case with the string con-
catenation FB shown in Figure 4 [19].
In [13], it is claimed that the implementation of an
event-driven activation of function blocks “implies the
Figure 4. FB for concatenation of WSTRING inputs.
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
Copyright © 2013 SciRes. JSEA
412
possible need of storing events in queues of a variable
length and loss of events in case the queue capacity is ex-
ceeded”. This may lead, according to the author, to non
deterministic behavior that has been addressed by the
IEC 61499 community by several proposals such as the
synchronous model of execution, the cyclic model of
execution, and the ISaGRAF model, which is considered
as close to the cyclic. An “application-level practical so-
lution” is proposed towards this direction, to achieve the
determinism of event-driven applications. According to
this, external inputs are sampled periodically, using the
E_CYCLE FB, and delivered to the rest of the applica-
tion if any change is detected. This solution is presented
as “preserving the event-driven nature of the applica-
tion”. The author claims that this solution is different
from the PLC scan, since “the controller application exe-
cutes only when a change of any input is detected”.
Moreover, another benefit, according to [13], is that “the
event-driven execution also can help in activating only
those blocks which are directly dependent on that event,
unlike the PLC case, where all program modules are ex-
ecuted, which may result in “less time for execution even
in the worst case”. In the same paper, FBRT is referred
as a “pure” event-driven implementation platform, even
though it is well known that the FBRT implements the
event connections between FB instances using method
call. As claimed in [9] “the event-notification mechanism
is implemented as a simple function call”.
Moreover, IEC 61499 does not adopt an event trig-
gered approach to handle the external events. As claimed
in [9] “Up to now, there exist no mechanisms to intro-
duce any events into applications, which is a critical is-
sue. The responder SIFBs are so-called resource initiated
and they are special SIFBs that are triggered by an ex-
ternal event source (ES). Therefore, such specific SIFBs
generate events for applications. This means that an un-
derlying service (e.g., timing interrupt or network invo-
cation) activates the execution of FBs.” It also states that
external event sources “(e.g., timers) are mapped to own
Java threads”.
To analyze the misperception on the event driven ex-
ecution, the example FBN for the control of a pneumatic
cylinder, shown in Figure 5, is used. This example is
used in [25] and [34]. BUTTONS and LIGHT are imple-
menting the, what authors call, “resource-initiated ser-
vice model”, which means that “upon any change of the
source signal, e.g., light curtain status, the corresponding
FB is activated without any input event (…)”. POSI-
TION FB, on the other side, is activated periodically by
the pulse generator E_CYCLE FB. However, it is not
clear what is the nature of BUTTONS and LIGHT FBs.
It is mentioned that they are activated by the resource but
it is not known if the resource acts in a time-triggered or
event-triggered mode.
It should be noted that with a notation like this, FBs
have hidden interfaces and dependencies, which are not
shown in the design specification, i.e., external input and
output events are not shown on the application’s design
specification. Furthermore, it is questionable if the be-
havior to these dependencies is captured in their corre-
sponding ECCs.
It is also interesting to discuss the ECC of the CYL-
INDER_CTL FB, which is shown in Figure 6, as given
in [34]. Even though the semantics of this state machine
are not known, so it is unreadable, one may comment on
the difference on handling the INIT event from the other
events. There is a specific state, i.e., the WAIT one, to
model the time the state machine is waiting for an event
Figure 5. FBN with time-triggered and event-triggered control [25].
IEC 61499 vs. 61131: A Comparison Based on Misperceptions 413
Figure 6. FBN with time-triggered and event-triggered control [34].
input excluding INIT. The wait behavior is not modeled
as state in other cases, e.g., in states START, STOP or
ZONE0 and ZONE1. Moreover there are several states,
e.g., SELECT, that represent nothing. But the most im-
portant is that this state machine handles responses to the
SENS periodically activated event and also to events re-
sulted from interrupts, as claimed by authors, i.e., LIGHT
and BTN. And of course it is not obvious what is the be-
havior in case an interrupt occurs during the processing
of the SENS event or what is the behavior in case the
LIGHT interrupt occurs when the state machine is in
state ZONE0.
Moreover, it should be noted that even though the au-
thors use the E_CYCLE FB to implement in practice the
cyclic scan model of 61131, they consider and examine
on the same FBN the application of the cyclic scan mod-
el without excluding the E_CYCLE FB.
The misperception about the event driven model is
evident if the IEC 61499 Compliance Profile for Execu-
tion models, which defines according to [13] an execu-
tion model, is considered. The objective of this profile,
according to [35], which briefly describes it, is “to estab-
lish a draft compliance profile [18] for varying IEC61499
architectures and establish a means of ensuring compati-
bility in execution for future implementations of the stan-
dard”. Section 5.1 of this profile, identifies the need to
“have a predefined order before execution, such that dur-
ing the course of a scan, all FB’s within an FBN will al-
ways be invoked in the same order” [35]. This is ob-
tained by having the designer to assign a unique priority
to each FB of the FBN. This priority is actually defining
the execution order of the FB instances during every scan
cycle, i.e., “the tool invokes all the FB’s within a re-
source’s contained FBN in a fixed order (schedule)” [35].
ISaGRAF combines, according to [35], “the scan-based
logic execution of the IEC 61131 PLC standard, with the
EDI concept of 61499, known as the “Cyclic Execution
Semantics”, where EDI stands for event-driven invoca-
tion. In addition, as claimed in [10], the “event driven
IEC 61499 FBs are executed on top of a cyclic scanned
and time-triggered IEC 61131-3 run-time system”.
From the above it is clear that the execution model
proposed by the Compliance Profile is based on the key
concepts of the execution model of the IEC 61131 FBD.
This is in antithesis with the main objective of IEC
61499 and this is captured very well in [12], where it is
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
414
claimed that the IEC 61499 standard has emerged in re-
sponse to the technological limitations encountered in the
currently dominating standard IEC 61131, with one of
these being the cyclic scan model. In the same paper the
61131 model of computation is criticized as “severely
inadequate to meet the current industry demands for dis-
tributed, flexible automation systems”.
7. Summary
IEC 61499 has been proposed by IEC to address the re-
strictions imposed by the IEC 61131 standard in the de-
velopment of today’s demanding industrial applications.
The standard was highly promoted by the academic com-
munity as addressing requirements among which reus-
ability, portability, interoperability and distribution, which
are imposed by today’s complex industrial systems. Sev-
eral journal publications exploit these features of the IEC
61499 to propose it as new more robust and effective
platform for industrial applications compared to IEC
61131. However, as claimed in this paper, the advantages
related with these features are unsustainable on the com-
parisons with IEC 61131. A number of misperceptions
on these features are presented and discussed to show
that IEC 614499 does not define a platform that provides
considerable support for these features, i.e. reusability,
portability, interoperability and distribution. Arguments
used to show that IEC 61499 provides better support for
reuse, portability and interoperability are not existing or
they are very weak and the results of the comparisons
unsustainable. The event driven model of IEC 61499,
which is considered as enabling technology towards these
features is discussed in detail to identify and present
three misperceptions related with it. It has been shown
that 61499 cannot be considered as the effective succes-
sor of 61131, not even provide, at least with the current
version, a reliable alternative for the development of in-
dustrial automation systems.
REFERENCES
[1] International Electrotechnical Commission, “IEC Interna-
tional Standard IEC 61131-3: Programmable Controllers,
Part 3: Programming Languages,” IEC, 2003.
[2] A. Zoitl, T. Strasser, C. Sunder and T. Baier, “Is IEC
61499 in Harmony with IEC 61131-3?” IEEE Industrial
Electronics Magazine, Vol. 3, No. 4, 2009, pp. 49-55.
doi:10.1109/MIE.2009.934797
[3] A. Otto and K. Hellmans, “IEC 61131: A General Over-
view and Emerging Trends,” IEEE Industrial Electronics
Magazine, Vol. 3, 2009, pp. 27-31.
doi:10.1109/MIE.2009.934793
[4] P. Vrba, P. Tichý, V. Mařík, K. H. Hall, R. J. Staron, F. P.
Maturana and P. Kadera, “Rockwell Automation’s Holo-
nic and Multiagent Control Systems Compendium,” IEEE
Transactions on Systems, Man, and Cybernetics, Part C:
Applications and Reviews, Vol. 41, No. 1, 2011, pp. 14-
30. doi:10.1109/TSMCC.2010.2055852
[5] H. Carlsson, B. Svensson, F. Danielsson and B. Lennart-
son, “Methods for Reliable Simulation-Based PLC Code
Verification,” IEEE Transactions on Industrial Informat-
ics, Vol. 8, No. 2, 2012, pp. 267-278.
doi:10.1109/TII.2011.2182653
[6] E. Estevez and M. Marcos, “Model-Based Validation of
Industrial Control Systems,” IEEE Transactions on In-
dustrial Informatics, Vol. 8, No. 2, 2012, pp. 302-310.
doi:10.1109/TII.2011.2174248
[7] K. Thramboulidis and G. Frey, “Towards a Model-Driven
IEC 61131-Based Development Process in Industrial Au-
tomation,” Journal of Software Engineering and Applica-
tions (JSEA), Vol. 4, No. 4, 2011, pp. 217-226.
doi:10.4236/jsea.2011.44024
[8] PLCOpen, 2012. http://www.plcopen.org
[9] T. Strasser, A. Zoitl, J. H. Christensen and C. Sunder,
“Design and Execution Issues in IEC 61499 Distributed
Automation and Control Systems,” IEEE Transactions on
Systems, Man, and Cybernetics, Part C: Applications and
Reviews, Vol. 41, No. 1, 2011.
[10] A. Zoitl and V. Vyatkin, “IEC 61499 Architecture for
Distributed Automation: The ‘Glass Half Full’ View,”
IEEE Industrial Electronics Magazine, Vol. 3, No. 4,
2009, pp. 7-22. doi:10.1109/MIE.2009.934789
[11] International Electrotechnical Commission, “International
Standard IEC61499, Function Blocks, Part 1-4,” IEC,
2005.
[12] L. H. Yoong, P. S. Roop, V. Vyatkin and Z. Salcic, “A
Synchronous Approach for IEC 61499 Function Block
Implementation,” IEEE Transactions on Computers, Vol.
58, No. 12, 2009, pp. 1599-1614.
doi:10.1109/TC.2009.128
[13] V. Vyatkin, “IEC 61499 as Enabler of Distributed and
Intelligent Automation: State-of-the-Art Review,” IEEE
Transactions on Industrial Informatics, Vol. 7, No. 4,
2011, pp. 768-781. doi:10.1109/TII.2011.2166785
[14] M. Khalgui and H. M. Hanisch, “Reconfiguration Proto-
col for Multi-Agent Control Software Architectures,” IEEE
Transactions on Systems, Man, and Cybernetics, Part C:
Applications and Reviews, Vol. 41, No. 1, 2011, pp. 70-
80. doi:10.1109/TSMCC.2010.2064163
[15] R. Lewis, “Modeling Control Systems Using IEC 61499
—Applying Function Blocks to Distributed Systems,”
The Institution of Electrical Engineers, London, 2001.
[16] K. Thramboulidis, “IEC 61499 Function Block Model:
Facts and Fallacies,” IEEE Industrial Electronics Maga-
zine, Vol. 3, 2009, pp. 7-23.
doi:10.1109/MIE.2009.934788
[17] K. Thramboulidis, “IEC 61499: Back to the Well Proven
Practice of IEC 61131?” 17th IEEE International Con-
ference on Emerging Technologies and Factory Automa-
tion, Krakow, 17-21 September 2012.
[18] G. Cengic and K. Akesson, “On Formal Analysis of IEC
61499 Applications, Part A: Modeling,” IEEE Transac-
tions on Industrial Informatics, Vol. 6, 2010, pp. 136-144.
doi:10.1109/TII.2010.2040392
Copyright © 2013 SciRes. JSEA
IEC 61499 vs. 61131: A Comparison Based on Misperceptions
Copyright © 2013 SciRes. JSEA
415
[19] FBDK Web Page. http://www.holobloc.com/doc/fbdk/
[20] I. Sommerville, “Software Engineering,” 5th Edition,
Addison-Wesley Publishing Ltd., New York, 1996.
[21] K. Thramboulidis, “Towards an Object-Oriented Exten-
sion for IEC 61131,” 17th IEEE International Conference
on Emerging Technologies and Factory Automation (ET-
FA), Krakow, 17-21 September 2012.
doi:10.1109/ETFA.2012.6489673
[22] V. Vyatkin, H.-M. Hanisch, C. Pang and J. Yang, “Ap-
plication of Closed Loop Modelling in Integrated Com-
ponent Design and Validation of Manufacturing Automa-
tion,” IEEE Transactions on Systems, Man, and Cyber-
netics, Part C, Applications and Reviews, Vol. 39, No. 1,
2009, pp. 17-28.
[23] W. Dai and V. Vyatkin, “Redesign Distributed PLC Con-
trol Systems Using IEC 61499 Function Blocks,” IEEE
Transactions on Automation Science and Engineering,
Vol. 9, No. 2, 2012, pp. 390-401.
[24] N. Higgins, V. Vyatkin, N. K. C. Nair and K. Schwarz,
“Distributed Power System Automation with IEC 61850,
IEC 61499, and Intelligent Control,” IEEE Transactions
on Systems, Man, and Cybernetics, Part C, Applications
and Reviews, Vol. 41, 2011, pp. 81-92.
[25] V. Vyatkin, “The IEC 61499 Standard and Its Seman-
tics,” IEEE Industrial Electronics Magazine, Vol. 3, No.
4, 2009, pp. 40-48. doi:10.1109/MIE.2009.934796
[26] V. N. Dubinin and V. Vyatkin, “Semantics-Robust De-
sign Patterns for IEC 61499,” IEEE Transactions on In-
dustrial Informatics, Vol. 8, No. 2, 2012, pp. 279-290.
doi:10.1109/TII.2012.2186820
[27] European Commission, “European Interoperability Frame-
work (EIF) for European Public Services,” Bruxelles,
2010.
[28] K. Thramboulidis, D. Perdikis and S. Kantas, “Model
Driven Development of Distributed Control Applica-
tions,” The International Journal of Advanced Manufac-
turing Technology, Vol. 33, No. 3-4, 2007, pp. 233-242.
[29] H. Kopetz, “Real-Time Systems: Design Principles for
Distributed Embedded Applications,” 2nd Edition, Sprin-
ger, Berlin, 2011.
[30] R. W. Brennan, W. A. Gruver and K. H. Hall, “Foward-
Special Issue on Industrial Applications of Holonic Ma-
nufacturing Systems,” IEEE Transactions on Systems,
Man, and Cybernetics, Part C: Applications and Reviews,
Vol. 41, No. 1, 2011, pp. 1-3.
doi:10.1109/TSMCC.2010.2082410
[31] G. Black and V. Vyatkin, “Intelligent Component-Based
Automation of Baggage Handling Systems with IEC
61499,” IEEE Transactions on Automation Science and
Engineering, Vol. 7, No. 2, 2010, pp. 337-351.
doi:10.1109/TASE.2008.2007216
[32] H. Prahofer, R. Schatz, C. Wirth and H. Mossenbock, “A
Comprehensive Solution for Deterministic Replay De-
bugging of Soft PLC Applications,” IEEE Transactions
on Industrial Informatics, Vol. 7, No. 4, 2011, pp. 641-
651. doi:10.1109/TII.2011.2166768
[33] W. Lepuschitz, A. Zoitl, M. Vallée and M. Merdan, “To-
ward Self-Reconfiguration of Manufacturing Systems Us-
ing Automation Agents,” IEEE Transactions on Systems,
Man, and Cybernetics, Part C: Applications and Reviews,
Vol. 41, No. 1, 2011, pp. 52-69.
doi:10.1109/TSMCC.2010.2059012
[34] V. Vyatkin and V. Dubinin, “Refactoring of Execution
Control Charts in Basic Function Blocks of the IEC
61499 Standard,” IEEE Transactions on Industrial In-
formatics, Vol. 6, No. 2, 2010.
doi:10.1109/TII.2009.2033051
[35] P. Tata and V. Vyatkin, “Proposing a Novel IEC 61499
Runtime Framework Implementing the Cyclic Execution
Semantics,” Proceedings of 7th IEEE International Con-
ference on Industrial Informatics, Cardiff, 23-26 June
2009, pp. 416-421.