MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 259

Abstract— The level of automation in factories and plants, and

the need for their fast development and customization, increases

steadily. Nowadays, industrial control applications are designed

and implemented by exploiting various techniques and approach-

es. Moreover, they are controlled by a plethora of heterogeneous

embedded hard- and software systems. These factors raise the

complexity of their development and the time required to conceive

them. The state-of-the art and foreseen trends in engineering for

the industrial automation still lack an efficient solution to circum-

vent the mentioned difficulties. An undergoing European project

tries to overcome this problem by an innovative component-based

approach wishing to automatically link the design and implemen-

tation phases of the development process. This document resumes

and analyses the results of a survey conducted among the indus-

trial partners of this European project. Arising is the lack of con-

nection between design and implementation, particularly in terms

of transformation rules.

Index Terms—Automation, Design Methodology, Industrial

Control, Programming.

I. INTRODUCTION

N the industrial automation sector there are many hardware

and software architectures to implement control applica-

tions, and various methods exist to tackle the design and de-

velopment activities. According to the application characteris-

tics, products like Computer Numerical Controls (CNC), Pro-

grammable Logic Controllers (PLC) or Distributed Control

Systems (DCS) can be used because they offer specialized,

very different functionalities and programming facilities. The

market is able to offer a wide choice of products off-the-shelf

for each of the previous categories. However many machine

builders prefer to develop proprietary, homemade control solu-

tions tailored to their specific needs by just standing on their

own competences.

M.Colla is with SUPSI-ICIMSI, University of Applied Sciences of South-

ern Switzerland, Galleria 2, CH-6928 Manno, Switzerland (phone: +41-58-

6666619; fax: +41-58-6666620; e-mail: marco.colla@supsi.ch).

T. Leidi is with SUPSI-ICIMSI, University of Applied Sciences of South-

ern Switzerland, Galleria 2, CH-6928 Manno, Switzerland (e-mail:

tiziano.leidi@supsi.ch).

M. semo is with logi.cals kirchner SOFT GmbH, 3124 Oberwölbling,

Austria (e-mail: mario.semo@logicals.com)

T. Strasser is with PROFACTOR GmbH, 4407 Steyr-Gleink, Austria (e-

mail: thomas.strasser@profactor.at).

Independently from the choices made when buying or develop-

ing a product, the biggest problem faced by engineers is the

separation existing between the activities and outcomes of the

design phase, and their transposition and implementation to

physical automation control systems.

The manual translation of the specification into an appro-

priate implementation is still the most widespread practice.

Consequently, companies implement or adopt proprietary and

sometimes undocumented rules. Worse than that, they delegate

this important task to the individual skills and preferences of

their programmers, bearing the weight of costs caused by

misalignments during the different phases of the product

lifecycle, from inception to retirement.

To overcome this kind of problems and to improve the

productivity of the design and development phases, an Euro-

pean project named MEDEIA, Model driven Embedded sys-

tems Design Environment for the Industrial Automation sector

[1], is currently running. Among the various goals, the main

ambition of this project is to link all specification and imple-

mentation activities by adopting an automated model-driven,

component based approach. The cornerstone of this solution

is a framework built around the concept of the Automation

Component (AC). This element will combine descriptions

about hardware, algorithms, interaction semantic and non-

functional properties in a modular way. Thanks to the AC

concept, it will be possible for the framework to support a new

methodology for modeling and simulating various industrial

automation systems through a compositional approach. AC

will act as a common repository for various users and domains.

For an effective implementation of the foreseen solution,

mandatory are research and development activities of modules

that automatically generate the source code of control applica-

tions for various hardware and software platforms. For this

reason, the purpose of one of the preliminary project activities

was to collect information about various implementation pos-

sibilities in the field of Industrial Automation and Control Sys-

tems (IACS). In this context, a list of the main features of

some prominent hardware platforms, their environments and

programming languages has been produced.

This document represents a survey identifying their common

and specialized characteristics and analyzing the way there are

exploited to conceive specific implementations of automation

systems. The survey considers the answers of the industrial

partners participating to the MEDEIA project. It therefore

concentrates on their industrial domains. Nevertheless, as it

A Survey of Methods and Technologies for

Developing Industrial Control Applications

M. Colla, T. Leidi, M. Semo, T. Strasser

I

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 260

will be pointed out in the next sections, the consortium is well

balanced in terms of domains complementarities and compa-

nies sizes, offering interesting information even with small

numbers.

An overview about the aim and rationale of the MEDEIA

method is provided in section II. Section III provides a short

overview of the state of the art regarding the transposition of

the design results to the development phase. Section IV pre-

sents the approach followed for conducting the survey and

shortly introduces the considered companies and their domain

of activity. While section V summarizes and analyzes the de-

sign and implementation processes that are currently in use,

section VI highlights various technical aspects specific to the

implementation phase, and section VII describes the character-

istics of various possible implementation platforms with par-

ticular regard to the envisaged component-based approach.

Section VIII summarizes requirements expressed by the indus-

trial partners and evolutions they expect. Section IX presents

conclusions and consequences for future work that can be

drawn from the presented work.

II. THE MEDEIA METHOD

A. Multi-Domain Model Driven Design

One main obstacle for efficient engineering of IACS is that

the design methodologies as well as the implementation tech-

nologies within plants and factories are diverse based as they

are on a range of different automation solutions currently

available. This aspect makes the overall design of an automa-

tion solution for a plant or factory very hard, especially when

different machines and embedded devices have to work to-

gether. To overcome the limitations of the high diversity of

system programming and modeling approaches within the field

of industrial automation, the MEDEIA multi-domain approach

aims at a meta-design architecture for the plant architecture.

