Simulation Modelling Practice and Theory 13 (2005) 525549 www.elsevier.

com/locate/simpat

OPC based distributed real time simulation of complex continuous processes

l Alves Santos a,*, Julio E. Normey-Rico a, Rau mez b, Luis Felipe Acebes Arconada c, Alejandro Merino Go sar de Prada Moraga c Ce
a

Department of Automation and Systems, Federal University of Santa Catarina, 88040-900 CTC-UFSC, polis-SC, Brazil Floriano b Center of Sugar Technology, University of Valladolid, Edicio 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 simulation 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), mez), felipe@autom.uva.es (L.F. Acebes Arconada), prada@autom. alejandro@cta.uva.es (A. Merino Go 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) 525549

applications, due to the standard provided by OPC, (iii) use of low cost conventional equipment 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 simulation 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 benet of the increased computational power. Key elements in distributed simulation are the partitioning of the simulation among the dierent modules, the interchange of data between them along the simulation 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 modules, or for interconnections involving variables that present the smoothest changes. For the distributed execution of simulations there are several software environments 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 Oce [8] of the Department of Defense of USA (DoD) [7], that have their own communication and synchronisation 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 communication, 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 development of a set of specications 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 instructor 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) 525549

527

object oriented modelling language named EcosimPro Language (EL) that supports both, continuous and discrete event systems, and incorporates state of the art integration algorithms for solving (sparse) DAE models. Two important characteristics are: rst, that the computational causality of the mathematical models is not predetermined, so that these can be re-used in dierent contexts, and second, that the simulation 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 todays PCs 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 components as DCOM y CORBA, but, taking into account the context in which these simulators 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 methodologies and results are valid independently of the simulation environment. The paper is organised as follows: After the introduction, Section 2 gives an overview of EcosimPro and Section 3 introduces OPC. The methodology for the development 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, nally, 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 modied automatically according to the context in which they are used. This means that the user can specify dierent boundary conditions without modifying the model code, and EcosimPro will manipulate symbolically the equations to adapt them to the specications, which increases its re-usability. Being object oriented it support the paradigms of encapsulation, inheritance, etc.

528

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

Its simulation language, called EL, allows the description of process models, named components, in a natural way by means of continuous dierential algebraic equations and discrete events variables. Once the user has built its system interconnecting 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 dierent elds 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, depends 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) technology. It is managed by the OPC Foundation, supported by the majority of the companies that operate in the process control sector. Its main objective is providing an uniform access to data in industrial applications, in such a way that several clients can access the data managed by an OPC server through a Windows network. Prior OPC, vendors and users have to develop specic 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 heterogeneous clients like SCADAs, DCS, spreadsheets, etc. each of which have their own OPC interfaces. The objective of OPC is to dene a set of standard interfaces and a well dened behaviour for the server in order to allow the interoperability among dierent industrial devices in a network of dierent suppliers. The original specication standard-

Fig. 1. Access to a device using OPC.

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

529

izes the process data acquisition. Later, new variant of the OPC specications 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 dierent steps in the construction of a distributed simulation will be described. These include, for each node of the network, generating the EcosimPro 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 specic case of a simulator for operator training in process factories. This includes, not only a distributed simulation 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 predened 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 dening which are the external variables 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 x the computational causality of the model and, after dening 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) 525549

Fig. 3. EcosimPro simulation environment.

which is further compiled and linked with the system libraries for integration, etc. giving way to an executable le. This le can be accessed via OLE and, in fact, the EcosimPro environment provides an application called EcoMonitor that oers a graphical interface for performing experiments on the models. At the same time, the C++ source les 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 communication routines provided by the OPC standard. They can be develop at home or provided 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 les generated by EcosimPro, allowing the conguration of the servers for dierent 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 dierent 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) 525549

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 dierent servers and writes them into the corresponding destination servers, operating in a synchronous mode. After the data interchange has nished, it allows the time advance of the simulations. 4.4. Management of the environment in a process control simulator Todays 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) 525549

we have developed in house a congurable 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 dierent 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 connected to the OPC servers containing the simulations through its OPC client interface. 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 several users to operate the process at the same time. For this purpose, each SCADA has to be congured using its conguration programs. This means specifying which are the variables of the servers to be accessed, the synoptics to be displayed, value tables, etc. Once the conguration is done, it generates the conguration le that is read by the SCADA. After this, it ready to operate the distributed simulation (Fig. 6).

Fig. 6. Conguration 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) 525549

533

