Journal of Software Engineering and Applications, 2011, 4, 217-226
doi:10.4236/jsea.2011.44024 Published Online April 2011 (http://www.SciRP.org/journal/jsea)
217
Towards a Model-Driven IEC 61131-Based
Development Process in Industrial Automation*
Kleanthis Thramboulidis1,2, Georg Frey2
1Electrical and Computer Engineering, University of Patras, Patras, Greece; 2Saarland University, Saarbrucken, Germany.
Received March 14th, 2011; revised March 24th, 2011; accepted March 27th, 2011.
ABSTRACT
The IEC 61131-3 standard defines a model and a set of programming languages for the development of industrial au-
tomation softwa re. It is widely accep ted by indu stry and most of the commercia l tool vendo rs advertise comp liance with
it. On the other side, Model Driven Development (MDD) has been proved as a quite successful paradigm in gener-
al-purpose computing . This was the motivation for exploiting th e benefits of MDD in the industrial automa tion domain.
With the emerging IEC 61131 specifica tion that defines an object-orien ted (OO) extension to the function block model,
there will be a push to the industry to better exploit the benefits of MDD in automation systems development. This work
discusses possible alternatives to integrate the current but also the emerging specification of IEC 61131 in the model
driven development process of automation systems. IEC 61499, UML and SysML are considered as possible alterna-
tives to allow the developer to work in higher layers of abstraction than the one supported by IEC 61131 and to more
effectively move from requirement specifications into the implementation model of the system.
Keywords: In d ustri al Aut o m a t i on Systems, Model Driven Development, IEC 61131, System Modeling, UML, SysML,
IEC 61499, Development Process
1. Introduction
The IEC 61131-3 standard [1] has been adopted by the
industry and is widely used by control engineers in speci-
fying the software part of systems in the industrial auto-
mation domain. However, it imposes several restrictions
for the development of today’s complex systems. There is
a trend to exploit best practices from the desktop applica-
tion domain. Object orientation, component based deve-
lopment and model driven engineering are among these
widely accepted best practices. Several research groups
are already working to this direction, e.g., [2-5]. Standar-
dization is also following this trend. The IEC 61499 stan-
dard [6] is considered as an extension of IEC 61131, to
address among others object oriented (OO) concepts and
the IEC 61131 working group is currently discussing an
Object-Oriented extension to the standard [7].
Model Driven Development (MDD) was widely ac-
cepted as a successful paradigm in the desktop domain.
The key issue in MDD is that models have become pri-
mary artifacts of software design, shifting much of the
focus away from program code. Thus MDD refers to “a
set of approaches in which code is automatically or semi
automatically generated from more abstract models, and
which employs standard specification languages for de-
scribing those models and the transformations between
them” [8].
According to this definition the use of the Function
Block Diagram (FBD) graphical programming language
of IEC 611131-3 in the specification of the design model
of the controller’s software and its subsequent automatic
translation to executable code for the target PLC platform,
characterizes the development process as model driven,
at least partially. Moreover, existing tools provide support
for code generation for several execution platforms. This
leads to the following question: what is all this research
about defining MDD approaches based on IEC 61131-3
and 61499, in the industrial automation domain?
The drawback of the IEC 61131 FBD is that it provi-
des only one kind of diagram that can be used to constru-
ct the model of the application software. This diagram is
composed of FB instances and their interconnections. A
similar diagram is also found in IEC 61499. In this paper,
we refer to this diagram with the term Function Block
*The authors would like to thank Stifterverband für die Deutsche Wis-
senschaft and ME Saar for partially funding this project.

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 218
Network (FBN). The FBN is used in the FBD language
to model the structure and the behavior of Programs or
FBs. Taking into consideration now that the Unified Mo-
deling Language (UML) and the Systems Modeling Lan-
guage (SysML) use several diagrams for the definition of
the application’s structure and behavior, it is clear that the
one diagram used by IEC 61131 is not enough to cons-
truct a reliable and expressive model for the application
software. This means that all discussion about an MDD
approach based on 61131 has to do with the use of more
diagrams to allow:
1) more abstract models to be constructed, and
2) more aspects of the system to be captured in order
to have a more complete and comprehensible model of
the system.
In this paper, IEC 61499, UML and SysML are consi-
dered as candidate notations to address this challenge. In
a first step the IEC 61131 FBD notation is analyzed from
the viewpoint of the object oriented paradigm. This is a
prerequisite in order to have a sound and clear understan-
ding of the OO concepts supported by the 61131 FBD
notation. It will also simplify the process of mapping this
notation to the three other notations that are examined in
this paper. Instead of what is widely believed, IEC 61131
has already introduced in the industrial automation do-
main, at least at the specification level, basic concepts of
the OO paradigm.
The Festo MPS laboratory system, a well documented
system used by many universities for research and educa-
tion purposes, is used as a running example in this paper.
It is composed of three units. The Distribution unit, which
is composed of a pneumatic feeder and a converter, for-
wards cylindrical work pieces from a Stack to the Testing
unit. The Testing unit performs checks on work pieces for
height, material type and color. Work pieces that suc-
cessfully pass this check are forwarded to the rotating
disk of the Processing unit, where the drilling of the work
piece is performed as the primary processing of this sys-
tem. The result of the drilling operation is next checked
by the checking machine and the work piece is forwarded
for further processing to another mechanical unit. A de-
tailed description of the system, as well as a design of the
control application based on the IEC 61499 can be found
in [9].
The remainder of this paper is organized as follows:
Section 2, presents the related work on using UML and
SysML. In section 3, the IEC 61131 FBD notation is exa-
mined in detail from the object oriented viewpoint. The
focus is on structure and behavior definition of Function
Block type and Function Block network. In Section 4, we
consider the potentials of using IEC 61499, UML and
SysML towards a more effective MDD process based on
the IEC 61131 FBD notation. The paper is concluded in
the last section.
2. Related Work
There are already several works that try to integrate IEC
61131 with UML and SysML. Vogel-Heuser, et al. in [10]
describe the automatic generation of IEC 61131 code ex-
pressed in Structured Text (ST) and Sequential Function
Chart (SFC) from UML 1.4 diagrams. Class diagrams are
used to capture the structure of the application, while state
charts are considered similar to SFCs and they are used to
capture the behavior. The authors do not map the UML
class to FB directly but instead they propose a complex
implementation of the class concept using nested FBs.
Furthermore, the object oriented view of the FB construct
is not exploited and the FB diagram is considered as a
diagram to capture behavior.
Ramos et al., in [11] describe an OO environment they
have developed for the development and implementation
of distributed process control systems. This environment
is based on the integration of UML with IEC 61131 and
Simulink. They use class diagrams and statechart diagra-
ms to create the requirements model of the application
and they implement a mapping of SFC to UML state-
charts. In fact they use UML as an intermediate model in
their transformation from Simulink and IEC 61131 to
Java code.
Sacha in [12] describes an approach that allows the de-
veloper to model the behavior using UML state charts
which are verified using UPPAAL, a model checking tool
for timed automata. These state charts are then automati-
cally transformed to an IEC 61131 program for STEP 7.
This work does not give any focus on the structural aspe-
cts of the application and does not use scenario and ac-
tivity diagrams that provide a more effective modeling
process for the behavior, when used in combination with
state charts.
A UML specialization for process automation (UML-PA)
is presented by Katzke, et al., in [13]. The authors pro-
pose the use of only six UML diagrams for the modeling
of the system and the use of IEC 61131 languages to de-
scribe the actions in UML state charts. However, a speci-
fic mapping between these six UML diagrams and the
corresponding IEC 61131 code is not given.
SysML is evaluated in [14] by Chiron et al., as a mod-
eling notation for programmable logical controllers. Even
though the authors propose the use of block definition
diagram (bdd) of SysML to represent structure, they con-
sider the internal block diagram (ibd) of SysML as the
proper diagram to represent the IEC 61131 FBN. They
use atomic flow ports to represent the interconnection
points of the FB with the environment, and the activity
diagram to represent the behavior. In the decomposition
process of the program they use the term task and this is

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 219
confusing for those that are familiar with IEC 61131. In
general the authors use the SysML to represent the appli-
cation design at the same level of abstraction as the one
presented using IEC 61131 FBD.
In all the above works, the authors do not exploit the
OO aspects of IEC 61131 which results into inefficient
mappings of UML and SysML to IEC 61131. We are not
aware of any work that exploits the OO view point of
IEC 61131 to propose an effective MDD process based
on UML or SysML.
3. IEC 61131: The OO Point of View
The FBD language of IEC 61131-3 has already introdu-
ced a few basic concepts of the object oriented program-
ming paradigm, in the automation domain. The FB con-
cept can be used to capture the structure and behavior of
a collection of objects (instances) that may be used in an
automation project. In the Festo MPS case study, the
Feeder FB is the software representative of the real world
feeder of the mechanical part of the laboratory system
into the software domain. Figure 1(a) presents the Feed-
er FB that captures the interface of the corresponding
software module, while Figure 1(b) presents its behavior
using SFC. Input variables are used to get the sensor va-
lues; output variables are used to affect the feeder’s actu-
ators; and internal variables are used to store the state of
the object.
3.1. The Function Block
The FB icon is a graphical representation, i.e., a view
element, of the FB concept and it can be considered as a
design time construct. There is also a textual construct to
represent this concept. The graphical representation of
the FB may be compared with the UML class design
construct and the textual one with the class construct of
OO languages such as Java and C++. It should be noted
that the IEC 61131-3 allows a mixing of various textual
and graphical languages to be used for the program spe-
cification which is not common in software engineering
notations. Common programming languages use mainly
only a textual representation, while UML or similar gra-
phical notations for modeling, are based mainly on gra-
phical symbols. In general, the Function Block (FB), (we
use the term FB for the function block type and the term
instance when we refer to an FB instance) may be consi-
dered as a special kind of class with several restrictions
but also extensions. In a similar way to the class, it has
a name; it defines the state of its instances using a set of
local variables, declared either textually or graphically;
and it defines the behavior of its instances through its
body. However, there are several differentiations regard-
ing:
1) Behavior
There is a restriction in the behavior definition; only
one method can be defined1 However, this method
usually captures all the different behaviors exhibited by
the FB instance in response to the various messages an
instance receives from the environment. This means that
there are no method signatures as in common OO lan-
guages; actually there is no signature even for this one
method defined by the FB body. This method is executed
when the FB instance is called. The call of the FB in-
stance depends on the language used, but in all the cases
at least the name of the FB instance followed by a list of
actual parameters is used. Based on this description of
the FB concept, the FB can be considered as a special
type of class that defines the behavior of its instances by
only one method. The specification of this method can be
given either in textual or in graphical notation. One or
more FBNs can be used to graphically specify the beha-
vior. The SFC is more convenient in the case that the FB
directly implements a state machine. In practice, com-
mercial tools do not support parallel branches of SFC in
FB specification, even though this is not defined by the
standard. If parallel branches of SFC are supported, the
IEC 61131 FB will be much more powerful construct
compared to the IEC 61499 FB. A comparison of the
semantics of SFC with those of the state chart is given in
[4]. A textual representation can also be used to specify
the behavior.
2) Structure
There are no formal parameters defined for the method
of the FB, but instead input and output variables are used
for this purpose. This means that input and output varia-
bles have semantics similar to the method formal para-
meters, even though they are defined along with local va-
riables as part of the structure of the FB instances. Input
and output variables may be considered analogous to the
flow ports defined by SysML, which constitute part of
the structure of the classifier. This means that UML ag-
gregation of type composite is supported by FBs. It
should be noted that it is not possible to define an FB va-
riable as public, so there is no direct access to the FB sta-
te variables from outside of the FB. Output variables may
be used to export state information.
3) Instantiation
Instantiation is not permitted during run time; all the
instantiations should take place during the deployment of
the part of the application that corresponds to the specific
FB diagram. An instantiation is forced on every variable
declaration of FB type. This means that only the compo-
site kind of aggregation, which is called PartAssociation
in SysML, is implemented. This kind of association im-
plies that the composite object is responsible for the exis-
1The OO extension of the FB construct that is under discussion in IEC
is not taken into account in this section.

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 220
(a)
(b)
Figure 1. IEC 61131 FB for the Festo MPS feeder: (a) interface, (b) behavior specification using SFC.

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 221
tence and storage of the composed objects, i.e., its parts.
4) Inheritance
Inheritance between FB types is not supported.
5) Interface
Interface definition is not supported.
3.2. The Function Block Network
The FBN is a design time artifact. Even though the FBN
can be considered as a structural specification diagram
like the composite structure diagram of UML 2.0 or the
internal block diagram (ibd) of SysML, it is actually used,
according to the standard, to capture the behavior of Pro-
grams and FBs. The closest UML diagrams that can be
compared with the FBN are the activity and collaboration
diagrams. However, the execution semantics of the FBN,
and more specifically those related to the execution order
and flow of control are quite different from the ones of
the above diagrams. Moreover, the level of abstraction
applied in FBN is lower compared to the level of abstrac-
tion of the UML diagrams. In the activity and collabora-
tion diagrams of UML, the execution order and flow of
control may be captured on the diagrams and explicitly
specified by the designer. On the other hand, there are
predefined execution semantics in FBN, such as the order
of calling functions or FB instances. It is the responsibil-
ity of the designer to ensure that the proposed design ex-
ploits properly the predefined execution semantics in or-
der to get the desired behavior. The FBN is analogous to
the abstract syntax tree generated by a C compiler to cal-
culate the value of an expression. Like the Activity dia-
gram, the FBN diagram captures the activities that have
to be performed and the flow of information between
these activities. An FBN that includes only FB instances
is more close to a collaboration diagram with the restric-
tion that every object has one method.
Message passing between the nodes of an FBN is not
realized in terms of method call that is the common me-
chanism for message passing in OO languages. In fact,
there are no method signatures, but just one FB method
which is activated when the FB instance is called. An FB
instance can be called by any Program Organization Unit
(POU) that has visibility access to it. The FB method is
executed on the specific instances structure, i.e., inputs,
state and output. The result is normally: 1) a new instan-
ce state that is captured in the instance’s internal varia-
bles, in the case of state depended behavior, and 2) a res-
ponse to the environment that is captured by the instan-
ce’s output variables and the value of the FB call. Messa-
ge passing between FB instances allocated in different
resources in the same configuration is implemented by
global variables (VAR_GLOBAL) of the configuration,
while between those allocated in different configurations
is implemented through access paths defined in configu-
rations with VAR_ACCESS.
4. Towards a More Effective Modeling
Process for IEC 61131
4.1. The Need for More Diagrams and for
Higher Levels of Abstraction in
Application Modeling
As it was stated above, the IEC 61131-3 FBD language
can be considered as a realization of the MDD paradigm
in the industrial automation domain. However, it can be
used to model the application to a very low level of abs-
traction, very close to the executable code. It does not al-
low the designer to capture in a graphical way all the
aspects of the application, as for example its structure.
Moreover, even though the execution semantics are well
defined and common for all the IEC 61131-3 compliant
execution environments, it is more informative for the
control engineer to have a graphical representation of this
information using sequence or activity diagrams. In this
case, these diagrams may be used even before the assign-
ment of the application activities to function blocks, al-
lowing a more flexible transition from the system re-
quirements to the application design specifications.
In order to increase the effectiveness of this MDD pro-
cess, more models should be exploited, e.g., to capture
the behavior, and also new ones more abstract should be
used, e.g., to support the definition of the structure of the
application. These models, if properly defined, would be
automatically transformed to the IEC 61131 FBD nota-
tion and finally to executable code for existing run-time
environments. In this section, three notations are consi-
dered as possible candidates for such an extension of the
IEC 61131-based modeling process:
1) the IEC 61499 function block model,
2) the UML, and
3) the systems modeling language SysML.
Moreover, it should be noted that the device centric
approach, which is currently used with the IEC 61131,
does not provide a strong request for higher layers of ab-
straction in the development process. However, this ap-
proach does not allow for the adoption of a synergistic
development process of the constituent parts of the au-
tomation system that is the current trend in Metchatronic
systems development [15], such as the industrial automa-
tion systems. The application centric paradigm, that is
proposed to better fit with the synergistic development of
the constituent parts of the automation system, is almost
impossible to be applied without special emphasis on the
architecture of the system. This is why UML and SysML
may be used as early specifications of the automation
system, during the development process, before the 61131
one. In [16] a detailed discussion, including examples, is

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 222
given on the limitations of IEC 61499 to be used as nota-
tion for architectural specification. On the other hand
UML and SysML are widely accepted as architecture
specification languages.
4.2. Using IEC 61499
The IEC 61499 FB model has been proposed by IEC as
an extension of the IEC 61131 FB one to exploit OO
concepts and address several other challenges in indus-
trial automation systems, such as interoperability, porta-
bi-lity, run-time reconfigurability, etc. However, even
though several researchers have published many articles
on the applicability of the new standard, e.g. [17], and
also on the migration from IEC 61131 to IEC 61449,
such as Gerber et al., in [18] and Hussain et al. in [19],
the industry has not yet made serious steps towards its
adoption [16]. When the first proposal for the Object-
Oriented extension of IEC 61131 FB model was presen-
ted by CODESYS, a debate has raised between the two
communities [20]. Does the industry need both standards
or the new version of IEC 61131 will officially denote
the abandonment of IEC 61499? Or, in other words, what
is the value added of IEC 61499 compared to IEC
61131?
In this subsection we assess the potential of using IEC
61499 to enhance the IEC 61131 development process.
Due to our assumption to be compliant with the execu-
tion semantics of IEC 61131 that includes execution of
the program based on cyclic or periodic mode, the events
of IEC 61499 FB, at least those that interconnect the
FBN with the controlled system, are useless. Based on
this, the main differences between IEC 61131 and IEC
61499 FB are:
1) The IEC 61499 uses the ECC to capture the dyna-
mic behavior of its instances. However, this is nothing
more than a graphical way of representing the IEC 61131
FB body that can also be done using SFC, as shown in
Figure 1.
2) The ability to specify in IEC 61499 the behavior to
incoming events as independent distinct algorithms (me-
thods). This allows for a more modular FB body but since
there is no support for inheritance there are no direct be-
nefits regarding reusability.
It should be noted that the restriction of IEC 61499 to
disallow a direct method call bypassing the ECC is con-
sidered very positive for this kind of systems. However,
the introduction of the algorithm scheduling function im-
poses a very heavy constraint on the Safety Integrity Le-
vel that can be obtained using IEC 61499.
The differences are more important when we consider
the FBNs. As already mentioned the IEC 61131 FBN is
used to model the behavior. The IEC 61499 FBN is quite
similar to the UML composite diagram or the SysML
internal block definition (ibd) diagram. It represents the
structure of the application or the composite FB and all
the possible interactions among them. Figure 2 presents
an FBN for the distribution unit of the Festo MPS exam-
ple application. As argued by Thramboulidis et al. in [21],
the FBN is not considered appropriate for behavior mod-
eling. This means that the IEC 61499 does not provide a
better way to capture the behavior of the application
compared to the IEC 61131. It is only the FBN that has
to be evaluated as a possible diagram to enhance the IEC
61131 development process. But as argued in [19], the
IEC 61499 is not considered as an effective architecture
specification language.
Based on the above analysis, the authors do not see
any valuable benefit in using IEC 61499 to enhance the
IEC 61131 development process. It does not provide di-
agrams for higher level of abstractions models, nor even
diagrams to effectively model the other aspects of the
application.
4.3. Using UML
It is evident that a specific UML class may be used to re-
present the IEC 61131 FB. Moreover, several UML dia-
grams can be used to create more abstract models of the
application, compared to the one supported by the IEC
61131 FBD. More specifically:
1) The UML composite diagram can be used to cap-
ture the structure of programs and FBs.
2) The state diagram can be used to capture the beha-
vior of programs and FBs.
3) The sequence and/or activity diagrams may be used
to model the behavior in terms of interactions between
FB instances, and to model the behavior of an enclosing
FB.
4) The class diagram may be used to represent the
structure of the PLC infrastructure.
5) The deployment diagram may be used as graphical
representation of a configuration.
To have a better exploitation of the above UML dia-
grams in the domain of IEC 61131, a UML profile may
be defined. This profile will contain stereotypes for the
main key constructs of IEC 61131. For example the spe-
cific UML class that will be used to represent the IEC
61131 FB will be a stereotype of this profile. This profile
will allow the industrial engineer to build the models
using already known constructs and at the same time to
work in the UML abstraction layer. This means that it is
possible to create the model of the application in more
abstract format compared to IEC 61131, while still using
the IEC 61131 basic terminology. Specific model-to-model
transformers are required to have an automatic transfor-
mation of the UML application specification to an IEC
61131 based one, which will be subsequently translated

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 223
Figure 2. IEC 61499 function block network for the Festo MPS distribution unit.
using existing tools to executable code for commercial
run-time environments. The definition of the meta-models
of the source and target domains, as well as the set of
mapping rules between them, is a prerequisite for this ap-
proach to be effectively implemented. A problem with
UML is that the class concept is specifically defined to
support the OO programming paradigm, so UML does
not provide inherent support for the procedural paradigm
that is also supported by IEC 61131. This is why SysML
is considered a better choice for building a more effective
higher layer of abstraction on top of IEC 61131.
4.4. Using SysML
The construct of block that is the basic static, structural
construct of SysML, is broader than the UML class. The
block can be used to represent the modular units of sys-
tem description. A block can define the “type of logical
or conceptual entity, a physical entity, a hardware, soft-
ware or data component, a person, a facility, an entity that
flows in the system or even entities from the environ-
ment” [22]. This means that the block construct of SysML
may be used to represent not only an FB, but also a func-
tion and a configuration. The <<FB>> stereotype will be
used to represent the IEC 61131 FB and the <<Func-
tion>> stereotype will be used to represent the IEC 61131
function. In a similar way <<Program>> and <<Confi-
guration>> will be defined to represent a program and a
configuration respectively. The SysML block definition
diagram (bdd) can be used to capture the structure of
configurations, programs and also FBs that may accept
FB instances as input variables. Figure 3 shows the bdd
for the Distribution Unit block of the Festo MPS mod-
eled in SysML. It consists of a Feeder FB instance, a
Converter FB instance and an FB instance of type Dis-
tributionUnit, that coordinates these.
The same diagram presents also the interfaces of Fee-
der and Converter, as well as the flow specifications for
the interactions of real world feeder and converter with
the corresponding FB instances. The SysML internal blo-
ck diagram (ibd) can be used to capture the interconnec-
tions among the constituent parts of constructs, such as
configurations, programs and also FBs that may accept
FB instances as input variables.
The sequence diagram can be used to capture the inter-
actions of the system components in the context of a par-
ticular operation of the system. The SysML sequence
diagram, shown in Figure 4, captures the interaction of
the system components in the context of the reaction of

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 224
Figure 3. SysML block definition diagr am (bdd) for the festo MPS distribution unit.
the control application to the sensor event frontPosRea-
ched that comes from the corresponding sensor of the
mechanical Feeder.
From SysML design diagrams as the ones shown in
Figures 3 and 4, using proper model-to-model transfor-
mers, we may get the corresponding IEC 61131 design
diagrams for the application. In this way SysML can be
used to provide a completely graphical environment for
modeling control applications in a higher and also more
expressive layer than the one already supported by IEC
61131 market tools. This profile can be developed from
scratch or more effectively based on an existing profile in
the embedded real-time systems domain, such as the
MARTE profile [23]. Assuming that the corresponding
profile will be standardized, this approach will result in a
uniform way of modeling industrial automation software
that will hide the proprietary individual characteristics of
IEC 61131 tools at the modeling layer.
5. Conclusions
The IEC 61131-3 standard has already introduced in the
industrial automation domain basic concepts of the OO
paradigm, even though these are not widely exploited in
practice by existing development tools. It has also intro-
duced the use of graphical notations, i.e., the use of mod-
els, in the development process. The FBD language is an
attempt to use graphical models in the development pro-
cess that is one of the basics of model driven develop-
ment paradigm. However, the FBD notation does not
support modeling at high levels of abstraction, that is
required when the size and complexity of the application
is increasing. Moreover, it does not allow the modeling
of all aspects of the application.
We have discussed, in this paper, three notations as
candidates to address the increasing size and complexity
of industrial applications. IEC 61499, UML and SysML
were examined for possible integration with IEC 61131
to increase the effectiveness of the IEC 61131-based de-
velopment processes. IEC 61499 does not provide any
valuable benefit in enhancing the IEC 61131 development
process. UML may be successfully used, but SysML
seems to better match the semantics of IEC 61131. With
a proper profile, SysML can be used to define a comple-
tely graphical environment that will allow the industrial
automation developer to create the model of the applica-
tion and automatically transform it to IEC 61131 speci-
fication. This integration may also hide the proprietary
individual characteristics of IEC 61131 market tools at

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 225
Figure 4. SysML Collaboration diagram for the reaction of the Feeder unit to the frontPos-
Reached signal of the corresponding Feeder sensor.
the modeling layer and result in a uniform modeling no-
tation.
REFERENCES
[1] International Electrotechnical Commission, “IEC Interna-
tional Standard IEC 61131-3: Programmable Controllers,
Part 3: Programming Languages,” IEC, 2003.
[2] G. Doukas and K. Thramboulidis, “A Real-Time Linux
Based Framework for Model-Driven Engineering in Con-
trol and Automation,” IEEE Transactions on Industrial
Electronics, Vol. 58, No. 3, March 2011, pp. 914-924.
[3] D. Streitferdt, G. Wendt, P. Nenninger, A. Nyssen and H.
Lichter, “Model Driven Development Challenges in the
Automation Domain,” 32nd Annual IEEE International
Conference on Computer Software and Applications,
Turku, 28 July-1 August 2008, pp. 1372-1375.
[4] S. Panjaitan and G. Frey, “Combination of UML Model-
ing and the IEC 61499 Function Block Concept for the
development of Distributed Automation Systems,” 11th
IEEE International Conference on Emerging Technolo-
gies and Factory Automation, Prague, September 2006,
pp. 766-773.
[5] 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.
[6] International Electrotechnical Commission, “International
Standard IEC61499, Function Blocks, Part 1-Part 4,” IEC,
2005.
[7] B. Werner, “Object-Oriented Extensions for IEC 61131,”
IEEE Industrial Electronics Magazine, Vol. 3, No. 4,
2009, pp. 36-39.
[8] B. Selic, “From Model-Driven Development to Model-
Driven Engineering,” 19th Euromicro Conference on
Real-Time Systems, Pisa, 4-6 July 2007.
[9] K. Thramboulidis, “Design Alternatives in the IEC 61499
Function Block Model,” 11th IEEE International Confe-
rence on Emerging Technologies and Factory Automa-
tion, Prague, September 2006, pp. 1309-1316.
[10] B. Vogel-Heuser, D. Witsch and U. Katzke, “Automatic
Code Generation from a UML model to JEC 61131-3 and
System Configuration Tools,” International Conference
on Control and Automation, Budapest, 27-29 June 2005,
pp. 1034-1039.
[11] D. N. Ramos-Hernandez, P. J. Fleming and J. M. Bass,
“A Novel Object-Oriented Environment for Distributed
Process Control Systems,” Control Engineering Practice,
Vol. 13, No. 2, 2005, pp. 213-230.
[12] K. Sacha, “Verification and Implementation of Dependa-
ble Controllers,” 3rd International Conference on De-
pendability of Computer Systems DepCoS-RELCOMEX,
Szklarska Poreba, Poland, June 2008, pp. 143-151.
[13] U. Katzke and B. Vogel-Heuser, “Combining UML with
IEC 61131-3 Languages to Preserve the Usability of
Graphical Notations in the Software Development of
Complex Automation Systems,” 10th IFAC, IFIP, IFORS,
IEA Symposium on Analysis, Design, and Evaluation of
Human-Machine Systems, Seoul, September 2007.
[14] F. Chiron and K. Kouiss, “Design of IEC 61131-3 Func-
tion Blocks Using SysML,” Mediterranean Conference
on Control & Automation, Athens, 2007.
[15] K. Thramboulidis, “The 3 + 1 SysML View-Model in
Model Integrated Mechatronics,” Journal of Software
Engineering and Applications, Vol. 3, No. 2, 2010, pp.
109-118.
[16] K. Thramboulidis, “IEC61499 Function Block Model:
Facts and Fallacies,” IEEE Industrial Electronics Maga-
zine, Vol. 3, No. 4, December 2009, pp. 7-26.
[17] A. Zoitl and V. Vyatkin, “IEC 61499 Architecture for

Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation 226
Distributed Automation: The ‘Glass Half Full” View’,”
IEEE Industrial Electronics Magazine, Vol. 3, No. 4,
2009, pp. 7-23.
[18] C. Gerber, H. M. Hanisch and S. Ebbinghaus, “From IEC
61131 to IEC 61499 for Distributed Systems: A Case
Study,” EURASIP Journal on Embedded Systems, Vol.
2008, Article ID 231630, p. 8.
[19] T. Hussain and G. Frey, “Migration of a PLC Controller
to an IEC 61499 Compliant Distributed Control System:
Hands-on Experiences,” 21st IEEE International Confe-
rence on Robotics and Automation, Barcelona, 18-22
April 2005, pp. 3984-3989.
[20] K. Thramboulidis, “Τhe Function Block Model in Em-
bedded Control and Automation: From IEC61131 to
IEC61499,” WSEAS Transactions on Computers, Vol. 8,
No. 9, September 2009, pp. 1597-1609.
[21] K. Thramboulidis, G. Doukas and A. Frantzis, “Towards
an Implementation Model for FB-Based Reconfigurable
Distributed Control Applications,” 7th International
Symposium on Object-Oriented Real-Time Distributed
Computing, Viena, 2004, pp. 193-200.
[22] OMG, “OMG Systems Modeling Language,” V1.0,
September 2007.
[23] OMG, “A UML Profile for MARTE: Modeling and
Analysis of Real-Time Embeded systems,” Beta 2, June
2008.