The objectives of this approach can be summarized as follows:

Formal framework for model-driven component-based

development of embedded control: The main focus will

be on a formal framework for the design of heterogene-

ous embedded automation and control systems. The

main components of the framework are Automation

Components (AC) which are in general a combination

of embedded hard- & software.

Integrated modeling of diagnostics: A coherent and inte-

grated diagnostics concept will be developed that rec-

ords and analyses out-of-norm/faulty behavior to effec-

tively support the maintenance process of heterogene-

ous embedded hard- and software in an IACS.

Automatic, embedded platform specific code-generation:

ACs can be deployed to heterogeneous embedded au-

tomation hardware by an automatic code-generation

based on the AC and the system model.

1) General Approach

As mentioned above the MEDEIA design methodology is

based on the so-called ACs which are in general a combination

of embedded hard- & software. An AC holds the general mod-

el of its functionality and its interface for interacting with other

components. The starting point of each engineering flow is the

definition/specification of the system requirements. The design

flow accepts the functional and non-functional specification of

a plant as the initial starting point. The functional structure is

realized through systems or components. These systems or

components are formed from subsystems which are again

formed by sub-subsystems. This structure characterizes

MEDEIA’s strong compositional approach (see Fig. 1). This

approach greatly increases the productivity in designing and

building machines and plants from the mechanical/electrical

point of view.

In contrast to the functional structure of a plant, the state-of-

the-art design process for the control system is usually not

compliant with this point of view. Structures defined in em-

bedded systems disciplines like control hard- & software, as

well as communication, are rather based on technical reasons

than on functional assignment. The MEDEIA approach will

close this gap between the mechanical/electrical engineering

and the embedded control engineering perspectives. The first

step within the design flow is the specification of a rough plant

architecture and ACs. Additionally, existing ACs or already

available implementations of ACs can be included. By contin-

uous refinement, adaptation to new requirements, splitting up

to sub-problems/components and composition of ACs, the

MEDEIA design flow becomes highly flexible and integrative

at each level of the plant architecture. Independent of the cur-

rent state of the specification of an AC, the AC model enables

execution of the AC within a simulation framework. Therefore,

simulation of AC models together with concrete implementa-

tions enables a new kind of hardware-in-the-loop execution. At

any level of the plant architecture as well as for mixed envi-

ronments of existing and simulated ACs, the execution of parts

of the system or the overall system will be possible. This fea-

ture results in highly shortened development cycles, early test-

ing and improved dependability of single components as well

as of the overall plant.

2) Hierarchical Plant Structure Model

The overall plant architecture based on the functional analy-

sis and the AC components emerges as a hierarchical one. Fig.

1 depicts this situation schematically.

Two main types of ACs are distinguished: Hardware Specif-

ic ACs represent control equipment specific means (e.g. I/O

points, display, robot) while Compositional ACs contain sev-

eral other ACs and coordination/supervisory functionality.

Compositional ACs use the interface of ACs one level below,

add their functionality and provide their interface to the ACs

that will use them. Thus, on each level of the control software

hierarchy the ACs are built up in the same way. This helps the

control engineer in understanding the control program. The

second advantage regarding the understanding of the control

program is that, for a certain function of the plant, only one

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 261

level has to be considered. Furthermore, the MEDEIA ap-

proach will provide an integrated design of control and diag-

nostics on the AC level. The constricted view combined with

the diagnostics & control integration build the basis for a high-

ly efficient and easy understandable engineering.

AC AC AC AC

ACAC

AC

AC

ACExpert from

domain A Expert from

domain C

Expert from

domain B

Ma

ch

ine

Le

ve

lD

evic

e L

eve

lS

yste

m L

eve

lFPGA Visualisation Machine Tool

Controller

(PLC)Robot

Machine

Components Fig. 1. Hierarchical Plant Structure Model.

3) Automation Component Model

The determining element within the MEDEIA approach is

the Automation Component (AC). The overall plant or auto-

mation application is represented as an AC as is each single

device on the lowest level. The plant evolves by the aggrega-

tion of ACs to more complex ones, or the reverse, that is split-

ting up complex ACs into smaller ACs. The abstract meta-

model provides the core of each AC. Fig. 2 depicts the archi-

tecture of an AC.

Automation

Component

model

Domain

specific models

Domain specific

implementations

Internal

behavior

Comm.,

Local I/Os

Hierarchical

aggregationInterface

specification

Diag-

nostic

Con-

trol

Fig. 2. Automation Component (AC) model.

The MEDEIA AC model is represented by use of the fol-

lowing characteristic elements.

Interface description: An AC is represented by its inter-

face to the environment. MEDEIA enforces a detailed

interface description, which includes not only data and

action ports but also the timing behavior. The interface

is a constraint on the environment where the AC is used

and consists of an input assumption and an output guar-

antee.

Internal behavior: In addition to the interface description,

MEDEIA also addresses the description of the internal

behavior of the ACs, summarizing these into a stateful

description of the AC. The project does not only ad-

dress the control flow of the ACs, since this would re-

strict the model to an incomplete representation. One of

the most important items of the internal behavior con-

cerns to the diagnostic flow, which is linked very close-

ly to the control flow.

Hierarchical aggregation: As the MEDEIA approach is

based on a hierarchical structure of the plant, each AC

will use ACs one level below. The interaction and com-

position of these compositional ACs is based on the in-

terface description of the ACs used and on their connec-

tions. The description of the AC interaction is added by

the internal behavior, which represents the coordination

/ supervisory functionality and also additional function-

ality in this case.

Communication/local I/Os: As soon as an AC is related to

an embedded hardware device, additional information is

obtained from the communication and the associated

local I/Os. The first one becomes important during the

