Simulation Modelling Practice and Theory 13 (2005) 525–549

www.elsevier.com/locate/simpat

OPC based distributed real time simulation

of complex continuous processes
Raúl Alves Santos a,*, Julio E. Normey-Rico a,
Alejandro Merino Gómez b, Luis Felipe Acebes Arconada c,
César de Prada Moraga c
a
Department of Automation and Systems, Federal University of Santa Catarina, 88040-900 CTC-UFSC,
Florianópolis-SC, Brazil
b
Center of Sugar Technology, University of Valladolid, Edificio Alfonso VIII, 47011, Valladolid, Spain
c
Department of Systems Engineering and Automatic Control, University of Valladolid,
Faculty of Sciences, c/ Real de Burgos s/n 47011, Valladolid, Spain

Received 28 July 2004; received in revised form 25 October 2004; accepted 28 January 2005
Available online 9 March 2005

Abstract

This paper presents a methodology for the development of distributed process simulation
using OPC (OLE for Process Control). The distributed components operate as OPC servers
enclosing continuous simulations developed with the simulation language EcosimPro. The
paper presents the problems related to data interchange and synchronisation in real time
and the solutions adopted and gives results about the performance of OPC in this kind of
applications. The methodology has been applied to a large process simulator of a beet sugar
factory used for control room operator training. This includes a process simulation operating
in a network of six computers, a SCADA system for operation on the process, an instructor
console and the corresponding software for real time communication and synchronisation.
The main advantages of this approach are: (i) independence of the development of the simu-
lation from the communication mechanisms, (ii) access to the simulations by a wide range of

*
Corresponding author. Tel.: +554891218884.
E-mail addresses: ralves@das.ufsc.br (R. Alves Santos), julio@das.ufsc.br (J.E. Normey-Rico),
alejandro@cta.uva.es (A. Merino Gómez), felipe@autom.uva.es (L.F. Acebes Arconada), prada@autom.
uva.es (C. de Prada Moraga).

1569-190X/$ - see front matter
2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.simpat.2005.01.005
526 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

applications, due to the standard provided by OPC, (iii) use of low cost conventional equip-
ment and (iv) support for large scale simulations.

2005 Elsevier B.V. All rights reserved.

Keywords: Process; Distributed; Interactive; Training

1. Introduction

There are an increasing number of simulation applications which size exceed the
computational capacities of conventional computers, mainly if real time execution of
the simulated models is required. One solution for this problem that is been adopted
in an increased number of applications is based on distributing the computational
load among a set of interconnected computers. Instead of running a big size simula-
tion in a single computer, the simulation is divided in several modules, each of them
suitable for running in a computer at the desired speed. In this way the simulation is
performed in parallel in a computer network gaining benefit of the increased compu-
tational power.
Key elements in distributed simulation are the partitioning of the simulation
among the different modules, the interchange of data between them along the simu-
lation time and the synchronisation of the execution of the modules.
Criteria that can be used for the division of a simulation in modules are quite
wide, ranging from selecting modules that correspond to physical elements such as
process units, to looking for minimum number of interconnections among the mod-
ules, or for interconnections involving variables that present the smoothest changes.
For the distributed execution of simulations there are several software environ-
ments that provide data interchange and synchronisation services, among them,
for instance, HLA and CAPE-OPEN. The High Level Architecture (HLA) [15] is
a standard of the Defense Modeling and Simulation Office [8] of the Department
of Defense of USA (DoD) [7], that have their own communication and synchronisa-
tion libraries called Runtime Infrastructure (RTI). On the other hand, CAPE-OPEN
(Computer Aided Process Engineering Open Simulation Environment) [5,6] is the
result of an European Union joint project and instead of providing libraries for com-
munication, it specify the component interfaces for two middlewares, OMG CORBA
[13,16] and Microsoft DCOM [11,12]. In both cases, the common idea is the devel-
opment of a set of specifications on the modules or components so that they can be
developed and re-used easily.
In this paper we approach the topic of distributed simulation from the perspective
of the requirements imposed by the development of simulators for control-room
operators training in the process industries. These simulators combine a real-time
simulation of the process, usually the whole factory, with a SCADA (Supervisor
Control And Data Adquisition System) that acts as human interface and an instruc-
tor module for supervision and problem generation. The process simulation has been
developed in the simulation environment EcosimPro [9]. It disposes of a modern
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 527

