2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
“©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promo-
tional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component
of this work in other works must be obtained from the IEEE.”
Using UML in Control and Automation: A Model Driven Approach
Kleanthis C. Thramboulidis
Electrical & Computer Engineering, University of Patras, 26500 Patras, Greece, e-mail: thrambo@ee.upatras.gr
Abstract—The Function Block (FB) has been defined by the
International Electro-technical Commission as the basic con-
struct for the development of reusable, interoperable, distrib-
uted control applications. However, the FB does not exploits
recent advances in software engineering. The Unified Model-
ing Language (UML) is the new industry standard for model-
ing software-intensive systems. UML brings in the develop-
ment process the best software engineering practices. In this
paper, we examine the use of UML in control and automation
and describe the use of a hybrid approach in the development
process of distributed control systems. The proposed approach
integrates UML with the already well accepted by control en-
gineers FB construct, to cover the analysis and design phases
of the development process. A model driven approach is
adopted to move from analysis through design, to implementa-
tion. The applicability of the UML profile for Schedulabity,
Performance and Time, to the proposed development process,
is also examined.
Index Terms— Control and automation, Distributed Con-
trol Systems, UML, Function Block, model driven develop-
ment, UML profile.
I. INTRODUCTION
The majority of today’s Distributed Control Systems
(DCSs) consist of industrial-grade computers or PLCs,
which are interconnected by dedicated fieldbus networks.
Control applications are usually developed in the form of
large monolithic software packages that are difficult to
maintain, modify, and extend [1]. The market is dominated
by a small number of very large corporations with proprie-
tary solutions and the engineering tools used in the devel-
opment and deployment processes address a little, or not at
all, dimensions such as modularity, flexibility, extensibility,
reusability, and interoperability. Even one of the most com-
mon design and analysis tools for control systems, the fam-
ily of MATLAB products, tends to generate monolithic
rather than component based C language code, which
makes the validation and code update more difficult as re-
ported by Heck et al. in [2].
The International Electro-technical Commission (IEC),
in an attempt to define an open standard for DCSs, has de-
fined the basic concepts and a methodology for the design
of modular and re-usable systems. The IEC61499 standard
[3] defines the Function Block (FB) as the main building
block and the way that FBs can be used to define robust, re-
usable software components that constitute complex DCSs.
However, the FB approach does not incorporate current
practices of software engineering. Advances in software
technologies may facilitate the development and deploy-
1
ment of complex control systems. Heck et al. give in [2] a
tutorial overview of specific new software technologies that
are useful for the implementation of complex control sys-
tems and claim that component based architectures, and the
object-oriented approach are technologies very promising
for the control and automation application domain. Object-
Technology has attracted the interest of researchers in con-
trol and automation from the early 90’s.
In this paper, we examine the use of the Unified Model-
ing Language (UML) [4], which is the new industry stan-
dard for object-oriented development, in the control and
automation domain. We discriminate and briefly describe
three approaches that dominate the DCS domain. We have
adopted, in the context of the CORFU project, the so called
“hybrid approach”. This approach integrates UML with the
already well accepted by control engineers FB construct, to
cover the analysis and design phases of the development
process. A model driven approach is followed to move
from analysis through design, to implementation. IBM’s
Rational Rose is utilized to cover the analysis and early de-
sign phases. CORFU FBDK is used to automate the trans-
formation of the so created UML models to FB design
models. These design models are next translated to execu-
table models following a fully automated model-to-model
transformation process. Two alternatives for the implemen-
tation model are considered and briefly described. The ap-
plicability of the UML profile for Schedulability, Perform-
ance and Time (SP&T) [5] to the proposed development
process, is also examined. A simplified control system, the
Teabag Boxing Control System (TBCS), is used as a run-
ning example throughout the paper.
The remainder of this paper is organized as follows: In
the next section, we refer to UML, as a notation to model
software systems and we briefly present a historical per-
spective that exploits the power of this new industry stan-
dard. In section 3, we discriminate and briefly describe
three possible scenarios for the development of today’s
DCSs. Our model driven approach is described in section
4. In section 5, the applicability of the UML profile for
SP&T is examined. Finally, we conclude the paper in the
last section.
II. UML: A MODELING NOTATION
A . Modeling of software systems
Modeling, which is as old as engineering, is the design-
ing of software applications before coding. It is an essential
part of large software projects, and helpful to medium and
even small projects as well [6]. A large number of methods
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
have been proposed, in the last years, to support the crea-
tion of models for software systems. Until 1989 the pro-
posed methods followed the structured approach with the
structured analysis and structured design (SA/SD), created
by Yourdon and Constantine in 1987, to be considered the
most widely used method. An updated version of this
method, called Modern Structured Analysis, was published
in 1989 by Yourdon. However, this method did not attain
wide acceptance since: a) the complexity of today’s sys-
tems is almost impossible to be handled by the traditional
procedural-like approaches, and b) many new proposals,
following the more promising object-oriented (OO) ap-
proach, appeared at the same time. The great advantage of
the OO paradigm, which has been gradually accepted dur-
ing the last decade, is the conceptual continuity across all
phases of the software development process [7]. In the
90’s, at least 20 object-oriented methods have been pro-
posed in books and many more have been proposed in con-
ference and journal papers. A survey and a classification
scheme for object-oriented methodologies can be found in
[7]. In the same article, the author states that, “after more
than thirty years since the first OO programming language
was introduced, the debate over the claimed benefits of the
object-oriented paradigm still goes on. But there is no
doubt that most new software systems will be object-
oriented; that no-body disputes.” Wieringa surveyed, in [8],
state-of-the-art structured and object-oriented development
methods. He identifies the underlying composition of struc-
tured and object-oriented software specifications and inves-
tigates in which respect OO specifications differ essentially
from structured ones. The last specification method in his
catalogue of OO methods is the Unified Modeling Lan-
guage version 1.0.
UML is the new industry standard for modeling soft-
ware-intensive systems. UML was conceived as a general-
purpose language for modeling object-oriented software
applications. The language represents a further abstraction
step away from the one provided by high level program-
ming languages, which are close to the underlying imple-
mentation technology. The easiest answer to the question
“what is UML?” is, according to Quatrani [9], the follow-
ing: “UML is the standard language for specifying, visual-
izing, constructing, and documenting all the artifacts of a
software system.”
B . UML: A historical perspective
The UML started out as a collaboration among three
outstanding methodologists: Grady Booch, Ivar Jacobson
and James Rumbaugh. At a first step Booch and Rumbaugh
collaborated to combine the best features of their individual
object-oriented analysis and design methods reported in
[10] and [11] correspondingly and they presented at
OOPSLA in 1995, the Unified Method version 0.8. At that
time, the Unified Method was both a language and a proc-
ess. Later, Jacobson joined the group and contributed the
best features of the OOSE methodology that is presented in
[12]. The result of this collaboration was the separation of
the language from the process, which was later described in
[13]. The language was defined and was presented in 1996
as UML 0.9. Later, in January 1997 they submitted their
initial proposal as UML 1.0. Since then the standardization
2
odyssey of UML is in evolution.
Kobryn in [14] placed the end of this odyssey to 2001
but UML 2.0 had a long way to go. Crawford in [15] notes
that “proposals of the UML2 are now under consideration,
and what’s clear is the future is unclear.” As Miller in [16]
argues, UML1 unified several of the competing schools of
modeling; however some equally important ideas for good
OO design did not influence the language. Further more, a
lot of problems have been cited as for example by Kobryn
in [14] and [17], and by Dori in [18]. These errors are wait-
ing for a solution in UML2. A spirited debate on the future
of UML is in evolution. Five groups submitted proposals in
response to the OMG RFPs but hopefully there is a desire
for a consensus version as reported by Miller in [19]. They
all agree, as reported by Miller and Mukerji in [20], that
UML2 should be in the context of OMG’s Model Driven
Architecture (MDA) initiative, which considers as primary
artifacts of software development not programs, but models
created by modeling languages. Artifacts of the Unified
Modeling Language should be used to create the platform
independent model, which should then be mapped by a
model compiler into a platform-specific model, as Mellor
states in [21].
The large number of practitioners and researchers that
have adopted UML at a rate exceeding even OMG’s most
optimistic predictions is a strong argument for UML ver. 2
to follow an evolutionary rather than revolutionary ap-
proach. However, as Selic et al. state in [22], “the same
forces have also created a strong pressure to improve the
effectiveness of UML and provide it with a multitude of
new features.” The one thing that is accepted by all parties
is that the language’s popularity has confirmed the urgency
for a standard communication medium for humans and
software tools. It is already widely accepted that UML2
will drive the software development industry for the next
decades.
UML is methodology-independent, which means that
UML can be used as a notation to represent the deliverables
defined by the methodology regardless of the type of meth-
odology used to perform the system’s development, i.e.
whether it is rigorous such as the Unified Process that is
defined by Jacobson et al. in [23], or lightweight such as
the Extreme Programming that is defined by Paulk in [24].
In any case, the methodology will guide the engineer in de-
ciding what artifacts to produce, what activities and what
workers to use to create and manage them, and how to use
those artifacts to measure and control the project as a whole
as is reported by Booch et al. in [25].
The twelve diagram types that can be used to model
every aspect of the system make UML extremely expres-
sive, allowing multiple aspects of a system to be modeled at
the same time. However, this expressiveness comes at a
price. UML is extremely large with many notational possi-
bilities as claimed by LeBlanc and Stiller in [26]. Thram-
boulidis in [27] presents a subset of the UML that repre-
sents the core of the language. The presented subset will
allow the control engineer to understand the basic concepts
of the language and communicate through UML diagrams,
the knowledge of the DCS that is under development.
Last years there is a trend to use UML in control, indus-
trial automation, as well as in industrial enterprise integra-
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
tion. A lot of papers present examples of using the UML in
many different levels of manufacturing information sys-
tems. However, there is a wide gap between the state-of-
the-art in software engineering and the state of practice in
industrial applications.
III. CONTROL AND AUTOMATION SOFTWARE
DEVELOPMENT: POSSIBLE SCENARIOS
In this section we try to address the following question
“So, what is the future in control and automation software
development?”. We discriminate three possible directions:
• UML-based approaches,
• Function Block-based approach, and
• Hybrid approaches integrating UML with the
Function Block concept.
We next make a brief reference to these approaches.
A. UML-based approaches
According to this approach the standard UML notation
is used to produce the models of the control system. This is
the approach proposed by many researchers such as Doug-
las in [28], Gomma in [29], Young et al. in [30], and
Mosemann and Wahl in [31]. The system is represented us-
ing multiple models. Each model describes the system from
a distinctly different perspective. Three kinds of views are
defined at the top level [33]. The structural classification
view considers the things of the system and their relation-
ships with each other. Class diagrams are used to express
the static view of the system, use case diagrams to express
the use case view, and component and deployment dia-
grams to express the implementation view. The dynamic
behavior view describes the different aspects of the applica-
tion’s dynamic behavior. Statechart diagrams are used to
express the state machine view; activity diagrams to ex-
press the activity view; sequence and collaboration dia-
grams to express the interaction view of the system. The
model management view describes the organization of the
system models into hierarchical units. Class diagrams are
used to express the organization of the system models into
hierarchical units.
The big disadvantage of this approach is that it is a com-
pletely new approach for practitioners in control and auto-
mation, which are mainly accustomed with IEC languages
and concepts.
B. Function Block-based approach
This approach, which is the one proposed by the evolv-
ing IEC standards 61499 and 61804 [34], is based on the
function block construct. Although many researchers are
already working on different aspects of the IEC proposal as
for example Vyatkin and Hanisch [35], Brennan and Norrie
[36], Fletcher and Norrie [37], Thramboulidis and Tranoris
[38], the absence of tools and products that are compliant
with this approach is evident. The Function Block Devel-
opment Kit (FBDK) by Rockwell Automation and the
CORFU-FBDK [39] are the only known tools supporting
this approach.
However, it should be mentioned that the IDA architec-
ture, which is proposed by the IDA group (http://www.ida-
group.org), proposes an application model that is based on
3
the reference architecture defined in IEC61499. Also the
Profinet Engineering Model, which is the proposal of the
Profibus User Organization to achieve open distributed
automation, even though non IEC-compliant, is planned to
have an IEC-compliant mapping in the near future.
The big advantage of this approach is that it exploits the
experience of industry’s practitioners and easily integrates
the big number of existing legacy applications and systems.
However, it does not exploit all the benefits of object and
component technologies.
C. The Hybrid approach
This approach integrates the UML notation with the
function block concept. However, this integration is done
from different perspectives. Brennan et al. in [40] describe
two approaches for modeling decentralized Manufacturing
Systems with UML capsules. They propose the modeling of
the control system at the conceptual level using UML-RT
[41] and then they propose a mapping of UML-RT to IEC
61499 models that are used for the implementation of con-
trol application. However, a) the described model is not
implementable (at least with the information given in the
paper), b) no evidence for a reference implementation is
given, and c) it is quite difficult for control engineers to
model in UML-RT.
The approach presented by Thramboulidis in [42], and
Thramboulidis and Tranoris in [39] and [43], considers the
use of the UML notation in the requirements specification
phase using the concept of use case. The UML analysis
models are next transformed to FB based models, applying
a set of well-defined mapping rules. A specific tool, the
CORFU model transformer, automates this process.
In this paper, we adopt a model driven development
process and describe the process of moving from FB-design
models to implementation models.
IV. A MODEL DRIVEN APPROACH
The Model Driven Architecture (MDA) [47], which is
consistent with the MIC paradigm firstly presented by Szti-
panovits et al. in [44], is an initiative that considers as pri-
mary artifacts of software development not programs, but
models created by modeling languages. Artifacts of the
UML are used to create the platform independent model,
which then is mapped by a model compiler into a platform-
specific model. In this way the development process is de-
fined as a transformation of models, which constitute in-
stances of meta-models that are defined by domain experts.
To illustrate the proposed approach we are using as run-
ning example our Teabag Boxing system (TBS) case study.
TBS is a simplified version of a real system used in the pro-
duction chain of packed teabags. The system receives tea-
bags from a teabag producer, checks their weight and for-
wards them either for packaging to a valid-teabag con-
sumer, or for recycling to an invalid-teabag consumer. TBS
is composed of: a) a scale, for weighing teabags, b) a
feeder, for rejecting out-of-range teabags, and c) 3 con-
veyor belts for moving teabags.
Figure 1 presents the environment model of the Teabag
Boxing System (TBS) and its main components: a) the
TBCS that is the controlling system, and b) the Teabag
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
Boxing Mechanical Process (TBMP) that is the controlled
system. Sensors and actuators are embedded in the Teabag
Boxing Mechanical Process.
We consider the development of the mechanical process,
namely the TBMP, to be carried out independently of the
development process of the controlling system. A more
promising approach based on model integration is proposed
in [32]. This approach is the first step to what we call
Model Integrated Mechatronics.
Figure 2 presents an abstract model of the Teabag Box-
ing Mechanical Process with the appropriate primary sen-
sors and actuators.
Fig. 1. The Teabag Boxing System
Fig. 2. Abstract model of the Teabag Boxing Mechanical Process.
A. Applying the Model Driven Approach
Domain specific model interpreters are used by CORFU
FBDK to transform the more-PIM, to more-PSM with the
objective to obtain a fully automated production of the im-
plementation model. CORFU FBDK fully exploits the
IEC61499 function block concept and the UML notation,
as well as current practices in distributed real-time soft-
ware. Domain mapping rules are used to describe the map-
ping of the source-domain metamodel constructs to target-
domain metamodel constructs. Figure 3 illustrates the
model driven approach adopted for the transformation of
UML analysis models to FB design models.
Domain mapping Design Domain
Analysis Domain
Metamodel
rules Metamodel
implements
UML- FB-based
CORFU Model
based Transformer Model
Model
Fig. 3. The model based transformation process.
The control engineer using a CASE tool, such as the
IBM’s RT Rose, defines, in terms of UML, the require-
ments model of the control application as an instance of our
4
analysis domain metamodel. However, the proper stereo-
types should be embedded as primitive constructs in the
CASE tool.
Use cases are used as a means to capture requirements.
Table I presents the list of use cases for the TBS. For each
use case an initiating Industrial Process Terminator (IPT) is
defined which is either the Operator or an entity of the me-
chanical process.
Table I : Use cases for the TBCS
Use case title Initiating IPT
1 Initialize TBS Operator
2 Stop system Operator
3 Weight teabag Scale (S0)
4 Cary teabag on conveyer-2 Feeder (S1)
5 Cary teabag on conveyer-1 belt-1 Scale (S6)
6 Cary teabag on conveyer-1 belt-2 Conveyer1 (S4)
7 Valid-teabag finished processing Conveyer1 (S3)
8 Teabag recycled Conveyer2 (S5)
9 Feeder Arm Reaches Initial Position Feeder (S2)
We next give the “Carry Teabag to conveyor-1 belt-2”
use case to demonstrate our slightly modified notation for
use cases to capture the semantics of control applications.
Use case: Carry Teabag to conveyor-1 belt-2
Initiating IPT: Conveyor-1 belt-1 IPP: Teabag leaving
Conveyor-1 Belt-1 (S4)
Involved IPTs: Conveyor-1 Belt-1 M3 (out), Conveyor-1-
Belt-2 M2 (out)
Precondition: Conveyor1-Belt-1 is in the MOVING state.
Description
The Conveyor-1 Belt-1 notifies the system (through S4)
that the Teabag has been moved on conveyor-1 belt-2. The
system decrements the internal representation of the num-
ber of teabags on conveyor-1 belt-1. If the number of tea-
bags is zero it sends a STOP message to conveyor-1 belt-1
(M3). The system checks the number of teabags on con-
veyor-1 belt-2 (internal representation). If the number of
teabags is zero it sends a MOVE FORWARD message to
conveyor-1 belt-2 (M2) and increments the number. The
use case is terminated.
Postcondition: Conveyor-1 belt-2 is in the MOVING state.
Exceptions: [tbd]
For the use case realization, we use Component Interac-
tion Diagrams (CIDs) of two levels of abstraction: a) the
first-level CID, which captures the interactions of the con-
trol application represented as a component, with external
entities, and b) the second-level CID (detailed-CID), in
which the components required to compose the system for
the described behavior to be obtained, should be identified
and their collaboration should be defined. Figure 4 presents
the detailed CID of the “Carry Teabag to conveyor-1 belt-
2”. This CID is considered as the first formal realization of
this use case. Components of type IPT stereotype and FB
stereotype are used to create the component collaboration
required for the system to implement the described use
case.
The CORFU model-to-model transformer that has been
implemented as part of the CORFU FBDK, automatically
translates the UML analysis model, to FB-based design
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany

model. Timing constraints that have already been expressed

in the form of end-to-end response time in CID diagrams,
should be spitted to the corresponding FB computational
path and result to: a) FB execution constraints that con-
strains FB Execution Time (FBET), and b) message trans-
fer constraints that constraint message propagation. FBET
is the amount of time the FB needs to finish its reaction,
provided that it is not preempted by another FB. It repre-
sents the actual time spent on FB’s execution. FBET is used
to determine schedulability and resource utilization. The
timing constraints are attached to messages and include
deadline or priority constraint. These constraints should be
annotated on the model to make the automated software
synthesis process more effective. The annotated model is
further refined and converted to a more platform specific
model ready to be used for the production of the implemen-
tation model. For the transformation of the design model to
executable code we are briefly describing the following two
approaches:
1. Model transformation to C++ code, and
2. Model transformation to UML-RT models.
A prototype model transformer for C++ code was devel-
oped by P.Manesis and is described in detail in [46].
B. Using UML-RT in the model transformation process
To obtain a more flexible code generation process than
the one described above, we considered the use of UML-
RT. Modeling constructs of IEC61499 have quite similar
semantics with UML-RT constructs. This enables the trans-
formation of FB design diagrams to equivalent UML-RT
design diagrams. The most important task for this transfor-
mation is the definition of the FB transformation. We next
describe the FBCapsule capsule, which has been defined
to represent the semantics of the IEC61499 active basic FB.
Classes may be used to represent passive FBs to improve
the efficiency of the system, but this mapping is still under
investigation. The class diagram of Figure 7 shows the
composition structure of the FBCapsule, which we utilize
as a template for the transformation of application net-
work’s FBs to capsules of the resulting implementation
model defined in terms of UML-RT constructs.
//states definition
//events definition
class <fb name>{
:
void OnEvent(<fb name>Event event);

private:
void Execute(<fb name>Event event);
bool ChangeState(void);
void SetInputEventVariables(<fb name>Event
event);
void ResetEventInputVariables(void);
void ResetEventOutputVariables(void);
:
};