design phase. The interface description also consists of

timing information which is of special interest if com-

munication introduces no negligible disturbances to the

AC in the case of separation to several hardware devic-

es. The local I/O information becomes relevant for the

generation of platform specific implementation.

Within the formal framework, the AC model needs to be

represented in a variety of other models:

Domain specific models: Within the heterogeneous envi-

ronment of industrial automation and control systems,

there exists a huge variety of different specification

techniques and languages. A recognizable amount of

such different views need to be addressed within one

plant or factory. The AC model will not replace any of

them. But any of these specification techniques and lan-

guages will be expressed as a domain specific model.

By use of bidirectional model transformations, the

overall plant model can be specified and analyzed from

any domain specific view. Therefore, the design engi-

neer has the possibility to understand and specify ACs

in his preferred and familiar way.

Embedded platform specific implementations: Due to the

same reason as described for the domain specific mod-

els, the implementation of an AC (regardless of the lev-

el within the hierarchical structure of a plant or factory)

is again characterized by a high variety of different sys-

tems and programming languages. Therefore, the

MEDEIA approach introduces specific models for these

different systems and programming languages. By the

use of bidirectional model transformations, an AC can

be transferred to source code for real hardware and also

predefined components can be integrated into the gen-

eral AC model.

B. Rationale of the MEDEIA Approach

The current situation for the design of automation and con-

trol systems is characterized by a huge variety of different ap-

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 262

proaches in both the specification and implementation of

plants (in any occurrence whether continuous or discrete pro-

cesses). Different end-users of an automation system may use

any of the available specification methods, often dependent on

their domain (the term domain is not used as an umbrella term

for a big market sector but instead, for a specific field of appli-

cation). The specification method is used to describe end us-

ers’ needs and wishes. End user specifications can take several

forms (this list represents only a small set of possible means):

Textual description,

Gantt charts & Pert diagrams,

P & ID (Pipe and instrumentation diagrams),

Lists of sensors and actuators,

VGB R170C, VDI/VDE 3682, etc.

The list may be continued ad infinitum because different

companies often describe their own specification methods and

internal standards. When different end-users, each of whom

has expressed their requirements in different forms, have to

interact, difficulties arise. Currently, very little support exists

in automated workflows or even in the interoperability of dif-

ferent software tools implementing the combined set of speci-

fications, partly because the specifications themselves have

been defined in different forms. The problems are not only

limited to the front end of the development process. In any

automation solution, the implementation of solutions reflecting

end user requirements is completed by programmers each of

whom expresses the solution based upon different preferences

according to the type of plant and various environmental con-

ditions. Most often, the solutions are complex meaning that

different vendors of control systems with different program-

ming languages have to be incorporated. There is, currently,

no possibility to reuse existing code between platforms. Even

more importantly, there often exists no formalized way of

mapping from specifications to implementations. Fig. 3 depicts

this current situation in the upper part of the schematic, where

there are different kinds of users using different methods for

specification and implementation. You will note the key issue -

there is only very little communication (in a formalized man-

ner) possible among the different users. This is especially

problematical because, in general, there are many different

people involved in the establishment of a plant.

The main idea of this approach is to put a common element,

the AC, in between of the specification and implementation

elements of a plant automation system implementation as a

means of bridging the gap between the different users and their

special ways of specifying and implementing any given solu-

tion. This approach of using ACs has two main benefits:

For the specification of a plant the AC provides the basis

for interaction of different specification methods, which

are called Domain Specific Views (DSVs). These are

represented as domain specific models as depicted

above. The automation component model provides the

equivalent of a translator enabling the information spec-

ified in any given DSV to be viewed (and also edited)

in any other DSV, by means of the AC. Even in the case

where the DSVs specify different aspects of the plant,

the AC will incorporate all information as a common

element.

Any implementation can be based on the common infor-

mation within the AC based on code generation. Ac-

cordingly different platforms may be supported due to

appropriate transformations in the so-called Embedded

Platform Specific Implementations.

Plant specification

and implementation

SPECIFICATION

User A:

Gantt chart

User B:

P&I

User C:

VDI/VDE 3682

IMPLEMENTATION

User X:

IEC 61131-3

User Y:

VHDL

User Z:

C/C++

?

?

?

?

Plant specification and

implementation

MEDEIA

approach

SPECIFICATION

Domain

Specific View 2

Domain

Specific View 1

IMPLEMENTATION

Plattform Specific

Implementation 1

Plattform Specific

Implementation 2

Now (ñ) and Then (ò) in automation system design!

Fig. 3. Comparison between the current and MEDEIA-based

design situation.

III. STATE OF THE ART

Many academic efforts have been made for linking in a

more or less automatically way the outcomes from the design

phase to the implementation activities. However, they mainly

concentrated in transforming just a particular perspective of

the whole design space, usually represented by mean of spe-

cialized notations and tools, into specific programming lan-

guages for dedicated platforms.

The efforts reported by various authors in [2], [3] and [4],

particularly concentrated on using UML [5] artifacts and con-

verting them to the IEC 61131-3 [6] languages. Chiron and

Kouiss [7] took a similar approach using SysML [8] instead of

UML. Also Estevez, Marcos and Orive [9] concentrated them-

selves on the IEC61131-3 and PLC domain developing a new

markup language called icsML for describing a control appli-

cation in a vendor independent way, supported by transfor-

mations to various specific formats. As an example of a more

general approach the CASE tool integration platform named

GeneralStore [10] tried to couple subsystems from different

modeling domains and to generate running prototypes using

UML as metamodel for storing the data. Unfortunately such

attempts haven’t found a wide acceptance at the industry level.

A new, industry and academic jointly driven, initiative

