A tool supported engineering process for developing

control applications

Christos Tranoris, Kleanthis Thramboulidis *

Electrical and Computer Engineering, University of Patras, 26500 Patras, Greece

Received 12 May 2005; accepted 15 February 2006

Abstract

Engineers in industrial and control sector continuously face problems on developing modern distributed industrial control applications. The

latest standard in this domain, the IEC61499, defines a methodology to be used by system designers to construct distributed industrial control

applications. New generation Engineering Support Systems (ESSs) are required to support the whole development process. In this paper, a process

that introduces new and enhances already defined phases of the IEC61499 development process is presented. Model Driven Development has been

adopted and two meta-models have been defined: a Unified Modelling Language (UML) based one that is used in the analysis phase and an

IEC61499 based for the design phase. A set of transformation rules, formally defined by means of UML’s Object Constraint Language, is defined to

ameliorate the transformation process between the two metamodels. The proposed development process is supported by a prototype ESS, namely

CORFU ESS, which is used to present a case study.

# 2006 Elsevier B.V. All rights reserved.

Keywords: Distributed Control Applications; Function Block; IEC61499; Control Application development process; Model Driven Development

www.elsevier.com/locate/compind

Computers in Industry 57 (2006) 462–472

1. Introduction

Following technology’s trends, engineers in industrial and

control sector continuously face problems on developing

distributed control applications that should meet various

functional, interface, operational and performance require-

ments and additionally conform on engineering concerns such

as maintainability and reliability. To deal with these challenges,

control engineers are underway in applying Software Engi-

neering practices in the development process of distributed

control applications. Proofs of this motion are the 61499 [1] and

61804 [2] standards of the International Electrotechnical

Commission (IEC). Both standards, which are affected from

current Software Engineering trends and practices, are based on

the Function Block (FB) construct. Control engineers are

already familiar with the FB concept defined in the IEC61131-3

standard [3], so the shift to the IEC61499 model, which is based

on an enhanced FB concept, might be effortless.

* Corresponding author. Tel.: +30 2610996436; fax: +30 2610996820.

E-mail addresses: tranoris@ee.upatras.gr (C. Tranoris),

thrambo@ee.upatras.gr (K. Thramboulidis).

0166-3615/$ – see front matter # 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.compind.2006.02.006

The object-oriented approach is currently the most dominant

Software Engineering practice. The Unified Modelling

Language (UML) [4], which is the industry standard for

modelling software systems, permits the specification of a

system, independent of the development process. However, the

use of UML in the development process of control applications

introduces the following problems:

(1) c

ontrol engineers have a weak understanding of Software

Engineering methodologies,

(2) t

here is a gap between the modelling of the application, and

the final implemented and executable Control Application,

and

(3) u

sually, new control applications should be compliant with

already installed legacy systems.

Following industrial engineering technological trends an

effort was made to overcome the above problems and introduce

the CORFU Environment for the Model Driven Development

of Industrial Process Measurement and Control Systems

(IPMCSs). Core constituent of the CORFU Environment is

the CORFU development process, which exploits current

Software Engineering practices in the development of IPMCSs.

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472 463

Fig. 1. IPMCS application model as a Function Block network.

This process tries to minimize the gap between the object-

oriented approach and the Function Block-based approach of

IEC61499. In general, the process addresses the requirement

and analysis phases of IPMCSs using UML [5], and the design

and deployment phases by means of the FB construct as defined

by the IEC61499 standard. A prototype system, the CORFU

Engineering Support System (CORFU ESS), has been

developed to demonstrate the applicability of the proposed

process.

An ESS should support the design, implementation,

commissioning and operation of IPMCSs. Nowadays, the first

ESSs that attempt to support the engineering phase of industrial

control applications by following the IEC61499 standard are

under development. The Function Block Development Kit

(FBDK) [6], a publicly available IEC-compliant ESS, allows

the definition of Function Block types, and the design of

Function Block network diagrams. However, it does not follow

a well-defined development process; it does not support

requirements specification as well as the distribution of