Fig. 5. Part of the header file used as pattern in the C++ code generation
Fig. 4. A sample CID for the Teabag Boxing Control system. process.

#include "StdAfx.h"
Two alternative abstract implementation meta-models #include "fb6type.h"
independent of run time platform are presented and de- #include "afxwin.h"
scribed in detail by Thramboulidis et al. in [45]. <fb name>::<fb name>(void) {}//Constructor
<fb name>::~< fb name >(void){} //Destructor
void <fb name>::OnEvent(<fb name>Event event){
B. FB design model to C++/Java implementation model Execute(event);}
void <fb name>::Execute(<fb name>Event event){
The XML representation of FB design diagrams is SetInputEventVariables(event);
parsed and it is automatically translated to C++ or Java :
source code. For each FB type a C++ header and a C++ while(ChangeState()==true){
switch(current_state){
.cpp file is created. The header file contains: a) definitions :
for states, b) definitions for events, and c) a class corre- }
ResetEventInputVariables();
sponding to the FB type. Active FBs are mapped to Java }
threads or native threads in case of C++ code. ResetEventInputVariables();
A template has been defined for the generated header ResetEventOutputVariables();
}
file, as well for the .cpp file, for the transformation process void <fb name>::SetInputEventVariables(<fb
to be fully automated. Figure 5 presents part of the header name>Event event){
template and figure 6 part of the .cpp template. The exe- switch(event){
: }
cute() and changeState() methods are used to implement the }
FB’s ECC. For the definition of the body of the execute() bool <fb name>::ChangeState(void){
method the following pattern is used. bool transmission_done=0;
switch(current_state){
[for each fb state append] :}
case <fb name>_<state name>_STATE: return transmission_done;
[for each algorithm of state append] }
this-><algorithm name>; void <fb name>::ResetEventInputVariables(void){}
<external fb name>.Set<data input name>; void <fb name>::ResetEventOutputVariables(void){}
<external fb name>.OnEvent(<fb name>_
<eventname>_EVENT); Fig. 6. Part of the .cpp file used as pattern in the C++ code generation
break; process.