called AutomationML [11] tries also to glue the automation

engineering activities with a neutral XML-schema [12] based

data format. The goal in this case is to interconnect heteroge-

neous engineering tools from different disciplines covering

mechanical plant and electrical design, as also HMI, PLC and

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 263

robot control aspects. To this goal an Intermediate Modeling

Layer has been introduced, but the spectrum of the considered

description models and implementation languages is very nar-

row.

IV. SURVEY METHOD AND SCOPE

A. Survey Method

The principle driving the survey was that two main artifacts

could be the pillars for bridging the gap between the design

and implementation phases in the industrial automation field:

A model, which contains and structures the information in

an abstract way favoring goals such as reusability and

composition.

Modules that automatically transform the information

contained in the model into the desired representation

and backward.

Existing control applications need therefore to be analyzed

and classified under categories, isolating the parts that are

common and those peculiar to a specific implementation. By

mean of such an analysis approach, concentrating on how and

why such applications are designed, structured and executed, it

will be possible to understand which kind of information has to

be put in the model, isolating the variability that will be han-

dled when automatically generating the desired code.

For this goal, questionnaires were prepared and used for

collecting the information from the project industrial partners

on the following topics:

Description of current design and implementation pro-

cesses, tools, languages and platforms.

Detailed technical description of current implementations

characteristics.

Expected progresses beyond the state of the praxis.

B. Survey Scope

The industrial partners of the MEDEIA project are the

scope of the survey and represent the following sectors:

Machine tools and Flexible Manufacturing Systems

(FMS),

Packaging machine builders,

Power generation and distribution,

Robotics and

General process automation engineering.

The medium sized enterprise representing the manufacturing

domain utilizes plants made of machining centers and FMS

Systems for the automotive, aerospace and general mechanics

industry production. A hierarchical distributed automation

system controls such plants through three different control

levels.

Equipment (transducers and actuators),

Services (PLCs and CNCs),

Supervisor (organized in a hierarchical structure).

The small and medium sized packaging machine builders

are grouped and represented through a consortium. They usu-

ally build families of machines by starting from a first design

effort and then generating specific instances. These are pro-

duced according to the adopted technology platform, the ma-

chine and the control system configuration, and the customer

choice of integrated automation features.

The partner from the power generation field is a very big

company that owns, operates, and is the architect of its power

plants. Its systems can be distributed on more plants, are main-

ly based on commercial-off-the-shelf (COTS) products and are

structured in four levels:

Field (sensors and actuators),

Automation (individual or group control),.

Supervision (process control and operator interface),

Operation & maintenance.

The control devices they use range from relays to PLCs,

DCS and Supervisor, Control and Data Acquisition (SCADA)

systems. The also includes specific components like Field Pro-

grammable Gate Arrays (FPGA) and network of wireless sen-

sors for environmental or process monitoring that are pro-

grammed using C, Java or VHDL.

The medium sized enterprise from the robotic field builds

various mechatronic modules that can be combined in a flexi-

ble way to create modular configurations for different automa-

tion solutions. These systems are used in various domains like

in the factory and laboratory automation or for inspection sys-

tems and service robotics. For this reason the company pro-

vides a construction kit for configuring the mechanical and

electrical setup, while it is up to the customer to integrate them

with the control system.

The small company representing the general process auto-

mation engineering field provides support for the development

of PLC based applications. They don’t force their customers

to a specific way when designing applications, but develop a

domain independent suite, supporting the modeling, documen-

tation, development and test phases for various application

domains in an integrated and configurable way.

V. CURRENT SITUATION ANALYSIS

The survey about the current design and implementation

processes, used tools, languages and platforms to implement

specific control applications, has been organized around the

following main categories.

A. Methods to implement Control Applications

Every project partner manually writes its control applica-

tions. No one has an automatic transformation, either forward

or backward, between the design and the implementation

phases. This situation confirms the gap between the design and

implementation phase, and strengthen the need for an innova-

tive approach like the one proposed in the MEDEIA project.

B. Methods to transform the Design into Implementation

Most of the interviewed partners delegate this crucial pro-

cess to their programmers’ skills. Some of the small and medi-

um sized packaging machine builders indicated that they have

internal rules between the design and implementation process.

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 264

In the big company from the power generation domain, simula-

tion activities are executed internally while safety and architec-

ture constraints are explicitly specified.

This lack of automatic conversion mandates the supplemen-

tary definition of rules when transforming design information

into specific implementations. An interesting alternative

should provide a solution for users to describe and customize

such transformation rules according to their needs.

C. Methods to map Source Code to Hardware

Every project partner manually specifies the hardware and

the inputs and outputs (I/Os) of a specific platform using

COTS tools. Moreover such tools are used to map, compile

and deploy the control code to the destination hardware.

This means that innovative approaches and solutions should

integrate such existing tools by converting the information

forward and backward between the abstract model and the

proprietary or open data persistence format used by such tools.

D. Tools to design and handle Control Applications

Mainly proprietary textual and diagram editors are used for

the design of control applications, as shown in Fig. 4.

0

10

20

30

40

50

%

Word

UML

Visio

Diagrams

Fig. 4. Design tools used by project partners.

PLC specific development tools are mostly used when writ-

ing, mapping to hardware platforms and deploying control

applications. However, generic platforms like ECLIPSE [13]

or specific environments for languages like VHDL are used

too, as shown in Fig. 5.

The resulting picture can be commented as follows:

It is impossible to automatically derive an implementation

from informal descriptions, like those produced using

Word or Visio. To bridge the gap between design and

implementation a more formal design procedure has to

be introduced.

PLC development tools usually store the data using pro-

prietary formats and refer to specific proprietary hard-

