2.7.1 Persistence Overview

Basically, two kinds of data can be seen: instance-related and non-instance-related. Instance-related belong to the DTM itself, non-instance-related belong to a project or are global (e.g. libraries).

The following types of persistence requirements for a DTM can be seen:

• A typical DTM without local data storage must be able to save and restore its instance-related data within the project database of the Frame Application. Therefore it can use the standard IPersistXXX mechanism.
• A DTM using additional own, local storage must be able to store a reference to its instance-related data within the project database of the Frame Application. Such a reference allows the DTM to find the requested data in its own private storage. So the instance-related as well as the non-instance related data can be stored in a proprietary way using the file system path of the Frame Application provided by the bulk data interface. But a DTM that uses a private storage mechanism has to guarantee the data consistence for multi user and multi client data access. For import and export these DTM must provide data of its private storage via a separate interface to the Frame Application. It is not allowed for a DTM to install private data base systems.

A Frame Application must be able to store DTM’s private data and all device parameters. Such a storage component, e.g. a database of an engineering tool, has to handle the locking and concurrent access to data by DTMs and Frame Application. The notification for synchronization is done via the interface IFdtContainer.

To use the storage component of the Frame Application, a DTM has to implement the standard COM-interfaces IPersistPropertyBag and IPersistStreamInit. It is not determined how the DTM performs the storage or which kind of private data of a DTM is stored.

The Frame Application requests the storage of private data of a DTM. A DTM must be able to re-establish its complete state when this is requested by the Frame Application. This is done by calling the function IPersistXXX::Load() of the DTM. Reload of a DTM object by calling IPersistXXX::Load() several times may not be supported by all DTM suppliers. With an IPersistXXX:Save() request a DTM must store its private data within the Frame Application. A DTM object for a new instance must be initialized if the IPersistXXX:InitNew() method is called by the Frame Application.

DTMs using additional own data storage must provide all data which are necessary for commissioning via the IPersistXXX interface. Private data not provided via the IPersistXXX interface must be offered to the Frame Application for import and export via the IDtmImportExport interface. Also an IStream object is used to store and retrieve such import and export data.

Remarks:

• In order to simplify the DTM development, it is up to a DTM to implement one of the defined persistent interfaces (n or IPersistPropertyBag) according to the Microsoft standard. The Frame Application must be able to handle both.
• References to DTMs do not belong to the instance data of a DTM. A DTM must not store any references to other DTMs. A DTM can get information concerning its parents or childs via IFdtTopology::GetParentNodes() and IFdtTopology::GetChildNodes().
• DTM should report data load errors via standard COM error mechanism (HRESULT not equal to S_OK). Optionally, DTM can write further human readable error information to standard COM global error info (Win32 SetLastError method).