Int J Adv Manuf Technol (2007) 35:527–540
DOI 10.1007/s00170-007-1127-4
ORIGINAL ARTICLE
Automatic generation of PLC automation projects
from component-based models
Elisabet Estévez & Marga Marcos & Darío Orive
Received: 9 January 2007 / Accepted: 12 June 2007 / Published online: 18 July 2007
# Springer-Verlag London Limited 2007
Abstract Industrial process measurement and control sys-
tems (IPMCS) are used in most of the industrial sectors
to achieve production improvement, process optimization
and time and cost reduction. Integration, reuse, flexibility and
optimization are demanded to adapt to a rapidly changing and
competitive market. In order to achieve these goals, the use of
standards in the application field, methodologies for defining
the application design and tools for supporting the develop-
ment cycle are needed. This paper proposes a component-
based model of the implementation of the control system
under design (the hardware and software architectures). The
software architecture is defined to follow the software model
of the IEC 61131-3 standard for programming programmable
logic controllers and the hardware architecture is composed
by equipment characterised by vendor and range of product.
The proposed modelling is implemented as a markup
language that allows to describe models of industrial control
systems (icsML). From the application model, described in
the markup language, the automation project for every
programmable logic controller (PLC) present in the applica-
tion is automatically generated.
Keywords Industrial control systems . Component-based
modelling . Model-driven development . IEC 61131-3 .
XML technologies
E. Estévez (*) : M. Marcos : D. Orive
Department of Automatic Control and Systems Engineering,
University of the Basque Country,
Alda Urquijo S/N,
48013 Bilbao, Spain
e-mail: elisabet.estevez@ehu.es
M. Marcos
e-mail: marga.marcos@ehu.es
D. Orive
e-mail: dario.orive@ehu.es
1 Introduction
Industrial control systems are a special type of computer
system that control physical devices by means of control logic
and sequences. Besides, they usually have to respond to
external events coming from the environment they control.
They use programmable logic controllers (PLCs), industrial
communication systems (fieldbus), and dedicated I/O devices
to meet the operational requirements. As a computer system,
its design deals with the definition of the software architecture,
which implements the control strategies. Traditionally, each
control equipment vendor offered a development system
based on proprietary software architecture and programming
languages. To promote the use of standards for this application
field, international organisations are making a huge effort.
PLCOpen [1] was founded in 1992 and it is a vendor- and
product-independent worldwide association whose mission
is to be the leading association resolving topics related to
control programming to support the use of international
standards in this field. The International Electrotechnical
Commission (IEC) promotes open systems to be used in the
industrial control field. The IEC 61131-3 standard [2, 3]
proposes a software model and programming languages for
industrial process measurement and control systems
(IPMCS). Most of the PLC manufacturers are aiming to
become IEC 61131-3 standard compliant. PLCopen has
defined different compliance levels (base and conformity)
and many companies are certified. For instance, Schneider
Electric, Rockwell Automation ICS Triplex ISaGRAF,
Infoteam, KW Software, Mitsubishi Electric, Panasonic,
and Smart Software Solutions, among others. The Automa-
tion Alliance [4] is constituted by companies of the
automation industry such as ABB or WAGO, whose
hardware devices are all programmed with the same IEC
61131-3 programming system [5]. Most of them, among
other manufacturers, belong to the PLCopen organisation.
528
As the industry reaches a greater maturity level and
applications increase in complexity, a consolidation of
methodologies, which allow system description and definition
before its construction, becomes necessary. In [6], an
interesting review of the information systems and production
system environments is presented. It also shows how the
information system methodologies have been transferred to
production systems. The application of consolidated infor-
mation systems technologies and methodologies to produc-
tion systems is still a current practice. In this sense,
component-based software engineering (CBSE) is a relative-
ly new software engineering approach that has been proven
to be very powerful in the design of software intensive
systems [7, 8]. In [9] a component technology specifically for
field devices is proposed. Other interesting work is described
in [10], where a model for prediction and consistency
checking of extra-functional properties relevant to distributed
real-time control-systems is developed and implemented.
This paper deals with applying the CBSE concepts to
define a component-based approach as applied to industrial
control systems. Components and connectors for defining
the hardware and software architectures are identified, as
well as the composition rules they must fulfilled in order to
describe industrial control applications. The component-
based approach is implemented as a markup language.
XML technologies [11, 12] have been used not only for
defining the elements of the language but also for
implementing the check rules that assure the fulfilment of
the constraints imposed by the architectural style. Finally,
related XML technologies are used for filtering, processing
and formatting the complete application model in order to
generate the automation project for the target commercial
tool. Different cases arise depending on the target tool
storage format. The steps to follow and the different XML
technologies for every case are presented.
Section 2 is devoted to related work aiming at modelling
industrial control applications. In Sect. 3, a novel approach
for modelling industrial control application is proposed, in
terms of hardware and software components and connec-
tors. In Sect. 4 a markup language for describing such type
of applications is proposed. Section 5 details the automatic
generation of the automation project from the application
model. Finally, the conclusions section points out future
extensions of this work. In particular, the use of other XML
technologies that could be used for developing a model
based framework aiming at integrating the tools involved in
the design of industrial control applications.
2 Related work
The component based strategy aims at managing complex-
ity, shortening time to-market, and reducing maintenance
Int J Adv Manuf Technol (2007) 35:527–540
requirements by building systems with existing components
and connectors. Some attempts have been done by different
authors towards the use of well-known modelling lan-
guages for designing industrial process measurement
control systems (IPMCS). [13, 14] propose the use of the
unified modelling language (UML) [15, 16] for specifying
components of control systems following the IEC 61131-3
standard. Both approaches apply Object-Oriented technol-
ogy to model industrial automation applications. However,
it is not clear if the resulting models are analysed in terms
of consistency of POUs (program organization units)
functionality modelled in UML. Furthermore, the papers
do not explain if these models could be imported from a
PLC programming tool in order to download the automa-
tion project onto the target. In [17] a model-based approach
is proposed that uses two views to describe the design of
manufacturing systems: the conceptual view and the control
engineer view. They also use UML to guide the design of
the system. In particular, they analyse the system behaviour
before its implementation using the potentiality of UML
diagrams. But, they do not support automatic code
generation.
There are other works that focus on the design of
applications using the IEC 61131 standard. [18] proposes a
methodology for the analysis and modelling of discrete
event systems applied to the development of the control
logic based on the IEC 61131-3 standard. This methodol-
ogy is offered jointly with a tool that provides an IEC
61131-3 program expressing the execution control of the
application.
Related to distributed industrial control systems, the
evolving IEC 61499 standard [19, 20] is being discussed as
a successor of the IEC 61131 standard. Currently, there is a
great interest in analyzing the influence of the new standard
in industry, as well as its convergence with the IEC 61131-3
standard. Several groups are focussed their research in this
topic. [21] discusses the role of the IEC 61499 in the
factory automation and analyses the current on going
research by several groups. [22–24] describe a framework
called CORFU (common object-oriented real-time frame-
work for the unified development of industrial control
systems application) that defines an industrial process-
control protocol for the development, distribution, and
operation of such type of applications based on IEC 61499
Function Blocks. The design is object oriented and uses
UML to define a 4-layered architecture for designing such
type of systems [25].
There are very few commercial-off-the-shelf-tools that
are IEC 61499 compliant. In fact, only ISaGRAF® PLC
programming tool [26] announces it is.
However, nowadays most of the PLC manufacturers
offer programming tools that follow the IEC 61131-3
standard, and in most cases, they provide a proprietary
Int J Adv Manuf Technol (2007) 35:527–540 529