ware platforms. Again a move toward open internation-

al standards formats to describre hardware and control

programs, like e.g. the PLCopen XML [14], is an essen-

tial requirement.

Particularly regarding the mapping of control programs

and variables to hardware platforms, PLC tools can of-

fer a support that is not available in tools exploiting

computer science generic programming languages like

C or Java. A solution automating the design to imple-

mentation process needs to support both scenarios.

0

10

20

30

40

50

60

%

PLC

Text

Eclipse

Matlab

Fig. 5. Tools for handling control applications.

E. Programming Languages

The IEC 61131-3 languages (ST, IL, LD, FB, SFC) and the

computer science programming language C are the most wide-

spread among the project partners, as shown in Fig. 6. Never-

theless object oriented and hardware description languages are

considered too. The former are mainly used at the supervisor

level. The latter are instead used to speed up the execution of

control applications.

0

10

20

30

40

%

61131-3

C

Java/C++

VHDL

Fig. 6. Programming languages used by project partners.

The increasing diffusion of computer science generic lan-

guages expands the software competences needed by control

engineers. All this calls for a high level modeling approach

sustained by automatic code generation integrated functionali-

ty as the MEDEIA approach foster.

F. Automation Platforms

In agreement with the preceding results, commercial PLCs

are the widest used category of platforms. Nevertheless, indus-

trial personal computers and embedded hardware platforms

share an important market slice, as shown in Fig. 7.

The variety of automation platforms and the great diffusion

of proprietary hardware solutions force considering alternative

paths when dealing with an automatic generation of source

code. Possible solutions could introduce an abstraction layer

featuring a common interface and/or huge modularity to im-

plement interchangeable code generators.

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 265

0

10

20

30

40

50

%

PLC

IPC

Embedded

DCS

Fig. 7. Automation platforms used by project partners.

VI. IMPLEMENTATION ASPECTS ANALYSIS

This section summarizes the key technical aspects to con-

sider when automatically generating a control application. The

information provided originates from specific solutions adopt-

ed by the project partners and highlight that, beyond the PLC

control applications, there are many, alternative, homemade

implementations, possible at various automation levels, name-

ly:

Java, PC based, multi-station supervisor applications,

Embedded PC based control applications,

Signal control applications implemented in FPGA,

Wireless networks of distributed, Java based, embedded

control devices, and

Distributed automation systems modeled following the

IEC 61499 standard [15].

A. Execution Environment

At the system level, the majority of implementations asks

for distribution on more control stations (machine, rack, CPU),

with a granularity that can vary from whole applications to

parts of them. A generator able to produce source code, thus

further needs to feature mechanisms communication and syn-

chronization of distributed parts. Moreover, the code genera-

tor should divide the created source files according to their

final destination and should generate makefiles to build

executables.

Peculiarities of the hardware platforms, listed in Fig. 7, vary

in a important way and must therefore be considered by an

automatic code generator in combination with the implementa-

tion language. The PLC category usually represents a closed

proprietary environment. Embedded platforms have instead

very different hardware architectures. When generating source

code, the industrial PC platform is well suited because of its

open standard architecture.

The software environment is strongly coupled with the

hardware platform. When a commercial PLC is in use the

whole environment is typically closed, proprietary and perhaps

undocumented or unknown in some parts. Embedded or real-

time versions of Windows, Linux or even DOS are instead

used on PC platforms. In the embedded world the typology of

embedded or real-time operating systems in use is extremely

diversified. Consequently, when source code has to be gener-

ated, a common Application Programming Interface (API)

offered by a hand-written middleware layer could mask the

differences between the various solutions, reducing the varia-

bility to be managed. Fig. 8 shows the software environments

mainly used.

0

10

20

30

40

50

%

PLC

Win,Linux

RTOS

No OS

Fig. 8. Software environments used by project partners.

B. I/Os Interface

The interface to the I/Os can severely concern an automatic

code generator in terms of physical medium, communication

protocol and API.

The information in Fig. 9 highlights the choice available on

the market. An approach of masking the interface variability

through an hand-written middleware layer, in a similar way to

the solution postulated for the execution environment, could

simplify the job of the code generator.

0

5

10

15

20

25

%

Profibus

Others

Ethernet

Direct

RS232

Fig. 9. I/Os interfaces used by project partners.

C. Communication Interface

Previous sections introduced that many systems are multi-

station and need therefore communication interfaces among

their elements.

Ethernet is the most widespread solution at the physical lay-

er, as shown in Fig. 10, but at upper levels are available many

proprietary protocols masked through ad-hoc APIs. Even in

this case a neutral, common, hand-written middleware layer, or

dedicated components, could help masking the various proto-

cols differences.

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 266

0

10

20

30

40

50

%

Ethernet

RS232

CAN

LON

Fig. 10. Communication interfaces used by project partners.

D. Applications Management

Many control environments have local and/or remote man-

agement services. They usually allow starting, stopping, delet-

ing, shutting down and reconfiguring applications, but also

reading and writing data. Such services are often already im-

plemented in the runtime environment. Sometimes there is

however a need for an automatic generation of them.

E. Applications Architecture

This category of analysis focuses on considerations about

how application architectures are implemented in code.

In various cases there are many applications running con-

currently, they are aware of each other and communicate by

mean of mechanisms like message passing or global variables.

Surprisingly, in some cases such applications don’t use any

synchronization mechanism at all. They communicate but

don’t synchronize their execution.

It was previously introduced that many applications run in

an operating system and are hence structured in multiple

threads of execution. Such threads are traditionally scheduled

in a cyclic way (scan model) for applications running on PLC

platforms, or event driven as supported e.g. by the IEC 61499