Function Block instances to the system’s devices.

The remaining of this paper is organized as follows: In the

next section the basics of this work are presented. In Section 3,

the proposed development process is described. The transfor-

mation of the UML model to Function Block-based model that

is based on a well-defined set of transformation rules, is

described in detail in Section 4. Section 5 presents, through a

case study, the way that CORFU ESS supports and automates

the development process. Finally, the last section concludes the

paper.

2. Basis of this work

The proposed development process is the result of an

integration of artefacts from both Software Engineering

practices and Control Application domain. It exploits Model

Driven Development (MDD) in the design of distributed

industrial control applications and it is based on a four-layer

architecture [7]. The main elements of the process are the UML

and the IEC61499 model. The following paragraphs briefly

introduce MDD, the IEC61499 FB concept, and the CORFU

four-layer architecture.

MDD is the continuation of the trend on how engineers

tackle problems of complexity in programming [8]. MDD lets

engineers model what functionality is needed and what overall

architecture the system should have, instead of expressing

every detail of a system’s implementation using a programming

language [9]. It makes models less sensitive to computing

technology specialists to produce software systems. Conse-

quently, a key premise behind MDD is that programs could be

automatically generated from their corresponding models [10].

A core element of the CORFU development process is the

Function Block construct. The FB is an abstraction mechanism

that allows industrial algorithms to be encapsulated in a form

that can be readily understood and applied by industrial

engineers, who are not specialists in the implementation of

complex algorithms [11]. IEC61499, in Annex C1 of the

IEC61499-Part 1, defines the basic functionality for an ESS,

which is the tool that supports the whole life cycle of IPMCSs.

It further defines a general model and a methodology for

describing IPMCS applications in a form that is independent

from a specific implementation. An application consists of one

or more Function Block instances, interconnected through their

event and data inputs/outputs, as shown in Fig. 1.

The CORFU development process is based on a four-layer

architecture [7] that consists of the following layers: (a) the

Industrial Process Layer; boilers, valves, motors are the real-

world plant components that constitute the implementation

artefacts of this layer, (b) the System Layer, which includes the

analysis, design and implementation artefacts of the system on

which the Control Application will be executed; such artefacts

are fieldbus segments, field devices and the network used for the

real-time interconnection of fieldbus segments, (c) the

Application Layer, which includes the required software

constructs used in the analysis, design and implementation

of IPMCS applications, such as use case diagrams, object-

interaction diagrams, scenario, class and FB diagrams, and (d)

the Human Machine Interface (HMI) layer, which captures all

the abstractions that concern the development and operational

phases of the HMI subsystem.

The CORFU development process is enhanced with elements

that are defined as stereotypes which are used to obtain a better

abstraction of the under study model. Stereotypes represent one

of the built-in extensibility mechanisms of UML which are

included in the Profile extensions of version 2.0 of the language

[4]. A stereotyped element, which is essentially a new metaclass,

may have additional constraints to the ones of the model element

on which it is based. It may also define element model-time

properties through a list of tag definitions.

It is expected that domain specific code generators and other

tools will treat stereotyped elements accordingly. A key

stereotype introduced and utilized by the CORFU development

process is the Industrial Process Terminator (IPT) stereotype

that is used to represent in the design-space industrial process

entities such as valves, conveyers, etc., that are monitored or

controlled by the Control Application.

3. The proposed development process

The proposed development process, which is an attempt to

improve the already defined process of the IEC61499

specification, defines a series of phases that cover requirements,

analysis, design, testing, and implementation. This develop-

ment process, which adopts best practices from Software

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472464

Engineering and integrates them with the FB concept, is

described with the notation suggested by the Software Process

Engineering Metamodel (SPEM) specification [12] of the

Object Management Group (OMG).

SPEM is a metamodel for defining processes and their

components. It is limited to the minimal set of process

modelling elements that are necessary to describe any software

development process, without adding specific models or

constraints for any specific area or discipline, such as project

management or analysis. The purpose of SPEM is to support the

