a cape-open compliant simulation module for an ammonia ... - CiteSeerX

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. Pérez1, A. O. Domancich12, G. E. Vazquez12, N. B. Brignole12 1

Grupo de Investigación y Desarrollo en Computación Científica (GIDeCC) Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur - Bahía Blanca - ARGENTINA 2

Planta Piloto de Ingeniería Química (UNS-CONICET) Complejo CRIBABB - Bahía 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 Ingeniería Química (UNS-CONICET) Complejo CRIBABB - Cno. La Carrindanga km 7 CC717 - Bahía Blanca - 8000 – Argentina E-mail: [email protected](N.B. Brignole)

1


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


•

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.

3


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 Group’s (OMG) CORBA (OMG CORBA, 2005) and Microsoft’s 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


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 (Köller and Töbermann, 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 (Köller, 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


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 (Köller and Töbermann, 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 developer’s 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 (Köller and Töbermann, 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

6


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


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


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.

9


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. Köller, J. (1999). Migration Methodology Handbook, available at http://www.colan.org. Köller, J., Töbermann, 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

a cape-open compliant simulation module for an ammonia ... - CiteSeerX

a cape-open compliant simulation module for an ammonia ... - CiteSeerX

Suggest Documents