EP1869548A2

EP1869548A2 - Synchronisation of data

Info

Publication number: EP1869548A2
Application number: EP06725635A
Authority: EP
Inventors: Ronald Lange; Thomas Banik; Rainer Bitzer; Rainer Heller; Peter Niederhuber; Rudolf Pohlan
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2005-04-11
Filing date: 2006-04-07
Publication date: 2007-12-26
Also published as: DE102005016690A1; US8032893B2; WO2006108801A3; US20090217312A1; WO2006108801A2

Abstract

The invention relates to a method and a system for the synchronisation of data between applications. According to said method, the data is exchanged at least partially between the applications, said exchanged data being synchronised with the data that is present in the respective application. To simplify the synchronisation process, according to the invention an identification that signifies incompleteness is assigned to the data.

Description

description

Synchronization of data

The invention relates to a method and a device for synchronizing data.

The invention has for its object to simplify the synchronization of data between applications.

This object is achieved by a method for the synchronization of data between applications, in which the data is at least partially exchanged between the applications, whereby the exchanged data is synchronized with data present in the respective application, the data being marked for incompleteness is assigned.

This object is achieved by a system for the synchronization of data between applications, wherein data is at least partially interchangeable between the applications, wherein synchronization means are provided for synchronizing the exchanged data with existing data in the respective application, wherein the data can be assigned an identification for an incompleteness is.

In the engineering chain from product to Anlagenpla ^¬ planning and plant automation there are transitions between different data management systems. On the one hand, this is technically conditioned because there will not be (even in the future) a product ^suite that offers all aspects integrated. On the other hand, this is due to the different user roles within the engineering chain, which want to work occasionally unsynchronized and want to compare with the data management of the other user roles at defined times. It is important that a change is potentially carried out by all user roles In principle, the synchronization of the data records must therefore be bi- or multidirectional.

XML has become the basic description language for structured data exchange. However, XML does not provide sufficient specifications to handle the above mentioned. Fully support the scenario. First further definitions were made in the PNO specification XMLgPROFIBUS (object model, management of foreign keys, multilingualism, ...).

In particular, the invention addresses the change management in data exchange. These are u.a. the following use cases that can not be adequately supported by XML alone:

o If WUR already synchronizes the data conversations ^¬, only the changes need to be replaced in subsequent synchronizations. o How can the changes to the already ^¬ exchange project data relate? o How can deletions be transmitted? are o How can pass object paths ^¬ jektdaten without Whether to duplicate?

o The models of the different data storage systems are typically not congruent. Therefore, a Datenhal ^¬ supply obligations tung incomplete information for other Datenhal ^¬. o How is this incompleteness expressed? In particular ^¬ sondere such distinction is that a date in exchange does not exist, because it does not know the exportie ^¬-saving data management, or because the date was canceled?

o During export, a root object can typically be selected, from which all objects are exported. additionally Filter settings can still be defined so that not all object data is always exported. o How can recognize the importing application, wel ^¬ ches root object or which filter settings were selected overall? o How can the resulting export files still be described using a uniform XML schema?

o The data schemas of the data records can change. o How can you determine if there are changes to the data schema when importing data records? If so, of what kind (compatible, incompatible, object related, ...)?

The specification PROFIBUS Guideline XML @ PROFIBUS (PNO Order No. 2342) addresses change management only unzurei ^¬ accordingly. The present invention relates in the exporting ^¬ approximately examples in part on the fenen in this guideline getrof ^¬ specifications.

The present invention and its advantageous Ausgestal ^¬ lines solve the above questions. The specified in the description of concrete XML syntax is to be understood as exporting approximately ^¬ example, the invention is of course independent of it. The invention or the advantageous embodiments of the invention include the following concepts:

o Marking for the incompleteness of exported

Objects and attributes. This marking is also referred to as partial labeling. The identification is advantageously hierarchically assignable and / or inheritable.