definition of software development processes specifically

including those processes that involve or mandate the use of

UML. SPEM specifies and utilizes the following artefacts:

� A

n Element or ModelElement describes an aspect of a

Software Engineering Process.

� A

Process is a complete description of a Software

Engineering process, in terms of ModelElements.

� A

n Activity is the main element of a work and describes what

a ProcessRole performs.

� A

ProcessRole describes the roles, responsibilities and

competencies of an individual carrying out Activities within a

Process. A ProcessRole is responsible for certain Work-

Products.

� A

WorkProduct is a description of a piece of information or

physical entity produced or used by the activities of the

Software Engineering process. Examples are models, code,

documents, etc.

Fig. 2. An activity diagram representing

� A

Guidance is a model element associated with ModelEle-

ments. It contains additional descriptions such as techniques

or guidelines and provides more detailed information to

practitioners about the associated ModelElement. Possible

types of Guidance depend on the process family and can be

for example: Guidelines, Techniques, Metrics, UML Profiles,

Templates, etc.

Fig. 2 shows an activity diagram by means of SPEM

elements that illustrates the CORFU development process. This

diagram presents the sequence of activities with their input and

output work products. ProcessRoles, such as Requirements

Analyst and IPMCS Engineer, in order to implement an IPMCS

application should follow a set of Activities, which are properly

defined.

Three main swimlines have been defined to separate the

responsibilities of the following ProcessRoles: Requirements

and Functional Analyst, IPMCS Analyst and IPMCS

Designer. The Requirements and Functional Analyst captures

the functional requirements of the IPMCS application, by

means of use-case diagrams [13]. During this activity, the use

cases of the IPMCS application are defined to form the

IPMCS Requirements Document. The use cases abstractly

describe the system’s behaviour in response to external events

that originate either from devices or humans. Then, the

IPMCS Analyst using as input the Requirements Document

proceeds to the activities of Capture Application Behaviour

and Capture Application Static View. The former describes

the CORFU development process.

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472 465

the dynamic behaviour of the system. Object Interaction

Diagrams are considered as the first realization of system’s

use cases and are used to show the system’s internal objects

and the way they collaborate to provide the required

behaviour [14]. The latter deals with the static view of the

system that is expressed in terms of class diagrams. Since the

diagrams produced through the above process must be

consistent, the engineer has to go back and forth through these

activities, in order to better specify the analysis and early

design models of the system. Both, Capture Application

Behaviour and Static View activities have as output textual

specification documents and models of the application. The

completion of both activities, signals the continuation of the

process to the activity of IPMCS model inspection and

completion, where the IPMCS Analyst complements the

IPMCS Behavioural, Static and System Layer models adding

model elements, such as state diagrams, if required. This

activity produces also a first version of the System Layer

model that includes the definition of IPTs, which are inserted

into the design space of the System Layer, to properly define

the interaction of the control system with the controlled

process. IPT instances must be assigned to the System Layer

devices (i.e. digital input/output controllers, data acquisition

devices) that interface the application with the controlled

processes of the industrial environment. Each IPT has a

number of Industrial Process Parameters (IPPs), which

constitute the inputs and the outputs of the Control

Application. For instance, the temperature and pressure

might be IPPs of a boiler IPT.

The generated models, i.e. IPMCS Behavioural, IPMCS

Static and System Layer, are used by the IPMCS Designer, to

construct the design model of the application by means of the

IEC61499 Function Block construct. The IPMCS Designer first

executes the Models transformation activity, which utilizes

both IPMCS Behavioural and IPMCS Static models. The

Models transformation activity is supported by the IPMCS

model-to-model transformation Guidance element, a core

concept of the CORFU development process, which is the basis

for the automated transformation process. The IPMCS model-

to-model transformation Guidance element utilizes a metamo-

del-based model transformation technique. Outputs of the

Fig. 3. Applying metamodelling in th

Models transformation activity are a Function Block model

constructed from the OO models, and an updated with specific

elements System Layer model. The IPMCS Designer then