Similar steps are required by the instructor console, but in this case, additional variables from the process are congured to be handled, so that the instructor can act on a wider range of variables, creating, for instance, faults and malfunctions that must be identied and solved by the operators being trained. The resulting architecture for the training simulator is shown in the Fig. 7. It consists of several process simulations each representing a part of a global process, running 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 modies 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. Windows 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 independent 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) 525549

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 perhaps of real time in real time applications). In addition, the SCADA, that has their own timing, requires data from the simulation corresponding at pre-specied real time instants. Nevertheless, due to the dierent 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 synchronisation of the modules. Using the C++ classes generated by EcosimPro we can access and control the simulation. In particular, the simulation advance can be made with some functions provided by the code generated by EcosimPro. There are several ways of advancing the simulation time: advance a xed 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 simulate 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 functions operate with these granularity times. In order to determine the wait times Windows high performance counters have been used. These counters can determine the wait time in values of microseconds.
Table 1 Time advance simulation functions Function INTEG_CINT INTEG_TO INTEG Description Advances the simulation step by step. The step is determined by the communication interval, using the variable CINT Integrates the model until a certain time instant indicated in one parameter of the function 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) 525549

535

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

Fig. 10 shows the ow 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 externally by a client application that makes use of an advance ag for data interchange and synchronisation. The ag Single Server indicates when the server works in a single mode or in cooperation with others servers. The ag Advance is activated by the external application and it is used to implement the synchronisation. If it is deactivated the server remains waiting until its activation. 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 ag Advance is deactivated and the number of send is increased, so, the external application knows that the server has nished its calculations. When all the servers have nished their tasks

536

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

Fig. 10. Time advance thread.

the client application performs the data interchange and activates the Advance ags of the servers, starting so the next time step.

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

537

In addition in the thread it is possible to introduce an extra pause, or an acceleration factor in the simulation advance. The interest of this feature is to span or reduce the time scale in order to accommodate it to the needs of extremely slow processes. The pause is made through the activation of a ag 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 implemented introducing a ag that activates or deactivates the delay. 5.2. OPC server The access to the simulation is made through the elements, items, congured in the server. When an external client accesses a server it receives the values of the items according to the congured update time of the data. The communications with the client can be synchronous or asynchronous. In this case we use a dierent approach that combines synchronous and asynchronous communication. The rst one is used with the control signal because it is necessary to transfer the data in a given time instant. The asynchronous one is only used for the data to be exchanged. The conguration 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 subsequent periods. If an external event takes place, such as for instance a modication 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 dierent situations that could take place. In practice, reading and writing of data is done thought a buer controlled by the thread that manages the simulation advance, so that data can be interchanged between the simulation and the buer at each communication interval, when the computations are nished. In this way the reads and writes correspond to values

538

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

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

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, delity 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 conditions 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) 525549

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. Specications of this application include the variables to be interchanged, the variables that control the simulations, the advance ag, the communication interval and the number of steps. The synchronisation is made through the advance ag and a variable that indicates 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 ag. Then it computes the next step, deactivates the advance ag and increases the numbers 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 communication interval time. Fig. 12 shows the ow chart corresponding to the data interchange and synchronisation 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 verication of the ags of all simulations. If all advance ags are deactivated this indicates that they have nished the computation of their

Fig. 12. Interaction between client and server.

540

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

Fig. 13. Chronogram of synchronisation through advance ag 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 conditions are satised and then performs the data interchange between the dierent simulations, activates advance ag 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 simulations through the advance ags and the numbers of sends. 6.3. Some tools In order to facilitate the implementation of the proposed architecture, two applications were developed that help automating the development of a distributed simulation:

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

541

CreaOPC: that generates automatically OPC servers from the simulations developed 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 semiautomatic mode, making the necessary modications on the C++ source les .cpp and .h generated by EcosimPro, as well as on the sources les of the program 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 conguration le, register the server, and, if it is intended to be used in remote mode, conguring the DCOM access security. The conguration le of the servers contains the associations between identiers (tags) of variables that must be offered 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 synchronisation between several OPC servers containing the simulations. Its internal operation was already explained in Section 6.2. In order to use this application, a conguration le is required. This le contains the pairs of variables that will be interchanged between servers. This le is created with the UneSimCnfg application, which allows the selection the pairs of variables origindestination of OPC servers connected in a network, facilitating the conguration process and avoiding errors at the time of introducing the names of the tag variables. In addition, it allows the modication of existing congurations. Also, jointly

Fig. 14. Graphic interface of CreaOPC application.

542

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

