A team of researchers at Technische Universität Berlin plus an expert from X-Visual Technologies GmbH, contributed a research paper in the March 2019 issue of Chemie Ingenieur Technik. This paper deals with the data exchange between process simulation, 2D CAD, and 3D CAD tools, and provides as well an overview of existing standards and formats
Not surprisingly, since Technische Universität Berlin is a strong advocate of CAPE-OPEN (for example their software tool MOSAICmodeling creates CAPE-OPEN Unit Operations), the authors cite CO-LaN (it should rather be CAPE-OPEN) as an initiative to ease the data transfer between software tools, and more specifically as enabling “interoperability between process simulators“.
From the CO-LaN point of view, it is worth stating that CAPE-OPEN is not a data model, it is an interoperability model and it is not acting between process simulators (in the paper, Aspen Plus is given as an example of a process simulator, i.e. a Process Modelling Environment according to the CAPE-OPEN terminology). The interoperability achieved through CAPE-OPEN is between Process Modelling Components and a Process Modelling Environment. The interoperability between Process Modelling Environments is not within the original scope of CAPE-OPEN.
Within section 2.2.3 of their paper, the authors state “In addition, the CAPE-OPEN specifications are currently limited to steady-state systems and there is no functionality in place to store and share results of simulations.“.
First of all, there is nothing in CAPE-OPEN that prevents a CAPE-OPEN Property Package to be used for the simulation of a dynamic system. Indeed such usage has been reported by ProSim SA at the CAPE-OPEN 2014 Annual Meeting by explaining how they made use of a CAPE-OPEN thermodynamic server in their simulation of batch distillation columns. In much the same way, Carl SANDROCK described how OpenModelica was made to use CAPE-OPEN Property Packages for the dynamic simulation of chemical engineering systems. I am pretty sure examples of use of CAPE-OPEN Property Packages in dynamic models made within gPROMS could be found as well.
It is also relevant to note that the CAPE-OPEN Equation Set Object is used in Diana for adressing Differential Algebraic Systems which are typically used to model dynamic systems.However I presume that what is really meant here is that the CAPE-OPEN Unit Operation interface specification is limited to steady-state systems.
This statement is both correct and incorrect.
Neither the Global CAPE-OPEN project or CO-LaN have publicly released an interface specification for dynamic unit operations. However such an interface has been designed, documented, presented, prototyped and implemented in commercial software.
Work on such an interface specification goes back to the early years of the UNIT Special Interest Group (see for example the public report of that SIG activities made in 2003). It shows it has been a topic addressed by CO-LaN when the organization was created. The specification was thoroughly tested within the TINA project between IFPEN, TOTAL and RSI. Transient pipe unit operation models, incorporating knowhow from IFPEN, were developed as CAPE-OPEN Dynamic Unit Operations and plugged into IndissPlus from RSI, using use cases out of TOTAL operations in oil and gas fields. Unfortunately the UNIT SIG did not retain the necessary technical expertise to put a final point to this interface specification. The UNIT SIG wants to put an end to the Petroleum Fractions interface specification before presumably moving back to the Dynamic Unit Operation interface specification.
However one could argue that this dynamic Unit Operation interface specification is mostly suited for Operator Training Simulators that IndissPlus is. It is indeed debatable and more technical insight in this is welcome.
On the fact that CAPE-OPEN has no functionality in place to store and share results of simulations. The wording is kind of misleading. First it can be interpreted as CAPE-OPEN does not support persistence while on the contrary, CAPE-OPEN provides a functionality to store results of simulation and to reload results of simulation as stored by a process simulator within this same process simulator. Now CAPE-OPEN does not specifically provide for exporting results of simulation from one process simulator and import it in another process simulator.
This is in fact not within the initial scope given to CAPE-OPEN.
Once more CAPE-OPEN was developed to permit the seamless plugging of Process Modelling Components within a Process Modelling Environment. That did not call for sharing results from one process simulator to another. However implementing CAPE-OPEN does not prevent such a functionality to be added. The main obstacle is to get vendors of process simulators to adhere to such a generic functionality.
Remember that CAPE-OPEN is the result of a compromise between many parties: end-users of process simulation software, vendors of such software and academics of that field. Before the CAPE-OPEN project was launched, it was envisioned a different scope for the project. Developing a standardized data model to make flowsheets and their data exchangeable between process simulators was considered, and abandoned because threatening the market position of major software vendors. So a compromise was developed with the current scope of CAPE-OPEN that can be considered as limited, but on the other hand it has been implemented in most of the software tools available in the market which makes CAPE-OPEN a de-facto industrial standard.
More on exporting / importing results of simulation from one process simulator to another: CAPE-OPEN is not targeted to make it happen but can be used to make it happen.
The authors further note that “Naturally, the CAPE-OPEN unit operation specification could be used to build entire flow sheets, but the specifications of the inlet streams to the process would only be stored in the flow sheet itself and, hence, would be lost on switching from one tool to another.” The authors are right to mention the ability of the CAPE-OPEN Unit Operation interface specification to be used for entire flowsheets. And more to it, it has been used, it is not just an idea.
My recollection is that the earliest application must have been the one of the SolidSim project in the mid-2000s. An entire flowsheet made within the SolidSim process simulator was easily wrapped as a CAPE-OPEN Unit Operation and plugged into such process simulators as Aspen Plus. The same has been made subsequently possible with COFE from AmsterCHEM: an entire flowsheet can be exported as a CAPE-OPEN Unit Operation. This has been reported at least in one paper published in a scientifc journal by researchers making use of that functionality provided by COFE.
Remains indeed the issue of the inlets and outlets that need to be redrawn in the target process simulator. However CAPE-OPEN has been taken one step further with the FlowExchange Unit Operation from AmsterCHEM that permits to store product or feed stream data in one dedicated Unit Operation that can be brought it with its data in another process simulator. Could be considered as a cumbersome workaround but nevertheless fully working.
Once more it shows that CAPE-OPEN is not trying to limit its applications and its functionality can be stretched a long way.
Regarding the topology of the Flowsheet for which the authors note “Also, the topology of the flow sheet would need to be
redone“, it is in fact present in CAPE-OPEN within the Sequential Modular Specific Tools (SMST) specifications and within the Flowsheet Monitoring interface specification. To be true the SMST specifications have not found their mark in terms of implementation and the Flowsheet Monitoring interface specification needs still to be publicly released (has already been prototyped in an earlier version though).
The authors conclude their analysis of CAPE-OPEN by stating “Hence, the CAPE-OPEN specification – while being a very useful standard for process simulation in chemical engineering – is ill-suited for actual data exchange between process simulation software or with tools of other disciplines.”
That is somehow true but CAPE-OPEN should not be interpreted as preventing data exchange between process simulation software. It is providing for data exchange between Process Modelling Components and Process Modelling Environments. It can be used to realize data exchange at the stream level between process simulators and to transfer a flowsheet from one process simulator to another. However CAPE-OPEN is not meant to be a data model, it is an interoperability model.
The authors offer a conclusion where they indicate that “there is no concerted push to drive the standardization beyond a single discipline or bilateral exchanges” and they cite as one of the many reasons “that few software vendors and users (of customized software) are currently willing to accept some level of compromise regarding the standardization.”
If one may draw anything from the experience of CAPE-OPEN, which has not been following a path of roses without thorns, reaching a compromise is indeed a complex undertaking. For CAPE-OPEN it called for almost three years of debate and learning to reach a common understanding leading to a compromise. Many could say that it took too long for what it is worth. Still, once the compromise on the goal was achieved, the actual technical work was launched and succeeded in delivered more than a proof of concept at ESCAPE 9 in Budapest. That was in May 1999, more or less five years after Peter BANKS asks for such a standard to be created (FOCAPD – July 1994).
CO-LaN is welcoming any initiative that would increase digitilization in the process industry. The paper discussed here shows that a number of aspects of CAPE-OPEN are lacking sufficient visibility, others need to be finalized, in order to present CAPE-OPEN as a less limited solution for interoperability.