2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering

th

A CAPE-OPEN COMPLIANT SIMULATION MODULE

FOR AN AMMONIA REACTOR UNIT
V. L. Prez1, A. O. Domancich12, G. E. Vazquez12, N. B. Brignole12
1

Grupo de Investigacin y Desarrollo en Computacin Cientfica (GIDeCC)

Departamento de Ciencias e Ingeniera de la Computacin
Universidad Nacional del Sur - Baha Blanca - ARGENTINA
2

Planta Piloto de Ingeniera Qumica (UNS-CONICET)

Complejo CRIBABB - Baha Blanca - ARGENTINA

Abstract. The easy widespread availability of process-engineering software is a subject of present concern.
There is a need for the development of integrated computing tools that can provide broad access to software
components coming from either academic sources or independent vendors. The CAPE-OPEN (CO) standard
provides a suitable environment for this purpose because it enables the generation of modules with plug-andplay facilities, which make them portable, thus facilitating their straightforward integration to different
simulation platforms.
Our research aims at the adaptation of complex existing modules so that they meet the CO standard. In this
work, the design and development of a CO-compatible component for the steady-state simulation of a multibed ammonia reactor is described. The resulting Operation Unit (OU) satisfies the definitions and guidelines
established by the standard. Before implementing the interfaces, an analysis of requirements for the correct
interaction of the OU with the other simulator components was carried out. Then, the objects to be invoked
were defined and the reactor model was codified. The original code, which had been written in FORTRAN,
was encapsulated in a dynamic link library (DLL) and employed as an OU calculating routine. Both the COcompliant OU and the interfaces were implemented in VISUAL BASIC, and then tested in the environment
of a commercial simulator.
Keywords: Process Systems Engineering, Software Components and Interoperability.

1. Introduction
Changes in the requirements placed on process engineers in research, development, design and production
have led to a whole new concept of manufacturing. Excellence in manufacturing is now possible only with high
efficiency, flexibility and responsiveness to market dynamics. In order to achieve these goals, the right operating
characteristics should be inherent in the design. The process of the plant together with the control, safety and
environmental protection systems conform an integrated whole to be designed. This is the essence of Computer
Aided Process Engineering (CAPE): the application of a systems modeling approach to a process and its
control, safety, utility and environmental protection systems, as an integrated whole, from the viewpoints of
development, design and operations (Lien and Perris, 1996).
CAPE is becoming a common used integration tool applied in modern industry. In industrial reality, the
application of CAPE is determined by the development of science and software tools with practical benefits
(Mayer and Shoenmakers, 1998).

Address: Planta Piloto de Ingeniera Qumica (UNS-CONICET) Complejo CRIBABB - Cno. La Carrindanga km 7 CC717 - Baha Blanca - 8000 Argentina
E-mail: dybrigno@criba.edu.ar(N.B. Brignole)

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

Actual limits of CAPE tools include the interface restrictions of software suppliers and the data management
problem (Mayer and Shoenmakers, 1998). Although simulation time has been reduced due to faster computers,
easier input and better solving algorithms; reporting the results may take much more time. This is because the
documentation process includes extracting data from modules from different suppliers.
To overcome these limits, many activities have aim to create an open environment for CAPE tools.
Integrated applications with several CAPE tools will be able to exchange data and program modules
independent from the supplier. One of the main projects working on this area is CAPE-OPEN (CO).
We describe the implementation and design of a Unit Operation, which supports the standard for
interoperability between software components in Chemical Engineering applications, called CAPE-OPEN. The
main goal of the present research project is to gain knowledge about this standard, which is a means of using
new software technologies in process engineering. In particular, the design and development of a COcompatible component for the steady-state simulation of a multi-bed ammonia reactor is presented. This work
will facilitate future adaptations involving other more specialized complex modules to the standard.
In view of the above-mentioned considerations, this paper begins with a description of the interoperability
standard CO, its main goals and work methodology. From this point, follows the possible migration strategies
and software tools available for this process. Then, the main features of our case of study, which is an ammonia
reactor, are described. The results obtained with the implemented reactor are then discussed. The final part of the
document deals with the main conclusions achieved.

