Editorial Board: Peter Banks, Bertrand Braunschweig, Celeste Colantonio, Ronald-Alexander Klein, Werner Merk, Hans Pingen, Michel Pons

Technical Support: ADDUCE GmbH

A full copy of the Interoperability SIG annual report is available from CO-LaN webmaster (see contact at page bottom).

The lessons to emerge from the tests and developments are catalogued below. Note that “CO standard” refers to an individual standard within the CO framework, e.g. the Unit Operation standard or the Thermo standard.

·    All PMEs need to be able to trap CO components that use versions of the CO standards that are not supported by the PME.

o    Attention: PME vendors

·         There is a need for a generic "interface reporting" component that will sit between the PME and PMC and report the information being passed between the two. This will greatly aid the debugging of CO interface implementations.

o        Action: Interoperability SIG  

·         Components and environments must be written strictly to the relevant standard.

o        Attention: All developers

·         Specific examples of non-adherence found so far that need to be considered are:

o        CO Unit Operations must respect the basis qualifier in calls to getProp and setProp for a material object. Furthermore, the basis qualifier must be strictly enforced in PMEs

o        The type of value returned for a parameter must match the parameter’s specification.

o        All string comparisons in CO components and environments must be case insensitive

o        A CO Unit Operation must not attempt to validate the material objects associated with its ports until it is asked to calculate. There is no guarantee that the material objects are valid until the calculation is requested

o        CO components must expect the correct return types when calling Material Object methods. For example, the specified return type for a call to GetComponentConstant of CapeArrayVariant is defined as VARIANT (i.e. any type) in the CO IDL. The use of CapeArrayVariant means that the variant returned will itself contain an array of variants – even if only a single value is being returned. The type of each variant in the array may be different depending on what data was requested.

o          Attention: All developers

·         The CO testers should be able to diagnose all cases where code does not strictly adhere to the standard.  We need to check to see if the testers need further development.

o        Action: Interoperability SIG

·         For complete interoperability, all PMEs should implement a supported standard in full (but see discussion below). For example, a PME implementing the Unit standard should support Array variables, otherwise some CO Unit Operations will not work fully.

o        Attention: PME Vendor s

·         However, this could be less onerous for vendors and clearer for purchasers, if the standards were split into a number of logical sections.  This would allow vendors to specify which sections of a standard their software supports, if they were unable to support it all. An example of this would be to move the CO Equilibrium Server into a separate section within the Thermo standard, so that a PME vendor can explicitly and easily state whether their PME does or does not support this feature. We request that SIGs with responsibility for standards should review and comment on this proposal.

o        Attention: SIGs with responsibility for standards .

·         Component and Environment developers must take extra care to ensure that their code is bug free, since detecting bugs becomes more difficult with inter-operation of components from different suppliers. An example of this is a component which contains a memory over-write, which may only appear when the component is used in a particular way in a single PME.

o        Attention: All developers

·         A new work-flow for the use of a CO Property System has been identified, as follows:

o        Open PME

o        Invoke CO Property System from within PME and open specific GUI for Property System

o        Load existing Property Package or create a new one

o        Close GUI for Property System and return to PME

o        Either select the required Property Package or have it automatically selected based on the choices made in the GUI for the Property System

·         This work-flow is not currently supported by the CO Thermo standard, which expects that the required Property Package has been created before the user opens the PME. We suggest that support for this alternative work flow should be considered in a future version of the Thermo standard.

o        Attention: Thermo SIG

·         A CO Property Package cannot currently assume that any calls it does not implement can be forwarded back to the material object it has been given, as the action to be taken in this situation is not specified in the standard. It is therefore possible that a material object will simply forward all calls relating to property calculations back to the Property Package associated with it. If the client is a Property Package this will result in recursive calls that will end in a crash.

o          Attention: Property Package developers

·         It would however be useful if a CO Property Package could obtain the necessary pure component properties from the PME, rather than the component having to include its own pure component property databank. We suggest that a protocol for such a call-back should be considered for a future version of the Thermo standard.

o        Attention: Thermo SIG

·         Furthermore, Property Packages that implement a sub-set of models (e.g. liquid density only) are not currently explicitly supported in the standard, although it may work in some PMEs. We suggest that this should be considered as a future enhancement to the Thermo standard.

o        Attention: Thermo SIG

·         If a CO Property Package does not implement all the properties expected by a PME, then the PME needs to report this in a meaningful way. Note that the CO Thermo standard does not specify which properties should be made available by a Property System, but simply provides a full list of those that are supported by the standard. However, we suggest that there should be any easy way of identifying the properties available in any specific implementation of a CO Property System, either via the System itself or the PME it is being used in.

o        Attention: PME Vendors and / or Property Package developers

·         A CO Property package may predict the existence of more valid phases than are supported by the PME in which it is being used. In this case the CO interface performs exactly as expected, but there is an obvious incompatibility between the component and environment and the effects are uncertain. The Thermo standard should be enhanced to at least document this scenario and provide suggested remedies, or the specification should be enhanced so that the interface itself can trap the problem

o        Attention: Thermo SIG

·         The CO Unit standard does not support a "string" parameter; instead this needs to be implemented as an Option parameter. We suggest that string parameters should be added to the Unit standard. The specification for Option parameters needs to be clarified: is it legal to have an Option Parameter with an empty Option list? Interoperability testing has shown that whereas one PME (HYSYS) allows this, another (Aspen Plus) doesn’t.

o        Attention: Unit SIG

·         A CO Unit Operation must not change the current working directory of the application in which it is running. Any CO Unit Operation that displays a File Open dialog and allows a file to be selected from any directory will change the current working directory as a side effect. The correct mechanism is to save the current working directory before displaying the dialog and then to restore it afterwards.

o        Attention: Unit Operation developers

·         The DLL for a CO Unit Operation must not be unloaded while the CO Unit is in use. Note that the provider of the CO Unit Operation can control the unloading of the DLL by implementing DLLCanUnloadNow.

o        Attention: Unit Operation developers

·         CO Unit Operations should handle the failure of calls to optional or non-essential Material Object methods robustly.

o        Attention: Unit Operation developers

·         CO Unit Operations must be correctly registered. In particular they must at least provide a value for CapeDescription\Version so that PMEs know which versions of the CO interfaces they support. In addition, PMEs should ignore Unit Operations (and other components) that do not have version specified.

o        Attention: Unit Operation developers and PME vendors