o Concept of shell objects that carry all the attributes required for identification (name, ID), but are not transferred as full-fledged objects. Ba ^¬ sis can be here in particular a name hierarchy. Versioning Concept (via XML schema version, XML namespace and data version) that when importing a data ^¬ pose the kind of data changes can be detected and can be generically responded. As a result, in most cases it is possible to change a data schema of an exporting application without having to change the import routines of the other data records. Advantageously, a multi-layered identification drawing of the version is used.

The invention will be described with reference to the embodiment shown in the figures, embodiments and tert erläu ^¬.

Show it:

1 shows a basic representation of an engineering ^chain ,

2 shows a flow diagram for the representation of the import of data,

3 shows a flow diagram for the representation of the merging of objects,

4 different possibilities of restriction in an export of data,

5 shows an example of name hierarchies and

6 shows an example of external references. An exporting application can define whether to perform a full or partial export. There are several scenarios for a partial export:

o An application can track the changes since a previous export, only this could decide to "delta information" to export only the new or edited objects and attributes that to exportie ^¬ ren.

o One external application may not be available all the data available, which expects an importing application (eg krepanzen due Objektmodelldis ^¬) so they that export as part reindeer marking would.

o If an application does not export its complete project, but only a subtree, then the superior objects of the root object (which are exported as shell objects) are by definition partial. The same applies to any target objects of external REFERENCED ^¬ zen that may exist.

Each object in an export file can have an optional attribute PartialExport, with the possible values being true or false. This attribute refers to the Whether ^¬ ject itself and aggregated to all its sub-elements, if not a subobject his own PartialExport attribute sitting be ^¬. At the root object, the attribute has a default value of true.

If PartialExport of an object is false (either because it is explicitly specified in the object or because it is "inherited" by its parent), then the importing application must assume that the file contains all the subelements of that object exists and contains additional subobjects that are not in the import files are found, they should be considered deleted. In most cases, the importing application does not automatically delete its internal object in such a scenario, but asks the user for confirmation.

If PartialExport true, the importing application processes all sub-objects, gene of the products contained in the import file ^¬, and allows additional subobjects which it may have in their ternal in ^¬ data unchanged.

Example instance fragment:

This example means:

o ObjectA has a child ObjectBl and can also have other child objects o ObjectB has exactly the child objects ObjectCl and ObjectDl and no other child objects.

In certain cases, an object type "dynamic Attribu ^¬ te" exhibit, ie attributes that can be present in an instance of that type or not and possibly even added during the lifetime of an instance or deleted. In such a scenario, an object (which is a "Settings" feature with such attributes ent holds ^¬) an optional "PartialAttribute" attribute include. Just like the PartialExport attribute refers this Att ^¬ ribut to the object itself and on all of its aggregated sub-elements, if not a subobject his own partial Attributes attribute owns. At the root object that has Att ^¬ ribut a default value of "true".

If PartialAttributes is false, the importing application assumes that the import file contains all the attributes of the object. If the object already exists and contains additional dynamic attributes, they should be seeks as deleted be ^¬.

If PartialAttributes true, the import ^¬ de application processes all attributes that are present in the import file, and allows additional attributes it may have in their ternal in ^¬ object unchanged.

PartialAttributes is irrelevant to attributes that are not dy ^¬ cally are (which are always present in the object instance and can not be deleted). The importing application can always static attributes unchanged when the Attrib ^¬ but not present in the import file.

Example:

<PropertyA> ll </ PropertyA><PropertyB> 0.5 </ PropertyB></Settings></ObjectC></ObjectB> o ObjectB has properties 1, 2, and 3 and possibly other attributes o ObjectC has exactly the properties A and B and no other (dynamic) attributes.

If an exporting application sets PartialExport or PartialAttributes to "true", it must have a way to specify that an object or attribute should be deleted by importing (simply not importing the deleted object is sufficient) not enough, the importing application would just leave its internal data unchanged).

For this purpose, every object and every dynamic attribute can have a "Deleted" attribute.

This flag is defined for objects by XML @ Profibus, but not for attributes. If an application has dynamic attributes (which are deletable), the schema must declare appropriate types, as in the following example:

Instance:

<ObjectC ID = "3" Name = "ObjectCl" Deleted = "true"/></ObjectA> Scheme:

<xsd: complexType name = "ObjectBSettingsFeatureT">

<xsd: complexContent> <xsd: extension base = "prim: FeatureT"> <xsd: sequence> <xsd: element name = "Propertyl" type = "Deletable_integer" minθccurs = "0" />

<xsd: element name = "Property2" type = "xsd: double" minOccurs = "0" />

<xsd: element name = "Property3" type = "xsd: integer minθccurs =" 0 "/> </ xsd: sequence> </ xsd: extension> </ xsd: complexContent> </ xsd: complexType>

<xsd: complexType name = "Deletable_integer"> <xsd: simpleContent>

<xsd: extension base = "xsd: integer"> <xsd: attribute name = "Deleted" type = "xsd: boolean" use = "optional" default = "false" /> </ xsd: extension> </ xsd: simpleContent> </ xsd: complexType>

If this attribute is set to "true", the transporting in ^¬ application should the object or Attrib ^¬ but regarded as canceled. If the object / attribute does not exist in the import application, it can be ignored.

If the deleted flag is set for an object or attribute, it is not necessary to write the full content of the element to the export file. However, it must be possible for the importing application to identify the object or attribute to be deleted, so that, for example, the name and / or the idea of an object should be specified; like any application-specific identifiers that may be present.

If the Deleted flag is used in conjunction with PartialExport / PartialAttributes set to false, the importing application should also consider the corresponding object or attribute deleted. This use is per ^¬ not recommended that the exporting application should simply not export the corresponding element to specify that it was deleted.

In many scenarios, the user may choose to either export a complete project or just a sub-tree. As a rule, he can select a root object in the tree view and start an export of this object and its subelements via a (context) menu. Is not normally ever ^¬ the object in a project hierarchy as the root object meaningful ^¬ full, it should only specific types can be selected for this purpose.

To ensure that the importing application has access to the complete context information (i.e., the name hierarchy), the parent objects of the selected root object should also be written to the export file as "shell objects".

<AttributeA> ll </ AttributeA> <AttributeB> some content </ AttributeB> <AttributeC> 0.5 </ AttributeC> </ Settings>

</ ObjectB></ObjectA> </ Document>

In addition to restricting export via "PartialExport" or exporting only a sub-tree, it may also be possible to apply a "filter" to an export. In principle, this means that only objects of specific types are written to the XML file. To designate such a "filter", the project element may carry an "ExportScope" attribute.

This document does not define a mechanism for formulating such filters. It is left to export the application to determine whether, for example filters are fixed or can be defined by the user or whether a filter is a "posi- tive list" exportable types or a "negative list" ge ^¬-filtered types.

From the standpoint of the XML format, it is only more ^¬ tig that the ExportScope attribute holds a "Filter Name" contains and that the exporting and importing application to share a common understanding of the described by that name filter characteristics.

Fig. 4 gives an example of the different ways to restrict an export.

Although each XML format ent with long-term stability as a goal ^¬ should be developed, it is virtually inevitable that a format may need to be changed domestic product or component during the life cycle of a product. The mechanisms described by ^¬ following in this chapter can help to ensure that such a change is manageable, but it should be noted that resistance to format ^¬ changes mainly "orientation robust imple-" a matter of an import mechanism. For example, if an importing application encountered an unknown element while parsing an XML file, it might, for example, treat the element in a generic way if possible, or it might choose to ignore it easily (and warn the user to spend). However, it must not crash in such a situation and should not abort the import process.

If an importing application does not find an expected element or attribute when parsing an XML file, it should similarly try to use default values instead.

The exact requirements for versioning an import export functionality can be different for each application ^¬ Lich, in general, it is desirable, however, that an application not only current XML files can be imported, but also files that a previous version of XML format.

One noteworthy point is the role an XML schema file plays in the overall export / import process. An XSD file can have two different purposes:

o You can nen as a documentation of the export format ^¬. By providing a schema, the exporting application can describe what kind of XML instance files it generates. Such documentation could also be provided as unstructured prose; the use of XSD has the advantage of a formal language for describing the format. The main ^{addressees of} this XSD are a human reader, who normally also has to understand the semantics of the format. O An XSD file can be used to check a set of statements using an XML instance file. XSD is just one language for formulating such statements (others are RelaxNG, Schematron, or even regular expressions). Which statements to test against a specific XML instance may depend on the instance's consumer and may even vary across the consumer's processing chain.

In the context of an export / import, a schema (and the schema fragments shown throughout the present document) has the main purpose of describing the XML format. The fact that the instance files can be validated on the basis of such a scheme is secondary - this alone will not guarantee that the instance may be he ^¬ successfully imported.

Changes to an XML format can be classified as "compatible" or "incompatible". The terms "kompati ^¬ bel" and "incompatible" are used in the following as defined in / XMLPB /. A compatible change is, for example, the addition of elements or attributes to existing objects. Incompatible changes include deleting or renaming attributes or structural changes.

If an application needs to change its XML format in an incompatible manner, it should change the namespace to explicitly break compatibility with the previous format. For this purpose, the month and year of the schema version is part of the namespace.

Simultaneously, the version number of the schema he ^¬ should höht (typically mer to the next Hauptversionsnum-).

A single XML instance file can combine elements from different versions, that is, from different namespaces. This allows an importing application - which is not necessarily interested in the full file - to determine if it is affected by an incompatible change. Theoretically, this mechanism can be used individually for each element type. However, it is recommended to use it only on the granularity of possible root objects for export.

Example 1 :

In the following example, an incompatible change has occurred in the format for ObjectA, and therefore the namespace has been updated. However, the format for the ObjectB subobject is unchanged. Since ObjectB can also be used as a root object for a partial export, such a partial export is still compatible with the previous version. Therefore, it may be useful to leave the namespace for ObjectB (and all its subelements) unchanged. Full export:

<Document xmlns = "http://www.siemens.com/ automation / 05/02 / SimaticML / SW"

xmlns: vθl = "http: // www. siemens.com / automation / 04/12 / SimaticML / SW">

<ObjectA ID = "1"> (...)

<v01: ObjectB ID = "2" Name = "0bjectBl">

(...)

</ v01: ObjectB> </ ObjectA> </ Document>

Export of sub-tree ObjectB:

<ObjectB ID = "2" Name = "ObjectBl"> (...)

</ ObjectB></Document> If the parent objects of the relevant subtree are exported as shell objects (which is typically the case), these shell objects should also be placed in the original namespace. Otherwise, they could possible ^¬, an importing application does not recognize and would not be able to the relevant subtree (ObjectB in the example) to navigate

(...) </ ObjectB> </ ObjectA> </ Document>

Example 2:

In this example, the format for the ObjectB subobject is changed incompatible, but the rest of the XML format (for objects A, C, and so on) remains unchanged. It may be useful to use only an updated namespace for the subtree starting with ObjectB. This may be reasonable if it is likely that export files will not contain instances of ObjectB (if it is an optional element) or import clients that ObjectB does not care about. <Document xmlns = "http: // www. Siemens.com/automation / 04/12 / SimaticML / SW"

xmlns: vO2 = "http: // www. siemens.com/automation/05/02/SimaticML/SW">

(...)

<v02: ObjectB ID = "2" Name = "ObjectBl">

(...) </ v02: ObjectB>

(...)

</ ObjectC> </ ObjectA> </ Document>

This mechanism of combining namespaces should be used cautiously because by both him Instanzda ^¬ parties and the schema definitions increasingly complex and less readable. In most cases, an incompatible change affects the whole format so that all the elements should be the same siege to the new namespace verla ^¬.

Namespace hierarchy:

In the case verne Teter namespaces and schemas in a compatible ^¬ change does not break a nested namespace compatibility instance files that do not use that particular sub-system. Fig. 5 shows an example.

be o The namespace for the SW scheme is changed to patibility Kom ^¬ to break o The schema files which import the SW schema müs- adapted sen, but retain their namespace o Instance files that do not contain SW-relevant elements correspond to both the old and the new schema. o Applications that are not interested in SW-related elements must be adapted to a new version