2. CAPE-OPEN Project
In order to obtain better results when solving a specific problem, it should be possible to access more than
one vendor simulator and to in-house software containing company specific methods or data. The main projects
working on this area are: IK CAPE, CAPE-OPEN and GLOBAL CAPE-OPEN (Mayer and Shoenmakers,
1998).

IK CAPE is a cooperation of chemical companies. The main activities are the formulation of common
standards for programming and for interfaces.

CAPE-OPEN (CO) is a project funded from European Community; partners are chemical companies
(BASF, Bayer, BP, DuPont, Elf, ICI, IFP, etc.), universities (Imperial College, Institut National
Polytechnique de Toulouse, RWTH Technische Hochschule Aachen, etc.) and vendors (Aspentech,
SinSci, Quantisci, etc.). The project formulates an open environment for simulation with common
interfaces independent from the vendors for program modules and data transfer. The main objective is to
enable native components of a simulator to be replaced by those from another independent source, or
that are part of another simulator, with minimal effort (CAPE-OPEN Synthesis Report, 1999). For this
purpose the CO project aims to develop, test, describe and publish agreed standards for interfaces of
software components of a process simulator. Prototypes of CAPE-OPEN compliant software
components have been developed tested and demonstrated that it is possible for these newly developed
components or wrapped legacy code to communicate through the open standard interfaces.
2

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

GLOBAL CAPE-OPEN is the extension of these ideas of CO to a world wide project. The project aims
to reach acceptance for the standards for interfaces and software. Its results will be mainly commercial
software.

Implementation of CO standard is the main activity of the CO Laboratories Network (CO-LaN). It is an

internationally recognized, user-driven organization that facilitates the implementation of CO standard interfaces
in commercial software to make open simulation a practical reality (COLAN 2003 Leaflet).
CO-Lan missions are to expose user priorities for the CO standard to software vendors, ensure the standard
exploitation and dissemination, provide training and migration facilities; and supply compliance testers and
interoperability tests.

2.1. Scope of the CAPE-OPEN project

The specific focus of the CAPE-OPEN project has been on general tools for process modeling and their use
for steady-state and dynamic simulation (CAPE-OPEN Synthesis Report,1999). The project has recognized two
types of such tools, modular and equation oriented ones.
In an architecture for modular process modeling tools there exists a modular Process Modeling Executive
(PME) which is responsible for constructing the model and carrying out all necessary computations to solve it.
For this purpose it communicates with other modules that describe individual unit operations. Each module
needs to communicate with property packages to compute the physical properties that occur within the unit
operation model. As each unit operation module needs to solve the equations of the mathematical model
associated, they may also perform specialized algorithms or call external numerical solvers.
An important characteristic of modular process modeling tools is the need for the executive to organize and
coordinate the computations carried out by the individual unit operation modules.
The basic structure in an architecture for an equation oriented process package is almost the same as the one
presented. The main difference is that the unit operation modules do not need to solve their own equations.
Instead, they pass the information to the Executive which assembles them into a large set of equations and
solves it by interacting with one or more numerical solvers.
The ultimate vision of CAPE-OPEN is to allow complex process modeling tasks and model-based
applications to be performed successfully and cost-effectively using collaborative software components coming
from several sources and possibly being executed on different computer hardware. An example for this is shown
in Figure 1. Here, the PME is supplied by one vendor, whereas the Process Modeling Components (PMC) come
from different suppliers.
This analysis leads to the identification of the following classes candidates to standardization:

Thermo: provides physical properties services.

Unit Operation Modules.

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

Simulator
Executive
Vendor A

External UO
Vendor B

External Thermo
Vendor D

Libraries
Numerics

Unit

External Numeric
Vendor C

Thermo

Figure 1. Integration of different CO tools.

Numerics: provides numerical solvers and services.

Flowsheet analysis tools.

