The ever-increasing use of mathematical models in all aspects of process development, design, and operation, as well documented in several recent studies such as Ref. 1, is being matched by a significant growth in the supply of ever-more-sophisticated modeling software from a variety of sources, including process-engineering software companies, automation system vendors, and academic institutions, as well as in-house developments within operating companies.

Some of this software aims at a narrow, well-- defined function, such as the computation of physical properties, the simulation of a particular unit operation, or the numerical solution of certain types of mathematical problems arising in process simulation or optimization. Other software tools, however, essentially are environments that support the construction of a process model either from first principles or libraries of existing models, or both. They then allow the user to perform a variety of different tasks, such as process simulation or optimization, using this single model of the process (2). The second category of process tools incorporates or relies on several software tools of the first category. The distinction between these two kinds of software, albeit in practice not always as clear as described above, is particularly important for the purposes of this article. We, henceforth, shall call them process modeling components (PMCs) and process modeling environments (PMEs), respectively.

The abundance of process engineering software is clearly a positive factor for the chemical process industries (CPI), and already has resulted in major benefits. Recent industrial experience has revealed some interesting technical and commercial factors worth noting:

The need of integrated process modeling. There is an increasing recognition of the need for adopting a more integrated view of the process one that takes into account all important interactions. This, in turn, implies that individual PMCs in isolation are of relatively limited applicability. For example, consider a specialized reactor that forms the heart of a certain plant. Although the availability of a software package implementing an accurate model for the reactor certainly would be very useful, it would be even more desirable to be able to couple this model with models of the separation part of the plant, thereby permitting an analysis of the tradeoffs between conversion, selectivity, and cost of separation. Ideally, the reactor PMC should be incorporated within an appropriate PME that facilitates the necessary coupling.

The adoption of generic PMEs. In the 1960s and 1970s, almost every major process-engineering company had developed internally its own PME, usually in the form of a steady-state modular flowsheeting package. (A similar trend was reflected in academic research, where a large number of steady-state and, later, dynamic simulation tools were being developed.) This trend continued well into the 1980s and, in some cases, the 1990s. It has become increasingly difficult, however, for operating companies to justify the large cost of maintaining and supporting these tools, let alone to continue their development while keeping up with the rapid progress in process modeling, as well as the growing sophistication of the underlying software engineering and mathematical solution techniques. The current trend, therefore, is to cease internal developments and, instead, to adopt PMEs provided by external software vendors. A small, but often quite significant, part of the internally developed technology (e.g., specialized unit operation models or physical property data) often represents a real competitive advantage, however; so, companies in many cases have incorporated this technology into generic PMEs brought in from external sources.

The limited supply of PMEs. The developments outlined above, together with the substantial increase in the sets of skills and resources required for developing, maintaining, and supporting PMEs, naturally have limited the number of process-engineering software companies. In fact, three vendors now dominate the market.

The growing range of model-based applications. Traditionally, process models have formed the basis for a relatively small number of different types of activities such as steady-state and dynamic simulation and optimization. It is increasingly recognized, however, that the range of possible applications of such models is potentially much wider - covering, for example, such diverse activities as plant data reconciliation, controllability analysis, process safety validation, fault detection, and so on.

The resulting problems

Each of the factors mentioned above, on its own, is quite understandable, reflecting the natural evolution and maturing of this sector of technology. All of them considered together, however, point to certain serious problems that need to be addressed if the CPI are to reap the full benefit of technical progress in this area:

There is an abundance of good-- quality PMCs; these, however, will be used widely by industry only if they are somehow incorporated within the relatively few PMEs that dominate the market.

There is a strong incentive to develop and use new types of modelbased applications. In most cases, the main cost of this activity, both in terms of money and time, is the development and validation of the process models upon which these applications are based. Although many of these models already exist, they are usually embedded within PMEs and access to them often is severely restricted.

In other words, we require efficient and effective mechanisms for:

1. incorporating new PMCs within existing PMEs; and

2. making the models embedded within PMEs accessible to other applications.

The conventional approach to addressing the first need has been for each software vendor to provide its own mechanisms for incorporating customer and third-party PMCs within its own PME(s), with each vendor defining its own application programming interfaces (APIs), data formats, and protocols - as well as the scope of interfaces supported. Traditionally, these mechanisms have been based on procedure calls and file transfers. More recently, vendors have adopted industry standard "middleware," such as the Object Management Group's CORBA (3), and Microsoft's COM (4,5). While this approach, which might be termed "open proprietary," has proven effective when dealing with only one vendor or PME, it suffers from the serious drawback that a new PMC implementation or interface must be developed for each target PME. Because developing and maintaining multiple implementations of a PMC poses considerable costs, and because vendors may not make the required interface documentation and tools openly available, this may lead to serious bottlenecks to the exploitation of rapidly evolving technologies.

