Software Architectures and Tools for Computer Aided Process Engineering

B. Braunschweig and R. Gani (Editors)

9 2002 Elsevier Science B.V. All rights reserved. 303

Chapter 4.4: The CAPE-OPEN Standard: Motivations,

D e v e l o p m e n t Process, Technical Architecture
& Examples

J.-P. Belaud, B. Braunschweig & M. White

The CAPE-OPEN standard was developed in two successive EU-funded projects,

CAPE-OPEN and Global CAPE-OPEN. Some aspects of CAPE-OPEN are
presented elsewhere in the book (see chapter 3.3); this chapter gives a broad view
of the standard and presents a few examples. The standard itself is available at
the www.colan.org website.

We start by setting up the scene with a section on motivations and history. Then
we present elements of the standard: its development process (section 4.4.2); its
global architecture (section 4.4.3), an example of use (4.4.4) for unit operations
and physical properties; and a further look at other portions of the standard,
namely numerical solvers and access to physical properties data bases (4.4.5 and
4.4.6); the chapter ends with a short conclusion and a presentation of future
activities and of the CO-LaN organisation.

4.4.1 MOTIVATIONS & HISTORY

The CAPE-OPEN project brought together software vendors, global chemical

manufacturing companies and universities to solve how enterprise software for
designing and optimising process plants could be made interoperable. The CAPE-
OPEN project and its successor, Global CAPE-OPEN has had a profound impact
on the strategic direction and markets for process simulation software.

At one time, chemical and refining companies built and maintained their own
simulators. In the 1970s and 80s almost all of these global companies came to
the conclusion that there was no strategic value in developing simulators, and
dropped their own proprietary simulator products in favour of a handful of
commercial software companies. Maintaining large in-house systems proprietary
systems with negligible strategic value became too difficult and expensive for
these large companies. This is a similar trend as other enterprise software
solutions, including payroll, accounting and h u m a n resources, where companies
304

opted not to continue developing in-house software and bought from external
software vendors.

By the time CAPE-OPEN was conceived and formed all of the companies on the
project had successfully divested their proprietary simulators in favour of
commercial versions from companies like Aspen, Hyprotech or Simulation
Sciences. The value of the software was in the plant models, thermodynamic
packages and solvers that each of the companies had developed to optimise the
design processes of their specific plants. Each global company still maintained
strategic and proprietary plant models, which were extraordinarily strategic to
their businesses. These models were built and used within the earlier
proprietary simulation packages and now were integrated into commercial
simulators provided by software vendors. The integration process for adding
these models was time consuming, painful and expensive. To complicate matters,
each software vendor had their own process and approach for integration into
their respective system.

As a result of the difficulties these global companies faced integrating these

software packages, combined with accelerating software technology trends, the
CAPE-OPEN project was launched, to create an open system that would allow
software vendors, global process operating companies and universities to define a
s t a n d a r d t h a t would allow plug and play of process modelling components across
commercial simulation packages. CAPE-OPEN's goal and challenge was to
create a single standard for integrating the components of software simulation
across commercial software suppliers.

The markets for process simulators, although crucial to design and operation of a
petrochemical plant, are mature. The CAPE-OPEN project enabled software
suppliers to change the software architecture of their underlying applications and
to better address the integration needs of their largest customers. The
collaborative and competitive nature of the CAPE-OPEN project was a perfect
environment to explore the technical and business direction of process simulation
software.

Establishing a business, chemical engineering and software driven standard

across competitive software vendors was a revolutionary concept. If an open
system for process simulation could be created it would m a r k the first time that
competitive software companies collaborated to define business standards and
components across existing enterprise software packages. For the global
operating companies, this project was a way to:
Continue to divest non-core software;
[] Influence standards of their domain;
[] Reduce cost and time of integrating models and other simulation
components;
[] Gain efficiencies in process engineering workflow.
 305

For the software company partners, the CAPE-OPEN project was a way to:

[] Explore avenues for increasing overall market share;

[] Improve integration strategies;
[] Move from monolithic application to flexible component architecture;
[] Transition to new architecture and technologies with direct user feedback;
[] Examine new business models for selling and positioning simulation products.

The CAPE-OPEN project enabled new levels of collaboration across partner

networks. Competitors and customers alike worked side-by-side to increase the
value of the process simulation software markets. Each software competitor
needed to open and discuss their competitive advantage so the market could be
expanded for all.
4.4.1.1 The P r o j e c t s

The CAPE-OPEN project was funded by the European Commission under the
Industrial and Materials Technologies Program from J a n u a r y 1997 to June 1999.
The partners comprised chemical or petroleum operating companies (BASF,
Bayer, BP, DuPont, Elf, ICI), a process licensor (IFP, co-ordinator), major
international vendors of process systems tools (AspenTech, Hyprotech and
SIMSCI), European academic research groups in the process systems field
(Imperial College, RWTH-Aachen, INP-Toulouse) and a software consultancy
(Quantisci). The project developed standard interface specifications for unit
operations modules, physical and thermodynamic properties systems, numerical
solvers, and graph analysis tools.

The second stage of developing an open architecture for process engineering was
the Global CAPE-OPEN (GCO) project, operating as an IMS activity involving
interregional collaboration. The partnership in GCO gathered an unprecedented
setting of highly skilled users, developers and researchers in CAPE. The
partners represented 50% of the world users of CAPE software, 90% of the
suppliers, and 10 amongst the top 12 research laboratories on the subject
worldwide.

The first achievements of the GCO project were demonstrated during the project
mid-term meeting hosted by AEAT Hyprotech and collocated with the
Hyprotech2000 conference in Amsterdam. Painless interoperability of two
commercial environments from Aspentech and AEAT Hyprotech was
demonstrated, completed by demonstrations of CAPE-OPEN compliant software
components from several companies and universities. New standards for
additional components were presented, and the foundation of the CO-LaN was
proposed.

The second half of the GCO project developed these technologies further, giving a
sound operation basis for the forthcoming CO-LaN initiative. Results of the GCO
306

project were demonstrated at its final technical meeting hosted by Aspen

Technologies in Cambridge, UK; the results included full commercial
interoperability of unit operations and physical properties from several large and
small software companies, software prototypes for new standards, many
migrated components from software vendors, universities and end-users.

4.4.2 T H E C A P E - O P E N D E V E L O P M E N T PROCESS

CO and GCO relied on a structured process starting from users requirement and
leading to software implementation, test and validation. The process is meant to
be incremental, as shown on figure 1, and uses UML (Unified Modelling
Language) notation for use case diagrams, sequence diagrams, component
diagrams and class/interface diagrams. Interface specification documents contain
a phased description of these diagrams, in order to allow future users and
developers to better u n d e r s t a n d the specifications and how they were developed.
Examples of UML diagrams and other technical elements are given in section
4.5.3.

Users Reqs
DAE solvers
,,4 - - ' oil.
~ User~Reqs __.._
/ ~ ...... ~'~ NLEQ solvers

