43rd IEEE Conference on Decision and Control

December 14-17, 2004

Atlantis, Paradise Island, Bahamas
FrB04.5
Design and Validation of Industrial Distributed
Control Systems
M. Marcos, Member IEEE, U. Gangoiti, . Orive, E. Estevez, S. Calvo, J. Barandiaran
Ds/rcl In this paper a methodology for designing and
validating industrial distributed control systems is proposed.
A hierarchical design, based on reusable functional
components, has been used. System validation and adaptation
has been achieved through a CORA based co-simulation
framework. The proposed methodology has been developed
within the FLEXICON project IST-2001-37269. The main
goal of the use of functional components in the design is the
component reusability and their portability to other
applications. On the other hand, the co-simulation framework
allows incremental validation of the control system
implementation. At the same time it allows control algorithms
to be optimized before the system is physically implemented.
The paper uses the frst results of the FLEXICON project and
illustrates them through an industrial case study of a heat
treatment line.
I. INTRODUCTION
T
HIS paper presents a methodology for designing and
validating industrial distributed contol systems. A
hierarchical design based on IEC 1131 standard and aiming
sofware re-use is described. A co-simulation framework
developed within FLEXICON project is also used for
control system validating.
Nowadays, the use of Programmable Logic Controllers
(PLCs) is widely spread in industry. Technological
advances in these controllers have allowed improving the
manufacturing processes, reducing costs and optimizing
production. Control stategies and systems must be flexible
enough for fast adapting to the changes required by
industrial processes. In this sense, the use of standads and
open systems are clearly required.
This paper focuses on a hierarchical design of industrial
distributed control systems following the guidelines
proposed by the IEC 1131-3 standard for programmable
controllers [1].
The IEC 1131-3 standard provides programming
languages and guidelines to implement vendor independent
Manuscript received March 4, 2004. This work was fnancially
supported by the European Union's Information and Science Technologies
programme.
M. M., G. U., O. D., E. E., C. S., are with the Departamento de
Ingerieria de Sistemas y Automatica fom the University of the Basque
County, Spain. (emails: [email protected]@bi.ehu.es.
[email protected], [email protected], [email protected])
B. J.is with S.P.G. Asesores (email: [email protected])
0-7803-8682-5/04/$20.00 2004 IEEE 4720
applications. The main features of this standard are:
Strong data typing.
Facilities for the implementation of multithreaded,
multirated and distributed applications.
Support of complex sequential behavior applications
(using a concise graphical language called Sequential
Function Chart).
Support of structured data types.
Flexible language selection. The standard provides
three graphical and two textual languages for
expressing different parts of a control application.
The IEC 1131 sofware model defines programs,
fnction blocks and fnctions as Program Organization
Units (POUs). These sofware units are programmed once
and used as many times as needed.
Other approaches of hierarchical designs have been
developed in this sense (e.g. using Siemens Step 7 [2] for
control system detectors [3], and for pneumatic control
system supervisors [4]). Hierarchical control systems were
frst used in robotic systems due to their complexity [5]
[6]-[7]-[8]-[9]. In addition, they are commonly used for
non-linear robust control systems [10], optimal contol
systems [11]-[12]- [13] and intelligent [14] control
systems.
On the other hand, the validation of the control system is
achieved by means of a co-simulation backbone based on
Common Object Request Broker Architecture (CORBA)
middleware and developed within the FLEXICON project.
Detailed information about it can be found in [15]. Many
of today's manufacturers are faced with difcult challenges
including reducing time to market and achieving right frst
time designs. To achieve this goal, computer models are
replacing the physical prototypes. There are many benefits
to this approach including a faster and lower cost
development with greater number of design alteratives
evaluated and more optimal designs achieved. Plenty of
proprietary tools exist to design, program and configure
their systems, but it is diffcult to reuse the work in other
equipments. Open systems concept tries to overcome these
difficulties through the integration of proprietary COTS
tools so that they collaborate in the phases of the
distributed system life cycle.
In this sense, a co-simulation famework between
commercial tools is presented as a pragmatic approach
towards such tool integration. Some attempts have been
done by other researchers [16] and vendors: Foresight [17]
integrates Foresight tool and Matlab environment; Exite
[18] which integrates Matlab [19] and ARTiSAN RT
Studio [20] Tool integration has also been investigated in
the automotive sector integrating ADAMS and Xmath
tools [21]. In all cases, only a concrete set of tools is
integrated.
This paper presents a hierarchical design methodology
for distributed industrial control systems and a validation
methodology by means of a co-simulation framework.
Section II gives a general overview of the FLEXICON
project. Section III describes the hierarchical design of the
distributed contol system. In section 1 the co-simulation
famework is presented. Finally, in section V, the
hierarchical design and the co-simulation famework are
illustrated through a case study: an industrial heat treatment
line.
II. FLEXICON PROJECT
The general goal of the FLEXICON project, fnanced by
the European Union's Information and Science
Technologies programme, is to develop methodologies that
enable Commercial Off-The-Shelf (COTS) tools
integration for the design and deployment of Distributed
Control Systems (DCS) with high degree of fexibility,
dependability and re-usability.
This project specifcally addesses the development of
the capability to produce open, high performance,
dependable, distributed fault tolerant systems in reduced
timescales and at lower cost.
Within the toolset, the different phases of the design
cycle are addressed using the appropriate tools. In this
sense, the prototpe that is being developed integrates
ARTiSAN RtS UML tool, Matlab environment and
ISaGRAF Enhanced tool. ARTiSAN RtS UML tool is used
to model the overall heterogeneous distributed control
system. Matlab environment is used to model the process
dynamics (during simulation phase) although it can also be
used to model some parts of the control system. Finally, the
discrete parts of the overall control system are
implemented in ISaGRAF Enhanced tool, a PLC
programming environment that is IEC 1131 standard
compliant.
III. HIERARCHICAL DESIGN OF THE DISTRIBUTED
CONTROL SYSTEM
The hierarchical design of the industrial distributed
control system has been developed following the
guidelines and recommendations of the IEC 1131 standad
for developing PLC based applications. This hierarchical
design allows the reuse of fnctional components
belonging to any level of the hierachy.
The control system specification consists of a hierarchy
of N levels:
Level . The plant.
Level l . Independent subsystems of the plant.
Level 2 to N-1. Sets of fnctional components.
4721
Level N. Elementary fnctional components.
Thus, the model is described by means of a set of
Functional Components (FCs) having each FC a set of
inputs and outputs and configuration parameters. These
inputs and outputs, as well as the FC functionality, must be
clealy defined and documented to allow an easy
component re-use.
The control system includes the actions done during the
normal operation as well as fault detection and
accommodation. Normally, when a non critical fault is
detected an alar is sent to the operator. Critical alarms
usually start actions on the process. In this sense, inputs to
and outputs fom FCs can be grouped depending on their
functionality as securities (alar signals), interlockings
(conditions to be met for the execution of a block),
operator commands and data, process data (feld signals)
and exteral data (inforation processed by other blocks).
On the other hand, oututs can be grouped as signalling
and process data. The different types of inputs/outputs
to/fom a FC are shown in Fig. 1.
L0HHPcIunS
Securities .
1Hl0IIOLKIHS
Operator commands
LCiul0I Uu!u
Exteral data
Configuration
parameters