The interfaces mentioned above could be implemented in various different ways, for example as a simple
subroutine call in standard procedural languages such as FORTRAN or C (CAPE-OPEN Synthesis Report,
1999). However, CAPE-OPEN has chosen to adopt a component software and object-oriented approach which
views each PMC as a separate object. Communication between objects is handled by middleware such as the
Object Management Groups (OMG) CORBA (OMG CORBA, 2005) and Microsofts COM (Microsoft COM,
2005) . Using these technologies each software object is able to interact with others based on a formal interface
definition expressed in standard languages. The communicating objects can be running as part of the same
process, or in different processes on the same or different computer hardware connected in a network, thus
providing local/remote transparency.
Each interface in CO involves a set of methods and arguments which are expressed in CORBA Interface
Definition Language (IDL) and COM IDL. Developers of CAPE-OPEN compliant components will need to
incorporate the same declarations in their applications and to use IDL compilers to generate the corresponding
instructions in source language. The wrapping code generated in this manner can then be linked with the rest of
the components. Legacy code, such as FORTRAN models, can also be used by encapsulation within CAPEOPEN compliant wrappers.
The definition of interfaces throughout the project was done following a development process based on the
Unified Modeling Language (UML) object-orientated notation for all formal models of the interfaces, including
the user requirements, producing use cases, sequence diagrams, state transition diagrams, class diagrams and,
finally, interface diagrams which accompany the corresponding middleware implementation (CAPE-OPEN
Synthesis Report, 1999).
The project is using UML because it is the current best practice in software engineering (CAPE-OPEN
Conceptual Design Document, 1999). The requirement analysis may allow readers to see in an unambiguous
way what has been done in the work packages and allow the simulator vendors and anyone else to implement
the interfaces that connect software components to simulators.
4

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

2.2. Unit Operation interfaces

A modular-oriented unit operation has (CAPE-OPEN,2001):

Ports: to allow the module to be connected to other modules and to exchange material, energy or
information with them. Each material port has a thermo material object associated to it, using appropriate
methods of this object the OU is able to get the thermo and physical properties inlet and outlet flows.
These properties are part of the Property Package System, out of the scope of the present document.

Parameters: represent information which is not associated with the ports but which, nevertheless, the
modules wish to expose to their clients.

User Interface: allows the user to configure each instance of the module in an appropriate fashion. This
interface should be provided by the developer and its out of the scope of the standard.

Reports: to present the results of its computations. This feature is not part of the standard.

The computation of a unit operation module is triggered explicitly by its clients via the invocation of a
method provided by the unit operation object, called Calculate. There are no agreed standards for this method,
but validation test should be performed at this point. For example, checking the validity status of the material
objects connected to each port.
Equation-oriented unit operation objects also have the same configuration. The key difference is that, instead
of carrying out any computations, the main responsibility of the object is to form and expose a set of
mathematical equations.

3. Migration strategy
Since CO standards are a recent development, a lot of in-house, academic or commercial CAPE software
naturally do not comply with the CO standards yet (Kller and Tbermann, 2002). The main problem that may
arise is that source code could be written in a procedural programming language, such as FORTRAN, where
there exists only a collection of subroutines. This view of a system is different from the one of the software
component to be created. This latter approach uses object oriented techniques. Therefore, a migration process is
needed. There are mainly two ways to do this: re-implementing from scratch or wrapping existing code (Kller,
1999).
The re-implementing strategy seems to be the simplest one. But special care must be taken when creating the
new system. Although the original system may have been used and tested for a long time, the software created
from scratch could have a lot of errors resulting in system crashes or, what is even worse, in inconsistencies
between the behavior of the old and new implementation. Finding and fixing these bugs will take a lot of
resources. Therefore, this strategy seems to be very dangerous and expensive.
On the other hand, one could migrate the system without changing the source code. In this case, the
FORTRAN code is treated as a black box which functionality is used but how this functionality is implemented
is ignored. An object-oriented shell around this black box is provided to integrate the system into the component
based framework. This shell is implemented using an object oriented language such as Java or C++. Based on
5

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