,,J s
/ / ," Users Reqs ~ X
[ /' ,' ~ LEQsolvers :~ \
Tests :' / ~ InterfaceModels... ,.
NLEQ s o l v e r s ....a / ' [
LEQ solvers
] Interface Models
h "~I'--.. lests
" " LEQ solvers Start ~/ NLEQ solvers
\ ~: Interface Specs ]
\ ~ LEQ solvers ]
~ Prototypes _ _.J , y
LEQ solvers
Prototypes ~ . . . . . .
NLEQ solvers Interface Specs
NLEQ solvers
Figure 1: Incremental specification of solvers

In addition, we used an approval system based on an RFC (Request for

Comments) process in order to make sure that all documents benefit from
contributions from and are agreed by all concerned specialists. The approval
process consists in a technical validation phase, followed by a period for
commenting, and concluded by formal voting, with a possibility of recycling at
any stage in case of failure.

The technical work process t h a t was followed for each interface is presented in
Table 1.
 307

Table 1: Work Process Phases

Phase Step Goal
ANALYSIS Users requirements, text Requirements in textual format
ANALYSIS Users Requirements, Use Cases Use Case models
DESIGN Design Models Sequence, Interface, Component
Diasrams
SPECS Draft Interface Specifications Draft Interface specifications in
COM and CORBAIDL ,,,

OPTIONAL RFC process Approval of Draft Specifications

PUBLISH
IMPLEMENT Interface Implementation Prototype implementation
TEST Standalone Testin$ Interface validation
TEST Interoperability Testing Validation on interoperability
scenarios
SPECS Final Interface Specifications Final specifications in COM and
CORBA IDL
PUBLISH RFC process Approval of final specifications

The need for such a formal approval process arises from the fact t h a t reaching
consensus on complex technical documents can be long and tedious, especially
w h e n m a n y organisations with different backgrounds a n d different goals have to
agree. The CAPE-OPEN approval process is based on examples from other
i n t e r n a t i o n a l bodies, such as the Object M a n a g e m e n t Group (OMG), or the
Petrotechnical Open Software Corporation (POSC). Compared with the OMG
process, the CO process is simplified so t h a t approval delays are shorter; on the
other h a n d s it explicitly t a k e s into account the s t a n d a r d s development process
with software prototypes playing a major p a r t in testing the specifications for
interoperability. The process has been successfully applied in the Global CAPE-
O P E N project and will be used by the CAPE-OPEN Laboratories Network.

4.4.3 T H E C A P E - O P E N S T A N D A R D

This section introduces the current status of the C A P E - O P E N (CO) s t a n d a r d

from a technical point of view. After an introduction to the formal documentation,
the architecture is mentioned. Then, the CO system is modelled concisely and
three examples of CO specifications are given. Although this c h a p t e r deals with
the version 0.9.3 of CO, up-to-date information on the s t a n d a r d can be found on
the official web site [1].

4.4.3.1 CO formal documentation set

The CO s t a n d a r d is characterised by a unique a n d global version n u m b e r a n d is

described by a set of documents. Each document has its own versioning n u m b e r
in order to track its own life cycling, however it r e m a i n s a subset of a CO version.
The road map of the CO formal documentation set is shown in the next figure.
308