NODE

Node_1

Bus
Bus
16 bits

…
Node_2 Node_3
16 bits

1 0..∞ 0..∞ 0..∞ 0..∞ Segment - Connector:

Communication Boards
Power Memory I/O
Processor … Data - Connector:
Supply Card Card …
Connector in I/O Boards
Fig. 1 Hardware components and connectors

solution and protocol for distributed applications involving
their own PLCs.
What the IEC 61131-3 standard does not solve is the
interoperability among PLC programming tools that would
allow true software reuse. In this context, the PLCOpen
technical committee 6 [27] has selected the XML [28, 29]
to define a common language for transferring POUs written
in any of the five supported languages among IEC 61131-3
compliant tools. It has defined a global XML schema [11] for
defining automation projects with the elements defined in the
IEC 61131-3 software model. As the aim is to communicate
programming tools, it is not necessary to check for
consistency (the transferred code is supposed to be tested
in the source tool).
The goal of this paper is more general, as it proposes a
generic markup language specifying not only the elements but
also the composition rules. Thus, it uses the same elements but
imposing the constraints that define a valid IEC 61131-3
automation project. Besides that, the markup language not
only defines the software architecture but also the hardware
architecture, which is based on common elements and vendor
specific characteristics. Thus, the definition of this language in
XML not only allows description of industrial control
applications but also analysis for consistency in terms of the
fulfilment of the composition rules. These later are performed
by means of XML schematron rules [12]. These checks are
necessary because a model could be generated from other
tools than PLC programming tools, such us modelling tools
[30–32], as well as frameworks like CORFU and the other
tools commented above. Thus, it is necessary checking the
correctness of the model before the generation of the
automation project. Other interesting work is presented in
[33–35]. It deals with the use of XML for obtaining a formal
description of the code using finite state machines for the

Fig. 2 Relationships among

Func.
software components 0..∞
Block.
Configuration Resource Program 0..∞ Func
1..∞ 1..∞ Block
Function
0..∞
0..∞

