ICapeUtilities Interface

When a PME requires some kind of functionality, with the help of the CAPE-OPEN categories, the user is able to select and create a CO class which will expose the required CO interfaces. There is the need for the PME to exchange some information with this instance of the PMC. This information consists in a set of simple unrelated functionalities that will be useful for any kind of CAPE-OPEN component, since they will allow maximum integration between clients and servers. All these functionalities can be grouped in a single interface. Some of the functionalities to fulfil consist in exchanging interface references between the PMC and the PME. Instead of adding these properties to each business interfaces, it is much more convenient to add them to a single common interface which refers to the whole PMC.

Furthermore, there is a need for getting parameters, editing and lifecycling.

The interface should fulfil the following requirements:

Parameters:

So far, only Unit Operations can expose their public parameters, through property ICapeUnit.parameters, which returns a collection of parameters. This property allows COSEs to support design specs between two CAPE-OPEN Unit Operations. That means that the CAPE-OPEN interfaces are powerful enough to allow that the design spec of a given Unit Operation (exposed through public parameters) depends on transformations of public parameters exposed by other CAPE-OPEN Unit Operations. If also other components, such as Material Object, would be able to expose public parameters, the functionality the aforementioned described functionality could be extended. Other functionalities would be:

(i) allowing optimizers to use a public variable exposed by any CAPE-OPEN component.

(ii) Allow performing regression on the interaction parameters of a CAPE-OPEN Property Package.

Centralising the property that accesses these collections in a single entry point, helps to clarify the life cycle usage standards for these collections. That means that it will be easier for the PMC clients to know how often they have to check whether the contents of these collections have changed (although the collection object will be valid until the PMC is destroyed). Setting general rules for the usage of these collections makes the business interface specifications more regular and simpler. Obviously, since too general rules may reduce flexibility, PMC specifications might point out exceptions to the general rule. Let’s see how would this affect the particular PMC specifications:

Simulation context:

So far, most of CAPE-OPEN interfaces have been designed to allow a client to access the functionality of a CAPE-OPEN component. Since clients will often be Simulation Environment, CAPE-OPEN components would benefit from using functionality provided by their client, a COSE for instance. These services provided by any PMEs are defined within the Simulation Context COSE Interface specification document.

The following interfaces are designed:

(i) Thermo Material Template Systems: Theses interface allows a PMC to choose between all the Thermo Material factories supported by the PME. These factories will allow the PMC to create a thermo material object associated to the elected Property Package (which can be CAPE-OPEN or not).

(ii) Diagnostics: This interface will allow to integrate seamlessly the diagnostics messages generated by any PMC with the mechanisms supported by the PME to display this information to the user.

(iii) COSEUtilities: In the same idea of this specification document, PME has also its own utilities interface in order to gather many basic operations. For instance that allows the PME to supply a list of standardised values.

Edit:

The Edit method defined by the UNIT specification proved to be very useful in order to provide Graphical User Interface (GUI) capabilities highly customized to each type of UNIT implementation. There’s no reason why other PMCs could not benefit of this capability. Obviously, when a PMC provides Edit functionality, being able to persist its state is a desired requirements, to prevent the user from having to repeatedly reconfigure the PMC.

LifeCycle:

There is probably no strict necessity to expose directly initialization nor destruction functions, since these should be invoked automatically by the used middleware (COM/CORBA). That is, the initialization could be performed in the constructor of the class and the destroy in its destructor. However, in some cases the client could need to invoke them explicitly. For example, all actions that could fail should be invoked by these methods. If these actions were places in the constructor or destructor, potential failures would cause memory leak, and they would be difficult to track, since it would not be clear if the component has been created/destroyed or not. Examples of cases where they are useful:

(i) Initialize: The client might need to initialize a given set of PMC in a specific order, in case that there are dependencies between them. Some PMC may be wrappers to other components, or may need an external file to get initialized. This initialization process may often fail, or the user may even decide to cancel it. Moving these actions from the class constructor to the initialize method allows communicating the client that the construction of the component must be aborted in some cases.

(ii) Destructors: The PMC primary object should destroy here all its secondary objects. Relying on the native destructor could cause deadlocks when loop references exist between PMC objects. See in the example diagram below that after the client releases its reference to the Unit Operation, both the Unit and the Parameter are being used by another objects. So, without an explicit terminate method, none of them would be ever terminated.

Reference document: Utilities Common Interface

Reference