object oriented modelling language named EcosimPro Language (EL) that supports
both, continuous and discrete event systems, and incorporates state of the art inte-
gration algorithms for solving (sparse) DAE models. Two important characteristics
are: first, that the computational causality of the mathematical models is not prede-
termined, so that these can be re-used in different contexts, and second, that the sim-
ulation models is generated as a C++ class that can be integrated in any C++
application.
Typical process models involve several thousand DAE equations so that for real
time operation with todayÕs PCÕs the simulation has to be distributed among several
computers. Besides the HLA and CAPE-OPEN mentioned before, it is possible to
take advantage of the generated C++ code and develop directly software compo-
nents as DCOM y CORBA, but, taking into account the context in which these sim-
ulators are used, an attractive alternative is to use OPC (OLE for Process Control)
[1,10,14] an emerging technology based on DCOM that has gained wide acceptance
and became a ‘‘de facto’’ standard in the process industry for communications
among devices. Adding a OPC layer to the simulation code allows a simulation
not only to interchange data with other simulations in a distributed environment,
but to be accessed by a wide range of applications and control equipment, including
distributed control systems (DCS), SCADAs, PLCs, etc., opening the door to other
applications such as hardware-in-the loop test, etc.
This paper study the problem of implementation of OPC interfaces in distributed
continuous simulations and gives results of its application in a plant wide simulator
of a sugar factory. The simulation language considered is EcosimPro but the meth-
odologies and results are valid independently of the simulation environment.
The paper is organised as follows: After the introduction, Section 2 gives an over-
view of EcosimPro and Section 3 introduces OPC. The methodology for the devel-
opment of distributed simulation applications is given in Section 4, while Section 5
describes the structure of the OPC server. The distributed simulation based on OPC
servers is considered in Section 6 as well as some tools developed for the automation
of the proposed methodology and, finally, Section 7 describes its application to a
practical industrial case of a sugar factory. The paper ends with some conclusions
and bibliography.

2. EcosimPro

EcosimPro belongs to the family of the simulation tools that support the so called
object oriented modelling languages (OOML, whose main exponent is Modelica),
such as gPROMS, Abacus, Dymola, MathCore, etc. in the sense that they support
non-causal models able to be modified automatically according to the context in
which they are used. This means that the user can specify different boundary
conditions without modifying the model code, and EcosimPro will manipulate
symbolically the equations to adapt them to the specifications, which increases its
re-usability. Being object oriented it support the paradigms of encapsulation, inheri-
tance, etc.
528 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Its simulation language, called EL, allows the description of process models,
named components, in a natural way by means of continuous differential algebraic
equations and discrete events variables. Once the user has built its system intercon-
necting components by ports, it is compiled and, after establishing a partition, that
is, describing which variables constitute the known boundary conditions, EcosimPro
generates C++ simulation code linked to the numerical solvers. This increases the
open character of the language. EcosimPro can deal with large models and has been
tested in different fields such as aerospace, power stations or process industries. A
typical process model involving several hundred DAEs will be integrated normally
in a fast and reliable way, but the speed of execution, assuring a given precision, de-
pends not only in the size, but, mainly, in the nature of the DAE involved. This
means that, if real time execution is required, some large models must be executed
in a distributed environment.

3. OLE for Process Control (OPC)

OPC consists of a standard set of interfaces, properties and methods that can be
used for device communication in process control and manufacturing applications.
OPC is based on Microsoft DCOM (Distributed Component Object Model) technol-
ogy. It is managed by the OPC Foundation, supported by the majority of the com-
panies that operate in the process control sector.
Its main objective is providing an uniform access to data in industrial applica-
tions, in such a way that several clients can access the data managed by an OPC ser-
ver through a Windows network.
Prior OPC, vendors and users have to develop specific drivers for communicating
process control equipment and devices. OPC reduces the development of several
drivers to a single one. See Fig. 1. Encapsulating a device, an OPC server interface
allows external access to the data acquired by the driver of this device to several het-
erogeneous clients like SCADAs, DCS, spreadsheets, etc. each of which have their
own OPC interfaces.
The objective of OPC is to define a set of standard interfaces and a well defined
behaviour for the server in order to allow the interoperability among different indus-
trial devices in a network of different suppliers. The original specification standard-

Fig. 1. Access to a device using OPC.

 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 529

izes the process data acquisition. Later, new variant of the OPC specifications were
been introduced: Alarm & Events, Batch, Data Access, Data eXchange, Historical
Data Access, Security and XML-DA [14].

4. A methodology for the development of distributed simulations with EcosimPro

In this section the different steps in the construction of a distributed simulation

will be described. These include, for each node of the network, generating the Ecos-
imPro code and developing of the corresponding OPC server, as displayed in Fig. 2.
It will be followed by the distribution of the simulations and the management of the
environment. As a reference, we will consider the specific case of a simulator for
operator training in process factories. This includes, not only a distributed simula-
tion of the processes, but a SCADA or DCS for the real time control of the factory,
plus an instructor module.

4.1. Code generation with EcosimPro