Code execution
Task organization
530
(HW)
Global
variables (SW)
I/O (HW)
Programmable Logic Configuration
Controller (HW) (SW)
Fig. 3 relationships between hardware and software
instruction list language. This is complementary to the work
presented here, as the proposed schema could be integrated
in the markup language for the body of POUs in IL.
There are different XML technologies [36–39] that allow
getting information or setting it from/to the model. In [40]
an integration development environment is presented that
uses the markup language proposed in this paper as the core
to integrate the COTS tools for supporting the development
cycle of industrial control applications. In the same way, it
could be possible to integrate any of the development tools
mentioned above, as well as any PLC programming tool.
3 Component-based modelling of IPMCS
The component-based strategy aims at managing complexity,
shortening time-to-market, and reducing maintenance require-
ments by building systems with existing components. Primary
reasons for component production and deployment are
independency of components from their context; independent
component development, testing, configuration and later
reuse, as well as upgrade and replacement in running systems.
Generally speaking, software architectures are defined as
configurations of components and connectors. A compo-
nent is an encapsulation of a computational unit and has an
interface (e.g., port) that specifies the capabilities that the
component can provide. connectors encapsulate the ways
Fig. 4 General overview of the
industrial control system mark-
up language
Int J Adv Manuf Technol (2007) 35:527–540
CPU Resource Program Task
(SW)
PROGRAM ProgA TASK TaskB
VAR_INPUT ... INTERVAL...
CAL FB... PRIORITY...
PROGRAM ProgA WITH TaskB;
that components interact. A connector is specified by the
type of the connector, the roles defined by the connector
type, and the constraints imposed on the roles of the
connector. Components are connected by attaching their
ports to the roles of connectors.
Another important concept is the architectural style. An
architectural style defines patterns and semantic constraints
on a configuration of components and connectors. As such,
a style can define a set or family of systems that share
common architectural semantics [41].
A component-based approach to describe industrial
control systems consists of identifying the components,
connectors and the architectural style that allow describing
both, the hardware and software architectures of the
application. The model must be completed with the relation-
ships between the elements of both architectures, as they
represent the same system. For instance, if the hardware
architecture describes three different PLCs in the application,
the software architecture must describe three automation
projects, one for each PLC. Or if the code uses a variable that
represents a value from a sensor, the hardware architecture
must contain an input within an I/O board that matches in
type (BOOL, BYTE or other) with such variable. Otherwise,
the application model results incoherent.
The hardware architecture represents the electronic-
electrical engineering view. Thus, it deals with the physical
equipment that constitutes the control system. Typically
Int J Adv Manuf Technol (2007) 35:527–540
Fig. 5 General overview of eeEng_ML.xsd
controllers (PLCs) where the control code is executed, I/O
devices, used to monitor and command the process and bus
segment, in the case the instrumentation is distributed.
Usually, the controllers and the I/O devices are composed
by a set of boards: the power supply, the CPU, memory
cards, communication cards and others. Controllers and bus
segments are related by a communication board.
Fig. 6 Definition of nodes from a base XML element
531
On the other hand, the software architecture represents
the software engineering view and it implements the
functionality of the control system. As commented above,
the software model proposed by the IEC 61131 standard [2]
defines the software architecture of industrial control
systems. Briefly, the elements provided to define a control
application are the following: each PLC or Open PLC
532
Fig. 7 General overview of swEng.xsd
(manufacturer independent control system) is represented
by a configuration. It contains resources and tasks.
resources provide support for program execution while
tasks allow the designer to control the execution rates of
different parts of the program. Finally, resources also
contain programs, a type of program organisation unit
(POU) that executes code. The code could be written in any
of the five programming languages provided by the
standard and it makes use of function block and function
POUs. The former is the key POU for achieving software
reuse. POUs define and/or use variables, characterized by
their visibility, type and value.
3.1 Modelling elements of the electronic-electrical
engineering view
The hardware architecture description of a distributed
industrial control system can be described in two levels.
The first level is a global view that represents the high level
architecture by means of nodes interconnected by bus
segments. The second level describes each node by means
of the modules and boards that compose it. The Fig. 1
illustrates the main elements involved in the description.
In this domain view, components do not encapsulate a
computational unit, but they are used to characterise the
hardware equipment. They may contain information useful
for configuring the hardware during the application start-
up. The hardware components are bus segments, nodes and
Fig. 8 Checking the ProgInst
<xs:key name="POUId">
pouName value
<xs:selector xpath="sw:Types/sw:Pous/sw:Program"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:keyref name="refPOUid" refer="sw:POUId">
<xs:selector xpath="sw:Instances/sw:Configuration/sw:Resource/sw:ProgrInst"/>
<xs:field xpath="@pouName"/>
</xs:keyref>
Int J Adv Manuf Technol (2007) 35:527–540
boards, except the communication board, that represents a
type of connector. All components are characterized by the
manufacturer, serial number and firmware version. Every
type of component adds new characteristics. For instance,
the component that describes a bus segment is characterized
at least by the speed and the protocol of the OSI application
layer. It is also possible for a component to have character-
istics defined by the manufacturer.
Related to hardware connectors, there is one type for
each description level. Each communication board that
connects a node to a bus segment represents a segment-
connector. The so-called data-connector is used at the
second level diagram, and it represents data contained in I/
O cards. In particular, a data-connector is associated to each
byte in a digital card, or to each analogue channel. In both
cases, connectors are characterized by their relative address
in the card and their size. Figure 1 illustrates the hardware
components and connectors.
3.2 Modelling elements of the software engineering view
The software engineering domain components and con-
nectors correspond to the elements of the IEC 61131-3
standard software model. Two types of components are
considered: those that allow defining the architecture
(configuration, resource and task), i.e., they do not
represent a computational unit but they contain other
components that contain code or organise the execution of
Int J Adv Manuf Technol (2007) 35:527–540
Fig. 9 Schematron rule for
<rule context="sw:Task">
checking the sw:task
<assert test="(current()/@period and current()/@trigger)
or (not(current()/@period and current()/@trigger))" priority="high">
A task mus be periodic or by event
</assert>
</rule>
components containing code (POU). The latter type allows
the achievement of true reusability, but the former type
allows the definition of correct software architecture and
they are directly related to hardware components.
The software model also defines dependencies between
these components, as illustrated in Fig. 2. A configuration
represents the complete software architecture that correspond
to the PLC it represents. It contains at least one resource.
Each resource contains the executable, code structured in
programs. Optionally, they may contain tasks, that can be
activated by event or by time and that have a priority. The
periodic and sporadic execution is achieved by associating
programs and function block POU instances to tasks. In this
sense, all the programs and function blocks associated to the
same task execute at the same period and priority.
On the other hand, software connectors correspond to the
IEC 61131-3 variables and they represent the communica-
tion between software components. In fact, their visibility
identifies the components that are involved in the commu-
nication: VAR_ACCESS identifies the communications
between programs residing in different configurations.
VAR_GLOBAL at configuration level identifies communi-
cation between programs residing in different resources of
the same configuration. VAR_GLOBAL at resource level
identifies the communication between programs of the
same resource. Finally, VAR_LOCAL identifies the com-
munication among nested POUs [2].
3.3 Relationships between hardware and software views
The hardware and software architectures describe the same
control system from different point of view. Thus, they are
not independent. In order to represent a consistent applica-
tion, components and connectors in each view must be
related. In particular, a PLC must correspond univocally to
a configuration, a CPU is related to a resource and data-
connectors (representing a byte of digital I/O or an
analogue channel) are related to a global variable or a field
of a global variable, as Fig. 3 illustrates.
Finally, if the control system consists of more than one
PLC, the communication between them requires a rela-
tionship between each communication board (segment-
connector) and an IEC 61131-3 access variable (VAR_-
ACCESS) that contains the exchangeable information.
533
4 A markup language for describing ICSs
In this section, a markup language for describing industrial
control systems is proposed. It makes use of the software
and hardware components and connectors and implements
the composition rules. The markup language has been
defined as a XML schema (icsML.xsd)1 and it allows one to
define applications in terms of three XML schema elements
as illustrated in Fig. 4: the hardware architecture (eeEng),
the software architecture (swEng) and the mappings
between components and connectors in both views.
The electronic-electrical engineering XML schema
element is illustrated in Fig. 5. As commented above, an
ICS is composed by at least one processing node that can
have distributed I/O. The connection between a processing
node and its I/O or among processing nodes is described by
means of a bus segment.
In order to define the node and bus components, the
extension mechanism is used as illustrated in Fig. 6a. The
common characteristics are defined as a basic type
(genericComponent). New types that add other character-
istics are defined for the genericBus and genericBoard.
The different type of boards (IO, power supply,
processor, memory card, ...) are defined by means of a
type that extends the generic board type.
A node is defined as a set of boards. Figure 6b illustrates
the definition of a processing node from Siemens manu-
facturer. It is composed by a set of boards: the power
supply, the processor, a memory card and a communication
card. All of them extend the basic characteristics of the
boardTypes of Fig. 6a.
Repositories organised by manufacturer and range of
product could be used to achieve hardware maintainability.
The software engineering XML schema element illus-
trated in Fig. 7 is defined by the following constraints and
composition rules imposed by the IEC 61131-3 software
model.
The description of the software architecture has two
main parts: one containing the types (data and POUs)
defined by the programmer and used by the application
(sw:Types), and the other containing the automation project
1
A prototype can be found at http://www.disa.bi.ehu.es/gcis/projects/
merconidi/ics_ML
534 Int J Adv Manuf Technol (2007) 35:527–540