proceeds to the IPMCS IEC61499 Function Block model

definition activity that results in the refinement of the Function

Block model. The Function Block Model contains also details

for the FB types used in the application.

The IPMCS Designer enters also the System Layer

definition activity, an important activity of the process.

During this activity the designer defines, interconnects and

parameterizes elements of the System Layer, such as devices

and fieldbuses. After the completion of both Function Block

model definition and System Layer definition activities, the

designer proceeds with the Function Block application

deployment activity and distributes the FB instances of the

application to the System Layer devices. Finally, the CORFU

development process is complemented by the activity of

verifying the application. It is assumed that the CORFU

development process should be applied iteratively in order to

be effective.

4. Transforming the UML-based model to a FB-based

model

As already mentioned the step after the UML-based analysis

phase is the production of Function Block design diagrams that

are better understood by control engineers.

Since, there was no clear and straightforward way of passing

effortlessly from the UML-based analysis model of the system

to the Function Block-based model, we decided to exploit

metamodelling. Two distinct metamodels were defined in the

IPMCS domain, the IPMCS-UML metamodel and the IPMCS-

IEC61499 Function Block one.

4.1. IPMCS domain metamodel

MDD exploits the transformation of models from one form

to another. Both models, i.e. the source and the target, should be

expressed in their own language, which has to be defined. The

syntax of each modelling language was defined by building a

model of the modelling language, i.e. the language’s

e CORFU development process.

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472466

Fig. 4. Function Block and IPT stereotypes defined in the IPMCS-UML metamodel.

metamodel. This process is analogous to the technique used to

define the UML standard that is written by means of the UML

metamodel [15].

Fig. 3 shows how metamodelling is applied in the CORFU

development process. The source metamodel is the IPMCS-

UML metamodel that was expressed in UML by extending the

UML itself. The target metamodel is the IPMCS-IEC61499

Function Block metamodel that was defined by extending the

IEC61499 specification using Object-Oriented concepts. This

metamodel was also expressed in UML to simplify the model-

to-model transformation process.

4.1.1. The IPMCS-UML metamodel

For the definition of the IPMCS-UML metamodel the

specification of UML 2.0 was used and a subset of the UML

metamodel was identified. Fig. 4 shows the two stereotypes

defined in the IPMCS-UML metamodel: the FunctionBlock and

the IPT stereotype. Both are extensions of the Class metaclass

of UML. Tagged values are defined on both stereotypes, as for

example name and FBtype for the FunctionBlock stereotype.

Constraints are expressed in OCL which is the UML’s language

for the formal specification of constraints [16]. Such a

constraint is shown in the comment box of Fig. 4. This

constraint defines that the public attributes of the Function-

Block stereotype should be ReadOnly by default.

4.1.2. The IPMCS-FB metamodel

The IPMCS-FB metamodel was also expressed in UML

notation. In the first step the basic concepts of the IEC61499

specification were captured. For example, the Function Block

Diagram was specified as an aggregation of FBInstances,

EventConnections and DataConnections. In a subsequent step,

the IEC61499 model was extended with elements from the

CORFU framework, namely the System Layer Diagram, the

Internal Device Diagram, the Industrial Process Terminator

(IPT), the Industrial Process Parameter (IPP) and their

interconnections. Fig. 5 shows part of the IPMCS-FB

metamodel with new classes that have been introduced to

extend the IEC61499 model.

The Internal Device Diagram (IDD), was defined as a

specialization of the Function Block Diagram to allow device

vendors to provide IEC61499 compliant input–outputs for their

devices in the form of IPPs of the underlying process. An IDD is

provided as a black box to encapsulate the device depended

information and help the developer to focus on the design issues

of the application. For example an IDD can encapsulate the FB

network that is required for an 8 bit value to be converted to an

IEC61499-compliant temperature value ready to be connected

to the Function Block network of the application. IPPs are

inserted in the Function Block Diagram and are connected to

the appropriate Function Block instances without worrying

about device specific information.

4.2. The model-to-model transformation process