As mentioned before, after partitioning a big size model in modules, each of which
is going to be simulated in a node of a network, the model code of each node can be
obtained in the EcosimPro development environment, Fig. 3, either writing the code
of its components or using the ones of a predefined library, and interconnecting them
by ports. In this way we obtain a single component that represents the dynamics of
the module. After compilation, the next step is defining which are the external vari-
ables that form the boundary conditions for its operation. They will include, among
others, those variables from other modules that must be interchanged during the
simulation of the whole factory. This step, called ‘‘establishing a partition’’, will
fix the computational causality of the model and, after defining possible experiments
to be performed on the simulation, will results in the generation of C++ source code

Fig. 2. Generating a node of a distributed simulation.

530 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 3. EcosimPro simulation environment.

which is further compiled and linked with the system libraries for integration, etc.
giving way to an executable file.
This file can be accessed via OLE and, in fact, the EcosimPro environment pro-
vides an application called EcoMonitor that offers a graphical interface for perform-
ing experiments on the models. At the same time, the C++ source files generated,
allows to use them outside the EcosimPro environment, in particular for providing
the simulation with OPC capabilities.

4.2. Generation of OPC servers

An OPC server can be created by adding to the simulation code the communica-
tion routines provided by the OPC standard. They can be develop at home or pro-
vided by commercial supplier. Then the OPC server can be accessed from any OPC
client. The procedure is described in [17]. Details of the structure of the server, its
timing, etc. are given in Section 5.
This process can be automated. In our case, an application, CreaOPC, creates
OPC servers from the sources files generated by EcosimPro, allowing the configura-
tion of the servers for different uses. Fig. 4 shows the aspect of this environment for
servers generation. The resulting server can be accessed with a generic client.

4.3. Distribution of the simulations

Once the OPC servers corresponding to the different parts of the process to be
simulated have been created, these can be executed in several computers connected
by a network. The cooperative execution of all the parts of a simulation requires a
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 531

Fig. 4. Automatic generation of OPC servers with CreaOPC.

procedure for data interchange among them as well as its synchronisation in order to
manage the cooperative time advance.
These tasks, data interchange and simulation synchronisation can be made
through an application that acts as a client of all the OPC servers attached to the
distributed simulations (Fig. 5). This software commands the time advance of the
simulation so that, at the adequate time instants, it reads the data to be interchanged
among the different servers and writes them into the corresponding destination serv-
ers, operating in a synchronous mode. After the data interchange has finished, it
allows the time advance of the simulations.

4.4. Management of the environment in a process control simulator

TodayÕs commercial DCS and control equipment are all provide of OPC client or
server capabilities. Nevertheless, in order to be independent of commercial products,

Fig. 5. Schematic of data interchange and synchronisation among simulations.

532 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

we have developed in house a configurable SCADA [4] that has the main functions
of this kind of systems: It is able to acquire data in real time from a process, display
the information in different formats, receive commands from the operators and send
them to the process, in addition to other tasks such as data storage, control, alarm
signalling, etc. The data interchange with the process is done via OPC. In our system,
the distributed simulations plays the role of the process and the SCADA can be con-
nected to the OPC servers containing the simulations through its OPC client inter-
face. In the simulator the SCADA acts as human interface allowing the operators
to see what is going on in the process and acting on it using the controllers, valves,
etc. Several SCADAs can be connected at the same time to the process allowing sev-
eral users to operate the process at the same time.
For this purpose, each SCADA has to be configured using its configuration pro-
grams. This means specifying which are the variables of the servers to be accessed,
the synoptics to be displayed, value tables, etc. Once the configuration is done, it gen-
erates the configuration file that is read by the SCADA. After this, it ready to oper-
ate the distributed simulation (Fig. 6).

Fig. 6. Configuration and use of the SCADA with the OPC servers.

Fig. 7. Simulator training architecture.

 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 533

Similar steps are required by the instructor console, but in this case, additional
variables from the process are configured to be handled, so that the instructor can
act on a wider range of variables, creating, for instance, faults and malfunctions that
must be identified and solved by the operators being trained.
The resulting architecture for the training simulator is shown in the Fig. 7. It con-
sists of several process simulations each representing a part of a global process, run-
ning in several PCs within a Windows NT network, plus a series of operators
stations accessing the simulations. In addition, an instructor console connected to
the system introduces exercises and modifies the operating conditions.

5. Generation and structure of the OPC server

Each distributed simulation module, besides the simulation code, has two main
parts: the thread that handles the advance of the simulation, and the OPC server,
which includes the access to the simulation (Fig. 8).
The OPC servers will be executed in a Windows NT or upper environment. Win-
dows NT is a multitasking operating system, but not a real-time system. If desired it
is possible to use a real-time patch, but this it not the case. In the servers, in order to
advance the simulation independently of the communication process, an indepen-
dent thread will be used. This thread has a higher priority that others applications.
This does not warranty that a system task will dislocate it, but only will avoid that
other task application and tasks with less priority can do that.