standard, as shown in Fig. 11.

0

10

20

30

40

%

Multithreaded

Scan

Event driven

Fig. 11. Execution models used by project partners.

Due to the component-based approach pursued in the

MEDEIA project, the structure of the applications is of great

interest for the analysis. An automatic code generator could be

forced to completely transform the model information when

asked to produce a specific application’s structure.

Being many of the applications PLC based, Fig. 12 shows

that most of them have a component similar architecture

thanks to the POU concept of the IEC 61331 standard, as also

put in evidence in [16].

0

10

20

30

40

%

PLC POU

Component

Other

Config file

Fig. 12. Applications structures adopted by project partners.

With procedural languages like C, it is possible to imple-

ment the component concept, through modules made of an

algorithm function and a data structure containing all interface

or internal variables. Further functions cold be made available

to initialize and dispose the component, or to connect it to oth-

ers by mean of shared, interface variables present in the data

structure. A component instance will thus be a variable of the

given component data structure, passed as an argument to the

algorithm function when called.

With object-oriented languages like Java the mapping be-

tween a component in the model and an implementation object

is of course more immediate. Further details about it are pro-

vided in the next section.

With both categories of languages, implementations can dif-

fer in the granularity used to map components to threads,

which can vary from the whole application, to compounds of

components, or to components alone. Accordingly to the pre-

viously cited scheduling policies, another aspect that greatly

influences the automatic code generation process is the order

in which components are executed.

F. Data Format

For further modifications, an automatically generated con-

trol system needs to be persisted in a combination of formats.

Needed to be stored, are the descriptions of its applications, its

hardware and how they map each other.

0

20

40

60

80

%Textual

XML

Fig. 13. Persistence format used by project partners.

Survey answers, shown in Fig. 13, indicated that applica-

tions are mainly persisted using the text format of the chosen

programming language. Hardware information is instead usu-

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 267

ally stored in a proprietary textual format. For IEC 61131 or

61499 implementations the standardized XML format is some-

time supported. This should be the direction to follow when

enhancing the interoperability of the tools.

VII. DETAILS ABOUT THE IMPLEMENTATION MODELS

The information provided for this survey by MEDEIA’s

partners, indicated that the programming languages exploited

in the industrial automation sector, vary according to their

functionality or depends from the hardware platform used to

execute applications.

No industrial project partner indicated the CNC language as

a potential target. Everyone indicated instead various automa-

tion domain languages required for their implementation. In

this group the following categories have been identified:

Programming languages explicitly conceived for control

applications commonly running on PLCs;

Programming languages coming from the computer sci-

ence, such as C, C++, Java, used to develop applica-

tions running on embedded and/or industrial PCs;

Hardware Description Languages (HDL) usually support-

ing hardware and system-on-chip design. They gained

popularity to speed-up control applications.

A. IEC 61131-3 Implementation Model

The function block model defined in IEC 61131-3 provides

a type-instance concept, allowing to instantiate already de-

signed function blocks more than once and to use these in-

stances in any other program organization unit (POU). Fur-

thermore it supports the concept of encapsulation, allowing the

designer to hide the internal behavior of a POU to the envi-

ronment of the instance.

The execution of control programs is driven by a scan based

model; this means the program code is cyclically executed at

fixed intervals of time.

Alternatively a textual representation, e.g. using ST, could

be targeted when generating the control application. In both

situations, either XML or textual, the PLC tool should subse-

quently treat the generated source code to map the variables to

a specified hardware. It also need to build and download the

executable for execution or debugging in the target runtime

environment.

B. IEC 61499 Implementation Model

The IEC 61499 standard defines a common architecture for

distributed control systems. The control applications are de-

fined as networks of elements called Function Blocks (FB).

Two types of FB, namely Basic and Composite, allow dif-

ferent levels of abstraction. In every Basic FB the control algo-

rithm is described by an Execution Control Chart (ECC), while

the functional algorithms may be described by IEC 61131-3 or

other programming languages (e.g. C, Java …). The execution

of Composite FBs and Applications is driven by an event-

based model, at the contrary of the IEC 61131-3 model, which

is scan based.

Moreover the IEC 61499 models are hardware independent,

thanks to the encapsulation concept, which allows defining

special FBs named Service Interface FBs (SIFB) as interfaces

towards specific hardware.

The standard further defines a textual and an XML persis-

tence format, making the interoperability among different IEC

61499 tools easier.

C. C Implementation Model

C is a block structured, general-purpose computer

programming language designed for procedural and imperative

programming. Although it was designed to implement system

software, it is also widely used when developing applications

targeting many different (embedded) software platforms and

hardware architectures.

Although C focuses on procedural programming, it is

possible to automatically convert a component based abstract

design, even featuring composition concepts like the one

MEDEIA proposes, to C source code. The key for this

conversion is a combination of functions and structure

available in the C language. This has introduced in the

previous section.

Choosing the C language as a platform specific

implementation mandates the availability of a runtime system.

It has to be implemented if it is not already available.

Moreover, a neutral middleware masking the details of the

specific operating system, I/Os and communication interfaces,

should be available, or the source code generator should be

made aware of each particular API.

D. Java Implementation Model

Java is an object-oriented programming language that

derives its syntax from C and C++. Unlike C++, which

combines solutions for structured, generic, and object-oriented

programming, Java was built almost exclusively as an object-

oriented language, presenting a simpler object model and

fewer low-level features. In fact all code is written inside a

class and everything is an object, with the exception of the

intrinsic data types (ordinal and real numbers, boolean values,

and characters), which are not classes because of performance

reasons.

One quality of Java is portability, which means that

computer programs written in the Java language must run

similarly on any supported combination of hardware and