A set of Transformation Rules has been defined to support

industrial engineers to proceed from the analysis to the design

model. These rules cope in general with the transformation of

Classes, Instances, Class Diagrams and Interaction Diagrams to

equivalent Function Block-based design specifications. The

transformation rules come to accomplish a twofold necessity:

Firstly, to create new Function Block types utilizing declared

classes and the additional information presented in the object

interaction diagrams. Secondly, to create Function Block

instances of these types and interconnect their Event and Data

connections, in order to create Function Block network

diagrams. The defined transformation rules consist of two

main categories:

(a) r

ules that define the information extraction from object

interaction diagrams and

(b) r

ules that define the information extraction from class

diagrams.

These rules, which have been originally described in plain

English in [17], have been enhanced and formally presented

with OCL in the context of the CORFU environment to

automate the transformation process.

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472 467

Fig. 5. Part of the IPMCS-FB metamodel showing new classes introduced in the IEC61499 model.

For the extraction of information from object interaction

diagrams of the application’s model, the following transforma-

tion rules are defined:

(1) F

or every object interaction diagram a Function Block

network diagram is constructed. The so constructed FB

network implements in terms of FBInstances the scenarios

described by the corresponding object interaction diagrams.

The ith Interaction Diagram has the same name with the ith

Function Block Diagram. The OCL specification of this rule

is given below.

(2) E

very Lifeline participating in an object interaction diagram

is transformed to a FBInstance in a target FBDiagram. This

is realized by an iteration to all Lifelines of an Interaction

Diagram and then for every Lifeline an ‘‘equivalent’’

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472468

FBInstance is created in the corresponding FBDiagram.

The FBInstance has the same name as the Lifeline and its

FBType is of the same type with the class represented by the

Lifeline. The new generated FBType has the same name

with the Lifeline class and has as ancestor the Basic

Function Block type (BasicFB). The OCL specification of

this rule is given below.

(3) E

very interaction (message) between two Function Block

stereotyped classes produces part of the EVENT interface

of the Function Block types. The message name will be the

name of the Event Output of the producer Function Block

type, as well as the name of the Event Input of the consumer

Function Block type.

(4) E

very interaction between a Function Block and an

Industrial Process Terminator (IPT) means that an

Industrial Process Parameter (IPP) of the IPT should be

inserted in the Function Block Diagram.

(5) F

or every interaction that has message parameters, these

parameters will be mapped to data inputs and outputs of the

equivalent Function Block types that collaborate.

The following rules will be applied in order to extract

information from class diagrams and insert it into the Function

Block Diagrams:

(1) E

very Function Block stereotyped class is mapped to a

Function Block type. In detail:

� the class name should be the Function Block type name;

� private/protected data members are mapped to internal

data (Internal Variable List) of the Function Block type;

� public data members are becoming the data input (if they

allow only set( ) operations) and data output (if they allow

only get( ) operations) variable names of the Function

Block type;

� public methods should be mapped to Function Block

Event inputs and algorithms. Method parameters should

be data declared on the Function Block type using the

WITH construct, except from get and set methods that

read/write internal variables;

� if a method has a return value, this value can be used as a

data output member.

(2) E

very dependency of the class diagram is mapped to a

Function Block connection.

(3) E

very aggregate class should be mapped to a Composite

Function Block type in case it is composed of classes running

on the same resource. If the aggregate class is composed of

classes running on different resources, the class should be

mapped to a Sub-application Function Block.

(4) E

very IPT stereotype is mapped to an IPT instance. In

detail, set( ) methods are mapped to input-IPPs and get( )

methods are mapped to output-IPPs of the IPT.

An argument might appear here: what are the benefits and

the added value of using UML interaction diagrams to capture

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472 469

Fig. 6. The ‘Feed and Carry object’ test system [21].

system’s behaviour, when the engineer has to know the specific

stereotypes dealing with Function Blocks. The answer on this is

that the stereotype construct provides additional semantics to

the model and is effective during the automated transformation