5
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
Figure 8 shows FBCapsule’s structural containment
and its communication relationships. We have mapped: a)
the input and output events of the FB to the EventPort port,
b) the input and output data of the FB to the DataPort port,
c) the internal data and events of the FB to corresponding
classes, d) the algorithms of the FB to operations of the
FBBody class, and d) the head of the FB to the FBHead
subcapsule. We have also adopted a port for the configura-
tion of the resulting capsule.
The resulting UML-RT model is translated to executable
model for a number of platforms using the automatic code
generation feature of RT Rose.
Fig. 7. Composition structure of the FB capsule template
Fig. 8. Structural containment and communication relationships of FBCap-
sule.
A detailed description of this approach is given in [45].
A prototype implementation for the TBCS has been devel-
oped using IBM’s RT Rose to demonstrate the applicability
of the approach.
V. UTILIZING THE UML PROFILE FOR SCHEDULABILITY
PERFORMANCE AND TIME
The UML profile for SP&T Specification is an attempt
of OMG to add in the standard UML notation, lacking
quantifiable notions of time and resource that will allow the
use of UML in the real-time and embedded domain. The
profile utilizes the lightweight extensibility mechanisms of
UML to model resource and time-related aspects that con-
stitute the key characteristics of timeliness, performance
and schedulability. The created framework is general
enough to be adopted and specialized by the FB-based ap-
proach in the development of DCSs. It will allow the next
generation ESSs to support many different analysis tech-
6
niques from the real-time software domain since it captures
the common elements of different real-time specific model
analysis methods and the essential patterns that are used in
deriving time based analysis models from application mod-
els. The ESS, adopting the concept of the quality of service
(QoS) through this profile, will allow the control engineer
to attach quantitative information to FB models in a uni-
form basis. QoS information annotated on the FB model
should represent, directly or indirectly, the physical proper-
ties of the hardware and software environments of the sys-
tem that are represented by the application and system layer
models as defined by the 4 layer CORFU architecture[39].
More specifically, the UML profile for SP&T by adding
to FB models specific annotations about required QoS,
should allow the new generation ESSs to: a) support the
analysis of FB models in the early development phases to
make predictions on these characteristics and detect prob-
lems that can be removed at a much lower cost and with
less rework, and b) to support the deployment process of
FB applications considering the required by the application
and the offered by the system layer QoSs.
Specific annotations on the FB model should allow a
wide variety of schedulability techniques to be applied. The
schedulability model of the system should allow the control
engineer to determine whether or not a model is schedul-
able i.e. it will be able to meet its guaranteed response
times. The ESS should allow the engineer to calculate the
schedulability of the systems i.e. its ability to meet all of the
deadlines defined in the design space, as well as to assist
with determining how the system can be improved, as for
example suggesting for making an entity schedulable or op-
timizing system usage for a more balanced system.
The big advantage of utilizing this profile is that control
engineers should be able to construct models of their DCSs
and utilize the different type of model analysis techniques
in order to determine whether these models meet their per-
formance and schedulability requirements, without requir-
ing a deep understanding of the inner working of those
techniques. However, even though this approach is charac-
terized by its flexibility and powerfulness, it may be proved
to be a balk towards the profile’s wide adoption especially
until proper tools will appear in the market.
VI. CONCLUSIONS
In this paper we have examined the use of the UML in
the development process of DCSs. We adopted a hybrid
approach that integrates UML with the FB construct and
we described our model driven approach that can lead the
engineers through a model transformation process from the
UML use case requirements models to FB-design models
and then to the implementation model through the use of
UML-RT. The proposed model driven approach enables us
to fully exploit available distributed real-time software
technologies such as real-time Java, real-time Linux, real-
time CORBA, real-time UML and XML in the domain of
DCSs. The exploitation of these technologies for the im-
plementation of the IEC-compliant CORFU system plat-
form greatly enhances the development cycle of DCSs.
The UML profile for Schedulability, Performance and
Time, may be exploited to improve the development proc-
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany
ess and allow the schedulability analysis of the control ap-
plication as well as its deployment to the execution envi-
ronment. However, a UML profile for control and automa-
tion should provide the best alternative for the development
of control applications. Such a profile should primarily in-
tend to tailor UML towards the control and automation do-
main. It should provide to modelers: a) access to common
model elements, and b) terminology from the control and
automation domain.
VII. ACKNOWLEDGMENTS
I gratefully thank the CORFU development group and
especially Peter Manesis for the prototype implementation
of the FB-to-C++ model transformer, and Alexandros
Fantzis for the prototype implementation of the TBCS us-
ing IBM’s RT Rose.
VIII. REFERENCES
[1] R. Lewis, Modeling control systems using IEC 61499, The Institution
of Electrical Engineers, 2001.
[2] B. Heck, Wills, L. and Vachtevanos G. “Software Technology for
Implementing Reusable, Distributed Control Systems”, IEEE Control
Systems Magazine, February 2003.
[3] IEC Technical Committee TC65/WG6, IEC61499 Industrial-Process
Measurement and Control – Specification, IEC Draft 2000.
[4] OMG, “OMG Unified Modeling Language Specification”, Version
1.5, Object Management Group Inc., http://www.omg.org/technol-
ogy/documents/formal/uml.htm
[5] OMG, “UML Profile for Schedulability, Performance, and Time
Specification, Ver. 1.0, September 2003.
[6] OMG, “Introduction to OMG’s Unified Modeling Language”, avail-
able on line, http://www.omg.org/gettingstarted/ what_is_uml.htm.
[7] L. Capretz, “A Brief History of the Object-Oriented Approach”,
Software Engineering notes vol. 28, no. 2, ACM SIGSOFT, March
2003.
[8] R. Wieringa, “A Survey of Structured and Object-Oriented Software
Specification Methods and Techniques”, ACM Computing Surveys,
Vol. 30, No. 4, December 1998.
[9] T. Quatrani, “Introduction to the Unified Modeling Language”, Ra-
tional Rose 2001, White paper, Available Online:
http://www.rational.com/media/uml/intro_rdn.pdf?SMSESSION=NO
[10] G. Booch, Object-Oriented Analysis and Design with Applications,
second edition, Benjamin/Cummings Pub. Company, Inc.1994.
[11] J. Rumbaugh, et al., Object-Oriented Modeling and Design, Prentice
Hall International 1991.
[12] I. Jacobson, Object-Oriented Software Engineering: A Use Case
Driven Approach, ACM Press, Addison Wesley 1992.
[13] I. Jacobson, G, Booch, J. Rumbaugh, The Unified Software Devel-
opment Process, Addison Wesley 1999.
[14] C. Kobryn, “UML 2001: A Standardization Odyssey”, Communica-
tions of the ACM, October 1999, Vol. 42, No.10.
[15] D. Crawford, “Editorial Pointers”, Communications of the ACM,
November 2002, Vol. 45, No.11.
[16] J. Miller, “What UML Should Be”, Communications of the ACM,
November 2002, Vol. 45, No.11.
[17] C. Kobryn, “Will UML 2.0 Be Agile or Awkward?”, Communica-
tions of the ACM, January 2002, Vol. 45, No.1.
[18] D. Dori, “Why Significant UML Change is Unlikely”, Communica-
tions of the ACM, November 2002, Vol. 45, No.11.
[19] J. Miller, “What UML Should Be”, Communications of the ACM,
November 2002, Vol. 45, No.11.
[20] J. Miller, and J. Mukerji, “Model Driven Architecture (MDA)”,
Document number ormsc/2001-07-01, Architecture Board ORMSC,
July 9, 2001. Available online: http://www.omg.org/docs/ormsc/01-
07-01.pdf
[21] S. Mellor, “Make Models Be Assets”, Communications of the ACM,
November 2002, Vol. 45, No.11.
[22] B. Selic, Ramackers, G., Kobryn, C., Evolution Not Revolution”,
Communications of the ACM, November 2002, Vol. 45, No.11.
7
[23] I. Jacobson, G, Booch, J. Rumbaugh, “The Unified Process”, IEEE
Software, Vol. 16, No. 3, May/June 1999.
[24] N.C. Paulk, “Extreme programming from a CMM perspective”, IEEE
Software, Vol. 18 No 6 , Nov.-Dec. 2001.
[25] G. Booch, Rumbaugh, J., Jacobson, I., The Unified Modeling Lan-
guage User Guide, 1999, Addison Wesley Longman Inc.
[26] C. LeBlanc and E. Stiller, “UML for Undergraduate Software Engi-
neering”, JCSC 15, 5 (May 2000), Consortium for Computing in
Small Colleges.
[27] K. Thramboulidis, “Unified Modeling Language: The Industry Stan-
dard for Object-Oriented Development”, chapter in Industrial Infor-
mation Technology Handbook, CRC Press, (forthcoming).
[28] B. Douglas “Doing Hard Time: Developing Real_time Systems with
UML, Objects, Frameworks, and Patterns”, Addison Wesley 1999.
[29] H. Gomma, Designing Concurrent, Distribute, and Real-Time Appli-
cations with UML, Addison Wesley 2000.
[30] K., Young, R. Piggin, P. Rachitrangsan, “An Object-Oriented Ap-
proach to an Agile Manufacturing Control System Design”, Int.
Journal of Advanced Manufacturing Technology, Vol. 17, Springer-
verlag 2001.
[31] H. Mosemann, F. Wahl, “Automatic Decomposition of Planned As-
sembly Sequences Into Skill Primitives”, IEEE transactions on Ro-
botics and Automation, Vol. 17, No. 5, October 2001.
[32] K. Thramboulidis, “Model Integrated Mechatronics: An Architecture
for the Model Driven Development of Mechatronic Systems”, 2nd
IEEE International Conference on Mechatronics, Istanbul, Turkey
2004.
[33] J. Rumbaugh, I. Jacobson, G., Booch, The Unified Modeling Lan-
guage – Reference Manual, 1999, Addison Wesley Longman Inc.
[34] IEC Technical Committee No. 65C: Digital Comm., WG 7: Function
blocks for Process Control , IEC1804 General Requirements, IEC
Draft 1999
[35] V.Vyatkin, H.Hanisch, “Formal-modelling and Verification in the
Software Engineering Framework of IEC61499:a way to self-
verifying systems”, IEEE Conference on Emerging Technologies in
Factory Automation (ETFA'01), Proceedings, Nice, pp 113-118, 15-
18 October, 2001.
[36] X. Brennan, X. Norrie, “Agents, holons and function blocks: distrib-
uted intelligent control in manufacturing, Journal of Applied System
Studies”, Special Issue on Industrial Applications of Multi-Agent and
Holonic Systems 2(1) (2001), 1-19.
[37] M. Fletcher, D. Norrie, “Real-time Reconfiguration using an IEC
61499 Operating System”, International Parallel and Distributed
Processing Symposium (IPDPS), San Francisco 2001.
[38] K. Thramboulidis, C. Tranoris, “An Architecture for the Develop-
ment of Function Block Oriented Engineering Support Systems”,
IEEE International Conference on Computational Intelligence in Ro-
botics and Automation, Canada, August 2001.
[39] K. Thramboulidis and C. Tranoris, “Developing a CASE Tool for
Distributed Control Applications”, International Journal of Advanced
Manufacturing Technology (forthcoming).
[40] R. Brennan, S. Olsen, M. Fletcher, D. Norrie, “Comparing two Ap-
proaches to Modelling Decentralized Manufacturing Control Systems
with UML Capsules”, Proceedings of the 13th IEEE International
Workshop on Database and Expert Systems Applications
(DEXA’02).
[41] B. Selic, Rumbaugh, J. “Using UML for Modeling Complex real-
Time Systems”, Rational Software, 1998.
[42] K. Thramboulidis, “Using UML for the Development of Distributed
Industrial Process Measurement and Control Systems”, IEEE Con-
ference on Control Applications (CCA), September 2001, Mexico.
[43] C. Tranoris, K. Thramboulidis, “Integrating UML and the Function
Block concept for the development of distributed control applica-
tions,” 9th IEEE International Conference on Emerging Technologies
and Factory Automation, Lisbon, Portugal, 16-19 September 2003.
[44] J. Sztipanovits, G. Karsai, “Model Integrated Computing”, IEEE
Computer, April 1997.
[45] K. Thramboulidis, G. Doukas, A. Frantzis, “Towards an Implementa-
tion Model for FB-based Reconfigurable Distributed Control Appli-
cations”, 7th International Symposium on Object-oriented Real-time
Distributed Computing (ISORC’04), Viena, Austria 2004.
[46] Peter S. Manesis, “Function Block to C++ Model Transformer”, the-
sis no 667/2003, Electrical & Computer Engineering, October 2003
[in Greek]
 2nd IEEE International Conference on Industrial Informatics INDIN’04, 24th -26th June, 2004, Berlin, Germany

[47] OMG, “Model Driven Architecture”, available online,

http://www.omg.org.