I CAPE-OPENstandard I
version0.9.4
I ! I I I
[ General~,on II Technicalarchitecture [I BusinessInterface II CommonInterface ([Implementati~ Spedfica"onI

Synthesis Report IntegratedGuidelines Thermodynamicand Identification Specification for COM

Road Map Migration Methodology Physical Properties
Parameter Specification for CORBA
Handbook Unit Operations
Conceptual Document IntegrationReport
Numerical Solvers Error
Path Recommendations
Sequential Modular
SpecificTools
Figure 1 CO documentation set

The formal documentation set includes the following blocks. Altogether they
define the c u r r e n t version of the CO standard:

[] General vision contains documents t h a t should be r e a d first to get the

s t a n d a r d general information such as general r e q u i r e m e n t s a n d needs.
[] Technical architecture integrates the horizontal technical materials and
defines an i n f r a s t r u c t u r e aiming at a process simulation b a s e d on the CO
standard.
[] Business interface contains all vertical interface specification documents.
These interfaces are domain-specific interfaces for the CAPE application
domain. They define CO components involved in a CO process simulation
application. In some way these documents are abstract specifications, which
create and document a conceptual model in an i m p l e m e n t a t i o n neutral
manner.
[] Common interface encloses horizontal interface specification documents for
handling concepts t h a t may be required by any business interfaces. This is a
collection of interfaces t h a t support basic functions and are always
i n d e p e n d e n t of business interfaces. In some way these documents are abstract
specifications, which create a n d document a common conceptual model in an
i m p l e m e n t a t i o n n e u t r a l manner.
[] I m p l e m e n t a t i o n Specification contains the i m p l e m e n t a t i o n of the business
and common interface specifications for a given distributed computing
platform. In order to produce CO compliant software components any
developer has to use these official interface definitions.

4.4.3.2 CO a r c h i t e c t u r e elements

The CO architecture elements section describes technical objectives and

terminology and provides the i n f r a s t r u c t u r e upon which supporting business and
common interfaces are based. This input comes from the folder technical
architecture (especially the integrated guidelines document) of the CO
documentation set. This section identifies the technologies associated with the
CO standard, includes the object model which defines common semantics and
shows the reference model which embodies the CO interface categories, CO
 309

components and communication mode. The CAPE wide-scale industry adoption of

this CO architecture provides application developers and end-users with the
means to build interoperable simulation software systems distributed across all
major hardware, operating system, and programming language environments.

Selected technologies

The following technical decisions are supported by the development of CO. More
general information on these methods and tools is provided in chapter 4.2. Key
elements are the software system modelling within co-operative working process
and the distributed computing accessible over the network (intra/extra/internet).

The CO interfaces are developed and expressed using an object-oriented

paradigm. This paradigm is currently the best technical solution for developing
interface standards. It also encompasses the "conventional" procedural approach.

The standard relies on the (distributed) component based approach. The

standard assumes that a process simulation tool can be made of several
components.

The standard uses object-oriented middleware technology, namely Microsoft

COM and OMG CORBA that basically carry out the communication. The
implementation specifications are available for both middleware. Consequently
the standard is independent from implementation languages, and is applicable to
several hardware platforms and operating systems. Furthermore,
interoperability of CO software components over a network of heterogeneous
system is guaranteed.

The standard allows the encapsulation of legacy code, such as Fortran code, to
deliver CO software components.

The Unified Modelling Language (UML) is extensively employed for visualizing,

specifying, constructing and documenting the artifacts of CO.

CO object model

The object model inherits from the OMG and Microsoft object model. Due to some
conceptual inner choices a specific model is built and becomes a CO object model.
Its main characteristics are explained in a few words in this section.

The CO object model provides an organised presentation of object concepts and

terminology. It defines common semantics for specifying the externally visible
characteristics of interface objects in a standard implementation-independent
way. In other words, it defines which interfaces, operations, formal parameters,
attributes, data types, classes, objects and components are in the scope of CO
310

system. The design of interfaces included in the business and common interface
specification documents are built from this CO object model.

Interface: An interface (in fact object class stereotyped <<interface>>) is a

collection of possible uses in order to specify through its operations the service of
a class. To standardise the interfaces specific to the CAPE domain is one major
objective of CO. They are classified as business or common interfaces. At this
level, they are designed in an abstract manner, explicitly using the UML notation
and the CO object model. English being the base language, the CO interfaces
follow the naming convention such as ICapePackageIdentifier within a scope of
packages organisation where the global package is CapeOpen.

From the conceptual models of business and common interface specifications, the
implementation specifications are expressed in Microsoft Interface Definition
Language and in OMG Interface Definition Language.

Object: An object is an instance of a class. An object satisfies a CO interface if it

can be specified as the target object in each potential request described by the CO
interface. It belongs to the implementation step and so is out of the CO scope.
The development of a CO compliant software does not imply the choice of an
object-oriented language. Indeed platforms such as COM and CORBA introduce a
kind of pseudo objects.

Component: The component is a blob of software that encapsulates the

implementation of some business process logic. It is important to distinguish the
component and object technologies. The former is a packaging and distribution
technology, focusing on what a component can do, while the latter is an
implementation technology, focusing on how a component works. Thus a CO
compliant component is a piece of software that wraps up the proprietary objects,
which realise or use CO interfaces. The communication between CO component
instances is defined by the standard.

In order to make the difference between the service provider and the service
requestor, the standard distinguishes two kinds of CO software components:
Process Modelling Component (PMC) and Process Modelling Environment
(PME), the former providing services to the latter. Typically, the PMEs are
environments that support the construction of a process model, and allow the
end-user to perform a variety of different tasks, such as process simulation or
optimisation. The distinction between these two components is not readily
obvious. Furthermore, it is worth noting that, in the near future, it will be
possible to assemble any number of PMCs to deal with a specific process
simulation task.

CO reference model: The CO reference model, illustrated in the next figure,

identifies and characterises the components, interfaces, and communication
 311

protocols. It includes the middleware component t h a t enables the communication

in a distributed environment, the CO components (PMEs a n d PMCs) a n d two
categories of interfaces (common interface and business interface).

Figure 2 Reference model

The middleware component is the basic m e c h a n i s m by which objects

t r a n s p a r e n t l y m a k e requests to and receive responses from each other on the
same machine or across a network. It forms the foundation for building open
simulation applications constructed from distributed CO components in both
homogeneous a n d heterogeneous environments. According to the selected
middleware technologies, the communication protocol is GIOP/IIOP for OMG
CORBA a n d DCE RPC/COM for Microsoft COM.

The business interfaces are domain-specific interfaces for process engineering

applications. Within this category, i m p o r t a n t classes of PMCs are identified such
as physical properties, unit operation modules, numerical solvers, a n d flowsheet
analysis tools.

The common interfaces are general-purpose interfaces t h a t can be f u n d a m e n t a l

for developing useful CO components. They are a collection of interfaces t h a t
support basic functions, which allow reusing of design concepts. The adopted CO
common interfaces are declined in p a r a m e t e r , identification a n d error interfaces.
P a r a m e t e r interface defines a p a r a m e t e r service for CO components t h a t wish to
expose their m a t h e m a t i c a l model i n t e r n a l data. Identification interface defines
an identification service for CO components t h a t wish to expose their n a m e s and
descriptions. This information refers to a component-specific instance. E r r o r
interface describes how a CO component has to m a n a g e an a b n o r m a l execution
termination. It defines a classification and a hierarchy of errors t h a t m a y occur
during a process simulation.
312

4.4.3.3 CO standard content

In order to describe the content of the current CO standard, this section exploits
the UML model of CO system. After introducing its scope, the different classes of
PMCs are detailed, as well as the relations between them and any PMEs. Those
can be thought as the physical views of the model. Then, the analysis of packages
and their dependencies will be done coming from the logical view.

Scope: Open architectures can benefit many different types of process

engineering software. However, the CO s t a n d a r d is specifically focused on
general tools for process modelling and, in particular, on their use for steady-
state and dynamic simulation. Moreover, the s t a n d a r d recognises explicitly the
de facto existence and widespread practical usage of two different types of such
tools, namely the modular and equation-orientated ones. Currently the CO
s t a n d a r d does not cover file format, physical model content, accuracy of models
and data, graphical user interface, process synthesis and computational fluid
dynamics.

Extracting CO components: physical view: The next figure illustrates the physical
aspects from the component view in the frame of a CO simulation system. It
shows the relations of dependency between the different PMCs and a PME.

Figure 3 Relations between PMC and PME

The following sections consider in greater detail the actual scope of each type of
component defined by CO. It also describes the key concepts underpinning each
PMC and its main characteristics.

Thermodynamic and physical property component: In the area of physical

properties, CO has focused on uniform fluids t h a t are mixtures of pure
components or pseudo-components, and whose quality can be described in terms
of molar composition. The physical properties operations t h a t have been provided
 313

with standardised interfaces are those required for the calculation of vapour-
liquid-liquid-solid equilibrium or subsets thereof, as well as other commonly used
thermodynamic and transport properties. A key concept in CO is t h a t of a
material object. Typically, each distinct material appearing in a process (in
streams flowing between unit operations, as well as within individual unit
operations) is characterised by one such object. Each unit operation module may
interact with one or more material objects. To support the implementation of the
above framework, CO has defined standard interfaces for material objects as well
as thermodynamic property packages, calculation routines and equilibrium
servers.

Unit operation component: CO has defined a comprehensive set of standard

interfaces for unit operation modules being used within modular and steady-state
PMEs. A unit operation module may have several ports, which allow it to be
connected to other modules and to exchange material, energy or information with
them. In the material case (which is also the most common), the port is
associated with a material object. Ports also have directions (input, output, or
input-output). Unit operation modules also have sets of parameters. These
represent information, which are not associated with the ports but t h a t the
modules wish to expose to their clients. Typical examples include equipment
design parameters (e.g. the geometry of a reactor) and important quantities
computed by the module (e.g. the capital and operating cost of a reactor).

Numerical solver component: Here, CO has focused on the solution algorithms

t h a t are necessary for carrying out steady-state and dynamic simulation of
lumped systems. In particular, this includes algorithms for the solution of large,
sparse systems of non-linear algebraic equations (NLAEs) and mixed (ordinary)
differential and algebraic equations (DAEs). Algorithms for the solution of the
large sparse systems of linear algebraic equations (LAEs) t h a t often arise as sub-
problems in the solution of NLAEs and DAEs have also been considered. CO has
introduced new concepts, such as models and the equation set object (ESO),
which is a software abstraction of a set of non-linear algebraic or mixed
(ordinary) differential and algebraic equations. The s t a n d a r d ESO interface
enables an access to the structure of the system, as well as to information on the
variables involved. The equations in any model may involve discontinuities.
Discontinuous equations in models are represented as state-transition networks
(STN). A formal presentation of numerical (solvers) methods is given in chapter
3.2..

Sequential modular specific tool component: A key part of the operation of

sequential modular simulation systems is the analysis of the process flowsheet in
order to determine a suitable sequence of calculation of the unit operation
modules. Thus, typically the set of units in the flowsheet is partitioned into one
or more disjoint subsets (maximal cyclic networks, MCNs), which may then be
solved in sequence rather t h a n simultaneously ("ordering"). The units within
314

each MCN are linked by one or more recycle loops while calculations involving
them are converged via the identification of appropriate "tear streams" and
through iterative solution techniques. The above tasks are typically carried out
using a set of tools t h a t operate on the directed graph representation of the
flowsheet. CO has defined standard interfaces for the construction of these
directed graphs, and for carrying out partitioning, ordering, tearing and
sequencing operations on them.

Organising services: logical view: We study now the s t a n d a r d from the logical
view. The s t a n d a r d has a large scope and already defines an important number of
interface classes. F u r t h e r m o r e this n u m b e r will increase along the standard life
cycle. As the interface is a structural element, which is too small in a real system
such as CO, the s t a n d a r d uses extensively the package concept, which acts as a
grouping element. A package forms a logical set of related interfaces with high
internal coherence and low external coupling. The division in packages brings
many advantages such as an easier m a n a g e m e n t of the system complexity, an
improvement of the maintainability and the life cycling. Coherence and
independence are the fundamental principles in order to organise the structure of
CO packages. It is interesting to notice t h a t a logical package does not assign
automatically a corresponding physical component. This is the case for CO where
services of a CO component are specified through several packages. When one
package, acting as a "client", uses another, acting as a "server", to supply needed
services, the client package is said to be dependent on the server package. The
structural model of analysis illustrates the dependencies between CO packages.
The next figure only displays second level package dependencies (CapeOpen
package being the "mother" package).

Figure 4 Package dependencies

The business and common interface folders of the CO formal documentation set
contain all the specifications that is under the package CapeOpen.
 315

The logical view t h a t contains the design view and its related structural
organisation can be seen as abstract since it remains middleware independent.
The implementation specification folder of the CO formal documentation set
encloses the design of CO system applied to COM and CORBA. The standard files
for COM and CORBA platform are respectively CAPE-OPEN.tlb and CAPE-
OPEN.idl knowing t h a t they are distributed as a whole. CAPE-OPEN.tlb is a
type library (a compiled version of the Microsoft IDL source) required by the MS-
Windows operating system. CAPE-OPEN.idl is a file expressed in OMG IDL. No
corresponding compiled version is provided because t h a t would be a strong
contradiction to the CORBA objective of implementation independence.

4.4.3.4 E x a m p l e 1: CO unit o p e r a t i o n

In order to illustrate an open interface specification, this section gives some

information on a CO unit operation component. The complete data can be found
in the CO formal documentation set. The unit operation open interface
specification document from the business interface folder is the central
contribution.

To look at this specification we will follow the different phases defined by the CO
development process through UML diagrams and parts of specification code. No
information will be supplied on the implementation and validation phases.

Analysis: This specification describes the unit operation (UO) component of the
CO System. The CO unit operation deals with straightforward unit operation
using regular fluids in a sequential modular, steady-state simulator. It makes
use of a physical properties interface. This behaviour is currently extended to
deal with equation-oriented simulation mode and dynamic simulation but this
has not been validated yet and so does not belong to the current CO standard.

The next figure shows the type of information passing through public unit
parameters and the transfer of stream information between a sequential modular
simulator and a CO UO. It describes a part of the system behaviour.

The global variables are essential for the calculation of heat and mass balances
(e.g. stream temperatures, ...). They have mandatory names across all CO
interfaces and are included in the CO standard. These variables are visible
across all CO components.

The public unit parameters (PUPs) are used for control/optimisation (sequential
modular simulators) and custom reporting. They are internal variables of a CO
UO and are n a m e d and made accessible to CO interfaces. Their names are not
part of the CO standard. PUPs can also be identified as "read only" if they are
calculated by the UO and therefore should not be changed (otherwise a CO error
is raised).
316

9 ThelatestvaluesofinputglobaltmdPUPswerequestedbyand derivativecdculatior~ although, ifhedoes, his U O w i l l b e m o r e

s u t ~ i e d to the UO. versatile a n d marketable.
9 The UO calculates new values o f the output global variables and 9 Derivaave values are p a s s e d t o the host ~imulator.
P U P s arxl passes them to the host sirmdator. 9 During the solulion o f the UO, repeated t ~ s i c a l protx'rly
9 Requests f o r derivatives at UO solution arepassed to the UO, i f requests a n d ~ e s will occur.
required However, U O supflier is not f o r c e d to provide.

Figure 5: Some requirements on Unit Operations

T h e n the user r e q u i r e m e n t s are e x p r e s s e d as a use case model. It identifies the

"users" of the system, called actors, and describes in t e r m s of use cases what they
w i s h the s y s t e m to do. It also identifies the boundaries of the s y s t e m , which here
is a unit operation model of a steady state, sequential modular process simulator.
Different use cases categories and priorities are described. Actors are defined
such as a flowsheet builder, a flowsheet user, a flowsheet solver or a simulator
executive. One m u s t notice that some actors are h u m a n ones while other are
software ones. The two next figures present a reduced use case map and the
description of a use case. Note that the actor flowsheet user u s u a l l y interacts
w i t h the CO unit operation through a graphical user interface provided by the
PME. The use case "evaluate a unit" is executed w h e n the user runs the
flowsheet. The flowsheet solver actor is responsible for the f l o w s h e e t to converge
by adjusting the variables in order to reach a specified value criterion.

Evaluate unit
Actors: <Flowsheet User>, <Flowsheet Solver>
Priority: <High>
Classification: < Unit Use Case>, <Specific Unit Use Case> ....
Status: < This Use Case is fulfilled by the following methods:
Calculate>
P re-conditions :
<[Add Unit to Flowsheet] has been used and successfully passed>
< The input and output ports (material, energy or information) have
been connected>
Flow of events:
The unit is requested to calculate its required results. The
Fiowsheet Solver tells the unit to calculate. The unit then requests
its unit ports to get its input stream data using the [Get Input
Material Streams from Input Ports] and [Get Input Energy Streams
from Input Ports] Use Cases, as well as the current values of any
required Public Unit Parameters (including its own) using the [Get
Values of Public Unit Parameters Through lnput Ports] Use Case.
If some specific data has been provided by the Flowsheet Builder,
but has not yet been retrieved by the unit, the unit gets this specific
Figure 6 Reduced use case map data. The unit then attempts to perform its calculations. It may also
make several requests for physical property ...
Post-conditions:
< The unitfinished its calculations successfully or not>
Exceptions:
< The unit may not solve successfully>
~ubordinatr Use Cases:
[Therm o: Request Physical Properties]
...

Figure 7 Use case description

Design: The CO unit operation design model is described by a combination of text

and U M L diagrams so as to display the solutions derived for the requirements
e x p r e s s e d in the previous section. The relevant U M L diagrams are the interface,
state and sequence diagrams. In this section, we propose some fundamental
diagrams as an illustration.

W i t h i n the content of the CO package Unit, the following types are defined:
 317

four interfaces (ICapeUnit, ICapeUnitPort, ICapeUnitCollection,

ICapeUnitReport) and their corresponding arrays, two ordered lists of identifiers
(CapePortType, CapePortDirection) and their corresponding arrays.

[] ICapeUnit is the key interface and handles most of the interaction.

[] ICapeUnitPort provides access to a unit port. This in t u r n gives access to
material, energy and information streams provided by the PME.
[] ICapeUnitCollection provides a means of merging lists of entities such as
p a r a m e t e r s and ports.
[] ICapeUnitReport provides access to the reporting facilities. This is a basic
design in the Unit package. The reporting facility is a candidate as a common
interface specification for next releases of the standard. This interface could
be removed from the Unit package in the future, being replaced by a link to
the Reporting package.

Figure 9 is a simplified interface diagram for the Unit package. This diagram is
abstract which means t h a t it is independent of any middleware implementation.
The Connect operation description, provided in Figure 9, illustrates how each CO
operation is detailed.

Figure 8 Interface diagram Figure 9 Description of an operation

The sequence diagram t h a t captures time-oriented dynamic behaviour is greatly

employed within all interface specification documents in order to show
interactions organised around CO interface objects and their links to one
another. The following figure proposes a possible scenario when the Flowsheet
User manipulates a CO compliant unit operation through a PME. However let us
318

note t h a t this scenario illustrates only some messages among all the necessary
interactions such as to add, create, edit, report, save and restore unit.

Figure 10 Manipulate unit

Specification: From the previous section, the implementation specifications are
written for the Microsoft COM and OMG CORBA distributed computing
platform. Due to differences between these two platforms, it is not surprising to
 319

get two codes, which are not so similar even if they come from the same abstract
design model.

Below you can find Microsoft IDL code lines and OMG IDL code lines. These
examples are based on the ICapeUnitPort interface and are extracted from the
files CAPE-OPENv0-9-4.tlb and CAPE-OPENv0-9-4.idl in the implementation
specification folder. From t h e s e extracts, we can notice the different approaches
especially in regards to the inheritance scheme and the error handling.

[ interface ICape UnitPort :

object, Common: :Identification: :ICapeldentification {
uuid(ICape UnitP ort_IID),
dual, CapePortType GetTypeO raises
helpstring("ICape UnitPort Interface"), (Common: :Error: :ECape Unknown
pointerdefautt(unique) Common: :Error: :ECapeFailedlnitialisation) ;
]
interface ICapeUnitPort: 1Dispatch CapeP ortDirecti on GetDirecti onO raises
( (Common: :Error: :ECape Unknown,
//Exceptions : ECapeUnknown, ECapeFailedlnitialisation Common: :Error: :E CapeFailedlnitialisation) ;
[propget, id(1), helpstring("type of port, e.g.material, energy or information")]
HRESUL T type([out, retval] CapePortType* portType) ; Thrm: : Cose : :ICape ThermoMaterialObject
//Exceptions : ECapeUnknown, ECapeFailedlnitialisation GetConnectedObject 0 raises
[propget, id(2), helpstring("direction of port, e.g. input, output or unspecified')] (Common: :Error: :ECape Unknown,
HRESUL T direction(lout, retval] CapePortDirection * portDirection) ; Common: :Error: :ECapeFailedInitialisation) ;
//Exceptions : ECapeUnknown, ECapeFailedlnitialisation
[propget, id(3), helpstring("gets the objet connected to the port, e.g. material, void Connect(in Thrm: :Cose: :ICape ThermoMaterialObject
energy or information')] matObj) raises
HRESUL T connectedObject([out, retval] Capelnterface * connectedObjec O; (Common: :Error: :ECape Unknown,
//Exceptions : ECapeUnknown, ECapelnvalidArgument Common: :Error: :ECapelnvalidArgument) ;
[id(4), helpstring("connects the port to the object sent as argument, e.g.
material, energy or information")] void Disconnect 0 raises
HRESUL T Connect([in] Capelnterface* objectToConnect) ; (Common: :Error: :ECape Unknown) ;
//Exceptions : ECapeUnknown
[id(5), helpstring("disconnects the port")] l:
HRESUL T Disconnect O;
1: Figure 12 Implementation
specification for CORBA
Figure 11 Implementation specification
for COM

4.4.4 E X A M P L E OF U S E

This example is reproduced by kind permission of the Global CAPE-OPEN's

Interoperability Task Force team led by BP. It uses excerpts of an
interoperability scenario developed by this task force.

Initially intended to test the specifications and to achieve the necessary steps
towards full interoperability of CO-compliant unit operations and thermo
components, the scenario also demonstrates the use of the CO interface
specifications in current implementations.

The scenario lists actions and situations that would arise during typical day-to-
day use of CO simulation components and CO-compliant Simulator Executives
(COSE's). It is primarily concerned with the simulation user's actions, however it
also lists software actions that are hidden from the user. Any specific
implementation suggestions are included solely for the purposes of illustration.
320

Software actions are marked in italic style. These actions generally correspond to
calls to CO interfaces, shown in computer l i s t i n g style. We only show the
methods invoked at each step, not their p a r a m e t e r s .

For the purposes of this exercise, the following assumptions are made:
The CO unit component used in the tests is a mixer/splitter.
All streams, both inlet, outlet and internal, have the same m a t e r i a l template.

Add a CO Unit to the Flowsheet

User selects a CO mixer-splitter from a palette of unit operations and places it on

the flowsheet.

COSE asks the unit to initialise itself. (ICapeUnic : : Initialize ())

The user selects or creates the streams and requests the COSE to connect them
to the ports of the unit, preferably in a way consistent with the rest of the
flowsheet. (I C a p e U n i t : :G e t P o r t s ( ) , I C a p e U n i t C o l l e c t i o n : :I t e m () , I C a p e U n i t P o r t ::
GetType () , I C a p e U n i t P o r t : :GetDirection () , I C a p e U n i t P o r t : : C o n n e c t ())

Enter Unit Specific Data

The COSE requests the unit for a user interface (UI). I f a UI is available, it is
displayed. I f not, the COSE could attempt to construct one from the unit's list of
Public Unit Parameters, or report to the user. (ICapeUnit::GetParameters(),
ICapeUnitCollection: :I t e m ( ) , I C a p e P a r a m e t e r : :GetValue () , I C a p e P a r a m e t e r : :GetM
ode(), ICapeParameter: :GetSpecification())

User inputs data, including selection of final and monitor reports.

(ICapeParameter: : S e t V a l u e () , I C a p e U n i t : : G e t R e p o r t O b j e c t () , I C a p e U n i t R e p o r t : :G
etReports() , ICapeUnitReport::SetSelectedReport())

When the input is complete the unit checks its parameters for validity and
consistency and reports any errors.
(ICapeUnit: :Validate() , ICapeUnit: :GetValStatus() )

Make Simulation Run

User asks the COSE to calculate the fiowsheet.

COSE asks the unit for the reporting options chosen by the user and acts
accordingly during the simulation run. (zcapeunic: :GeCReportObject (),
ICapeUnitReport : :G e t S e l e c t e d R e p o r t () )

COSE asks the unit to calculate itself. (ICapeUnit::Calculate0)

The unit retrieves the materials associated with its streams by requesting them
from itsports. (ICapeUnit : :GetConnectedObject ())
 321

The unit creates a n internal material object. This is to contain the mixed feeds.
The unit may create an internal array to contain the mixed composition. This is a
possible way to minimise calls to the material object to set compositions.
(ICapeThermoMaterialTemplate : :C r e a t e M a t e r i a l O b j e c t () )

The unit requests the mixed stream and all the outlet streams to postpone
calculation of their internal states until it has finished defining the compositions
and conditions.

The unit retrieves the component flows of each feed from the associated materials
and adds them to the mixed stream composition array. When complete, the
composition is assigned to the mixed stream material object.
(ICapeThermoMaterialObj ect : :GetNumComponents () ,
ICapeThermoMaterialObject : :GetProp () , ICapeThermoMaterialObj e c t : :S e t P r o p () )

The unit fetches the enthalpy from each feed material object, sums them and adds
the specified heat input. The total enthalpy is assigned to the mixed stream.
(I C a p e T h e r m o M a t e r i a l O b j e c t : :G e t P r o p () ) , ICapeThermoMaterialObj e c t : :S e t P r o p ()
)

The unit sets the pressure of the mixed stream to the m i n i m u m of the feed
pressures.
(I C a p e T h e r m o M a t e r i a l O b j e c t : :G e t P r o p () ) , ICapeThermoMaterialObj e c t : :S e t P r o p ()
)

The unit asks the mixed stream to calculate its temperature.

(ICapeThermoMaterialObject : :CalcProp () )

The unit assigns molar and enthalpy flows to the output streams in accordance
with the specified split factors. (ICapeThermoMater• : : SetProp ())

The unit assigns the composition of the mixed stream to the output streams.
(ICapeThermoMaterialObj e c t : :S e t P r o p ())

The unit assigns the pressure of the mixed stream to the output streams.
(ICapeThermoMaterialObj e c t : :S e t P r o p () )
The unit requests the output streams to calculate their temperatures.
(ICapeThermoMaterialObj e c t : :C a l c P r o p () )

Exit COSE
U s e r saves the s i m u l a t i o n .
U s e r exits from t h e COSE.

Rerun Simulation
U s e r opens the COSE.
U s e r r e q u e s t s the COSE to load the s i m u l a t i o n .
322

COSE detects any changes in the CO components and reports to user.

User makes any edits necessary.
COSE repeats the Simulation Run.

Use a CO Property Package

User creates a CO property package, using a CO-compliant property system,
which registers the CO property package.
(I C a p e T h e r m o S y s t e m : :G e t P r o p e r t y P a c k a g e s () )

User selects the CO property package in the COSE and assigns it to a unit
component in the simulation. ( I C a p e T h e r m o S y s t e m : :ResolvePropertyPackage ())

User Reruns Simulation.

User repeats these actions with the same CO property package assigned to the
whole simulation.

User repeats these actions, but first introduces a CO thermodynamic method

component, e.g. SRK, into the CO-compliant property system, before creating the
CO property package for use in the simulation.

The scenario was successfully d e m o n s t r a t e d in several occasions using

commercial versions of Aspen Plus / AspenProperties and Hysys. A video file of
the software demonstration can be downloaded from the CO-LaN website, see
reference.

4.4.5 N U M E R I C A L S O L V E R S I N T H E C A P E - O P E N SYSTEM

This section deals with the numerical solvers within the scope of the CO open
architecture framework. Thus it will allow you to identify what the CO system
can or cannot do for you whatever you are a numerical tools supplier or a user of
these algorithms.

The features of the CO solver framework will be described. Then the analysis and
design of this framework will be done. Finally some tools built on this framework
will illustrate this section.
 323

4.4.5.1 O v e r v i e w a n d f e a t u r e s

The CO numerical solver framework has focused on the solution algorithms t h a t

are necessary for carrying out steady-state and dynamic simulation of lumped
systems. In particular, this includes algorithms for the solution of large, sparse
systems of non-linear algebraic equations (NLAEs) and mixed (ordinary)
differential and algebraic equations (DAEs). Algorithms for the solution of the
large sparse systems of linear algebraic equations (LAEs) t h a t often arise as sub-
problems in the solution of NLAEs and DAEs have also been considered.

A technical difficulty encountered in this context is the large amount of

information t h a t is necessary for the definition of a system of non-linear
equations. In fact, this amount increases as more and more sophisticated solution
algorithms are being developed. For instance, most modern codes for the solution
of large DAE systems require information on the sparsity structure of the system,
as well as the ability to compute both the residuals and the partial derivatives of
the equations. Even more sophisticated codes need further information on any
discontinuities t h a t may occur in the DAE system, the logical conditions that
trigger these discontinuities and so on.

To overcome the above problem i n a systematic manner, the CO standard has

introduced new concepts, such as models and the equation set object (ESO) which
is a software abstraction of a set of non-linear algebraic or mixed (ordinary)
differential and algebraic equations. The standard ESO interface allows access to
the structure of the system (i.e. the number of variables and equations in it, and
its scarcity pattern), as well as to information on the variables involved (i.e. their
names, current values and lower and upper bounds). It also allows the ESO's
clients to modify the current values of the variables and their time derivatives,
and to request the corresponding values of the residuals and partial derivatives
(Jacobian matrix) of a subset or all of the equations in the system.

The equations in any model may involve discontinuities (e.g. arising from
transitions of flow regime from laminar to turbulent and vice versa, appearance
and/or disappearance of thermodynamic phases, equipment failure and so on).
Discontinuous equations in models are represented as state-transition networks
(STN). At any particular time, the system is assumed to be in one of the states in
the STN and its transient behaviour is described by a set of DAEs, which is itself
an ESO. Transitions from one state to another occur when defined logical
conditions become true; the model interface provides complete access to the
structure of these logical conditions as well as allowing their evaluation. Such
information is essential for the implementation of state-of-the-art algorithms for
handling of discontinuities in dynamic simulation.

Any CO compliant code for the solution of systems of LAEs, NLAEs or DAEs
provides a "system factory" interface. Typically, client software starts by creating
324

a model t h a t contains a complete m a t h e m a t i c a l description of the problem being

solved. It then passes this model to the appropriate system factory to create a
"system" object t h a t combines an instance of the solver with the model to which
the solver will be applied. The system object then provides appropriate operations
for solving the problem completely (in the case of a NLAE system) or advancing
the solution over time (in the case of DAEs).

The primary aim of the introduction of the ESO and model concepts is to support
the operation of CO compliant non-linear solvers. However, an important side
benefit is t h a t ESOs also provide a general mechanism for PMEs to expose the
m a t h e m a t i c a l structure of models defined within these PMEs. Thus, it may fulfil
the role of "model servers" providing the basis for the development of new types
of model-based applications beyond those t h a t are supported by the PMEs
themselves.

4.4.5.2 Analysis, design and specification

Analysis

The N u m r package is subdivided into four packages:

[] The Solver package focuses on the solution algorithms for the solution of large
and sparse systems of linear algebraic equations (LAE), non linear algebraic
equations (NLE) and mixed differential and algebraic equations (DAE).
[] The Eso package contains the ESO concept (which is an abstraction
representing a square or rectangular set of equations). These equations define
the physical behaviour of the process. An ESO is a purely continuous
m a t h e m a t i c a l description: the equations remain the same for all the possible
values of the variables.
[] The Model package introduces the Model object to embody the general
m a t h e m a t i c a l description of a physical system. The fundamental building
block employed for this purpose is a set of ESO. A Model may additionally
encompass one or more STNs.
[] The Utility package contains the public p a r a m e t e r concept which allows some
customisation of each CO Solver component.

The following package diagram details the various dependencies between the
N u m r packages. The black arrows within the picture display the relations that
are in the CO scope. The s t a n d a r d defines the services proposed by the Solver
components. Currently the way one builds an Eso or a Model within any PME, or
accesses them, is not standardised by CO. This task is left to the flowsheeting
tool suppliers. However the publication of services to the Solver component is CO
standardised.
So, software suppliers, industrials and academics can provide CO compliant
Solver, or call numerical services from any CO compliant PMC.
 325

Figure 13 Numerical package dependencies

Design

The Solver package, which is responsible for driving the resolution of the problem
using all the information from the Model and the Eso, contains the five following
interfaces:

[] ICapeNumericSolverManager acts as a factory and creates any kind of solver

for a specific ESO from a specific type, linear, non-linear or differential.
[] ICapeNumericSolver is the base interface of the solver hierarchy and so
defines general facilities for identifying the various algorithmic parameters
that are recognised by a numerical solver, for altering their values if
necessary.
[] ICapeNumericLASolver defines facilities, which are specific to solvers of LAE
systems. No specific methods have been defined for this kind of solver. It is
assumed t h a t the Solve method gets the A matrix and the b vector of the
A. x = b system using the already defined methods.
[] ICapeNumericNLASolver defines facilities, which are specific to solvers of
NLAE systems. It defines methods t h a t allow obtaining and setting
convergence tolerance and the number of iterations.
[] ICapeNumericDAESolver defines facilities, which are specific to solvers of
DAE systems. It defines methods t h a t allow obtaining and setting relative
and absolute tolerance.
326

The next diagram displays the interface diagram of the Solver package and its
relationship with the Utility package.

Figure 14 Interface diagram of the Solver package

Specification

The open interface specification document on Numerical Solvers can be found in

the Business Interface folder from the CO formal documentation set. The
implementation specification for COM and CORBA system is enclosed in the CO
libraries such as CAPE-OPENv0-9-4.tlb and CAPE-OPENv0-9-4.idl.

4.4.5.3 Implementation and tools

The CO system being new no commercial product based on the CO numerical

solver framework is currently available on the CAPE market. Nevertheless we
can cite software prototypes from the academics. These tools are more or less
validated, they provide important implementation feedback and then they
promote proposals for future improvements for the benefit of the entire CAPE
community. Already they demonstrate all the advantages of this open software
architecture for the next generation of solver tools, such as great interoperability,
increased commercial viability for specific algorithms and (web-enabled)
distributed calculation.
 327

As examples we can notify the non linear equation solver from RWTH Aachen
Germany and the NSP tool from LGC-INP Toulouse France. These components
are compliant with the CO system for solvers. According to the previous analysis
and design, they realise the Solver package depending on the Model and Eso
packages. Following the CO architecture for CORBA system, they act as
numerical servers through the Object Request Broker, employ the Identification
Common Interface and follows the CO Error Handling strategy. Obviously, these
software are separate processes t h a t can be used on a single machine, or across
the network within an internet-based enterprise business system.

A PME application, which is compliant with the CO standard, can bind to them
in order to resolve its process mathematical model. Some basic CO compliant
PMEs have been developed in order to validate the framework, they interact with
the above CO solver components playing some test cases such as isothermal flash
and Raleigh distillation. In this way they implement and supply the Model and
the Eso interfaces. The next figure illustrates the physical view of these CAPE
applications. The two components, PME and Solver PMC, can be on the same
host or on a remote host.

Figure 15 Component diagram

The non linear equation solver from RWTH Aachen comes from the migration of
a non linear equation solver developed in FORTRAN into a CO solver component
based on the CORBA system. The algorithm N L E Q l s from the Konrad-Zuse-
Zentrum fiir Informationstechnik Berlin has been used as the underlying
implementation.

The NSP (Numerical Services Provider) application combines J a v a and C/C++

codes as well as F o r t r a n 77 legacy codes thanks to the wrapping technique. It
supplies the LAE, NLAE and DAE objects, jointly to the configuration parameter
objects.
328

The linear algebraic solver is the result of the wrapping of a FORTAN solver.

The non-linear algebraic solver deals with the system F(x)=0. It relies on the
Newton-Raphson algorithm and profits from the previous linear solver for solving

~x
The differential algebraic equation solver manages the system F t,x,--~ =0. Its

strategy is based on the Gear method with variable order and step.

4.4.6 P H Y S I C A L P R O P E R T I E S D A T A B A S E S IN THE C A P E - O P E N
SYSTEM 1

A physical property data base (PPDB) is an abstract model for all types of
collections with thermophysical property data and with parameters of models for
calculating thermophysical property data t h a t have been taken from the
literature, have been measured or processed in one's own laboratory or have been
obtained from other sources. Such a database can be implemented in a variety of
physical manners. It can be a relational database, an online service, or a neutral
file.

A PPDB consists of data tables, which have a header with the definition of the
properties and their units and a body with the numerical values. There is no
distinction between dependent and independent variables. Each table is linked to
a mixture description and a set of bibliographic specifications.

A PPDB can contain any type of data. However, all properties must fit into a
catalogue of properties. This catalogue is part of the CAPE-OPEN standard. It
also contains a list of calculation methods, for which model parameters are
stored, and the exact form of their equation. This catalogue makes the whole
standard very flexible, because additional properties can be added easily, and
this means, that the standard will evolve.

In principle, a PPDB can contain any type of pure compounds and mixtures with
any state of aggregation: organic, inorganic, plastics, materials (metals and
alloys), and emulsions. However, in the first stage of standardization, there is a
restriction to regular chemicals. A "regular chemical" is defined as a substance
that is listed in one of the registers of the Chemical Abstracts Service
(Columbus, Oh, USA) and has a Chemical Abstracts Registry Number (CAS-
number). But the standard also accepts substances having no CAS-numbers. For

This section uses selected text from the 1.0 CAPE-OPEN PPDB interface specification, authored by H. Langer et al.,
available on www.colan.org.
 329

these substances a special e n u m e r a t i o n scheme is developed. Especially technical

mixtures like mineral oils, heat transfer fluids or victuals (food) have to be t a k e n
into account. They should be treated as "pseudo-compounds".

Because a PPDB can have any internal structure, there m u s t exist a general
interface for linking PPDBs to user programs t h a t is independent of the internal
structure of the PPDB.

The internal implementation of a PPDB interface-set m a y be complicated,

because there are so m a n y different types of PPDBs, but it is not of interest for a
client. He needs to see only two objects with the following access methods.
1. a catalogue of the available data bases
[] display contents of catalogue
2. an object representing a PPDB
[] opening a data base
[] closing a data base
[] list of available compounds
[] list of dictionary information, e.g. available journals or stored properties
[] search for properties
[] obtain overview of tables found
[] fetch numerical data and experimental errors contained in found tables
[] fetch model p a r a m e t e r contained in found tables
[] fetch chemical mixture belonging to found tables
[] fetch bibliographic specification belonging to found tables

In order to keep this set of interfaces as simple as possible, model p a r a m e t e r s are

in m a n y aspects treated as property data.

User programs have two different ways to use data stored in a PPDB:
1. Direct retrieval of the data
2. Retrieval of models or model parameters, which can later be used for
calculation property values.

The main interfaces of the PPDB s t a n d a r d in CAPE-OPEN are:

[] IcapePdbdRegister, knows all about the different types of PPDBs, which are
accessible, and makes this knowledge available to the clients. The system
administrator and not client users manage it.
[] IcapePpdb opens and closes the databases, and m a n a g e s information about
their contents: structures, lists of properties and compounds, bibliographic
references;
[] ICapePpdbTables selects tables from the PPDBs and queries t h e m for data;
two queries methods, simple and extended, are specified;
[] IcapePpdbModels queries PPDBs for models and models p a r a m e t e r s , in a
similar way as IcapePpdbTables queries for compounds data; it also provides
simple and extended querying mechanisms;
330

Finally the PPDB specification needs definitions of properties, units, methods or

equations, phase equilibrium information, states of aggregation in order to
invoke the interface methods in unambiguous ways: these definitions are part of
the CAPE-OPEN standard.

4.4.7 C O N C L U S I O N S & O U T L O O K

There is no doubt t h a t the CAPE-OPEN project was one of the most successful
standardization projects of its kind. The obstacles to success were many and in
other enterprise software domains, such as Enterprise Resource Planning (ERP),
where similar integration problems were faced, solutions to connect competitive
systems such as Baan and SAP, emerged as commercial products from companies
such as WebMethods, Extricity, IBM and Vitria. The CAPE-OPEN standard
benefited all members, enabling them to have a hands-on and collaborative
approach to solving CAPE integration problems t h a t they would have never been
able to solve alone.

One of the key reasons why the CAPE-OPEN project was successful was that
there was tremendous timing between the software technology curve, the
problems faced by engineers designing plants and processes, and the maturity of
the CAPE software markets. The collaborative nature of the project provided
huge benefits to all of the players.

The key to the future of standards in process engineering and plant design will
be how well these open collaboration processes are fostered and developed across
emerging technologies and business processes. The first step was t a k e n with the
establishment of the CO-LaN, an online collaboration to further develop and
refine process-engineering standards. Success in the future for CO-LaN will
continue to be measured by how well the CO-LaN bridges the gap between
engineering business problems and software technology. Design in general, is
playing an increasing role in the business processes of large global corporations,
and is being looked to for bottom line results. Consortiums such as Industria, in
the process industry and Converge in the semi-conductor industry have been
heavily funded to create seamless solutions that link the design process with
procurement processes.

J u s t like a company, and like the CAPE-OPEN project, the more valuable the
CO-LaN is to its members, the greater the outlook for success. Increased
collaboration across process industry standards organizations will provide huge,
and more importantly, measurable business process benefits to all members. CO-
LaN will ultimately be measured by the value it brings to its members and how it
solves new problems, integrates new technologies, ideas and goals.
 331

Finally, the fact is that people set standards, not organizations. Consensus
required across disparate and many times competitive companies is not a trivial
feat. Strong leadership, and commitment from many talented individuals
combined with a truly open forum of communication led to the establishment of a
lasting CAPE-OPEN standard and innovation over fear.

4.4.7.1 CO-LAN

The CAPE-OPEN standard is now under responsibility of the CAPE-OPEN

Laboratories Network (CO-LaN), a not-for-profit user-driven organisation for the
testing and management of the CAPE-OPEN standard. CO-LaN also helps to
facilitate implementation of standard interfaces in commercial software. The
missions of the CO-LaN are:

[] User priorities for CO standards: work with software vendors to clarify user
priorities for process modelling software component/environment
interoperability and also to promote communication and cooperation among
CAPE software vendors to insure that the CO standards actually translate
into commercially valuable interoperability;
[] Exploitation and dissemination: promote the CO standard to end-users and
distribute CO information and technology internationally;
[] CAPE-OPEN specifications life cycle management: organise the maintenance,
evolution, and expansion of the specifications;
[] Testing, interoperability facilitation: supply compliance testers to support
development of components, organise interoperability tests between suppliers
of PMCs ~rocess Modelling Components) and PMEs (Process Modelling
Environments)
[] Training/Migration facilitation: ensure that training modules, guidelines and
tools to facilitate component wrapping are developed and available.

Activities of the CO-LaN are extensively presented on its web site,

www.colan.org. Membership is organised in two categories:

[] Full members are end-user operating companies: companies who use CAPE
tools in their business activities and can be considered as end-users of the CO
standard. These are mainly operating companies, process licensing
companies, and (not academic) research institutes. End-user organisations
pay membership fees. These full members drive the society.
[] Associate members are all others: software suppliers, universities,
individuals, governmental organisations, etc. These associate members do not
have to pay membership fees (but they can always make donations), and have
no voting rights. They do, however, participate in the society's activities.
332

4.4.7.2 F u t u r e d e v e l o p m e n t s

It is obvious that the CO standard is an evolutionary system. Among other

activities, the CO-LaN consortium is in charge of managing its life cycle. The
main actions, which could result in a powerful development of the standard, are
listed below. Some of them already started but are not finalised when this book is
written.

At the technical architecture level, many technologies are or will be studied such
as EJB, COM+, the .NET and Web Services facilities, CORBA 3 (with its
associated CORBA Component Model). Tools such as compliance testers, wizards
for CO component development, and a repository for the standard management
are part of the current work in progress.

New business interface specifications are integrated in the 1.0 release of the
standard, including physical properties of petroleum fractions, chemical
reactions, the above mentioned physical property data base interface, distributed
parameters systems, parameter estimation and data reconciliation, optimisation
of linear and non linear systems, discrete and hybrid unit operation, connection
to real time systems. This version also includes common interface specifications.
New implementation specifications according to the previous evolutions will be
available.

The CO-LaN will produce an updated formal documentation set identified by

increasing version numbers of the standard. This way, the CAPE-OPEN
standard will be increasingly reliable, complete and in line with the most up-to-
date computing technologies.

4.4.8 R E F E R E N C E

[1] CO-LaN web site: www.colan.org