process. What makes the transformational approach particu-

larly attractive is the fact that the process can be fully automated

by a software tool.

4.3. Automating the development process by a software

tool

For the purpose of demonstrating and supporting the

CORFU development process, a prototype ESS was developed.

This tool, which is called CORFU ESS, comes to support the

control engineer in applying the CORFU development process;

it is compliant with the IEC61499 model and extends it to cover

issues not supported by the standard.

CORFU ESS consists of two software tools: a general

purpose Computer Aided Software Engineering (CASE) tool,

and the CORFU Function Block Development Kit (CORFU

FBDK). For the prototype implementation IBM’s Rose was

selected [18], but any other general purpose CASE tool can be

supported. CORFU FBDK supports the transformation of

UML-based models, created by means of Rose, to Function

Block design specifications. These specifications can be next

refined to produce the design specs of the Control Application,

which are next utilized to support the deployment phase, i.e. the

distribution of the FB network components to the System Layer

devices. The so produced application-assembly spec is saved in

XML format [19] that can be used along with the FB type specs

in XML format by the Archimedes deployer [20] to instantiate

and execute the application. FB types are downloaded into the

specific devices, FB instances are generated, and the necessary

interconnections between FB instances and devices are

automatically created. CORFU ESS can be downloaded from

http://seg.ece.upatras.gr/Corfu.

5. Case study

An example application was developed by means of CORFU

ESS to demonstrate the applicability of the CORFU develop-

ment process. The system used in this case study is the ‘Feed

and Carry object’ first developed by Yamatake [21]. It consists

of a Human Machine Interface (HMI) running on a PC

computer, a Feeder machine which is controlled from a device,

and two conveyers that are controlled from another device. An

object must be moved from the feeder to the conveyer and

carried until the end of the conveyer, as shown in Fig. 6.

5.1. The IPMCS-UML model

The development process starts with the phase of capturing

the application’s requirements, by means of use cases. An

example is the ‘Feed object to conveyer and Carry’ use case

that is described in the following.

The operator sends, through the HMI, a command to the

system to start the Feeder machine. The system sends the

Feeder status and requests from the Feeder to start moving the

object forward, towards the Conveyer. The Feeder sends

continuously the status of sensors S1 and S2 to the system.

When the Feeder is in front of sensor S1 the system sends a

message to the Feeder to start moving backwards. It also sends a

message to the Conveyer to start operating M3 and reports the

status to the HMI. The Conveyer starts moving while

continuously sends the status of sensor S4. When the Feeder

is in front of S2 the system sends a message to the Feeder to stop

moving. When the object is in front of the sensor S4 the system

sends a message to the Conveyer to move M2 and stop M3.

When the object is in front of the sensor S3 the system sends a

message to the Conveyer to stop M2. The system always reports

the status of the Conveyer to the HMI.

The next two activities, i.e. capture system behaviour and

system’s static view, come in parallel. The interaction diagram,

which is the realization of the use case, and the class diagram

that depicts the system’s static view are constructed. Fig. 7

displays a snapshot of an interaction diagram in CORFU ESS,

and particularly the interaction diagram that implements the

‘Feed object to conveyer and Carry’ use case.

5.2. The IPMCS-FB model

According to the proposed development process, the design

phase follows and particularly the activity of designing the

application by means of Function Block network diagrams. At

this stage the transformation process assists the engineer to

automatically construct the Function Block design diagrams by

extracting information from the class and object-interaction

diagrams.

The Transformation Facility Manager (TFM), a built in

utility of CORFU FBDK that implements the transformation

process, reads the internal object model from Rose and applies

the transformation rules to create new kind of constructs such as

FB types, FB instances, etc., that constitute the first draft design

model of the Control Application. This design model is

composed of Function Block type definitions as well as a set of

Function Block network diagrams, such as the one shown in

Fig. 8.

TFM applying the transformation process for our case study

has created the following three Function Block instances:

FeederControler, ConveyerControler, and HMI_Inst. Function

Block types for these instances have also been created