5.1. Simulation Advance Thread

The modules that form a distributed simulation are not independent, but need the
value of some variables belonging to other modules for a proper computation of

Fig. 8. A distributed simulation module.

534 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

their own variables. This means that, with given frequency, they must interchange
values which should correspond to the same time instant of the simulation (and per-
haps of real time in real time applications). In addition, the SCADA, that has their
own timing, requires data from the simulation corresponding at pre-specified real
time instants. Nevertheless, due to the different computational loads, each module
will spent variable time intervals along the duration of the simulation. This implies
the need of controlling the time advance of the simulation as well as the synchroni-
sation of the modules.
Using the C++ classes generated by EcosimPro we can access and control the sim-
ulation. In particular, the simulation advance can be made with some functions pro-
vided by the code generated by EcosimPro. There are several ways of advancing the
simulation time: advance a fixed time interval, advance up to a time or advance until
the end of the simulation. They are described in Table 1.
The timing of the simulation is performed in a thread where a loop controls the
advance of the simulation step by step as well as the delays that are necessary to sim-
ulate real or scaled time behaviour (wall clock time) and the interchange of data with
the OPC servers that contain the simulations. An obvious precondition is that the
modules should be able of running faster than real or scaled time. Alternatively, if
real time execution is not needed and a module is running independently, then it
is possible to run the simulation in an ‘‘as-fast-as-possible’’ mode.
The basic loop consists on the following steps:

• Data interchange from the OPC server to its simulation assigning values provided
by other modules to the boundary conditions of the module.
• Simulation advance until the next synchronisation interval in simulated time of
the module.
• The module stops execution until the time instant of the next synchronisation
interval in terms of real time arrives.
• Data interchange from the simulation to OPC server.

It is shown in Fig. 9 where a time interval of 5 s has been assumed.

Another factor used, that is associated to the operating system, is the granularity
of the timers. The timers have a granularity of 10 ms, approximated. The wait func-
tions operate with these granularity times. In order to determine the wait times Win-
dowsÕ high performance counters have been used. These counters can determine the
wait time in values of microseconds.

Table 1
Time advance simulation functions
Function Description
INTEG_CINT Advances the simulation step by step. The step is determined by the communication
interval, using the variable CINT
INTEG_TO Integrates the model until a certain time instant indicated in one parameter of the
function
INTEG Integrates the model until the time of conclusion established by the variable TSTOP
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 535

Fig. 9. Relation between the clock time and the internal simulation time.

Fig. 10 shows the flow chart of the thread that handles the simulation advance. It
is valid for both, simulations that are executed in isolation or in cooperation with
others. When several simulations run in parallel, its synchronisation is handled exter-
nally by a client application that makes use of an advance flag for data interchange
and synchronisation.
The flag Single Server indicates when the server works in a single mode or in coop-
eration with others servers.
The flag Advance is activated by the external application and it is used to imple-
ment the synchronisation. If it is deactivated the server remains waiting until its acti-
vation. Once activated, the execution of the loop continues with the updating of data
between the OPC interface and the simulation. After that, the calculation of the next
interval of the simulation is made.
Once the simulation has advanced until the next interval in terms of their own
simulated time, the time delay until the next step in real time is calculated subtracting
the interval from the time spent by the simulation in integrating the model and the
data transfer time.
Finally, the simulation remains idle for the delay computed, and the updating of
data from the simulation to the OPC interface is made. The flag Advance is deacti-
vated and the number of send is increased, so, the external application knows that
the server has finished its calculations. When all the servers have finished their tasks
536 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 10. Time advance thread.

the client application performs the data interchange and activates the Advance flags
of the servers, starting so the next time step.
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 537

In addition in the thread it is possible to introduce an extra pause, or an acceler-

ation factor in the simulation advance. The interest of this feature is to span or re-
duce the time scale in order to accommodate it to the needs of extremely slow
processes. The pause is made through the activation of a flag that will perform a
delay until its deactivation. The introduction of the acceleration factor is made by
the increase or decrease of the internal delay.
Finally, the option of advancing the simulation ‘‘as-fast-as-possible’’ is imple-
mented introducing a flag that activates or deactivates the delay.

5.2. OPC server

The access to the simulation is made through the elements, ‘‘items’’, configured in
the server. When an external client accesses a server it receives the values of the items
according to the configured update time of the data. The communications with the
client can be synchronous or asynchronous. In this case we use a different approach
that combines synchronous and asynchronous communication. The first one is used
with the control signal because it is necessary to transfer the data in a given time in-
stant. The asynchronous one is only used for the data to be exchanged. The config-
uration of the communication mode might be done in the client application.