The second need also is inadequately addressed today. While most software vendors do provide mechanisms for integrating simulation models developed using their PMEs with other applications, for example, using Microsoft Excel or Visual Basic, it generally is not possible to extract individual PMCs embedded within existing PMEs for use in other PMEs or applications. Furthermore, the available mechanisms suffer from the same drawback mentioned above - a separate implementation is required for each PME. The overall process is subject to much the same bottlenecks as those identified above, often magnified significantly in view of the much larger technical and commercial issues involved.

This article discusses an alternative "open standards" approach to addressing the above concerns. This approach identifies several important classes of PMCs and defines standard software interfaces for each such class. These steps are seen as an essential prerequisite for a long-term vision according to which:

New PMCs will be constructed to adhere to these standards while existing ones will be modified ("wrapped") to do so;

PMEs will make use of PMCs adhering to the standards, thus allowing process engineers to use software from heterogeneous sources operating together to carry out complex model-- based tasks.

We will focus in particular on CAPE-OPEN, a major collaborative effort that has been spearheading these developments over the past couple of years. We will describe the structure and scope of this project, as well as the underlying concepts and characteristics of the main PMC interfaces defined by CAPE-OPEN. We also will touch upon the use of "middleware," such as CORBA and COM, for the formal definition and implementation of CAPE-- OPEN-compliant interfaces, as well as the work methodology adopted by CAPE-OPEN.

CAPE-OPEN is by no means the only major standardization effort in the area of process engineering. We, therefore, also consider its relation to other initiatives such as OPC and pdXi.

Finally, we detail some developments that currently are underway, particularly, the Global CAPE-OPEN Project that started in July 1999. We conclude with some remarks on the current state, prospects, and benefits of open architectures for process engineering software.

The CAPE-OPEN Project

The CAPE-OPEN - "Computer Aided Process Engineering. Open Simulation Environment" - Project involves the collaboration of a number of major operating companies (BP plc, BASF AG, BAYER AG, DuPont Iberica SA, Elf, ICI plc, and IFP), academic institutions (RWTH Aachen, ICSTM London, and ENSIGC Toulouse), and process engineering software vendors (AspenTech, Hyprotech, QuantiSci Ltd., and SIMSCI). The project had an overall budget of 3.25 million ECUs and was partly funded by the European Community under the Brite-EuRam III program (6).

The CAPE-OPEN project started in January 1997 and concluded in June 1999. Its main aims have included:

identification of major classes of PMCs, and the formal definition of general interface(s) for each class;

construction and testing of appropriate prototype software, demonstrating the use of the above interfaces and the benefits realizable; and

dissemination of the results of the project, leading to the understanding, acceptance, and adoption of open software architectures by the process engineering community.

Scope of the CAPE-OPEN Project. Open architectures can benefit many different types of process engineering software. The CAPE-OPEN Project, however, specifically has focused on general tools for process modeling (often known as "process simulators," although, as has already been mentioned in this article and elsewhere, they usually support several activities other than process simulation, all based around a common process model) and, in particular, on their use for steady-- state and dynamic simulation. Moreover, the project has recognized explicitly the de facto existence and widespread practical usage of two different types of such tools, namely "modular" and "equation-orientated" ones. The distinction between these two types is not always entirely clear. For the purposes of this article, we shall use the term "modular" to refer to process modeling tools in which the models of unit operations have a certain responsibility for solving their own equations. On the other hand, in "equation-orientated" tools, models of unit operations simply provide their equations to a simulation executive that has overall responsibility for their solution.

To identify the key classes of PMCs that a standardization effort such as CAPE-OPEN needs to address, it is instructive to consider "typical" architectures for process modeling tools. Figure 1 depicts a common, albeit somewhat simplified, architecture for modular tools.

As shown in that figure, overall responsibility for constructing a model of a process and carrying out various computations with it is vested in a "process modeling executive." The latter interacts with modules describing individual unit operations. Typically, these will need to interact with packages used to compute the physical properties that occur within the unit operation models. As has already been mentioned, in the modular case each unit operation module also will need to solve the equations of the corresponding mathematical model; the solution may be performed by specialized algorithms (often coded within the unit operation modules themselves), or by making use of external numerical solvers (as shown for the third unit operation module in Figure 1).

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. This often involves the analysis of the process flowsheet to identify "partitions" that may be solved independently, or sets of streams that have to be "torn" to remove cyclic dependencies (7). Appropriate flowsheet analysis tools, usually based on graph-theoretical concepts, are used for this purpose.

Figure 2 depicts a typical architecture for an equation-orientated package. Although the basic structure resembles that shown in Figure 1, a fundamental difference is that the unit operation modules no longer have responsibility for solving their own equations. Instead, they pass information on these equations to the executive, which assembles them into a (typically large) set of equations which it then solves by interacting with one or more appropriate numerical solvers.

The above analysis naturally leads to the identification of the following important classes of PMCs that are prime candidates for standardization:

physical properties;

unit operation modules;

numerical solvers; and

flowsheet analysis tools.

The ultimate vision of CAPE-- OPEN is to allow complex process-- modeling tasks and model-based applications to be performed successfully and cost-effectively via the collaborative use of software components from a wide variety of sources, possibly being executed on different computer hardware. An example of this is shown in Figure 3. Here, the PME (the simulator executive and the user interface) is supplied by one vendor, whereas the PMCs (e.g., one or more unit operations, the physical properties calculations, and the solution algorithm) come from different suppliers. Extending this principle, the individual components will be able to communicate in a standard fashion with other environments such as process control and monitoring systems, or costing applications.

PMC interfaces

In view of the very wide range of materials and unit operations employed by the CPI, as well as the variety of solution techniques used for dealing with different model-based applications, it is not surprising that each of the PMC types identified can be subdivided further into several more subclasses. Clearly, not all of these could be handled within a project of limited duration and resources. This section considers in more detail the actual scope of each type of interface defined by the CAPE-OPEN Project. It also describes the key concepts underpinning each interface and its main characteristics.

Physical property interfaces. In the area of physical properties, CAPE-OPEN has focused on uniform fluids that are mixtures of pure components or pseudo-components, and whose quality can be described in terms of molar composition. The physical properties methods that have been provided with standardized interfaces are those required for the calculation of vapor/liquid/liquid/solid equilibria or subsets thereof, as well as other commonly used thermodynamic and transport properties.

A key concept in CAPE-OPEN is that 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) will be characterized by one such object.

Each unit operation module may interact with one or more material objects. For instance, a module modeling the separation of an input stream into vapor and liquid output streams using a nonequilibrium model may interact with four material objects, representing the material in the input and both output streams, as well as at the vapor/liquid interface, respectively. Partial derivatives of physical properties with respect to the independent variables also can be computed.

In practice, material objects will compute physical properties or perform phase equilibrium calculations via thermodynamic property packages which, in turn, carry out these tasks by making use of thermodynamic property calculation routines and equilibrium servers.

To support the implementation of the above framework, CAPE-OPEN has defined standard interfaces for material objects, as well as thermodynamic property packages, calculation routines, and equilibrium servers. The design of all these interfaces has paid particular attention to important issues such as extendibility and efficiency. For instance, the list of properties that any thermodynamic property package is capable of computing is not fixed, but can be obtained by client software via a method provided by the corresponding object.

Unit operation module interfaces. CAPE-OPEN has defined a comprehensive set of standard interfaces for unit operation modules being used within modular PMEs. We review some of the key concepts underpinning these interfaces below.

A unit operation module may have a number of ports that 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 will be associated with a material object (see above). In addition, ports have directions (input, output, or input/output).

Unit operation modules also have sets of parameters. These represent information that is not associated with the ports but that, nevertheless, 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).

A unit operation module may have its own user interface that allows the user to configure the module in an appropriate fashion for each specific case - typically at the time of insertion in a flowsheet. This may involve a specification of the precise mode of operation of the unit and the provision of values for the associated degrees of freedom.

Finally, a unit operation module may be capable of producing one or more reports on the results of its computations. Other facilities include the ability of a unit to perform (potentially complex) initialization computations, to save its current state, and to restore it at a subsequent point in time.

Much of the above considerations also apply to equation-orientated unit-- operation objects. A 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. A prerequisite for this mode of operation to be feasible is the introduction of formal ways of specifying sets of equations of various kinds. This problem also has been addressed by CAPE-OPEN in the manner described below.

Numerical solver interfaces. Here, CAPE-OPEN has focused on the solution algorithms that 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 nonlinear 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) that often arise as subproblems in the solution of NLAEs and DAEs also have been considered.

A technical difficulty encountered in this context is the large amount of information that is necessary for the definition of a system of nonlinear 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 that may occur in the DAE system, the logical conditions that trigger these discontinuities, and so on.