0H0H8l

uH
Fig. 1. Generic fnctional basic component
Signalhngs
Process data
Within the FLEXICON project, level N FCs are
implemented using any of the languages provided by the
IEC1131-3 standard and stored in libraries. The FCs
belonging to level N-l , programs are implemented in IEC
1131-3 Structued Text (ST). The IEC1131 standad
enforces the use of reusable Function Blocks (FB), these
FBs are programmed once and used as many times as
needed. Usually, in this kind of hierarchical design, level 0
contains the application, level 1 contains programs, and
levels fom 2 to N-l are composed by FBs. Finally, lowest
level, level N, contains FBs that are imported fom
libraries.
Within the FLEXICON project, ARTiSAN RtS UML
tool [20] is the tool in which the model of the overall
distributed control system is defned. The model consists of
the functionality, following a hierarchical specifcation,
and the application implementation using particular
technologies. The defnition of the hardware and sofware
architectures follows the IEC 1131 sofwae model. During
the second year of the project the main target is to achieve
automatic code generation in IECI131 3 Structured Text
(ST) fom the specification modelled in the UML tool.
The automatic code generator allows rapid prototyping.
In this way, the toolset can be used to perfor validation
tests. Generated code is validated in the following way:
Level N: Unitay tests of FBs, previously to be
stored in a library. This is performed within the
development tool.
Levels N-l to 0: Incremental integrated tests fom
level N-l up to level . To achieve these integrated
tests, a co-simulation famework has been designed
within the FLEXICON project.
Next section summarizes the co-simulation framework. A
detailed description of the co-simulation framework can be
found in [15]. In section V the use of the famework is
illustrated through a case study.
IV. CO-SILATION FREWOR
The main targets of this famework are:
Loosely couplement of tools that participate in the
co-simulation
Tool integration between execution times: output
data fom a tool is processed by other tools.
Integration during simulation time: tools exchange
data during simulation.
This famework is generically made up of N tools that
interact through the co-simulation environment.
Interactions between tools are implemented using CORBA
middleware. For each tool, a server is developed. These
servers offer data write and read as well as command
dispatching services using the API of each tool. On the
other hand, there is a co-simulation application which
embeds the N CORBA clients. This application will
manage the co-simulation execution and tool
synchronization by means of the simulation and data
interchange each sampling period. Fig.2 shows the N tool
co-simulation scenario that contains, in addition to the N
tools and N servers, the co-simulation application.
fool 1 &
COR8A See
1oo|28
CCR9ASece
100 N &
CORBA Server
\OS!0UlB\O1 l|CB`IOD
ACORSA 0|et-
Fig.2. Generic co-simulation scenario
Each CORBA server is the link between the tool and the
co-simulation application. These servers transform direct
requests fom CORBA clients into data transactions or
direct commands using the tool API.
In order to add a new tool to the co-simulation
framework the next steps must be followed:
. First step
First of all, a detailed study of the API offered by the tool
to be added has to be performed. It includes the supported
programming languages, as well as the data types and
4722
commands. This information allows the defnition of the
CORBA interfaces.
The Object Management Group (OMG) Interface
Definition Language (IDL) [22] is the language used to
describe the interfaces that clients require and servers
provide. An interface defnition written in OMG IDL
completely defnes the interface for each operation. An
OMG IDL interface provides the information needed to
develop clients that use the interface operations. IDL is a
language-neutral Interface Definition Language. Each
language (e.g. Java, C++ ... ) that supports CORBA has its
own IDL mapping.
1. Second step
Once the interface (IDL file) has been defined, the
methods detailed in the IDL fle must be developed in the
CORBA servers.
CORBA clients, one per server, are embedded into the
co-simulation application. In CORBA clients, there is no
need to develop any kind of extra code, only the IDL
interface must be compiled. Through these clients, the co
simulation application will be able to send requests to
servers, executing the methods defned in the IDL.
C Third step
Finally, it is necessary to defne the interaction sequence
between tools during the co-simulation operation. The co
simulation is confgured by means of a confguration fle
that defines the interaction between tools. By means of the
edition of this confguration file, the logic of the co
simulation can be changed.
V. CASE STUY: A HEAT TREATMENT LI
In this section the proposed hierarchical design is applied
to an industrial heat treatment line (HTL). The co
simulation framework is used for achieving integrated
tests. A typical HTL, as shown in Fig. 3, is composed by
the following sub-systems: a load system, an austenizing
face, a tempering tank, a washing tank and an annealing
face.

Fig. 3. General overview of a heat teatment line

Fig. 4 illustrates the austenizing fuace that is composed
by four zones and two buers in each zone. Temperature
regulation is performed for each zone, usually around 8500
C. A conveyor belt moves the pieces through the face.
The speed of this conveyor depends on the required
heating treatment.
Oas
rcr I
Temle
Fig. 4. Overview of the Austenizing Fuace
The design of this line includes four hierarchical levels:
Level 0: The plant
Levell: Independent subsystems of the plant. In this
case study: the austenizing face, the tempering
tank, the load system, the washing tank and the
annealing face.
Level 2: Sets of elementary fnctional components.
For instance, the austenizing face contains 6 sets
of elementary fnctions: the gas train control, the
buer combustion control, the zone fan contol, the
combustion fan control, the temperatue regulation
and the movement control.
Level 3: Elementary functional components. For
instance, the level 2 Movements Control Component
contains three elementary blocks: the Conveyor
Control, the Conveyor Movement Contol and the
Set Point.
. Hierarchical design
A scheme of the hierarchical design of the level 1 FC
Load System is shown in table I.
TALEr
LOA S\81iVHliuAu CulCAIDi8lGr
lP i
L L
Load Charge Control Load Charge
Shaker ! Movements Shaker !
Control SP Selector
Hopper Contol Gate
Load
Weighting Contol
Analogue Input
System
Real Comparator
Economizer Control Gate
Shaker 2 Movements Shaker 2
Control SP Selector
Program Sequence
Automatic Mode
Automatic Sequence
An example of the information needed to reuse a third
level FC, detailing its inputs, outputs and configuration
parameters, can be seen in table II. This FC can be re-used
in any other applications in which a shaker of the same
characteristics has to be controlled.
4723
TALE II
LiViI3FB suAki . 1

T
l T@ l T@c
Sccuritics: SignaIIing:
failInFreqDriver bool ProccssData:
1ntcrIockiugs: ActivateShak bool
autSwNotShoot bool
Shaker
Opcr.Command:
startButPressed bool
stopButPressed bool
xtcruaIData:
T@c
startAutoMode bool
None
stopAutoMode bool
1. Control system validation through the co-simulation
As commented before, FC validations must be performed
following an incremental way fom the lowest levels up to
level . In the development of level N FCs, unitary tests
have to be performed and documented before they are
added to the library using the development tools.
In this sense, if an application requires the development
of a new third level FC, it has to be tested before its
addition to a library. Once the necessay unitay tests have
been successfully done, and all the elementary FCs reside
in libraries, incremental integration tests have to be
perfored fom level N-l up to level 0 using the co
simulation famework. To achieve this:
A program that uses the FC fnctionalit must be
designed within the programming tool.
A model representing the part of the process
controlled by this FC must be defned within the
simulation tool.
A co-simulation configuration fle has to be generated
in order to describe the tool. The simulation of the
process model is divided in sub-steps where inputs
come fom the previous contol system simulation.
In the same way, inputs for a simulation step of the
control system come fom the previous process
simulation.
The co-simulation application interface allows the
generation of the confguration fle.
A prototpe has been developed within FLEXICON
project in which the integration of Matlab / Simulink /
Stateflow and ISaGRAF Enhanced tools has been
perfored through CORA. In order to integrate both
tools the steps defined above have been followed.
In this application Matlab/SimulinkiStatefow is used to
simulate the process dynamics and ISaGRAF Enhanced to
develop the distibuted control system to be in PLCs or
Open Controllers.
1) MatlablSimulink and 1SaGRF models
Fig.5 shows the model of the austenizing face. H
contains a Stateflow diagram that defines the possible
uansitins betwen face operation states. During
sImulatIOn the active state appears highlighted. This state
diagram handles the execution sequence of the models
associated to each state.
The tansitions between operation states are driven by
input ports that may come fom the control system or fom
the Local Operator Station. Information fom the process
environment is modelled as input ports. Field signals are
modelled as output ports. There ae also some other ports
that have been modelled for signalling purposes. Table III
illustrates the austenizing frnace model ports.
The control system has been developed using ISaGRAF
Enhanced tool (Fig.6). An ISaGRAF Enhanced project is
defined through the IEC 1131 standard elements:
confgurations (e.g. PLC), resources (e.g. CPUs), tasks,
programs, fction blocks and functions [23].
Fig.6. Contol system for te HTL developed in ISaGRAPH Enanced
The control system of the austenizing face, developed
in ISaGRAF Enhanced, contains a confguration and two
resources. Resource 1 executes the logic part of the control
system while Resource 2 executes the temperature
regulations.
To achieve the co-simulation between the process model
(in Matlab) and the control system (in ISaGRAF enhanced)
two different types of interaction between them have to be
distinguished.
The logic part of the control system which is in
chage of the fll line operation, fault detection and
alarm generation. Thus, exchange should be as fast
as possible.
4724
The timed pats. In this case it is constituted by the
temperature regulators. Thus, data must be
exchanged each controller sampling period.
In table III the control model input and output variables
are also classifed as logic or timed variables.
2) Conguration of the co-simulation
Data interchange between control system in ISaGRAF
and the process model in Matlab/SimulinkiStatefow must
be confgured. This exchange of information includes both
the logic part of the control system and the timed part
processed at each controller sampling period.
Thus, the Matlab model inputs and oututs must be
associated to the ISaGRAF model input and output
variables (as shown in table III).
bool
bool
bool
bool
bool
bool
bool
bool
real
bool
bool
bool
real
TABLE III
ISAGRAF MATLAB Miil!G8
NaralcNamc ?ar ?0rNam
servovalveOpened logic servovalveOpen
onPurge logic onPurge
purgeDone logic purgeDone
activateElectrovalve logic activateMainElec
alarmBuNotStartd logic buerNotStarted
buerOn logic buerOn
fanCon logic zFanConect
conZoneFan logic cFanConnect
zl AirServovalve timed zl AirServovalve
?0rNam NaralcNamc
servovalveOpened outut mainElectrConLS
mainElectovalvCon output combustionMotorCon
cFanConnected output openServovalve
Tausl output tempZl InputValue

sm
input
input
input
input
input
input
input
input

logic
logic
logic
timed
Fig.7 represents the user interface where the map
between the process input and output ports and the control
variables is performed. In the example there are four inner
cycles that correspond to the logic part. This value means
that logical data interchange will occur four times faster
than control information, interchanged at the sampling
fequency.
Fig. 7. Co-simulation confguration interface
The complete scenario with both tools and the co
simulation application can be shown in Fig 8.
CO-Snu|aIOnP|Ca!On
Fig 8: Co-simulation scenario
During co-simulation, the control loops are closed
through CORBA as stated in the co-simulation
confguration file. But, it is also possible to send direct or
time diven commands to both tools (e.g. to simulate a fault
in a sensor signal or to send an operator order to the control
system).
N. CONCLUSION
In this paper a methodology for designing and validating
industial distributed contol systems has been proposed.
The design, based on IEC 1131 standard and hierarchically
defined, aims component reuse. The co-simulation
famework, developed within the FLEXICON project,
allows incremental validations of the design. The steps to
achieve both the design and the validation have been
detailed with a case study.
Within the FLEXICON project work on automatic IEC
1131 3 ST code generation is on progress. In this sense,
frther research includes incremental design validations
using automatically generated code as well as
automatically generated co-simulation confguration files.
ACKNOWLEDGMENT
The authors grateflly acknowledge the financial support
of the European Union's Information and Science
Technologies programme for the FLEXICON project IST-
2001-37269.
REFERENCES
[1] Lewis R.W. "Programming Industrial Control Systems using IEC
1131-3, lEE Control Engineering series 50. ISBN-O 85296 950 3",
1997.
4725
[2] Berger H. "Automating with STEP 7 in STL and SCL". Ed. Siemens
Akiengesellschaf, Berlin and Munich, 2000.
[3] De Cataldo G. "The Detector Control System for the HPID in the
ALICE Experiment at LHC". 6' Workshop on Electronicsf!)r IHC
Experiments, Cracow, Poland. 2000.
[4] Tolga I., Kurtulan S., Goren L.
"
Supervisory Control of a Pneumatic
System Using PLC". International COl?lerence on Electrical and
Electronics Engineering. 2003.
[5] Albus J.S., Lumia R., McCain H. "Hierarchical contol of intelligent
machines applied to space station telerobots". Aerospace and
Electronic Systems. 1988, Volume 24, pp. 535-541.
[6] Adams J., Paul R. "Human Management of a Hierarchical Contol
System for Multiple Mobile Agents". IEEE Interational
Conference on Systems. Man. and Cybernetics, San Antonio. 1994.
[7] Guldner, J., Utkin V., Bauer U., Bauer R., tree-layered hierarchical
path control system for mobile robots: Algorithms and experiments".
Robotics and Autonomous systems, 1995, Volume 14, Issues 2-3, pp.
133-147.
[8] Shibata T., Abe T., Tanie K., Nose M. "Skill based motion planning
in hierarchical intelligent contol of a redundant manipulator".
Robotics and Autonomous systems, 1996, Volume 18, Issues 1-2,
pp. 65-73.
[9] Popovic D., Popovic M. "Tunning of a Nonanalytical Hierarchical
Control system for Reaching with FES". IEEE Transactions on
Biomedical Engineering, 1998, Volume 45, No. 2, pp. 203-212.
[10] Leonessa A., Haddad W., Chellaboina W. "Nonlinear Robust
Hierarchical Control for Nonlinear Uncertain Systems".
Mathematical Problems in Engineering, 2000, Volume 5, pp. 499-
542.
[11] Roberts P., Becerra V. "Optimal contol of a class of discrete
continuous non-linear systems-decomposition and hierarchical
structure". Automatica, 2001, Volume 37, pp. 1757-1769.
[12] Andrzej J. "Hierarchical Control of Transient Flow in Natural Gas
Pipeline Systems". Int. Tans. Opl Res .. 1998, Volume 5, No. 4, pp.
285-302.
[13] Lee M., Han C., Chang K. "Hierarchical Time-Optimal Control of a
Continuous Copolymerization Reactor dung Start-up or Grade
Operation using Genetic Algorithms". Compo of Chem. Eng., 1997
Volume 21, pp. 1037-1042.
[14] Keung K.W., Ip W.H., Yuen D. "An intelligent hierarchical
workstation contol model for FMS". Journal of Materials
Processing Technology. 2003, Volume 139, pp. 134-139.
[15] Marcos M., Gangoiti U., Estevez E., Portillo J., Calvo !. "A
CORBA-based Co-simulation Framework for Integrating COTS
Tools", submitted to: Sixth Portuguese Conference on Automatic
Control CONTROLO 2004, Faro, Portugal. 2004.
[16] Adriano, B.A and Wager, F.R. "A Standardized Co-simulation
Backbone". Universit of Porto Alegre, Brasil. 2001
[17] Foresign Systems, Inc. "Combining Foresight and Matlab for
Complex System Design", 2002. Available htp://www.Foresight
Systems. com
[18] Extessy AG. (2003) Available htt:// www.extessy.com
[19] The MathWorks (2002), "Using Matlab version 6.5"
[20] Aisan Sofware. "Manual of ARTiSAN Real-Time Studio, Version
4.2", ARTiSAN Sofware tools. 2002.
[21] George N. "Cosimulation of an Automotive Contol System using
ADAMS and Xmath". Interational ADAMS User Conference.
Utrecht, 1998, The Netherlands
[22] OMG "OMG IDL Syntax and Semantics. IDL specifcation". 2002.
Available: www.omg.orgidocs/formal/02-06-07.pdf
[23] PLCopen, "Overview IEC 61131". 2003. Available:
http://www.p1copen.orglintro_iec/overview_oCiec_61131.htm