Fig. 10 TIME data type in XML <xs:simpleType name="TIME">

schema
<xs:restriction base="xs:string">
<xs:pattern value="(T|t|TIME|time)(#\d*\p{P}?\d*d)"/>
<xs:pattern value="(T|t|TIME|time)(#\d*d\d*\p{P}?(_)?\d*(h|m|s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*d\d*\p{P}?(_)?\d*h\d*\p{P}?(_)?\d*(m|s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*d\d*\p{P}?(_)?\d*m\d*\p{P}?(_)?\d*(s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*d\d*\p{P}?(_)?\d*s\d*\p{P}?(_)?\d*ms)"/>
<xs:pattern value="(T|t|TIME|time)(#\d*h\d*\p{P}?(_)?\d*(m|s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*h\d*\p{P}?(_)?\d*m\d*\p{P}?(_)?\d*(s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*m\d*\p{P}?(_)?\d*(s|ms))"/>
<xs:pattern value="(T|t|TIME|time)(#\d*m\d*\p{P}?(_)?\d*s\d*\p{P}?(_)?\d*ms)"/>
...
</xs:restriction>
</xs:simpleType>

itself (sw:instances). This separation of concerns was first
proposed by the TC6-XML group of PLCopen. The work
presented here proposes three main changes to the original
proposal: firstly, each type of component identified in
Sect. 3 within the IEC 61131 software model is defined as a
XML schema element. Thus, some elements in the
PLCOpen TC6 schema become attributes in the new
proposal. Secondly, a SimpleType of a XML schema
element is defined for each elementary data type of the
IEC 61131-3 standard. This allows one to check the
correctness in default values of variables. Finally, in order
to assure that the architectural style for describing an
automation project is followed, XML schema key-keyref
elements as well as schematron rules have been used to
assure consistency. These modifications are necessary if
other tools, such as modelling, configuration or documen-
tation tools may generate or consume part of the model.
The configuration component (sw:configuration) is char-
acterized by its connectors or variables (global and access)
and at least by one resource component. This latter is also
defined by its connectors (global variables), optionally by
task components and at least by one POU instance of
program type. Figure 8 illustrates a key/keyref example for
assuring that the value of the POUName attribute within
each program instance (sw:ProgInst) is one of the applica-
tion POUs defined within the Types element (sw:Types).
Figure 9 illustrates an example of a schematron rule that
checks if a task component is defined as periodic or by
event. One and only one attribute is required.
On the other hand, the software architecture connectors,
the variables, are characterized by their visibility (global or
access), type and initial value. In this sense, and in order to
check the correctness of the initial value, the data types
considered as elementary by the standard [42] have been
defined in XML. The data types are characterized by their
Fig. 11 Checking the correctness
period value of IEC 61131-3 <task name=“task_1" priority="8" period="00:00:01.0“/>
task
<task name=“task_1" priority="8" period="T#1s0ms“/>
range of values and by their representation patterns. The
definition of the elementary data types in XML is illustrated
in Fig. 10 through the definition of the TIME data type.
Figure 11 illustrates the definition of a task instance of
priority eight and period one second. The period has to be
expressed using the TIME type format. The first example
uses other representation pattern (TIME_OF_DAY type)
and the XML parser will raise an error.
Additionally, a set of schematron rules for checking
cross reference values have been developed.
The third XML element of the icsML schema represents
the relationships between components and connectors of the
hardware and software architectures, as illustrated in Fig. 12.
A set of 39 composition rules have been implemented in
order to assure that the industrial control application
conforms to the constraints of the architectural style: 33
correspond to composition rules of the hardware and the
software architectures themselves and the other six assure
consistency between the hardware and software architec-
tures (in terms of mappings between both architectures).
These latter have been implemented as part of the icsML
XML schema using the key-keyref elements [43] jointly
with schematron rules. Figure 13 illustrates an example. In
this case, it corresponds to a mapping between a hardware
component (processing node) and a software component
(configuration). Using the key-keyref XML schema ele-
ment, one is assured that both elements exist. A schematron
rule allows the assurance that this mapping is unique.
5 Generation of the automation project
One possible application of the proposed modelling is the
use of the model for automatically generating the automa-
tion project in the target PLC programming tool. Other
It does NOT follow IEC 61131-3 TIME data
type pattern format
It follows IEC 61131-3 TIME data type pattern
format
Int J Adv Manuf Technol (2007) 35:527–540
Fig. 12 Definition of the relationship between hardware and software components and connectors
related XML technologies are useful to achieve this goal. In
particular, those that allow extracting, filtering, processing and
formatting the information contained in the application XML
file. In particular, the extensible stylesheet languageXML
technology [44] consists of a language for transforming
XML documents [36], and a XML vocabulary for specifying
formatting semantics, XSL-FO [37]. Other technologies such
us document object model (DOM) [38] and simple API of
XML (SAX) [39] are very useful for generating XML files
or for manipulating XML files.
Figure 14 illustrates the sequence of actions to be carried
out for each PLC/configuration defined in the application
XML file.
First of all, it is necessary to add the information that the
tool expects (every tool has its own characteristics related
to the definition of an automation project). This adaptation,
transforming a XML file to another XML file with different
content and/or structure, could be performed by means of
the XML stylesheet, 2Tool.xsl of Fig. 14. It processes the
input file, adds the tool dependent information and
generates the file Tool.xml. From this XML file, the
automation project for the target tool can be generated.
The following sub-sections describe the two possible
situations that arise depending on the capabilities of the
PLC programming tool to import/export information.
key/keyref schema elements
<xs:key name="configurationId">
<xs:selector xpath="sw:swEng/sw:Instances/sw:Configuration"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:keyref name="refConfigurationId" refer="ics:configurationId">
<xs:selector xpath="rel:relationships/rel:Component_ee_sw"/>
<xs:field xpath="@configuration"/>
</xs:keyref>
<xs:key name="nodeId">
<xs:selector xpath="ee:eeEng/ee:Node/ee:ProcessingNode/*"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:keyref name="refNodeId" refer="ics:nodeId">
<xs:selector xpath="rel:relationships/rel:Component_ee_sw"/>
<xs:field xpath="@node"/>
</xs:keyref>
Fig. 13 A configuration must correspond univocally to a processing node
535
5.1 The tool offers import/export option
Commonly, every tool allows one to import/export part of an
automation project stored in its database. The format usually is
a kind of structured text whose structure is tool dependent.
However, since PLCopen TC6 XML defined the PLCopen
XML interface to support communication between PLC
programming tools, it is possible to find tools that offer XML
import/export. Depending on the import/export option (struc-
tured text or PLCopen XML); the steps to follow to obtain the
automation projects from the application.xml are different.
If the programming tool imports/exports projects or part
of them from/to structured text, the processing must not
only add the tool dependent information, but also transform
the xml file into structured text that the tool expects and
vice versa (case a of Fig. 14).
Figure 15 illustrates this case for the CoDeSys program-
ming tool from Automation Alliance [4]. This tool allows
exporting/importing the application POUs or the overall
software architecture to/from a structured text file with .exp
extension. The input file is the application.xml that follows
the icsML language. The XML stylesheet developed
(2CoDeSys.xsl) adds the tool dependent information and
gives as output file the structured text expected by
CoDeSys. To perform these transformations two different
Schematron rules
<rule context="rel:Component_ee_sw">
<assert test="count(@configuration)='1'" priority="hight">
configuration only could correspond to a one and only one node
</assert>
<assert test="count(@node)='1'" priority="hight">
node only could be associated to a one and only one configuration
</assert>
</rule>
536
Fig. 14 Steps to generate the automation project depending on the tool import/export option
types of XSL templates have been used: match that
contains the processing to be applied to a particular XML
element. This processing could be organised by means of
the so-called name templates, that allows structuring the
transformation. Table 1 lists the set of templates.
<xsl:template match="*" mode="POU"> 1
<xsl:variable name="type">
<xsl:call-template name="pouType"/>
</xsl:variable>
<xsl:value-of select="$type"/>
<xsl:text> </xsl:text><xsl:value-of select="@name"/>
<xsl:apply-templates select="sw:Interface"/>
<xsl:apply-templates select="sw:Body"/>
<xsl:text>END_</xsl:text><xsl:value-of select="$type"/>
</xsl:template>
<xsl:template name="pouType"> 2 <xsl:text>VAR_INOUT</xsl:text>
<xsl:if test="contains(name(),'Program')">
<xsl:value-of select="'PROGRAM'"/></xsl:if>
<xsl:if test="contains(name(),'FunctionBlock')">
<xsl:value-of select="'FUNCTION_BLOCK'"/></xsl:if>
<xsl:if test="contains(name(),'Function')">
<xsl:value-of select="'FUNCTION'"/></xsl:if>
</xsl:template>
4 </xsl:if>
<xsl:template match="sw:Variables">
<xsl:for-each select="./*/*">
<xsl:value-of select="@name"/><xsl:text> : </xsl:text>
<xsl:value-of select="substring-after(name(),'sw:')"/>
</xsl:for-each>
</xsl:template>
Fig. 15 Templates for generating the interface of the POUs
Int J Adv Manuf Technol (2007) 35:527–540
As an example of the use of XML stylesheets, Fig. 15
shows the involved templates that read the application
XML and generate the interface of all the POUs defined
within the application. In this case, the output is a text file
following the CoDeSys structure. Four templates are used:
<xsl:template match="sw:Interface"> 3
<xsl:if test="sw:Variables[@visibility='in']">
<xsl:text>VAR_INPUT</xsl:text>
<xsl:apply-templates select="sw:Variables[@visibility='in']"/>
<xsl:text>END_VAR</xsl:text>
</xsl:if>
<xsl:if test="sw:Variables[@visibility='out']">
<xsl:text>VAR_OUTPUT</xsl:text>
<xsl:apply-templates select="sw:Variables[@visibility='out']"/>
<xsl:text>END_VAR</xsl:text>
</xsl:if>
<xsl:if test="sw:Variables[@visibility='inout']">
<xsl:apply-templates select="sw:Variables[@visibility='inout']"/>
<xsl:text>END_VAR</xsl:text>
</xsl:if>
<xsl:if test="sw:Variables[@visibility='external']">
<xsl:text>VAR_EXTERNAL</xsl:text>
<xsl:apply-templates select="sw:Variables[@visibility='external']"/>
<xsl:text>END_VAR</xsl:text>
<xsl:if test="sw:Variables[@visibility='local']">
<xsl:text>VAR</xsl:text>
<xsl:apply-templates select="sw:Variables[@visibility='local']"/>
<xsl:text>END_VAR</xsl:text>
</xsl:if>
</xsl:template>
Int J Adv Manuf Technol (2007) 35:527–540 537