operating-system. It is therefore possible to write and compile

a program once and run it anywhere. This is achieved by

compiling the Java language into bytecode: platform

independent instructions interpreted by a Java virtual machine

(JVM), which is instead specifically tailored to each host

hardware. However, the overhead of interpretation almost

always imposes a slower execution of the program and

therefore Java suffered the reputation of a poor performing

language. This gap has been recently narrowed by a number of

optimization techniques introduced in recent JVM

implementations. For example, the just-in-time compilation of

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 268

bytecode to native code during program execution is supported

by some of the JVMs, resulting in a faster execution.

Moreover, Java uses an automatic garbage collector to

handle the disposal of the memory occupied by objects during

the application lifecycle. While the programmer determines

when objects are created, the Java runtime is responsible for

recovering the memory once objects are no longer in use.

JVMs a typically allowed to perform garbage collection at any

time, ideally when a program is idle. This activity can further

impact performance and response time. In embedded or real-

time implementations some particular techniques are thus used

to avoid drawbacks and risks.

Due to its object oriented nature, Java fits perfectly to the

Automation Component model, because it allows a one-to-one

mapping of an AC to an object. Each component can straight-

forwardly be implemented by Java class featuring data fields

for the internal state and methods for the external communica-

tion and for its execution. No particular strategy is required, as

it was instead previously explained for the C language. Fur-

thermore Java easily supports dynamic operations like down-

load and reconfiguration of the application parts. The automat-

ic code generator could be independent from the chosen run-

time environment, particularly if standardized libraries for the

operating system and network interfaces are available and pre-

defined objects implementing a concept similar to the IEC

61499 Service Interface Function Blocks for the I/Os are used.

E. VHDL Implementation Model

The VHSIC Hardware Description Language (VHDL),

where VHSIC stands for Very-High-Speed Integrated Circuits,

belongs to the Hardware Description Languages (HDL) cate-

gory and is commonly used for the design of Field-

Programmable Gate Arrays (FPGA) and Application-Specific

Integrated Circuits (ASIC).

VHDL is strongly-typed and has concepts and syntax simi-

lar to the ones provided by the ADA programming language.

In addition it has constructs to inherently handle parallelism in

hardware designs and special extensions for hardware ele-

ments like Boolean operators.

Logic synthesis tools allow the transformation of a VHDL

program into hardware by generating the description of the

physical implementation of the circuit. However a subset of

VHDL code is not synthesizable, it cannot be translated into

hardware and is therefore used for simulation purposes only.

Instead of executing it, a VHDL model is normally translated

into gates and wires mapped to a programmable logic device,

by consequently configuring the hardware in use.

VHDL models are based on the concept of entities, which

describe interfaces using ports, and architectures, which de-

scribe the implementation of an algorithm. It is therefore very

similar to the Automation Component approach pursued in

MEDEIA.

It must be nevertheless underlined, that the main goal of this

language is to describe hardware circuits and that VHDL is a

dataflow language. It models a program as a directed graph of

the data flowing between operations. Such operations consist

of black boxes with inputs and outputs, which executes as soon

as all of their inputs become valid. This is different from

software applications that execute components when they are

scheduled. VHDL is inherently parallel unlike procedural

computing languages such as C that run sequentially. The

operations have no hidden state to keep track of the execution,

are all ready at the same time and hence cannot support basilar

concepts like a Turing machine with states, events and actions.

VIII. REQUIREMENTS ANALYSIS

This section summarizes the partners’ expectations from the

project in terms of functionalities available when implement-

ing platform specific application. Particular focus is on, infor-

mation to be handled, transformed, stored and integration with

existing tools.

A. Model and Generated Data

For all partners the automatically generated output should

be formatted source code to be used by third parties’ tools

performing other operations like simulation, compilation, de-

ployment, and debugging. There is no interest in deployable,

ready to run executables as an immediate output of generators.

0

10

20

30

40

50

60

%

61131-3

C

Java/C++

VHDL

61499

Fig. 14. Implementations required by project partners.

The languages choices for such code reflect the picture

shown in the previous Fig. 14: someone specified just some of

the possible five IEC 61131-3 languages, while there is also

interest for the IEC 61499 standard. Unfortunately, no one

indicated rules for transforming design parts to a specific IEC

61131-3 language.

The language format should be open and standardized, two

named choices are XML (e.g. PLCopen) or textual.

Regarding a possible duplication of vendor and/or tool spe-

cific platform information inside the component model, there

are different opinions. A slight preference has been expressed

for a solution featuring a central repository that integrates the

specific vendor and tool platform information through external

links. This way it would be possible to specify the generic ar-

chitecture of a system in the new component model, linking

such architecture elements to the external vendor specific in-

formation without duplicating it.

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 269

B. Integration with Existing Tools

The majority of the answers is consistent and indicated that

the automatically generated information should be available to

existing tools for operations like:

Mapping to platforms, I/Os, tasks,

Executable code generation,

System parameterization,

System test & diagnosis,

Debugging of runtime systems,

Runtime configuration and download, and

Configuration of communication parameters.

This means that many operations are expected to be done on

the generated code before an application executable is ready to

run on a control system.

C. Development Environment Functionalities

The expectations regarding further functionalities, beside

the automatic code generation, to introduced in MEDEIA are

very different.

Fig. 15 shows how important is the consistency between

generated code and design model in both directions, followed

by the distribution of control applications on generic devices

for simulation purposes.

0

10

20

30

40

%

Reverse Eng

Generic map

Simulation

Repository

Hw def+map

Troubleshoot

Fig. 15. Functionalities expected by project partners.

The need to maintain the generated code, maybe manipulat-

ed with third parties’ tools, consistent with the design model is