To overcome the above problem in a systematic manner, CAPE-OPEN has introduced a new concept, the Equation Set Object (ESO), as a software abstraction of a set of nonlinear algebraic or mixed (ordinary) differential and algebraic equations. The standard ESO interface allows access to the structure of the system (ie., the number of variables and equations in it, and its sparsity 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 primary aim of the introduction of the ESO concept is to support the operation of CAPE-OPEN-compliant nonlinear solvers. An important side benefit, however, is that ESOs also provide a general mechanism for PMEs to expose the mathematical structure of models defined within these PMEs. Thus, ESOs may fulfil the role of "model servers" in the manner envisaged by Pantelides and Britt (2), providing the basis for the development of new types of model-based applications beyond those that are supported by the PMEs themselves.

Graph analysis tool interfaces. A key part of the operation of sequential-modular simulation systems is the analysis of the process flowsheet to determine a suitable calculation sequence for the unit operation modules (see Figure 1). Thus, the set of units in the flowsheet typically is partitioned into one or more disjoint subsets (maximal cyclic networks, MCNs) that then may be solved in sequence rather than simultaneously ("ordering"). The units within each MCN are linked with one or more recycle loops that can be converged in an iterative manner via the identification of appropriate "tear streams" that allow the unit operation calculations to be sequenced. A more detailed description of these well-established operations may be found in Westerberg et al. (7).

The above tasks typically are carried out using a set of tools that operate on the directed graph representation of the flowsheet. CAPE-OPEN has defined standard interfaces for the construction of these directed graphs, and for carrying out partitioning, ordering, tearing, and sequencing operations on them.

Implementation and work methodology

Let's now consider some of the issues involved in the implementation of CAPE-OPEN interfaces, and the work process itself adopted by the CAPE-- OPEN Project.

The use of middleware. The interfaces described in the previous section could, in principle, be implemented in a number of different ways, including, for instance, simple "subroutine" or "procedure" calls in standard procedural languages such as FORTRAN or C. CAPE-OPEN has chosen, however, to adopt a component software and object-orientated approach that views each PMC as a separate object. All communication between objects is handled by "middleware," such as CORBA (3), and COM (4,5). These technologies provide standard mechanisms for one software object to interact with another based on a formal interface definition expressed in standard languages also provided by them. Issues - such as differences in the computer languages in which the various objects actually are implemented, or in the representation of fundamental data types (e.g., real numbers) between different machines - are handled automatically. All of these aspects are particularly important in view of the primary aim of CAPE-OPEN to support the interaction of process-modeling software components from heterogeneous sources.

CAPE-OPEN interfaces have been expressed in both CORBA and COM. Each interface involves lists of interfaces, methods, and arguments expressed in the CORBA IDL and the COM MIDL Interface Definition Languages. Developers of CAPE-OPEN-compliant components will need to incorporate the same declarations in their applications and to use IDL compilers of either or both kinds to generate the corresponding instructions (mainly "header" files containing various declarations for stubs and skeletons) in source language such as C, C++, Java, Smalltalk, etc. The "wrapping code" generated in this manner then can be linked with the rest of the component. Legacy code, such as FORTRAN models, also can be used by encapsulation within CAPE-- OPEN-compliant wrappers.

As an example, Figure 4 shows the simple standard interface specification for accessing some of the ports of a unit operation. The method belongs to the ICapeUnit interface, takes as input the type and directions of ports required, and returns a pointer to a portsInterface, which can then be used to communicate with the selected ports.

The work process. The definition of interfaces throughout the project was done following a development process based on the UML object-orientated notation (8) for all formal models of the interfaces, including the user requirements, and for producing use cases, sequence diagrams, state transition diagrams, class diagrams, and, finally, interface diagrams that accompany the corresponding middleware implementation. In practice, an iterative approach where the different models and implementations were subject to progressive refinements had to be adopted. Overall, this work process proved to be both an efficient and an effective mechanism for developing consensus standard interface specifications and prototypes meeting those specifications in a project involving a relatively large number of people with widely different backgrounds.

The Global CAPE-OPEN Project

The CAPE-OPEN Project concluded on June 30th, 1999. Global CAPE-- OPEN (GCO) is a followup project, which started on July 1 st, 1999, with a planned duration of 30 months. GCO is a European Commission funded project, under the Brite-EuRam framework, with a contribution of 2.5 million Euros from the European Commission and 3.2 million Euros from participants. It also is proposing to operate under the umbrella of the Intelligent Manufacturing Systems (IMS) initiative, an industry-led, international research and development program established in 1995 to develop the next generation of manufacturing and processing technologies.

The European part of GCO brings together an already unprecedented set of 16 entities, including industrial and software companies, and academic institutions. The International GCO proposal adds to this three other consortia of various magnitudes in the U.S., Canada, and Japan, respectively. These partners will work together towards the GCO strategic objectives:

1. Development of standards in new subfields of process modeling and simulation beyond those addressed by the initial CAPE-OPEN project - GCO will address complex physical properties, kinetic models, new numerical algorithms, and distributed models;

2. Support of the development of versions of simulation software conforming to the standard - several partners in GCO will develop CAPE-- OPEN-compliant components for internal use, research, or commercialization;

3. Research on the integration of open process simulation technology in the work process - GCO will take real industrial cases and assess the use of CAPE-OPEN technology, including supporting software and user training;

4. Definition of open standards for new technologies beyond process modeling and simulation - GCO will develop prototypes for on-line systems, discrete and mixed batch-continuous processes, finer granularity interfaces, and scheduling and planning systems;

5. Further dissemination of the technical results of CAPE-OPEN using both traditional and Internet-based mechanisms.

6. Assessment of the use and benefits of CAPE-OPEN standards for education and training; and

7. Formation of the "CAPE-OPEN Laboratories Network" (C.O.LaN), a nonprofit institution aimed at maintaining the standards and providing services to CAPE-OPEN developers and users.

More generally, the major expected result of GCO will be the global acceptance of CAPE-OPEN as a standard for communication among components in process engineering simulation software, leading to the availability of software components from leading vendors, research institutes, and specialized suppliers. This will enable the CPI to reach new quality and productivity levels in designing and operating their plants, while opening new markets for suppliers of CAPE components.

Other standardization activities

The CAPE-OPEN initiative aims to minimize the development time needed for interfacing process models, or elements of process models, with each other and with third-party elements. It specifically addresses the functional exchange of data and computation results pertaining to process simulation, optimization, and other types of model-based applications during ran-- time. Two other major standardization activities - pdXi and OPC - complement CAPE-OPEN efforts.

pdXi. The AIChE Process Data Exchange Institute (pdXi) is an initiative sponsored and funded by more than a dozen (mostly U.S.) operating companies, engineering and construction firms, and software vendors to promote the electronic exchange of process engineering data among diverse engineering applications and organizations (9,10). In particular, pdXi has addressed the development of a generalized data model, a standard, and approaches to software implementations that access data using the defined data model. Here, the term "process data" refers to stream and equipment data and other data used to support the process engineering activity over the entire life cycle of processing facilities. Membership in pdXi is open to operating companies within the CPI, software vendors, engineering contractors, and equipment design/manufacturing firms.

The goal is for the pdXi data-modeling work to result in a formal standard for process data exchange through the International Organization for Standardization (ISO). Its STEP, Standard for the Exchange of Product Model Data (ISO 10303), is an international activity for establishing standard data models and exchange protocols for a variety of manufacturing industries, including the CPI. At present, pdXi is sponsoring the ISO/STEP Application Protocol AP231 - "Process Engineering Data: Process Design and Process Specifications of Major Equipment." In addition to AP231, other STEP activities for the CPI include application protocols for detailed engineering: AP221 - "Functional Data and their Schematic Representation for Process Plants," and AP227 - "Plant Spatial Configuration." All three process-plant protocols will be "harmonized" in the future.

For software implementations, pdXi is exploring and prototyping the use of eXtensible Markup Language (XML), an emerging Internet standard, as a working file format to accomplish process data exchange between software applications in the near term. (We will more fully discuss the use of XML later.)

We believe that pdXi and CAPE-- OPEN are largely complementary activities with very little, if any, overlap between them. Consider, for example, a CAPE-OPEN-compliant unit operation object used to model a heat exchanger. A pdXi file could be used to configure this object by defining the characteristics of a particular heat exchanger unit. The precise mechanism by which this configuration is done is of no concern to the CAPE-OPEN object interface, which primarily is concerned with being able to compute the heat exchanger behavior. Through their common member companies, CAPE-- OPEN and pdXi are collaborating to leverage their respective work activities in closely related work areas.

OLE for Process Control (OPC). The OPC Foundation is a nonprofit organization promoting the establishment and use of standard interfaces for process control applications based on Microsoft's OLE/COM middleware (4,5). OPC defines standard methods for accessing control system functionalities and attributes of servers of realtime information, including distributed control systems (DCSs), programmable logic controllers (PLCs), smart field devices, and analyzers. The OPC initiative is supported by a group of more than 150 providers and users of control system hardware and software. Prototype OPC servers have been developed and demonstrated.

The choice of OLE/COM as unique middleware makes the OPC standard rely on Microsoft technology. Hence, software bridges would be required to provide Unix or VMS compatibility.

OPC primarily is concerned with real-time process data. As process models are increasingly used for real-- time operations support (e.g., in on-line optimization or as decision support tools), the availability of standard mechanisms for accessing plant data is particularly valuable. Once these data are acquired, then they may be used within process simulation and optimization activities - which are precisely those that CAPE-OPEN and its GCO continuation aim to support. Overall, then, OPC and CAPE-OPEN are highly complementary initiatives.

Possible future developments and opportunities

The widespread use of "plug-and-- play" PMCs is, of course, the main benefit expected from the introduction of open software architectures. Plug and play will apply to all the components for which a standard interface is available, provided that implementors follow the interface specifications faithfully. It will impact commercial software (e.g., using A's physical properties package in B's simulation executive environment); legacy software (e.g., using C's reactor model in D's environment); and niche software (e.g., using specific unit operations or physical properties in a standard simulation package).

Realistically, in view of the current domination of proprietary software packages, such plug-and-play usage initially will be limited to introducing a small number of external components within existing simulation packages. It may soon develop, however, into a whole industry of pluggable PMCs, with semi-automatic facilities for selecting components based on descriptions of their capabilities and cost, followed by electronic payment and downloading directly from the World Wide Web (see Ref. 11).

The achievements of the CAPE-- OPEN Project, together with the further developments planned under GCO, open new opportunities for the CPI. Once these ideas gain wide acceptance, we may find ourselves facing some very major changes in the ways process engineering software is designed, developed, marketed, distributed, and used.

One likely scenario is that emphasis will shift from comprehensive, single-- source process-modeling systems to a combination of PMEs and PMCs from diverse sources. Although vendors still will provide integrating process modeling environments (PMEs) within which these components will fit, we believe that most competitive advantage will be derived from two distinct sources:

1. better software components (eg., more accurate physical properties, higher-fidelity process models, and more reliable and efficient numerical solvers); and

2. new model-based applications making use of the above components (e.g., real-time dynamic optimization, model-based fault detection, and automated emergency handling systems).

The fundamental change brought by CAPE-OPEN and related activities as far as software suppliers are concerned is a lowering of the threshold for technical development and commercial exploitation of new software. In particular, individual suppliers will be able to concentrate their activities on the areas where their know-how and expertise provide them with a distinct competitive advantage, relying on third-party PMCs for everything else.

On the other hand, users of process engineering software will be able to purchase from a variety of sources only those PMCs that are of immediate use to them. The purchase cost of a PMC is likely to be much less than that of an entire integrated process-modeling system; moreover, the use of standard interfaces will facilitate the introduction of a new PMC or the replacement of one PMC by another. The overall effect on the CPI, hopefully, will be a dramatic lowering of the threshold of exploiting new technology.

We must emphasize, however, that it is not yet proven that open systems will lower overall costs or improve overall reliability. Indeed, there is a possibility that the opposite will occur. Without a primary supplier, support costs may go up. Responsibility for correctness of results may become diffused and impossible to pin down. Data obtained from experience with a broad range of actual implementations are required to determine the tradeoffs. What is certain is that open systems and standards will allow users the flexibility to use the PMCs that best meet their needs, and will open the door and lower the cost of entry for a wide variety of sources to create PMCs. It also is certain that e-commerce will be heavily involved in making these PMCs accessible. For example, designers probably will shop for equipment such as pumps, packing, etc., over the Web, with the equipment vendors providing PMCs for simulation and design as a means of promoting use of their products (e.g., an engineer on a column retrofit project evaluates packing from several different vendors by accessing details on them on the Web and running simulations to choose the one providing the best performance and overall cost, all in a few hours). This is the type of re-engineering of work processes that open systems and standards can enable.

Emerging enabling technologies and their impact

We already have seen how the current state of enabling computer software - in particular, the availability of middleware technologies - has influenced the outcome of the CAPE-- OPEN Project. It, therefore, is reasonable to expect that further developments in enabling technology may have an important impact on the future evolution and use of open standards and interfaces for process engineering software. So, let us now consider several emerging technologies that may have such an impact. Although some of our discussion may appear futuristic given the current state of the technology, the rate of evolution in this area is so rapid that even ostensibly farfetched propositions may become practical within only a few years.

Wizards. Companions, or "wizards," have become familiar tools in modem office software environments. For instance, while this article was being typed, it was monitored by an invisible or iconized component, which sometimes corrected spelling mistakes, sometimes suggested better use of the word processing software, and sometimes saved the work without prompting. Such wizards also can provide advice on advanced features that a person calls upon only infrequently.

In fact, companions for process simulation software already exist in some proprietary environments. These tools help to enter data, select models, check the solvability of a flowsheet, determine the number of unknowns, etc.

With the advent of open architectures for process engineering software, we will need intelligent software companions that are able to monitor, diagnose, and propose remedies to process simulation models across commercial, technical, and geographical barriers. We also may need "interface traffic managers," i.e., components that are able to observe functional exchanges through interfaces, and that, therefore, can suggest the best properties model for a specific material, solving mechanism, or the debugging of a convergence problem.

Collaborative CAPE environments. Computer-aided process design is a collaborative activity, because several workers usually must contribute knowledge about chemical processes and their simulation. With today's increasing globalization, these people may well be located all around the world, making conventional methods of collaboration - face-to-face meetings, telephone calls, exchange of reports and files, etc. - difficult. So, we envision the Internet becoming a key tool for collaboration. The CAPE-- OPEN and GCO Projects make extensive use of the "basic support for collaborative work" (BSCW) system, which has allowed more than 60 users to share standards documentation and the associated project information over the Internet (see Figure 5). Internetbased simulation systems already are appearing - for instance, for a refinery in Singapore (12). Although there still are some technical questions outstanding, the major challenge will be for workers to get used to sharing information by electronic means.

XML and DTD. Undoubtedly, Internet and Web technologies now dominate information systems and networks. The technologies involved include file formats (such as HTML), languages (cgi scripts, Java), and communication protocols (HTTP, FTP, etc.).

More recently, a new standard, XML, defined by the World Wide Web Consortium (W3C), has been emerging for the distribution of documents over the Web (see http://www.xml.com). XML is based on the SGML language developed by the documentation community, but contains a restricted set of SGML features. XML provides a structured, but also extensible, way of storing information. As noted by Norman Walsh (13):

"In HTML, both the tag semantics and the tag set are fixed. An <h1> is always a first level heading and the tag <ati.product.code> is meaningless. The W3C, in conjunction with browser vendors and the WWW community, is constantly working to extend the definition of HTML to allow new tags to keep pace with changing technology and to bring variations in presentation (stylesheets) to the Web. However, these changes are always rigidly confined by what the browser vendors have implemented and by the fact that backward compatibility is paramount. And for people who want to disseminate information widely, features supported by only the latest releases of Netscape and Internet Explorer are not useful. XML specifies neither semantics nor a tag set. In fact XML is really a meta-language for describing markup languages. In other words, XML provides a facility to define tags and the structural relationships between them. Since there's no predefined tag set, there can't be any preconceived semantics. All of the semantics of an XML document will either be defined by the applications that process them or by stylesheets."

What XML brings to the Web (and to intranets and extranets) is the ability to express structured queries that exploit the structured form of XML files. This is much more advanced than current query mechanisms that rely on simple character string matching with little knowledge of the content of the documents they search and retrieve. For example, the query "how to calculate the fugacity of methane" could well return a document containing the text "I don't know how to calculate the fugacity of methane, please tell me," which obviously misses the point.

An important aspect of XML is the document type declaration (DTD). A DTD provides structural information about XML documents by further defining the tags to be present in a document, their sequences, and their references to other elements. More formally, a DTD includes declarations for element types, attribute, internal and external entities, and parameters. Thus, DTDs allow the definition of a standard structure for complex documents so that XML-enabled software (including the latest versions of standard Web browsers such as Microsoft Internet Explorer 5 and Netscape Communicator 5) can understand information in the documents from the semantics of the DTD.

The widespread adoption of XML may lead to significant benefits in process engineering software. For example, the CAPE community has been considering the idea of defining a standard process-simulation database interface. (Possible developments in this direction already have been considered by both pdXi and CAPE-OPEN, and it is partly addressed by the GCO project.) In contrast to the CAPE-OPEN functional interfaces that allow process simulation components to communicate during the initialization and execution of a particular computation, a simulation database interface would allow the transfer of simulation data between applications. The simulation results, and, in particular, stream data and values of key variables within units (e.g., distillation column profiles) often are used for restarting the simulation at a later time. A standardized simulation interface would permit the use of the results of one simulator as a starting point for another. It also would help ensure that results can be used even by the same simulator several years (and software versions) later. Today, there is no practical way of storing and retrieving simulation data independently of the proprietary file formats of the existing simulation packages. An XML-based DTD for simulation results, eg., based on the pdXi data model, could be a way of resolving this problem in a fairly short time.

We also could store flowsheets and their associated data in XML documents. These then could be made available on a company's intranet, thus allowing users to issue from a Web browser structured queries regarding the flowsheets. We also could build reuse mechanisms for whole flowsheets or parts of flowsheets by querying the XML database of flowsheets. We could employ commercial plug-ins for the browsers, communicating with the XML models base, thereby running the simulation from within the browser. We could publish flowsheets and results on the Web for scientific purposes (or advertising).

Major national and international initiatives

Beyond the purely technical developments already considered, the move toward open architectures for process modeling tools may be significantly impacted by a number of current national and international initiatives - in particular, the European Commission's Fifth Framework Programme and the U.S.'s Vision 2020 and PITAC reports.

The Fifth Framework Programme. The Fifth Framework Programme (FPS) defines the European Union's research and development objectives for the period 1999-2002. With a budget of approximately 14 billion Euros, FPS is probably significantly bigger than any other such research initiative in the world.

FP5 is implemented through four main "vertical programmes" and three "horizontal supporting actions." Two of the main vertical programs - Information Society Technologies (IST), and Competitive and Sustainable Growth (GROWTH) - directly incorporate key actions relating to CAPE.

IST is the most important program within FPS, with a budget of 3.6 billion Euros over four years. Two of its four key actions - "2. New Methods of Work and Electronic Commerce," and "4. Essential Technologies and Infrastructures" - are of relevance to the new software architectures for CAPE. Action 2 addresses the use of new IS technologies for better working practices within the enterprise, including teamworking, knowledge management and sharing, security, digital object transfer, and electronic commerce. Action 4 centers on developing the future IS technologies that will support these practices, namely, real-time systems, networks, component-based software engineering, and high-performance simulation, among others.

The GROWTH program has a budget of up to 2.7 Billion Euros over four years. Its first key action, "Innovative Products, Processes and Organizations," supports research and development for building the competitive industry of the future through reduction of material content of products while increasing their service value, and through innovative, safer, cleaner, and low natural-resource-intensity processes and products, including new organizational methods and tools for reaching those targets.

It is not our goal to present the full work programs of IST and GROWTH; detailed descriptions appear in Refs. 14 and 15. We can draw some perspectives, however, concerning componentbased software - especially from IST key action 4.3, which proposes research directives in component-based software engineering (14):

"Objective: To develop and validate the innovative processes, methods, and tools necessary to design, implement, and manage software-intensive systems using a componentbased approach. The focus is on reuse, the incorporation of new technology COTS (commercial, off-the-- shelf) components and evolutionary re-configuration. The work should result in the definition of processes, methods, and their supporting technologies that enable the smooth and auditable integration of components from multiple independent sources into complex systems and services..."

PITAC. In the U.S., meanwhile, PITAC, the President's Information Technology Advisory Committee, in a recent report (16) cited component technologies as a high-level priority for information technology research in the next five years:

"Recommendation: Fund more fundamental research in software development methods and component technologies.

"The Committee recommends that research in software methods be aggressively pursued, especially in the area of automated support for software development and maintenance. Such research should:

Explore and create componentbased software design and production techniques, and the scientific and technological foundations needed for a software component industry.

Explore and create theories, languages and tools that support automated analysis, simulation, and testing of components and their aggregation into systems. Create a national library of certified domain-specific software components that can be reused by others.

Explore and create techniques for using measurably reliable and secure components and their aggregation into predictably reliable and secure systems.

Explore and create protocols, languages, and data structures to promote interoperability of applications running concurrently across wide-area networks."

Technology Vision 2020. This is a "visioning process" to develop a strategic plan to maintain the competitiveness of U.S. chemical companies in the global business environment. It is a joint effort of several organizations including AIChE, the American Chemical Soc., and the Chemical Manufacturers Assn. Technology Vision 2020 focuses on four areas of technology research and development (R&D):

1. new chemical science and engineering technology;

2. supply chain management;

3. information systems; and

4. manufacturing and operations.

The participants in the visioning process concluded that "the growth and competitive advantage of our industry depend upon individual and collaborative efforts of industry, government, and academia to improve the nation's R&D enterprise." This need for collaboration is the recurring theme of Vision 2020. The principal focus is to develop technology roadmaps that chart specific R&D needs for collaborative research to achieve the vision. This is done primarily through a series of topical workshops that bring together experts in the field.

The report "Technology Vision 2020 - The U.S. Chemical Industry" (17) describes the high level vision and needs. This reports places considerable emphasis on the need for open software systems, standard interfaces and data-exchange formats, and integrated computer applications, and generally encourages efforts by other organizations and vendors to meet these needs. To our knowledge, none of the Vision 2020 workshop or roadmap activities so far have directly addressed this area. It, however, certainly is congruent with CAPE-OPEN/GCO.

A historic opening

All of the above initiatives clearly aim at facilitating the widespread adoption of component software as the software technology of the next decade. The small steps that we are taking now (e.g., with CAPE-OPEN) form the foundation of a new wave that will transform the software industry into a provider of reusable components that can be mixed and matched in infinitely varied ways. It is now time to develop this new generation of software technology, to serve the growing demands of millions of users and to leverage the communication capabilities of the Internet.

We believe that open software architectures are the way forward for the next generation of CAPE tools. They allow previously incompatible environments to interoperate through consensus interface standards established on top of middleware platforms such as CORBA and COM. They contribute to the life-cycle approach for CAPE models that is promoted by commercial simulation suppliers and advocated elsewhere (18). Moreover, if process development for the next millennium is to be shared, as argued by Fowler in his keynote address at FOCAPD '99, open software architectures will provide the technical basis for such sharing between organizations, departments within organizations, and individuals within departments.

Although much has been achieved by the recently completed CAPE-- OPEN project, it represents just the beginning of the move of process engineering software toward truly open architectures. The recently started GCO Project intends to cover the steady-state and dynamic modeling of a much wider range of continuous, batch, and hybrid processes. The ultimate scope of the standard will include electrolyte mixtures, reacting fluids, polymer solutions, and particulates; it will address off-line simulation, optimization, parameter estimation, and data reconciliation.

Simulation software vendors consider CAPE-OPEN to be a key element in their overall strategies of product development. Moreover, CAPE-OPEN is perceived not just as a standard for interoperability with third-party products, but also as an architecture for use by software components within the same company.

The adoption of the CAPE-OPEN standards by a large number of specialized software-component providers should extend the use of modeling software, which, in turn, should provide a competitive advantage to end users, as well as PMC and PME suppliers. From this perspective, CAPE-OPEN can serve as the basis for a successful collaboration among all these parties.

Acknowledgments

This article uses updated portions of CAPE-OPEN's final documents and of GCO's work plan, which are collective writings by more than thirty authors from fifteen organizations.

The technical presentation on XML was borrowed from www.xml.com.

The authors are grateful to their colleagues in industry and academia for their contributions to the project and to many of the ideas presented here. The authors, however, are solely responsible for the views expressed.