 |
Where can I get information on CAPE-OPEN interface standards specifications? |
 |
www.colan.org (you already there!) |
|
|
What are some kinds of tools using CAPE models? |
|
- Steady-state and dynamic simulation for process design
- Training simulators for operators
- Data acquisition and reconciliation
- Advanced control, monitoring and diagnostic
- Optimization of processes
- Equipment design tools (heat exchanger, reactor, pipe network, pressure relief, distillation, etc.)
- Process design tools (process simulators, process network designers, etc.)
|
|
|
What are some examples of Process Modeling Components (PMCs) that are currently used? |
|
- HTRI and HTFS for heat exchanger design
- The Multiflash Thermo package from Infochem
- Pump models
- Distillation model from Prof. Dudukovic at Washington University (St. Louis, Missouri)
- Cracker furnace models
- Mixer/agitator calculators
- Distillation packing design tools
- Safety relief design calculators
- Fluid flow network calculators (e.g. FLOWMASTER)
- Non conventional unit operations
|
|
|
What are some examples of Process Modeling Environments (PMEs) that are currently used? |
|
The most obvious examples are the current process simulators from AspenTech (Aspen Plus and Aspen Hysys), Honeywell Process Solutions (UniSim Design), Process Systems Enterprise (gPROMS),
COCO (AmsterChem), ProSimPlus (ProSim SA) and SimSci-ESSCOR (PRO/II). However, in a more general sense it could be said that any software that "stands by itself" and calls on or
uses another Software Component is itself a PME. In practice, the distinction between a PME and a PMC is not always clear, as a PMC may
call on another PMC to complete its task, and therefore seems to behave as a PME. Such a clear distinction is not necessary to
understand and use the concept. |
|
What is a Process Modeling Component (PMC) |
|
A Software Component which is intended to carry out 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. This is a process element such as a unit operation, a numerical solver, a thermodynamic server, a physical
property data base, etc. Examples are heat exchanger design models, pump models, distillation models (including packing, distributor, or
tray models), hydrocarbon cracker furnace models, mixer/agitator calculators, safety relief design calculators, fluid flow network
calculators, non conventional unit operation models. |
|
What is a Process Modeling Environment (PME) |
|
A PME is essentially a software environment that supports the construction of a process model either from first-principles or from
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. To achieve their latter function, this category of process tools incorporates or
makes use of several Process Modeling Components.
|
|
What is the difference between a PME and a COSE (Process Modeling Environment and CAPE-OPEN Simulation Environment)?
|
|
A COSE, pronounced "co-zee", is a CO compliant PME. A COSE is described as having one or more CO "sockets" into
which a CO compliant Process Modeling Component can be "plugged". |
|
What is middleware? |
|
A software layer that allows inter-working of heterogeneous applications in heterogeneous distributed environments. It is "in the
middle" between the Process Modeling Component (PMC) and the Process Modeling Environment (PME) or between PMCs or PMEs such that
information can be exchanged between the Software Components.
|
|
What are COM and CORBA ? |
| -
COM (Component Object Model interface definition language) is Microsoft middle ware, the heart of Windows. COM is used in Windows
environments.
- CORBA is the Object Management Group (OMG) middle ware. OMG has 800+ members: software and hardware manufacturers, and industrial
users. http://cgi.omg.org. CORBA is used in UNIX environments.
|
|
When and where can I get some training on how to bring my models to the CAPE-OPEN standard?
|
|
One University course at E.N.S.I.A.C.E.T. (Toulouse, France) has addressed this need. A Short Course on CAPE-OPEN was given by ProSim SA at the AIChE Annual Meeting 2006
in San Francisco. Another one-day course was given by US EPA and AixCAPE e.V. on behalf of CO-LaN on March 7, 2007 in Heidelberg: this course described how to use
.NET with CAPE-OPEN. |
|
What does CO not cover? |
|
- File formats
- Model content
- Internal software structure and implementation
- Accuracy of models and data
- GUIs
- Units conversions
- Process synthesis software
|
|
Does CO cover CFD (Computational Fluid Dynamics)? |
|
Not explicitly, although the "distributed parameters interface" will be of interest to CFD vendors. There is already
interest from CFD vendors in wrapping their products to make them CO-compliant. This is an evolving area and as more information
becomes available, we will post it on the CO-LaN web site. |
|
What does "CO-compliant" mean? |
|
A Software Component is said to be CO-compliant if it correctly implements CAPE-OPEN interfaces, allowing it to interoperate with
other CO-compliant software. Not every component will implement every interface as not all are needed by each component. |
|
When and where can we join the club? |
|
Joining the CO-LaN is a simple process. Fill a membership application form and submit it to the CO-LaN Management Board.
|
|
What is the CO-LaN? |
|
CO-LaN stands for CAPE-OPEN Laboratories Network. This is the organization that carries forward the work of CAPE-OPEN initiated in
the European funded projects CAPE-OPEN, Global CAPE-OPEN and GCO Support. CO-LaN activities include promoting CAPE-OPEN, developing and
improving CAPE-OPEN standards, and generally insuring the success of the CAPE-OPEN concept and principles.
When significant projects
are required (e.g. for the creation or updating of an interface standard specification), task forces of interested organizations are
created for the task rather than staffing the CO-LaN to be able to handle such major efforts. CO-LaN was incorporated as a
non-for-profit Society in January 2001. |
|
How is the CO-LaN funded? |
|
Funding comes from membership dues. Membership is organized in two groups: Full Members and Associate Members. Full Members are end-users
of CAPE software. Associate Membershers are providers of CAPE software, either commercial or academic. Only Full Members are paying fees,
defined every year by the CO-LaN Board of Directors, and ratified during the Annual General Meeting of members, so as to meet the needs
of the Society and its members. |
|
How users know which Software Components are CO compliant? |
|
The CO-LaN maintains a list of CO-compliant Software Components. |
|
How much effort will be required to make a Software Component CO compliant? |
|
Like any other software development effort, it will depend on the complexity of the product. And the software engineer will need to
understands the applicable CO standards and the wrapping methods. It will also depend on the number of interface standard specifications
with which the Software Component needs to comply. Software developers are just beginning the work of wrapping components - when more
experience is accumulated, we will be able to at least offer some rules of thumb or general guidelines. For smaller components which
already have a modular structure or are otherwise well organized, an investment of days or a week or two is realistic. |
|
How will CO compliant Software Components be distributed? |
|
Like any other software component, although the future of software distribution will likely continue to move toward the web.
|
|
What is IMS?
|
|
The Intelligent Manufacturing Systems (IMS) initiative, is an industry-led, international research and development program established
in 1995 to foster development the next generation of manufacturing and processing technologies. For more information, see www.ims.org.
|
|
What is the relationship between CO and STEP? |
|
STEP (Standard for the Exchange of Product model data) is focused on digital product data - things such as geometry, topology,
tolerances, relationships, attributes, assemblies, configuration, etc.. CO is focused on the interoperability of process models and the
data to support those models. STEP and CO are complementary and do not overlap in either goals or implementation.
|
|
What is the relationship between CO and OPC?
|
|
OPC (OLE for Process Control. OLE = Object Linking Embedding) is an industry standard for interoperability of process control software,
using Microsoft COM as middleware. The OPC members are mainly automation companies i.e. Fisher Rosemount etc. OPC addresses a different
and complementary subject. CO makes use of OPC interfaces for accessing the process control data. OPC does not address interoperability
of process models - this is where CAPE-OPEN interfaces are used. |
|
What is the relationship between CO and Open-Spirit?
|
|
Open Spirit Inc. is a company providing interoperability solutions for the oil and gass industries in the form of
interface definitions for services and of software implementing them. Some partners in the former Open Spirit Alliance, which led to the
creation of Open Spirit Inc., have been partners in the Global CAPE-OPEN project. Some Open Spirit contributors have been involved in
the CO-LaN Master Plan and in the Method and Tools group of GCO. |
|
Who is providing CO-compliant environments and/or components?
|
| -
Vendors:
- AspenTech - Aspen Properties, Aspen Plus, Aspen Hysys
- SimSci-ESSCOR, PRO/II
- AmsterCHEM - COCO
- DECHEMA - Thermo plug & PPDB plug
- PSE - gProms thermo socket and unit plug
- ProSim - SIMULIS thermo plug and socket and ProSimPlus
- Belsim - Vali Thermo socket
- Infochem - Multiflash Thermo plug
- VMG - Thermo socket
- Honeywell Process Solutions - Thermo & Unit socket, Thermo Plug
- DIPPR. PPDB (Physical Property Data Base) plug
- Universities:
- DTU - Unit plugs (Technical University of Denmark)
- INPT - Solver plug (Institut National Polytechnique de Toulouse)
- RWTH - Solver plugs (Rheinisch-Westfälische Technische Hochschule Aachen)
- Operating Companies:
|
|
How does CO address which criteria to choose for process optimization?
|
|
CO provides interface specifications that enable the use and definition of any criteria one may think of. This means providing a
sufficient flexibility in the handling of variables and so on. How to conduct the optimization and what tools to use are choices the
user must make, and are not an issue for CO standards.
|
|
What is the incentive for different companies to share models?
|
|
The point is not to share models but to define and use interfaces that will make the use of proprietary models completely transparent
whatever the PME (Process Modeling Environment) one is using. Models are incorporating so much process knowledge that they will be kept
confidential and CO interfaces will help, since it won't be necessary to exchange information with vendors in order to use such models
within a specific PME. Using CO interfaces is a good means to enforce the proprietary nature of a model. In the case of companies
selling process technology, they would likely want to provide a CO compliant process model to aid their customers in CAPE
implementation of the technology. CO compliance will also make it much easier for Small to Medium-sized Enterprises (SMEs) to enter
the market place with specialized Software Components. |
|
Won't having to pay for the use of many components be a nightmare?
|
|
It is expected that such widely used specifications could well lead to freeware or shareware or different licensing arrangements.
A component will be marketed, sold, and purchased only if the developer and users think it is beneficial, so it will be driven by market
forces. If multiple vendor sources becomes a barrier to use, it will be up to those vendors to structure their product licenses to
minimize that barrier. |
|
What is the role for universities and research institutes in the CO marketplace?
|
|
Universities and other non-profit CAPE organizations can list their CO assets in terms of models developed. Models that have the
highest market value, either in terms of monetary return or recognition, will determine which components to migrate first. The source
code developed for example in Fortran 90, even in Fortran 77, should be able to remain relatively intact through migration. The migration
should be technically a low level task where only the CO compliant wrapper needs to be written. Senior students with an adequate
background in Visual Basic or Visual Fortran should be able to do the job. The CO-LaN will be ready to advise such institutions on
the possibility of migrating a piece of software. It seems likely that in the near future, companies would require that any software
developed in partnership with universities, etc. be CO compliant.
|
|
How will organizations find the resources to migrate to CO compliance and still meet their original goals of delivering the capability
of the Software Components? And, what will prevent organizations that are good at wrapping for CO compliance (but not so good at modeling)
from dominating the market? |
|
Migrating software to CO compliance will not keep people from pursuing their work. In fact it could well increase their prominence in
the CAPE community. It will be their component that is marketed, their name will be put on it, and it will traceable to them much easier
than is sometimes the case today. Bringing a component to CAPE-OPEN standards would result in the recognition of the work done by a
researcher, without a great deal of effort going into this migration. Further, there will be significantly less work involved in making
components operate in multiple simulation environments, so the total work load should not increase and may even go down. |