this shell, a CORBA layer is provided to make the functionality available to the outside. This layer is also
implemented in Java or C++.
Leaving source code untouched is a way to avoid introducing new bugs to the core functionality of the
system. Another advantage of this strategy is that optimization is not longer necessary because it was already
done by the original developers. Taking all this into account, the latter strategy was chosen for this project.
In the Global CAPE-OPEN project a number of tools have been developed to support the implementation of
CAPE-OPEN components (Kller and Tbermann, 2002). All these tools are wizards which can produce source
code skeletons for CAPE-OPEN components thereby relieving the developer from implementing all the things
that occur in almost every CAPE-OPEN component in similar ways. One of this wizards that targets the
mechanical generation of Unit Operation Package, was used in the present project. This wizard generates a
Visual Basic project containing the source code of the OU and the installation package to install it in other
machines. In particular, the calculation routine and the Graphical Unit Interface are not generated. It is the
developers responsibility to provide this code. The OU generated will be compatible with the 0-9-3 version of
the CO standard.
As we have seen so far, migration requires integrating pieces of code that have been implemented in
different programming languages. Each of these languages has its own data structures and data types and has
different calling conventions for procedures, subroutines or functions (Kller and Tbermann, 2002). To
overcome these differences a bridging technology is needed. Here, a piece of software which can be an
executable, a library or a piece of source code or macros, is used to call legacy routines that reside in a compiled
library in the new source code. The bridging approach clearly separates old and new code thereby facilitating the
maintenance of both subsystems.
One of these technologies is the Dynamic Link Libraries (DLL) used in this project. Creating a DLL allowed
us to call a FORTRAN subroutine from Visual Basic without additional code.

FORTRAN 77

FORTRAN DLL
VISUAL BASIC

Figure 2. Wrapping FORTRAN code

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

4. Study Case: a simple chemical reactor

4.1. Description
The reactor used as case of study is a plug flow unit and is assumed to be isothermal with fixed conversion
(Byke and Grossman, 1985). The kinetics of the ammonia synthesis reaction over a double-promoted iron
catalyst is described by the following rate equation:
N2 + 3 H2 2 NH3
The reactor must be cooled to prevent the temperature of the catalyst from rising above 800 K, the
deactivation temperature of the catalyst. An inlet temperature of 703 K and a heat transfer coefficient of 19644
KJ/hr-K are sufficient to maintain the catalyst temperature below 800 K.
Conversion in the unit varies directly with catalyst volume and for a given catalyst volume there is a single
heat transfer coefficient (UA) for which the conversion will be a maximum. UA dictates the rate at which heat
can be withdrawn from the reactor. For low values of UA, the heat generated by the reaction builds up rapidly in
the reactor, a hot spot occurs near the feed point and much of the catalyst volume is inactive. As a result, the
conversion is low. For high values of UA, the rate of heat removal is large enough to slow the reaction rate,
decreasing the conversion.
4.2. Source Code Considerations
The original code for the simulation of the reactor is written in FORTRAN 77 for the VAX 11/780 (Byke
and Grossman, 1985). It invokes an IMSL library routine, called Dgear, to integrate the differential equations
from the model. The new version of the IMSL library includes this routine under a different name and with some
additional features. This new routine is called Ivpag and was the one used in this project.
Another modification added to the original code involved the interaction with the user. The source code
already had a user interface which was removed because it became the OU responsibility to obtain and check the
input parameters and to display the results in an appropriate way.

5. Results
Once the FORTRAN code had been tested and wrapped into a DLL, the OU was created. This OU presents
the following features:

There are two available material ports, INPORT and OUPORT. The material object connected to the
INPORT carries the initial flow rates of hydrogen, ammonia, nitrogen, water, methane and argon. It also
provides the feed temperature and pressure. The OUTPORT flow rates, temperature and pressure are
specified by the unit.

A set of parameters specify the remaining data that must be provided to the calculating routine.

A pseudo code of the calculation routine of the OU is as follows:

7

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

Private Sub ICapeUnit_Calculate()

'Declare private variables
...
'Gets connected ports
Set PORTIN = GetPort("PORTIN")
Set PORTOUT = GetPort("PORTOUT")
'Gets material objects associated to the ports
Set materialIn = PORTIN.connectedObject
Set materialOut = PORTOUT.connectedObject
'Gets components ids and number of components
Components = materialIn.ComponentIds
NumComponents = materialIn.GetNumComponents
'Gets the total flow and partial flows of the input
flowIN = materialIn.GetProp("flow","Overall",Components,vbNullString,
"mole")
totalIN = materialIn.GetProp("totalFlow","Overall",Empty,vbNullString,
"mole")
'Gets the temperature and pressure of the input
T = materialIn.GetProp("temperature", "Overall", Empty, vbNullString,
Empty)
P = materialIn.GetProp("pressure", "Overall", Empty, vbNullString, Empty)
'Gets the values of the parameters
...
'Calculates input parameters for the DLL routine
...
'Calls the DLL routine
Call DLL_QBED(XIN, XOUT)
'Sets outport temperature and pressure from the output parameter XOUT
...
materialOut.SetProp "temperature", "Overall", Empty, vbNullString, Empty,
TOUT
materialOut.SetProp "pressure", "Overall", Empty, vbNullString, Empty, POUT
'Sets total and partial flow of outport from the output parameter XOUT
...
materialOut.SetProp "flow","Overall",Componentes,vbNullString,"mole",
flowOUT
materialOut.SetProp "totalFlow","Overall",Empty,vbNullString,"mole",
totalOUT
End Sub
Unit conversions were added in this OU calculation routine. This was necessary because CO specifies certain
units for temperature, pressure, flows and so on. Since these units differed from the ones used in the FORTRAN
code, the appropriate transformation was included. In addition to this, components names had to be properly
written in order to agree with those from the standard. All this information is available at the Thermodynamics
and Physical Properties document (CAPE-OPEN, 2002).
8

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