automatically by TFM.

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472470

Fig. 7. A snapshot of an interaction diagram in CORFU ESS.

5.3. The System Layer model

During the next phase the engineer has to utilize the System

Layer editor to design the underlying system on which the

Control Application will be executed. This diagram will be

used to distribute the Function Block instances to the system’s

devices. As shown in the bottom right corner of Fig. 9, the

engineer inserts in the System Layer Diagram IPTs, industrial I/

O, and network devices, and creates the connections between

them. Additionally, for each device the Internal Device

Diagrams (IDD) is defined to transform specific measurements

of the underlying process to IEC61499 compliant values, as for

example the transformation of an analogue measured value to

an IEC61499 temperature value.

5.4. Distributing the Control Application

The final step has to do with the distribution of the FB

instances of the application to the System Layer devices. Fig. 9

shows how the engineer assigns FB instances to devices. In this

example the engineer assigns the FB Feeder instance into the

FeederDevice.

The produced for the ‘Feed and Carry object’ application

assembly spec is saved in XML format. This XML specification

is used along with the FB type specs, which are also in XML

format, by the Archimedes deployer to instantiate and execute

the Control Application. FB types are downloaded into the

specific devices, FB instances are generated, and the necessary

interconnections between FB instances and devices are created

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472 471

Fig. 8. Part of the function flock design diagram of the Feed and Carry application.

Fig. 9. FB instances of the FB network diagram are assigned to the devices of the System Layer Diagram.

automatically. Of course the devices should be equipped with

an IEC compliant execution environment such as the one

provided by RTAI and RTSJ-AXE packages [20].

6. Conclusions

In this paper an approach for the development of distributed

industrial control applications or as defined in IEC61499,

IPMCS applications, is presented. The approach exploits

concepts and latest trends from current Software Engineering

practices. Metamodelling and Model Driven Development as

well as UML and UML’s Profile extensions such as stereotypes

and tagged values were utilized in the domain of distributed

industrial control applications. The approach, which is based on

a four-layer architecture, was defined and described following

the SPEM specification. The model-to-model transformation

process that constitutes a key concept of the proposed process is

presented. This transformation process facilitates the transition

C. Tranoris, K. Thramboulidis / Computers in Industry 57 (2006) 462–472472

from the object-oriented UML analysis model to the Function

Block-based design model of the IPMCS application. An

Engineering Support System, namely CORFU ESS, was

developed to facilitate the application of the so defined

development process to real-world systems. Finally, a case

study demonstrates how a control engineer can apply the

CORFU development process through the CORFU Engineering

Support System to build IPMCS applications.

With the proposed process the control engineer exploits

object technology in the development process of IPMCS

applications while at the same time designs the system with

already known constructs such as the Function Block. The

engineer may focus on operational requirements and not on

implementation issues, to produce a design that is interoperable

and independent of proprietary field devices, re-using already

defined software components.Although latest research shows

that compliance with already installed legacy systems, methods

immaturity and system complexity are the main reasons that

prevent engineers from applying model-driven practices [22],

we strongly believe that future design of industrial applications

will tend to use such practices, in order to enhance their

development cycle, improve their maintainability and relia-

bility and confront the introduced complexity that exists in

nowadays modern systems.

References

[1] IEC61499, IEC Technical Committee TC65/WG6, IEC61499 Industrial –

Process Measurement and Control – Specification, IEC Draft 2001.

[2] IEC61804, IEC sub committee no. 65c: digital communications, working

group 7: function blocks for process control, ‘‘IEC1804 General Require-

ments’’, IEC Draft 2001.

[3] IEC61131, IEC Technical Committee: IEC61131-3 Programmable Con-

trollers—Programming Languages Specification.

[4] UML 2.0, UML 2.0 Superstructure Final Adopted Specification, 2003.

http://www.omg.org/technology/documents/modeling_spec_catalog.ht-

m#UML, cited on November 2004.

[5] G. Booch, J. Rumbaugh, I. Jacobson, The UML User Guide, Addison-