6. Distributed simulation

6.1. Simulation granularity

When an OPC server operates in a distributed real time environment, there are, at
least, two important problems to be taken into account: Timing of the simulation
and consistence of the integration of the distributed modules.
In order to obtain a real time progress of the simulation we synchronize it at given
time intervals. This is obtained advancing the simulation as-fast-as-possible until the
next time interval, and then, if the time used in this computation is less than the time
interval, waiting in order to synchronize with real time. When the time used in the
computations exceeds the interval time the compensation is executed in the subse-
quent periods.
If an external event takes place, such as for instance a modification of a controller
set point in the SCADA by the operator at a given (usually random) time instant,
and the change were written directly in the simulation, as simulated and real time
are independent, then, there will be no way of knowing the precise time in which
the data has been changed. Something similar would happen when reading data
from the simulation. Fig. 11, in which Tr and Ts are clock and simulation times,
shows different situations that could take place.
In practice, reading and writing of data is done thought a buffer controlled by the
thread that manages the simulation advance, so that data can be interchanged
between the simulation and the buffer at each communication interval, when the
computations are finished. In this way the reads and writes correspond to values
538 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 11. Arrival of external events to the read/write simulation buffer.

of a simulation time multiple of the communication interval for instance

Ts = 0 s, 5 s, 10 s, . . . Nevertheless, it does not solve the problem being the only
way of mitigating it to increase the granularity of the communication.
During the time corresponding to the communication interval the data values are
going to remain constant. Notice that it means also that when successive writes are
applied to the same value within a sampling interval the value that will be transferred
to the simulation will be the last one, ignoring the previous ones. This is undesirable
but inevitable, so that the solution resides in choosing a communication interval
according to the process trying to obtain to the best compromise possible between
granularity, fidelity and computation time.
The consistency in the independent integration of the distributed modules is partly
related to this problem. Each model is integrated assuming that its boundary condi-
tions remain constant for every communication interval, which generates an error.
The solution of going back in time and integrating again correcting the boundary
conditions until convergence of the assumed values at the input of a module and
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 539

the generated by the output of other is achieve, is very time consuming and not free
from errors, so that, again, the choice of the granularity in the communication is the
preferred choice.

6.2. Synchronisation

As mentioned before, Fig. 5, the data interchange and the synchronisation among
the modules of the distributed simulation is performed by a client application, called
UneSim, able to access all the simulations. Specifications of this application include
the variables to be interchanged, the variables that control the simulations, the ad-
vance flag, the communication interval and the number of steps.
The synchronisation is made through the advance flag and a variable that indi-
cates the number of steps taken. The advance thread of each server waits until an
external signal from the client application arrives and activates the advance flag.
Then it computes the next step, deactivates the advance flag and increases the num-
bers of steps. With these data from every OPC server, the client application performs
the next actions: starts his OPC client that activates all the servers and creates a
thread, containing the interchange routine, with a timer which time equals the com-
munication interval time.
Fig. 12 shows the flow chart corresponding to the data interchange and synchro-
nisation cycle made in the client application as well as the interactions between the
server and a client.
In the client application, before entering into the repetitive loop, a counter with
the number of interchanges begins. Its aim is to control that all the simulations
are at the same time instant when the data interchange is made.
The cycle begins with the verification of the flags of all simulations. If all advance
flags are deactivated this indicates that they have finished the computation of their

Fig. 12. Interaction between client and server.

540 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 13. Chronogram of synchronisation through advance flag and number of sends.

simulations, and if all simulations have the same number of sends, indicates that all
the simulations are in the same time instant. The application waits until these con-
ditions are satisfied and then performs the data interchange between the different
simulations, activates advance flag of all of them, so that they begin computing
the next communication interval, and increases the number of sends made.
Fig. 13 shows the chronogram corresponding to the synchronisation of the simu-
lations through the advance flags and the numbers of sends.

6.3. Some tools

In order to facilitate the implementation of the proposed architecture, two appli-

cations were developed that help automating the development of a distributed
simulation:
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 541

• CreaOPC: that generates automatically OPC servers from the simulations devel-
oped with EcosimPro.
• UneSim: that automates the data interchange and synchronisation between the
servers in a Windows NT network.

6.3.1. CreaOPC
The CreaOPC program is in charge of the generation of OPC servers in a semi-
automatic mode, making the necessary modifications on the C++ source files
‘‘.cpp’’ and ‘‘.h’’ generated by EcosimPro, as well as on the sources files of the pro-
gram that provides an OPC interface to the simulation. See Fig. 14. In this way, the
making of an OPC server is reduced to generating the server with CreaOPC, create
the configuration file, register the server, and, if it is intended to be used in remote
mode, configuring the DCOM access security. The configuration file of the servers
contains the associations between identifiers (‘‘tags’’) of variables that must be of-
fered by the server and the corresponding variables of the simulation.