The CO-compliant OU developed was successfully installed and it became available in Hysys as an
extension to the Unit Operations list.

Figure 3. CO Operation Unit available at Hysys.

In order to test this new OU, it was installed in an ammonia plant simulated with Hysys. This plant used a
reactor provided by the mentioned simulator, which implements a model different from the one present in the
study case (Byke and Grossman, 1985). This is the reason why differences between the simulation runs and the
study case results were founded. The Hysys reactor was replaced by the CO component developed and
simulation runs were analyzed. The obtained results were similar to those from the study case, thus
demonstrating that the whole simulation successfully works using the CO unit.

Figure 4. CO Unit Operation in a Hysys simulation case.

2nd Mercosur Congress on Chemical Engineering

4 Mercosur Congress on Process Systems Engineering
th

6. Conclusions
The present document aimed at identifying the primary concepts and tools that should be used when building
a CO-compliant module. In particular, it focuses on Operation Units that use FORTRAN calculation routines.
The resulting CO unit was successfully installed and tested in a commercial simulator, thus providing an
important example of interoperability between CO modules and native ones. The migration process chosen
allowed a transparent adaptation of the existing code to the standard with minor modifications. On the basis of
this experience, the same process may be used to plug in an existing code to any CO-compliant simulator.
From an academic point of view, CAPE-OPEN allows new theoretical developments to be implemented and
tested with qualified software components. New modules are able to use extern software components, such as
data bases with thermo-dynamic properties of the simulator or from a different source, improving the final
product quality and reducing implementation time and cost. From a commercial point of view, CO permits
competitive development of products. Companies that develop software components for process industries will
expand the number of applications where their products can be executed. In addition to this, software companies
and academic institutions will be able to develop components and then transfer them to the process industry field
in a straightforward manner.
The development of CO-compliant software involves interaction between two main disciplines: Computer
Science and Process Engineering. This knowledge complementation is necessary because Software expertise
(DLL, Object-Oriented Programming, etc.) is required and details of the process to be implemented should be
deeply and properly understood.

References
Byke, S., Grossman, I. (1985), Design of an Ammonia Synthesis Plant, Department of Chemical Engineering, CarnegieMellon University, Pittsburgh, Pennsylvania.
CAPE-OPEN Conceptual Design Document CDD2 - Interim Report - Project BE 3512 (1999), available at
http://www.colan.org .
CAPE-OPEN Synthesis Report (1999), available at http://www.colan.org .
CAPE-OPEN Open Interface Specifications - Thermodynamics and Physical Properties (2002), available at
http://www.colan.org .
CAPE-OPEN Open Interface Specifications - Unit Operations (2001), available at http://www.colan.org.
COLAN 2003 Leaflet, available at http://www.colan.org.
CORBA Object Management Group, http://www.omg.org/corba.
Kller, J. (1999). Migration Methodology Handbook, available at http://www.colan.org.
Kller, J., Tbermann, J.(2002). Migration Cookbook, available at http://www.colan.org.
Lien, K., Perris, T., (1996). Future Directions for CAPE Research, Comp. Chem. Eng., 20, 1551.
Mayer, H.H., Shoenmakers H., (1998). Application of CAPE in Industry - Status and Outlook, Comp. Chem. Eng., 22, 1061.
Microsoft COM, http://www.microsoft.com/com.

10