In the case of a compatible change, only the version number of the XML format is increased (typically to the next minor version number), the name space remains unchanged. As defined by XML @ Profibus, the version number is part of the document header in each instance file as well as an XML schema file:

Instance:

<prim: DocumentInfo Version = "0.04"> <prim: Created Tool = "PCS7" User = "np" Timesamp = "2004-ll-09T08: 52: 37" />

</ prim: DocumentInfo>

(...) </ ObjectA>

</ Document> Scheme:

<xsd: schema targetName- pace = "http://www.siemens.com/automation/2004/12/SimaticML" xmlns: xsd = "http: //www.w3.org/ 2001 / XMLSchema"

xmlns: prim = "http: //www.profibus.com / Common / 2003 / ll / Primitives

II version = "0. 04">

<xsd: import names- pace = "http: //www.profibus.com / Common / 2003 / ll / Primitives" schemaLocation = "Common-Primitives-vl .0. xsd"/><xsd: element name = "Document" type = "prim: DocumentT"/> (...)

<xsd: schema>

Based on this version number, the importing application can determine how to perform the import.

o If the version number is smaller than the "current version" of the application, it could invoke a transformation or adapt the import routines to the old one

Data format to handle (it may be sufficient for in the

Import file missing attributes default values to deliver).

o If the version number is greater than or equal to the expected version, the application can rest assured that the file contains all the expected elements in it ^¬ waited format, but must come to be prepared to compatible enhancements (additional eg elements or attributes)

According to XML @ Profibus, every object in an XML export file can carry an optional version attribute. With this attribute, an exporting application can write the "project version number" of this object in the internal data representation.

This can be particularly significant when an application can handle multiple versions of objects in a project. (A discussion of versioning mechanisms within an application and its data representation, however, is beyond the scope of this document).

It must be noted that the XML format for instances of the same type in the same file must be the same (that is, the same schema), even if their data version is different. In other words, an XML Always export an export file that corresponds to a specific version, even if the internal data representation can contain objects of different versions.

Certain objects may additionally carry "version information", e.g., something like "firmware version" or a version number specified by the user. From the standpoint of export / import and XML format, such an attribute is treated just like any other object attribute (such as a comment field) and is stored in the object's "settings" feature.

The following instance fragment shows examples of all types of version information:

<Document xmlns = "http: // www. Siemens.com / automation / 2004/12 / SimaticML"

xmlns: prim = "http: //www.profibus.com / Common / 2003 / ll / Primitives">

<prim: DocumentInfo Version = "0.04">

<prim: Created Tool = "notepad" User = "np3304" "/> </ prim: DocumentInfo> <ObjectA ID =" 1 "Version =" 6.1 "> <ObjectB ID =" 2 "Name =" ObjectBl ">

</ ObjectB> </ ObjectA> </ Document>

An export file may only contain parts of a project. That is why it is possible that a relation an exported object to an object that is not part of the export.

The following diagram shows an example; the relationship between "TH 2" and "Cfc 1" can only be exported as an "external reference" in both Export 1 and Export 2. It is necessary for an importing application to initiate the re ^¬ lation after the import of Exportl and Export2 can generate new, whereby the order of the partial imports does not have to be relevant.

When importing an external reference, the importing application must be able to correctly resolve the reference, especially if

o the referenced object already exists (for example, on the basis of a previous import ^¬) or

o the referenced object is completely generated via a subsequent (partial) import.

To identify the target object, the same mechanisms should be available as for any other imported object. To this end, the target object as "envelope object" is exported, that is, it is written as a "placeholder" without its contents (attitudes, child objects and wider at ^¬ relations) in the export file. Such a shell object maintains its full name hierarchy in a "path" attribute in addition to the local name (so that the importing application has access to the full name hierarchy).

The "external" relation can now just like an internal Real ^¬ tion are written in XML, because both the source and the target object is a representation in the XML file be ^¬ sit. <ObjectA ID = "1">

<RelatesTo Target = "# 4" /> <ObjectB Name = "ObjectBl" ID = "4"