6.3.2. UneSim
UneSim is the client application in charge of making the data interchange and syn-
chronisation between several OPC servers containing the simulations. Its internal
operation was already explained in Section 6.2.
In order to use this application, a configuration file is required. This file contains
the pairs of variables that will be interchanged between servers. This file is created
with the UneSimCnfg application, which allows the selection the pairs of variables
origin–destination of OPC servers connected in a network, facilitating the configura-
tion process and avoiding errors at the time of introducing the names of the tag vari-
ables. In addition, it allows the modification of existing configurations. Also, jointly

Fig. 14. Graphic interface of CreaOPC application.

542 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 15. Graphic interface of UneSim application.

to the list of pairs of variables, the time value of the interchange interval is specified.
Then, UneSimCnfg will generate automatically the configuration file for the UneSim
OPC client.
Once the configuration file is ready, it is loaded by the UneSim application, which
will start the servers in their respective locations, beginning the synchronisation and
data interchange among them. The graphic interface of the UneSim application al-
lows to observe the time advance of the simulations, as well as the value of the data
interchanged. Fig. 15 shows this interface, in which the list of pairs of variables and
the graph of simulation time evolution can be observed, as well as the timing of the
simulations.

7. A practical application in a sugar factory

The proposed methodology and tools were applied to an industrial, large scale
process: a beet-sugar factory [2,3]. The purpose was testing them and developing a
simulator for control room operator training.
Modern process factories are highly automated, so that only a small number of
operators are necessary to command the factory from a control room using a
DCS or similar control equipment. As a result of it, they have a considerable respon-
sibility, both in the normal operation of the plant which includes product quality,
emissions control, efficiency and profitability, etc. as well as in abnormal situations,
related to security, speed of recovery to normal states, etc. This means that it is very
important to guarantee that the plant personnel is properly trained in order to im-
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 543

prove the operation and security in the factory. In the sequel, we will describe the
process, the training simulator and some results related to its operation.

7.1. The sugar factory

Sugar factories are fairly complex plants that involve a great variety of processes,
ranging from external services such as a power plant, distillation and fermentation,
waste water treatments, to the typical sugar process units: diffusers, evaporators,
reactors, heat exchangers, crystallisers, dryers, filters, etc. operating both in contin-
uous and batch modes. A schematic of the process can be seen in Fig. 16, showing
the main sections that compose the main line of beet sugar production each one
involving dozens of process units and perhaps thousands of variables.
The simulation of the factory has been performed in EcosimPro, organising sev-
eral libraries of process units products properties, ports and control equipment. The
components were then linked together as in the real process and parameterised using
process data and technical documentation from a factory in Benavente, Spain. As
the complete simulation of the sugar factory represents a huge model that requires
a great amount of computational time, the execution in a single conventional com-
puter is not possible if real time specifications are required and a distributed simula-
tion must be implemented. The fact that each section in Fig. 16 is linked to the
adjacent ones by a small number of pipes which mainly send juices and steam, facil-
itates the task of defining cut-points for the distribution of the simulation which cor-
respond roughly to the working departments or sections. Thus, the complete
simulation system was divided into seven individual simulations, one for each sec-
tion, except for the depuration, the biggest in terms of computation because it in-
volves a lot of mixed continuous and batch units, which has been subdivided in
two parts. Fig. 17 shows how the different sections are connected, as well as the num-
ber of interchanged data.
In order to create the OPC servers, the same methodology as in the example of the
previous section was applied. One server is used for each of the seven simulations.
After configuring the UneSim program, the external client is able of performing
the tasks of communicating and synchronising the different simulations.

Fig. 16. Main sections in a sugar factory.

544 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

Fig. 17. The different sections of the sugar factory.

7.2. The sugar plant simulator

The architecture of the simulator includes, besides the distributed simulation of

the process and the UneSim client application for data interchange and synchronisa-
tion, a SCADA connected to the OPC servers for operation of the process. In addi-
tion, one of the SCADA units, specially configured, play the role of instructor
console. Fig. 18 shows the architecture of the training simulator.
The operators can supervise the process and act on it by means of a human inter-
face that includes schematics, bars, trend graphs, historical data, alarm signalling,
etc. Fig. 19 shows a typical screen of the user interface of the SCADA.
The instructor console gives access to the most significant variables of the simu-
lated processes, so that, by means the adequate interfaces, he/she can modify the
working conditions, introduce faults and malfunctions, etc. which must be recogni-
sed and solved by the operators.

7.3. Test results

The tests were done in a set of computers connected to a standard 10/100 Mb net-
work. The characteristics of these computers are listed in Table 2.
In the tests, different combinations of the section to be distributed were consid-
ered, representing several degrees of distribution. The simulations were assigned
to the available computers and the calculation and communication times were

