AutomationML Version Management

Introduction

Sometimes engineering tools repeatedly export project data as AutomationML data without generating change and version information. This makes it difficult to detect changes when importing this data repeatedly. With the inpro AutomationML Version Management PlugIn, change and version information can be subsequently added based on a comparison of the last exported data with a previous version.

Requirements

There must be two AutomationML files from the same source. The identity of the sources is checked against the source document information in the AutomationML file. The persistence of the object IDs must also be ensured. If no ID persistence exists, an object-oriented comparison cannot be performed. The previous version of the last exported AutomationML document must be loaded into the AutomationML Editor. The newer version must be loaded in the version control PlugIn.

The Method

The method for generating change and version information consists of the following three steps.

Identification of equivalent objects

The object comparison is based on the identification of equivalent objects. Equivalent objects are characterized in that they fulfill the uniqueness criteria of AutomationML for identification. In detail, these are:

Identify InternalElement- and ExternalInterface equivalences based on matching object IDs.
Identify library- class- and type equivalences by matching CAEX paths.
Identify attribute equivalences using matching attribute paths (attributes are identified relative to the owning object, so that a name comparison is sufficient in this case).
Identify InternalLink equivalences based on matching object IDs of the linked ExternalInterface objects.
Identify Mapping equivalences based on matching names and IDs of the referenced Attributes and ExternalInterface objects.

Comparison of equivalent objects

The comparison is not text-based, but object-oriented and is based on the identified equivalences. The properties of the equivalent objects and the set of subordinate objects are compared. The property comparison is called "definition difference" and the comparison of the set of sub-objects is called "set difference". The set comparison identifies added objects, deleted objects and moved objects. If a difference is found during the set comparison, the higher-level object is marked as changed. The ordered sequence of the objects is irrelevant for the set comparison. A third category - the "value difference" - is defined for the attribute comparison. The value difference comprises the attribute data type, the attribute value, the unit and the default value. Since the comparison is not text-based, not all differences in the AutomationML files are recognized, e.g. changes in assigned additional information are not recognized.

Change- and version information generation

If differences are found, change and version information can be inserted into the newer version of both documents. To determine the value of the ChangeMode attribute of the changed objects, proceed as described below. This is defined in the CAEX standard::

The ChangeMode shall have the following value range: state, create, delete and change.
The value “state” shall be used for objects that have not changed since previous data
exchange. The value “create” shall be used for new objects that have been created.
The value “delete” shall be used if an object is to be deleted. The object is therefore
not physically removed out of the CAEX file but marked as to be deleted. The value
“change” shall be used if the object has changed.

the value state is assigned to all identified equivalent objects that have not been changed. Any existing ChangeMode values from previous version comparisons are overwritten. The assignment is limited to the identified equivalences and is not transferred to every unchanged CAEX element.
the value create is assigned to all objects that have been identified as additional elements in a set comparison. The assignment is limited to the identified set differences and is not transferred to each new CAEX element (for example, a new description).
the value delete is assigned to all objects that have been marked as deleted in a set difference. Since these objects are no longer contained in the newer version of the document, they must be reinserted back to their original position in order to set the change status. When a deleted object is inserted from the previous version, it only retains its XML attributes Name, ID and ChangeMode. All other attributes and sub elements are no longer included.
the value change is assigned to all identified equivalent objects for which a change has been determined by a set difference, a definition difference or a value difference.

Please note that moved objects are not marked with a ChangeMode if no difference has been detected for them. Only the respective parents are marked as changed.

In addition, differences in classes and attribute types can be made explicit by inserting Revision information.
For the generation and assignment of Revision information, the following provisions apply:

A detected defintion difference or set difference of a SystemUnitClass, RoleClass, InterfaceClass or AttributeType is handled as recommended:

According to IEC 62424:2015, A.2.2.7, changes of a source class should lead
to a new version of the class with another name. Within the new class, the
full path of the old version of the class should be stored in the CAEX tag
“OldVersion”. Additionally, within the old class, the path to the new
version should be stored in the CAEX tag “NewVersion”.

In this implementation, if a class difference is detected, the corresponding object from the previous document version is inserted back into the newer version. The re-inserted class only retains the properties that are required for identification. It is linked to the changed class as an old version of a revision.

There are two alternatives for inserting the two revised objects in the object hierarchy, which enhance the recommended procedure:

In the first variant, the original object is inserted back in its original position. The changed object is moved. It is inserted as the child of the re-inserted original object. References to the new version (as defined in AutomationML) must be redirected explicitly.
In the second variant, the original object is inserted again as a new child of the changed object. References do not have to be changed. Class instances automatically reference the changed version of the class.

Both variants will reference each other using created Revision objects as recommended.

Background

The method for generating change and version information is part of a sophisticated method for synthesizing consistent AutomationML models from individual model fragments from different sources and in different data formats. This method set -named as the AutomationML Merge Method- was developed in cooperation between inpro and its shareholder companies, primarily with the support of Daimler AG. Please contact inpro to get more information about the AutomationML Merge method.