Table 1 list of templates of 2CoDeSys.xsl stylesheet

Templates Characteristics

<xsl:template match="ics:IndustrialControlSysten"> It acts as a main function

<xsl:template match="sw:Eng"> It selects the SW architecture
<xsl:template match="sw:DataTypes"> It generates the derived data types
<xsl:template match="*" mode="POU"> It identifies the application POUs
<xsl:template name="pouType"> It returns the POU type
<xsl:template match="sw:interface"><xsl:template match="sw:Variables"> They generate the POU interface
<xsl:template match="sw:Body"><xsl:template match="sw:FBD">... They generate the POU functionality or body. There is a
template for each programming language
<xsl:template match="sw:Configurarion"><xsl:template match="sw: They generate the automation project structure as defined
resource"><xsl:template name="globalVars"><xsl:template match="sw: in CoDeSys tool
task"><xsl:template match="sw:ProgInst">

two for declaring the POU with the corresponding reserved
tags; other template for generating the interface; and the last
template for characterising the name and the type of each
formal parameter of the POU.
Note that the content of the generation templates imple-
ments the processing needed to obtain a text file under-
standable by the target tool.
On the other hand, if the PLC programming tool can import /
export a project from/to an xml file, for instance following the
interface defined by PLCopen TC6 XML, the transformation is
from icsML XML file to XML (case b.1 of Fig. 14). Thus, the
XML stylesheet must add the tool dependent information and
give to the resulting XML file the particular structure for the
target PLC programming tool. Two examples of commercial
tools that support XML import/export are MULTIPROG4.6®
(a PLCopen TC6 XML compliant tool) from KW Software
and Unity® from Schneider manufacturer.
In particular, the automatic generation of the automation
project from the application.xml file to Multiprog4.6® PLC
programming tool is developed by means of the 2PLCOpen.
xsl stylesheet. It is composed by a set of templates, one for
each IEC 61131-3 software element. It adds to the resulting