Fig. 18. Simulator architecture.

 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 545

Fig. 19. Operator interface of one screen of diffusion section of the sugar factory.

Table 2
Characteristics of the set of computers
Id. Processor Memory Operating System
PC1 PIV 1.6 GHz 512 Mb Windows 2000 Pro
PC2 PIII 800 MHz 256 Mb Windows 2000 Pro
PC3 PIV 1.6 GHz 512 Mb Windows 2000 Pro
PC4 PIV 1.6 GHz 512 Mb Windows NT 4.0
PC5 PIV 1.5 GHz 512 Mb Windows 2000 Pro
PC6 PIII 1 GHz 512 Mb Windows 2000 Pro

obtained. Table 3 shows how the distribution is done, indicating in each row in
which computer the simulations will be executed (DIF—Diffusion, PD—Pulp Dry-
ing, D13—Depuration parts 1 and 3, DE—Depuration part 2, EVA—Evaporation,
SH—Sugar House, SB—Steam Boilers, CLI—Client Program). The tests, named Pi,

Table 3
Distribution of the simulations
Test DIF PD D13 DE2 EVA SH SB CLI
P1 PC1 PC1 PC1 PC1 PC1 PC1 PC1 PC1
P2 PC1 PC3 PC1 PC1 PC3 PC3 PC3 PC1
P3 PC3 PC2 PC1 PC1 PC2 PC3 PC1 PC1
P4 PC3 PC2 PC1 PC1 PC3 PC4 PC2 PC1
P5 PC3 PC3 PC1 PC5 PC2 PC4 PC1 PC1
P6 PC3 PC6 PC1 PC5 PC6 PC4 PC2 PC1
546 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

begin with the execution in only one computer and ends with the execution in six
computers.
The results obtained according to the distribution indicated in Table 3 are showed
in Table 4 (Time—Execution time, Comm—Communication time, % Comm—
Percent of communication time, Interval Time—Communication time for one inter-
val). The times correspond to the execution of 300 s of the simulation with a CINT of
5 s. The last column gives the time spent in the communications for one time interval
of 5 s.
The variability of the communications time depends partly on the available CPU
of the machine in which the client resides. The necessary time per intervals decrease
as the distribution degree increase, reaching the minimum value with the greater dis-
tribution degree, 100 ms, corresponding to 2% of the CINT.
Fig. 20 shows execution time of each studied case and how this time depends on
the computational requirements of the simulation, the distribution degree and the
performance of the computer where it is located. Observing the execution times of
each simulation showed in Fig. 20 it is possible to see that these times decrease when
the distribution degree is increased assigning them to faster machines. It is possible
to determine the maximum distribution degree for the available machines. In P6, the
slowest simulation is executed alone in the faster machine. With the available equip-
ment we will not obtain smaller execution times. For the local tests we did not used
last generation machines.
Total execution time of the studied cases is shown in Fig. 21. Note that the smaller
execution time obtained is bigger than the simulated time. With most powerful

Table 4
Execution times (in seconds)
Test Time Comm % Comm Interval time
P1 1304.33 12.88 0.99 0.22
P2 654.29 8.36 1.28 0.14
P3 515.78 14.60 2.83 0.25
P4 413.52 13.81 3.34 0.23
P5 354.84 6.96 1.96 0.12
P6 313.11 6.13 1.96 0.10

Fig. 20. Execution times of each simulation when the distribution degree increases.
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 547

Fig. 21. Execution times with different distribution degrees.

Fig. 22. Times per interval in most powerful machines.

machines (four PIV-2.8, one PIV-2 and two Athlon XP 1800) we obtain an execution
time less than the simulation time, 163 s, with an interval time of 0.08 s. These do not
imply that real time execution in all of the intervals is not guaranteed. Fig. 22 shows
that in several instants the maximal value is exceeded.
As can be seen the distribution of the simulation gives: (a) lower execution times
and (b) less communication times. In this case the communication time is always
upper 1% of the total time, with an interval communication time between 100 ms
and 250 ms.

8. Conclusions

This paper presents a methodology for the development of distributed process

simulation using OPC. The distributed component operates as OPC servers enclos-
ing continuous simulations developed with the simulation language EcosimPro.
548 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549