Fig. 15. Graphic interface of UneSim application.

to the list of pairs of variables, the time value of the interchange interval is specied. Then, UneSimCnfg will generate automatically the conguration le for the UneSim OPC client. Once the conguration le 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 allows 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 responsibility, both in the normal operation of the plant which includes product quality, emissions control, eciency and protability, 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) 525549

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: diusers, evaporators, reactors, heat exchangers, crystallisers, dryers, lters, etc. operating both in continuous 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 several 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 computer is not possible if real time specications are required and a distributed simulation 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, facilitates the task of dening cut-points for the distribution of the simulation which correspond roughly to the working departments or sections. Thus, the complete simulation system was divided into seven individual simulations, one for each section, except for the depuration, the biggest in terms of computation because it involves a lot of mixed continuous and batch units, which has been subdivided in two parts. Fig. 17 shows how the dierent sections are connected, as well as the number 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 conguring the UneSim program, the external client is able of performing the tasks of communicating and synchronising the dierent simulations.

Fig. 16. Main sections in a sugar factory.

544

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

Fig. 17. The dierent 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 synchronisation, a SCADA connected to the OPC servers for operation of the process. In addition, one of the SCADA units, specially congured, 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 interface 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 signicant variables of the simulated processes, so that, by means the adequate interfaces, he/she can modify the working conditions, introduce faults and malfunctions, etc. which must be recognised 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 network. The characteristics of these computers are listed in Table 2. In the tests, dierent combinations of the section to be distributed were considered, 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) 525549

545

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

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

obtained. Table 3 shows how the distribution is done, indicating in each row in which computer the simulations will be executed (DIFDiusion, PDPulp Drying, D13Depuration parts 1 and 3, DEDepuration part 2, EVAEvaporation, SHSugar House, SBSteam Boilers, CLIClient Program). The tests, named Pi,
Table 3 Distribution of the simulations Test P1 P2 P3 P4 P5 P6 DIF PC1 PC1 PC3 PC3 PC3 PC3 PD PC1 PC3 PC2 PC2 PC3 PC6 D13 PC1 PC1 PC1 PC1 PC1 PC1 DE2 PC1 PC1 PC1 PC1 PC5 PC5 EVA PC1 PC3 PC2 PC3 PC2 PC6 SH PC1 PC3 PC3 PC4 PC4 PC4 SB PC1 PC3 PC1 PC2 PC1 PC2 CLI PC1 PC1 PC1 PC1 PC1 PC1

546

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

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 (TimeExecution time, CommCommunication time, % Comm Percent of communication time, Interval TimeCommunication time for one interval). 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 distribution 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 equipment 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 P1 P2 P3 P4 P5 P6 Time 1304.33 654.29 515.78 413.52 354.84 313.11 Comm 12.88 8.36 14.60 13.81 6.96 6.13 % Comm 0.99 1.28 2.83 3.34 1.96 1.96 Interval time 0.22 0.14 0.25 0.23 0.12 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) 525549

547

Fig. 21. Execution times with dierent 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 enclosing continuous simulations developed with the simulation language EcosimPro.

548

R. Alves Santos et al. / Simulation Modelling Practice and Theory 13 (2005) 525549

The use of OPC has many advantages and has been adopted by most of the companies 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 simulations 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 process engineers, because it avoids the details of the communications between simulations 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 interchange. 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 process, an instructor console and additional software for real-time process communication 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) 525549

549

[2] L.F. Acebes, C. de Prada, Process and Control Design Using Dynamic Simulation, CITS General Assembly99 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, CITS03, 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 Environment: 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 Oce, High Level Architecture, RunTime Infrastructure, RTI 1.3-Next Generation Programers Guide Version 5, 2002. [8] DMSO, Defense Modeling and Simulation Oce [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-77852883-1, 2002. [11] Microsoft Corporation, DCOM Technical Overview, November 1996. [12] Microsoft Corporation and Digital Equipment Corporation, The Component Object Model Specication, Draft Version 0.9, October 24, 1995. [13] Object Management Group, The Common Object Request Broker: Architecture and Specication, 2.2 ed., February 1998. [14] OPC Foundation [Online]. Retrieved from: <http://www.opcfoundation.org>. [15] S. Straburguer, T. Schulze, U. Klein, J.O. Henriksen, Internet-based Simulation using o-the-shelf Simulation Tools and HLA, in: Proceedings of the 1998 Winter Simulation Conference, SCS, Washington, DC, 1998, pp. 16691676. [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, SIMS2000, 2000.