Path = "ObjectA" Shel- 10bject = "true">

<prim: AppId AppName = "SIMATIC" Value = "000200lEl0000002" /> <prim: AppId AppName = "OtherTool"

Value = "0815" />

</ ObjectB> </ RelatesTo> </ Relations> </ ObjectC>

</ ObjectA>

If multiple instances in a file are related to the same external instance, each relation writes its own shell object. Have these shell objects its own unique ID (to ensure that the ID within ei ^¬ ner file is unique), but refer to the same target object (ie, point to the same name, path and the same Appld 's).

<prim: AppId AppName = "SIMATIC" Value = "DT000100lAl0000624" /> <Settings /> <Relations> <PlantHierarchy Target = "# 12">

<PlantHierarchyFolder Name = "GF34_Four" ID = "12"

Path = "Rubi_AS2_Prj / Ruby / MB3101" Shellθbject = "true">

<prim: AppId AppName = "SIMATIC"

Value = "OD01101071: 00000029: 00000000: 00000000" />

<prim: AppId AppName = "OtherTool" Value = "0816" /> </ PlantHierarchyFolder>

</ PlantHierarchy> </ Relations> </ CFC>

<prim: AppId AppName = "SIMATIC" Value = "DT000100lAl0000625" /> <Settings /> <Relations> <PlantHierarchy Target = "# 13">

<PlantHierarchyFolder Name = "GF34_Four" ID = "13"

Path = "Rubi_AS2_Prj / Ruby / MB3101" Shellθbject = "true">

<prim: AppId AppName = "SIMATIC" Value = "OD01101071: 00000029: 00000000: 0000000 />

<prim: AppId AppName = "OtherTool" Value = "0816" /> </ PlantHierarchyFolder> </ PlantHierarchy> </ Relations>

</ CFC> </ Charts> </ DeviceItem> </ Device>

In summary, the invention thus relates to a method and a system for the synchronization of data between applications, in which the data is at least partially exchanged between the applications, the exchanged data being synchronized with data present in the respective application. To simplify the synchronization, it is proposed that an incomplete tag be mapped to the data.

Claims

claims

1. A method for synchronizing data between applications, wherein the data is at least partially exchanged between the applications, wherein the exchanged data is synchronized with existing data in the respective application, wherein the data is assigned an identifier for an incompleteness.

2. The method of claim 1, wherein the data is at least partially transmitted in the form of Hüllobjekten, wherein the shell objects have attributes for identification, wherein the shell objects sen only part of a complete object aufwei ^¬.

The method of claim 1 or 2, wherein the data is described in an extensible tagging language.

4. The method according to any one of the preceding claims, wherein when importing data, the type of data changes are detected by means of a version identifier and depending on the version identifier, a generic reaction takes place.

5. The method according to any one of the preceding claims, wherein in the case of already synchronized data at later synchronizations only the changes are exchanged.

6. The method according to any one of the preceding claims, wherein when exporting data, a root object is selected, from which all objects are exported.

7. The method according to any one of the preceding claims, wherein filter settings are defined and, depending on the filter settings, a selection of the data to be exchanged.

8. A system for synchronization of data between applications, wherein data nen at least partially between the Applikatio ^¬ are interchangeable, wherein synchronization means for Syn ^¬ chronisation of the data exchanged with existing in the respective application data, said data an identifier for an incompleteness assignable is.

9. System according to claim 8, characterized in that envelope objects are provided, the data being transferable at least partially in the form of the envelope objects, the envelope objects having attributes for identification, the envelope objects having only parts of a complete object.

10. System according to claim 8 or 9, characterized in that the data in an extensible labeling language can be described.

11. The system of claim 8, wherein version identifiers are provided for characterizing data changes, wherein the version identifiers are provided for triggering a generic reaction upon import of the data.

12. System according to one of claims 8 to 11, characterized in that there are provided root objects, which in the export of

Data indicating the point from which all objects exported ^¬ to.

13. The system according to claim 8, wherein filter settings are provided and, depending on the filter settings, a selection of the data to be exchanged takes place.