The use of OPC has many advantages and has been adopted by most of the com-
panies in the process control sector as a standard for communications among control
and instrumentation equipment. Its use has been tested in the paper in a distributed
continuous process simulation.
The principal advantages introduced by this methodology against other software
environments are: (i) With the use of OPC we obtain a high degree of accessibility.
Many industrial applications as DCSs and SCADAs systems, and others desktop
applications can access directly to the OPC Servers, then, the created distributed sim-
ulations could be used in a wide range of applications. (ii) The creation of distributed
simulations or single simulations using the developed tools is very easy for the pro-
cess engineers, because it avoids the details of the communications between simula-
tions and the necessity of an explicit programming.
The conclusions are: (i) This methodology is useful for simulations that can be
executed with a high CINT value and having high computational requirements, in
this way, the relation between the CINT and the communication time decreases.
The communications latencies for distributed computers are usually on the order
of few hundreds of microseconds, depending of the proximity of the machines.
The times obtained with DCOM communications are from 0.300 ms for one data
interchange between 2 computers to 1 ms, approximately for each 1000 data inter-
change. OPC is based in DCOM that uses a more complex communication system,
and more data to be transmitted, thus having poor performance than DCOM. The
study case of the beet-sugar factory is an optimum case, in witch the minimum time
interval obtained was 100 ms, witch correspond to a 2% of the CINT. (ii) Seeing the
communication time interval we can determinate that this methodology is not useful
for simulation with a low computational requirements or/and with a small CINT.
The delays introduced might result in a high simulation time execution, possible
higher than monolithic simulation time execution. (iii) Another factor that we must
considered is the granularity introduced by the distribution. Smaller CINTs produce
smaller granularity and higher execution times and the other way round. (iv) This
methodology is very easy to use with the simulation created with EcosimPro. We
can use the same structure to create a server to be executed alone or in a cooperative
way, in real time or ‘‘as-fast-as-possible’’ way. The server created can be accessed for
a wide range of applications.
The methodology has been applied to a large process simulator of a beet sugar
factory used for control room operator training. This includes a process simulation
operating in a network of six computers, a SCADA system for operation on the pro-
cess, an instructor console and additional software for real-time process communica-
tion and synchronisation. The simulator operates in the CTA, a joint research centre
between the University of Valladolid and AEA, a sugar company.

References

[1] Al Chistrolm, OPC Data Access 2.0 Technical Overview. OLE for Process Control and Factory
Automation, Intellution, Inc., October 1998.
 R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525–549 549

[2] L.F. Acebes, C. de Prada, Process and Control Design Using Dynamic Simulation, CITS General
AssemblyÕ99 Amberes, Holland, May 1999.
[3] L.F. Acebes, C. de Prada, R. Alves, A. Merino, S. Pelayo, A. Garca, G. Gutierrez, A. Rueda,
Development Tools for Full Scale Simulators of Sugar Factories, CITSÕ03, 22nd General Assembly of
the CITS, Madrid, May 2003.
[4] R. Alves, J.E. Normey-Rico, A. Merino, C. de Prada, Un SCADA va OPC aplicado a una planta
piloto, 2 Congresso Brasileiro de P&D em Petrleo & Gas, Rio de Janeiro, June 2003.
[5] CAPE-OPEN, Next Generation Computer-Aided Process Engineering Open Simulation Environ-
ment: Public Synthesis & Roadmap, June 1999.
[6] COLaN, The CAPE-OPEN Laboratories Network [Online]. Retrieved from: <http://www.colan.
org>.
[7] Department of Defense, Defense Modeling and Simulation Office, High Level Architecture, Run-
Time Infrastructure, RTI 1.3-Next Generation ProgramerÕs Guide Version 5, 2002.
[8] DMSO, Defense Modeling and Simulation Office [Online]. Retrieved from: <http://www.dmso.mil>.
[9] EcosimPro by EA International, Dynamic Modeling & Simulation Tool [Online]. Retrieved from
<http://www.ecosimpro.com>.
[10] Frant Iwainitz, Jrgen Lance, OPC-Fundamentals, Implementation and Application, ISBN 3-7785-
2883-1, 2002.
[11] Microsoft Corporation, DCOM Technical Overview, November 1996.
[12] Microsoft Corporation and Digital Equipment Corporation, The Component Object Model
Specification, Draft Version 0.9, October 24, 1995.
[13] Object Management Group, The Common Object Request Broker: Architecture and Specification,
2.2 ed., February 1998.
[14] OPC Foundation [Online]. Retrieved from: <http://www.opcfoundation.org>.
[15] S. Straßburguer, T. Schulze, U. Klein, J.O. Henriksen, Internet-based Simulation using off-the-shelf
Simulation Tools and HLA, in: Proceedings of the 1998 Winter Simulation Conference, SCS,
Washington, DC, 1998, pp. 1669–1676.
[16] S. Vinoski, CORBA: integrating diverse applications within distributed heterogeneous environments,
IEEE Communications 14 (2) (1997).
[17] J.M. Zamarreo, L.F. Acebes, R. Alves, OPC-based real time simulator: architecture and practical
example, in: Proceedings of the 41st SIMS Simulation Conference, SIMSÕ2000, 2000.