a justified request. This task is particularly difficult, due to the

probable great distance and difference between the design

model and the generated source code. A feasible solution

could be the definition of a subset of changes that can be fed

back to the model in well defined points (e.g. one could modi-

fy an algorithm of a component in the generated code, but not

the architecture of an application).

IX. CONCLUSIONS

The survey results presented in this document, based on a

set of input sources (the industrial partners of the project) rela-

tively small but representative of various automation sectors,

provides an overview of different implementation possibilities

for control applications and identifies a list of topics related to

the automatic generation of such implementations starting

from the design outcomes.

The answers permit to state that:

The implementation of control applications is still a

handcraft work.

The translation of the design specification, which is main-

ly made of text and diagrams, to platform specific im-

plementations, is usually left to the programmers’ expe-

rience and competence. Codified rules for doing this

work are very seldom found.

The classical PLC world dominates the automation plat-

forms scene. Consequently:

o The used languages are more or less compliant to

those defined by IEC standards;

o The hardware and runtime environments are usu-

ally proprietary, and hence they are selected and

configured using vendor specific, closed com-

mercial tools;

o Such tools also support other development stages

like I/Os and applications mapping, compiling,

linking, downloading, debugging and mainte-

nance.

Other platforms and languages are further used when im-

plementing control applications, e.g. the C language on

industrial PCs. In these contexts the development tools

traditionally just support the programming activity. The

runtime system represents an important added value of

the company developing the control application.

The previous picture influences the goal of automating the

transformation process from design to implementation in many

ways:

The whole process must be pioneered. It seems that there

are no codified transformation rules,

An interesting possibility allows configuring and custom-

izing such transformation rules instead of codifying

them,

An automatically generated, platform specific implemen-

tation has to be compatible with the persistence format

of existing tools. They’ll probably be used to further

manipulate it. A possible choice could be open stand-

ards like IEC 61131-3 and 61499,

The reverse engineering functionality, which is the ability

to bring changes made with platform specific third par-

ties tools back in the model, should be supported at

least for a subset of the possible operations,

An interesting feature is the mapping of control applica-

tion parts to generic hardware for simulation purposes,

A central element, or repository, could be a good solution

for linking specific information, like the hardware con-

figuration, that is normally managed by third parties

tools.

The information shortly presented here is currently being

used by the project partners to define the Automation Compo-

nent Model and to conceive the transformation rules needed in

both the design and the implementation phases.

MASAUM Journal of Reviews and Surveys, Vol. 1, No. 3, November 2009 270

ACKNOWLEDGMENT

The work presented in this paper has been supported by the

European Commission under the seventh Framework Program

within the MEDEIA project (ICT 2007-211448).

REFERENCES

[1] MEDEIA: Model driven Embedded systems Design Environment for the

Industrial Automation sector, ICT Project Nr. 211448, 7th EU FP.

(http://www.medeia.eu/). [2] T. Heverhagen, R. Tracht, “Integrating UML-RealTime and IEC 61131-

3 with Function Block Adapters”, International Symposium on Object-oriented Real-time Computing (ISORC), 2001.

[3] K. Thramboulidis, “Using UML in Control and Automation: A Model Driven Approach”, Proc. IEEE Int. Conference on Industrial informat-ics (INDIN’04), 2004.

[4] B. Vogel-Heuser, D. Witsch, U. Katzke. “Automatic code generation from a UML model to IEC 61131-3 and system configuration tools”, In-ternational Conference on Control and Automation (ICCA’05), 2005. Vol 2, pp 1034-1039, 2005.

[5] UML, The Unified Modeling Language from the Object Management Group (OMG). Version 2.2, Available:http://www.uml.org/.

[6] International Electro-technical Commission, (IEC), “Programmable controllers - Part 3: Programming languages”, International Standard IEC61131-3, Second Edition 2003.

[7] F. Chiron, K. Kouiss, “Design of IEC 61131-3 Function Blocks using SysML”, Mediterranean Conference on Control and Automation, Ath-ens, Greece, 2007

[8] SysML, The Systems Modeling Language from the SysML partners. Version 1.1, Available:http://www.sysml.org/

[9] E. Estévez, M. Marcos, D. Orive, “Automatic generation of PLC auto-mation projects from component-based models”, The Int. Journal of Advanced Manufacturing Technology, Springer London, Vol. 35, Nb. 5-6, pp. 527-540, December 2007

[10] C. Reichmann, M. Kiihl, P. Graf, K.D. Muller-Glaser, “GeneralStore - a CASE-tool integration platform enabling model level coupling of heter-ogeneous designs for embedded electronic systems”, Proc. 11th IEEE International Conference and Workshop on the Engineering of Comput-er-Based Systems, 2004.

[11] R. Drath, A. Luder, J. Peschke, L. Hundt, “AutomationML - the glue for seamless automation engineering”, Proc. IEEE Int. Conference on Emerging Technologies and Factory Automation (ETFA’08), 2008, pp.616-623.

[12] XML: Extensible Markup Language, [Online], http://www.w3.org/XML/.

[13] The Eclipse open development platform, [Online], http://www.eclipse.org.

[14] PLCopen Technical Committee 6, “XML Formats for IEC 61131-3”, Technical Paper, Version 1.01, 2005

[15] International Electro-technical Commission, (IEC), “Function Blocks, Part 1 – 4”, International Standard IEC61499, First Edition 2005.

[16] C Sünder, A. Zoitl, J. H. Christensen, H. Steininger, J. Fritsche, “Con-sidering IEC 61131-3 and IEC 61499 in the context of Component Frameworks”, Proc. IEEE Int. Conference on Industrial informatics (INDIN’08), 2008.