Fig. 16 swEng template for <xsl:template match="sw:swEng">

adding the manufacturer depen-
dent information
<xsl:element name="project">
<xsl:element name="fileHeader">
<xsl:attribute name="companyName"><xsl:value-of select="'KW-Software'"/></xsl:attribute>
<xsl:attribute name="companyURL"><xsl:value-of select="'www.kw-software.com'"/></xsl:attribute>
<xsl:attribute name="productName"><xsl:value-of select="'MULTPROG'"/></xsl:attribute>
<xsl:attribute name="productVersion"><xsl:value-of select="'4.7'"/></xsl:attribute>
<xsl:attribute name="creationDateTime"><xsl:value-of select="@modificationDateTime"/></xsl:attribute>
</xsl:element>
<xsl:element name="contentHeader">
<xsl:attribute name="name"><xsl:value-of select="@name"/></xsl:attribute>
<xsl:attribute name="version"><xsl:value-of select="'1160655546'"/></xsl:attribute>
<xsl:attribute name="modificationDateTime"><xsl:value-of select="concat(substring-
before(@modificationDateTime,' '), 'T',substring-after(@modificationDateTime,' '))"/></xsl:attribute>
<coordinateInfo>
<pageSize x="999" y="999"/>
<fbd><scaling x="2" y="2"/></fbd>
<ld><scaling x="2" y="2"/></ld>
<sfc><scaling x="2" y="2"/></sfc>
</coordinateInfo>
</xsl:element>
<xsl:element name="types">
<xsl:element name="dataTypes">
<xsl:apply-templates select=".//sw:dataType"/>
</xsl:element>
<xsl:element name="pous">
<xsl:apply-templates select=".//sw:pou"/>
</xsl:element>
</xsl:element>
<xsl:element name="instances">
<xsl:element name="configurations">
<xsl:apply-templates select=".//sw:configuration"/>
</xsl:element>
</xsl:element>
</xsl:element>
</xsl:template>
538
Fig. 17 The generation of the automation project for ISaGRAF tool
XML file the tool dependent information. Figure 16
illustrates as an example the template that reads from the
input file the root element (sw:swEng) and generates in the
output file the corresponding root element, project, adding
the multiprog tool dependent information (fileHeader,
companyName, companyURL, productName, productVer-
sion and so on).
5.2 Import/export through tool API
In order to illustrate the more common case (option b.2 of
Fig. 14), i.e., no support for XML import/export, two
Fig. 18 Generation of STEP 7 project
Int J Adv Manuf Technol (2007) 35:527–540
commercial PLC programming tools have been selected.
The first one is the ISaGRAF4.2® tool that, although being
IEC 61131-3 compliant, as far as authors know, it supports
neither the definition of tasks nor program instantiation.
Thus, it is necessary to apply a XML stylesheet in order to
perform the transformations needed to have an automation
project understandable by the tool (ISaGRAF.xml file): no
task definition and resources characterised as cyclic,
periodic (characterised by the period and the priority) or
sporadic (characterised by the event that activates it). The
stylesheet unifies the program definition and instantiation in
the resulting file and it also defines as many resources as
Int J Adv Manuf Technol (2007) 35:527–540
tasks with different period (if the periods are not harmon-
ics). Finally, an application is developed that gets infor-
mation from the ISaGRAF.xml file and stores it in a
MS-Access™ database, which is the storage format for
ISaGRAF projects. This application makes use of DOM
which is very useful for getting information from a XML
file and entering it to the tool by means of its application
program interface. Figure 17 illustrates the template of the
stylesheet that looks for the tasks and for each task, it looks
for the programs and function blocks associated to it. Then,
it defines the necessary resources: one cyclic containing the
POUs not associated to tasks and the timed and by event
resources.
The second example illustrates the case of a tool having
a proprietary software model: the Simatic Administrator
from Siemens manufacturer. In this case, the processing that
the XML stylesheet must perform is more complicated, as
the software model of STEP 7 is different. Thus, besides
adding the tool dependent information, it also has to
convert the elements of the IEC 61131-3 software model
into STEP 7 elements.
Figure 18 illustrates the mapping proposed in this work
between the elements of both software models, as well as
part of the XML stylesheet that performs the commented
transformations. In particular, the programs not associated
to tasks are transformed to FCs to be executed in the
organisation block OB1. programs associated to tasks are
mapped to timed OBs.
6 Conclusions
This work has applied the concepts of CBSE to industrial
control systems applications. Two different views have
been identified as the domains involved in the design of
such type of systems. The concept of component and
connector drawn in CBSE has been used and adapted in
order to identify the different components and connectors,
its role in each domain, the relationship between the
different views as well as the composition rules for
describing the target applications. A markup language
(icsML) has been proposed. The implementation makes
use of XML schema and XML schematron rules technol-
ogies to implement the composition rules of the architec-
tural style. This allows the use tools other than PLC
programming tools for describing applications (UML-based
or scalar vector graphics-SVG-based) as coherency and
consistency checks are performed. This markup language is
being used as the core of an integrated development
environment achieving a model based design. There are
other extensions to this work that include the interoperability
between PLC programming tools from different manufac-
turers achieving true reusability. It could be achieved making
539
use of XSL and SAX or DOM technologies to import, export
and transform the software architecture between different
PLCs. Finally, another focus of interest that is being
investigated is the use of graphical XML languages (SVG)
to add to the markup language an abstract layer that allow the
edition and test of the application design. The immediate
benefit of the work presented here is that industrial end users
could reuse control code in different PLCs from different
manufacturer.
Acknowledgements The authors gratefully acknowledge the finan-
cial support of the European Union’s Information and Science
Technologies programme for the FLEXICON project IST-2001-
37269 and MCYT&FEDER under projects DPI 2003-2399 and DPI
2006-4003.
Authors would line to thank the anonymous reviewers for their
valuable comments.
References
1. PLCOpen international Organization, available at: http://www.
plcopen.org/
2. Lewis RW (1988) Programming industrial control systems using
IEC 1131-3. IEE Control Engineering Series. 1998
3. John K-H, Tiegelkamp M (2001) IEC1131-3: programming
industrial automation systems. Springer
4. Automation Alliance, available at: http://www.automation-alliance.
com/
5. CoDeSys of Smart Software Solutions, available at: http://
www.3s-software.com/
6. Edan Y, Pliskin N (2001) Transfer of software engineering tools
from information systems to production systems. Computer and
Industrial Engineering 39:19–34
7. Crnkovic I, Schmidt H, Stafford J, Wallnau K (2005) Automated
component-based software engineering. J Syst Softw 1:1
8. Crnkovic I, Larsson M (2002) Building reliable component-based
software systems. Artech House publisher, ISBN 1-58053-327-2
9. Nierstrass O, Arevalo G, Ducasse S, Wuyts R, Black A, Müller P,
Zeidler C, Genssler T, van den Born R (2002). A component
model for field devices. In: Proceedings of the First International
IFIP/ ACM Working Conference on Component Deployment
10. Schmidt H (2003) Trustworthy components: compositionality and
prediction. J Syst Softw 65(3):215–225
11. XML schema, available at: http://www.w3.org/XML/schema
12. Rick Jelliffe schematron rules, available at: http://www.ascc.net/
xml/schematron/
13. Bonfé, Fantuzzi (2000) Mechatronic Objects encapsulation in IEC
1131-3 Norm. Proceedings of the 2000 IEEE Int. Conf. on C A,
pp. 598–603
14. Heverhagen T, Tracht R (2001) Integrating UML-RealTime
and IEC 61131-3 with function block adapters. Proceedings of
the IEEE International Symposium on OO RT Distributed
Computing
15. Jacobson I, Christerson M, Jonsson P, Övergaard G, (1992)
Object-oriented software engineering. Addison-Wesley
16. Rumbaugh J, Blaha M, Premerlan W, Eddy F, Lorensen W, (1996)
Object-oriented modelling design. Prentice Hall
17. Young KW, Piggin R, Rachitrangsan P (2001) An object-oriented
approach to an agile manufacturing control system design. Int J
Adv Manuf Technol 17:850–859
540
18. Gonzalez VM, Mateos F, Amos N (2003) MLAV. Object-oriented
methodology for the analysis and modelling of the control logic of
discrete event systems, SSGRR 2003
19. International Electrotechical Commision, IEC International Work
in Progress, IEC 61499-3 (2004). Function Blocks for Industrial
Process Measurement and Control systems. 2004
20. Lewis RW, (Robert W) (2001) Modelling control systems using
IEC 61499 Applying function blocks to distributed Systems. The
Institution of Electrical Engineers
21. Thramboulidis K (2005) IEC 61499 In Factory Automation. Int.
Conf. on Industrial Electronics, Technology&Automation
(CISSE-IETA 2005). December 2005
22. Thramboulidis K (2004) Developing a CASE tool for distributed
control application. Int J Adv Manuf Technol 24:24–31
23. CORFU Framework, available at: http://seg.ee.upatras.gr/corfu/
dev/index.htm
24. Thramboulidis K (2002) Development of distributed industrial
control applications: the CORFU framework. In Proc of 4th IEEE
International Workshop on Factory Communication Systems,
Vasteras, Sweden, August 28–30, 2002
25. Thramboulidis K, Tranoris C (2001) A function block based
approach for development of distributed IPMCS applications. In
Proc of the 10th IEEE International Conference on Advanced
Robotics (ICAR 2001), August 22–25, 2001, Budapest, Hungary
26. ISaGRAF, available at: http://www.isagraf.com/
27. PLCopen Technical Committee 6. Available at: http://plcopen.org/
TC6/XML_Intro.htm
28. XML, available at: http://www.w3.org/XML/
29. Pruitt et al (1998) Steve Pruitt, Doug Stuart, T.W. Cook. “The merit
of XML as an Architecture Description Language Meta-Language”.
Microelectronics and Computer Technology Corp, October 1998
30. Estevez E, Marcos M, Iriondo N, Orive D. Graphical Modelling
of PLC-based Industrial Control Applications. In Proc of the 26th
American Control Conference, New York, USA, July 2007.
Acepted for presentation
Int J Adv Manuf Technol (2007) 35:527–540
31. Estévez E, Marcos M, Sarachaga I,Orive D. A methodology for
multidisciplinary modeling of industrial control systems using
UML, In Proc of the 5th International Conference on Industrial
Informatics. Austria, Viena, July, 2007. Acepted for presentation
32. Kandare G (2001) Model-based software design for procedural
process control with programmable logic controllers. The 2nd Int.
PhD student workshop on systems and control, [COBISS.SI-ID
16409639]
33. Bani Younis M, Frey G. Visualization of PLC programs using
XML”. In Proc. of the American Control Conference (ACC2004),
Boston, USA, pp. 3082–3087, June 2004
34. Bani Younis M, Frey G. Formalization and visualization of non-
binary PLC programs”. Proceedings of the 44th IEEE Conference
on Decision and Control (CDC 2005) and European Control
Conference (ECC 2005) Seville, Spain, pp. 8367–8372, Dec. 2005
35. Bani Younis M, Frey G. UML-based approach for the re-
engineering of PLC programs”. Proceedings of the 32nd Annual
Conference of the IEEE Industrial Electronics Society, Paris,
France, pp. 3691–3696, November 2006
36. XSL available at: http://www.w3.org/TR/xsl
37. XSL-FO available at: http://www.w3schools.com/xslfo/default.asp
38. DOM: http://www.w3.org/DOM/
39. SAX http://www.saxproject.org/
40. Estévez E, Marcos M, Gangoiti U, Orive D (2005) A tool integration
framework for industrial distributed control systems”. In Proc of the
44th IEEE Conference on Decision and Control and European Control
Conference, pp. 8373–8378, CDC-ECC, Seville, Spain (2005)
41. Medvidovic N, Taylor RN (1997) Exploiting architectural style to
develop a family of applications. IEE Proc Software Eng 144(5–
6):237–248
42. International Electrotechnical Commission. IEC International
Standard IEC 61131–3:2003, Programmable Controllers, Part 3:
Programming Languages, 2003
43. Van der Vlist E (2002) XML Schema,. Ed. O’REILLY
44. Fidwell D (2001) XSLT. Ed O’REILLY