Wesley, 1999.

[6] Rockwell Automation, The Function Block Development Kit, 2002.

http://www.holobloc.com/fbdk/README.htm, cited on November 12,

2004.

[7] K. Thramboulidis, C. Tranoris, Developing a CASE tool for distributed

control applications, The International Journal of Advanced Manufactur-

ing Technology 24 (1/2) (2004).

[8] J. Mukerji, J. Miller, Model Driven Architecture, 2003. www.omg.org/cgi-

bin/doc?ormsc, cited on September 2004.

[9] C. Atkinson, T. Kuhne, Model driven development: a metamodeling

foundation, IEEE Software 20 (5) (2003) 36–41.

[10] Selic Bran, The pragmatics of model-driven development, IEEE Software

20 (5) (2003) 19–25.

[11] R. Lewis, Modelling control systems using IEC61499, The Institution of

Electrical Engineers (2001).

[12] SPEM, Software Process Engineering Metamodel, 2002. http://www.om-

g.org/cgi-bin/apps/doc?formal/02-11-14.pdf, cited on March 5, 2004.

[13] I. Jacobson, Object-Oriented Software Engineering: A Use-Case Driven

Approach, Addison-Wesley, 1992.

[14] K. Thramboulidis, Using UML in control and automation: a model driven

approach, in: Proceedings of the Second IEEE International Conference

on Industrial Informatics (INDIN’04), Berlin, Germany, June 24–26,

2004.

[15] S.J. Mellor, A.N. Clark, T. Futagami, Model driven development, IEEE

Software (2003) 14–18.

[16] UML 2.0 OCL, UML 2.0 OCL Final Adopted Specification, 2003. http://

www.omg.org/cgi-bin/apps/doc?ptc/03-10-14.pdf, cited on November

2004.

[17] C. Tranoris, K. Thramboulidis, From requirements to function block

diagrams: a new approach for the design of industrial applications, in:

Proceedings of the 10th IEEE Mediterranean Conference on Control and

Automation, MED’02, 2002.

[18] IBM Rational Software, 2003. http://www.rational.com, cited on February

6, 2003.

[19] M. Erdmann, R. Studer, How to structure and access XML documents with

ontologies, Data and Knowledge Engineering, 2001.

[20] K. Thramboulidis, A. Zoupas, Real-time Java in control and automation: a

model driven development approach, in: Proceedings of the 10th IEEE

International Conference on Emerging Technologies and Factory Auto-

mation (ETFA’05), Catania, Italy, September 2005.

[21] Yamatake, Feed and Carry, 2004. http://www.holobloc.com/stds/iec/

tc65wg6/presentations/feed_carry_test.pdf, cited January 2005.

[22] B. Graaf, M. Lormans, H. Toetenetl, Embedded software engineering: the

state of the practice, IEEE Software 20 (6) (2003).

Christos Tranoris is a researcher in the Software

Engineering Group of the Electrical and Computer

Engineering at the University of Patras, Greece and

he is currently working on CORFU, a framework for

the unified development of distributed Factory Auto-

mation systems. He received his PhD in electrical

and computer engineering from the University of

Patras. His research areas cover object-oriented tech-

nology, Model Driven Development, distributed con-

trol and automation systems software. He is a

member of the IEEE and ACM.

Kleanthis Thramboulidis received his BSc and PhD

degrees in electrical engineering from the University

of Patras, Greece, in 1981 and 1989, respectively.

Currently he is an associate professor in software

engineering in the Department of Electrical and

Computer Engineering at University of Patras,

Greece, where he is leading the Software Engineer-

ing Group. He has authored four books on program-

ming and modelling (in Greek) and proposed a

constructivism-based approach to teach object

oriented programming. His research areas cover object technology, Model

Driven Development, metamodelling, distributed control and automation sys-

tems, embedded systems, CASE tools, component-based development, Mecha-

tronics. He has proposed Model Integrated Mechatronics (MIM), a new

paradigm for the Model Driven Development of Mechatronic Manufacturing

systems.