CIM Difference Model

Another manner of reducing the volume and complexity of the CIM RDF XML exchanges is to utilize the CIM Difference Model XML format that describes the changes between two CIM RDF XML files. This allows incremental exchanges of CIM data so that the full network model does not need to be exchanged.

The Difference Model format defines four statement sets:

• Reverse Differences
• Forward Differences
• Pre-Conditions
• Post-Conditions

(In reality the Pre and Post conditions are rarely used, and interoperability tests focus on the Forward and Reverse differences). A difference model can add new objects, remove existing objects or update objects by changing, adding or removing attributes. The Reverse Differences define the removals while Forward Differences define the additions. A change (update) is defined as a pair of Forward and Reverse differences on an existing object.

The CIM DM XML format is RDF-based and uses a similar format to that of the full model CIM RDF XML described in the previous section.

Difference Model RDF XML Format

As with the full CIM RDF XML data, the Difference Model format begins with the namespace declarations under an RDF node:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:cim="http://iec.ch/TC57/2009/CIM-schema-cim14#"
  xmlns:dm="http://iec.ch/2002/schema/CIM_difference_model#">

In addition to the CIM and RDF namespaces that were present in the full model, the Difference Model namespace is included. This defines the additional elements that are used to contain the forward and reverse statements:

<dm:DifferenceModel>
  <dm:reverseDifferences parseType="Statements">
       ...
    </dm:reverseDifferences>
    <dm:forwardDifferences parseType="Statements">
       ...
    </dm:forwardDifferences>
</dm:DifferenceModel>

Inside these reverseDifferences and forwardDifferences nodes are placed the data elements that are to be added, removed or updated.

Addition

To add a CIM object the data structure is identical to that of the full CIM RDF XML format. The elements are placed with the forwardDifferences node and take the format shown below:

<dm:forwardDifferences parseType="Statements">
    <cim:ACLineSegment rdf:ID="_lang0182743">
    <cim:IdentifiedObject.name>A New Line</cim:IdentifiedObject.name>
    </cim:ACLineSegment>
</dm:forwardDifferences>

In the example above a new ACLineSegment has been added. The format and structure is identical to that of an ACLineSegment in a full RDF XML file, with the rdf:ID providing the unique identifier for the object and all attributes and associations included inline.

Deletion

The deletion of an existing object uses a very similar format, albeit under the reverseDifferences rather than the forwardDifferences node. For a deletion there are two methods for defining the node to be accomplished. The first is a shorthand syntax that defines only the object’s ID and none of the object’s attributes or associations. For example, to delete the object that was added in the example above the shorthand syntax takes the form:

<dm:reverseDifferences parseType="Statements">
    <cim:ACLineSegment rdf:ID="_lang0182743"/>
</dm:reverseDifferences>
The other approach is a more verbose syntax that includes all of the object’s attributes and associations:
<dm:reverseDifferences parseType="Statements">
    <cim:ACLineSegment rdf:ID="_lang0182743">
    <cim:IdentifiedObject.name>A New Line</cim:IdentifiedObject.name>
    </cim:ACLineSegment>
</dm:reverseDifferences>

The benefit of the shorthand syntax is that when removing a large number of objects it reduces the size of the incremental file and omits additional data that is, essentially, superfluous when the object is to be deleted anyway.

However, by using the longhand syntax, a difference file can be applied in reverse by changing all forwardDifferences to reverseDifferences and vice-versa. This allows a system to undo a difference file using only the data contained within the difference file. By storing all changes as verbose, longhand syntax incremental difference model files previous systems states can be restored without requiring additional state information to be stored separately. 

The longhand syntax also has the additional benefit of allowing a system to perform additional data verification by ensuring that the object’s attributes and associations match those in the difference model. If a mismatch is identified this will alert the user that their system may be out of synchronization with whatever system generated the incremental.³⁶

Updates

To change an existing object the syntax is slightly different. In this situation the RDF Description notation is used with the rdf:about attribute replacing rdf:ID as the identifier. This is used to indicate that the node is referencing a pre-existing object within the full model, rather than being the creation of a new object.

So, to remove an attribute or an association on an existing model, a Description element is added with the syntax:

<rdf:Description rdf:about="#_pqrs34567890">
  ...
</rdf:Description>
This refers to an existing object of ID _pqrs34567890 that already exists within the system. Inside these Description tags are placed the attributes or associations that have to be added or removed on this object. For example, to remove the association from a Terminal with the ID _pqrs34567890 to a piece of ConductingEquipment with the ID _abcdef0123456789 the resulting DM XML is:
<dm:reverseDifferences parseType="Statements">
    <rdf:Description rdf:about="#_pqrs34567890">
       <cim:Terminal.ConductingEquipment rdf:resource="#_abcdef0123456789"/>
    </rdf:Description>
</dm:reverseDifferences>

The syntax inside the Description tags is identical to that of the full model RDF XML, the difference here is that we are indicating that his association is to be removed. The corresponding forwardDifferences statement is an identical format, but by being within the forwardDifferences element it is interpreted as an addition rather than a removal from the object:

<dm:forwardDifferences parseType="Statements">
    <rdf:Description rdf:about="#_pqrs34567890">
       <cim:Terminal.ConductingEquipment rdf:resource="#_lang0182743"/>
    </rdf:Description>
</dm:forwardDifferences>

The combination of a forward and reverse statement for the object therefore results in an update, changing the ConductingEquipment association in this case from _abcdef0123456789 to _lang0182743 (the ID of the ACLineSegment that was added in the first example). Combining the addition and the updates together into a single DM XML file that adds a new ACLineSegment and changes an existing Terminal to associate with this new line we get:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
    xmlns:cim="http://iec.ch/TC57/2009/CIM-schema-cim14#" 
    xmlns:dm="http://iec.ch/2002/schema/CIM_difference_model#">
    <dm:DifferenceModel>
       <dm:reverseDifferences parseType="Statements">
           <rdf:Description rdf:about="#_pqrs34567890">
              <cim:Terminal.ConductingEquipment rdf:resource="#_abcdef0123456789"/>
           </rdf:Description>
       </dm:reverseDifferences>
       <dm:forwardDifferences parseType="Statements">
           <cim:ACLineSegment rdf:ID="_lang0182743">
              <cim:IdentifiedObject.name>A New Line </cim:IdentifiedObject.name>
           </cim:ACLineSegment>
           <rdf:Description rdf:about="#_pqrs34567890">
              <cim:Terminal.ConductingEquipment rdf:resource="#_lang0182743"/>
           </rdf:Description>
       </dm:forwardDifferences>
  </dm:DifferenceModel>
</rdf:RDF>

Footnotes

³⁶ This is not necessarily an unexpected situation. There are several scenarios where a difference file may be applied to a base model that doesn’t exactly match that of the sending system (for example, where a difference file represents a potential network extension, and the user wants to apply it to a different planning model than the one it was created against). In this situation the user (or system) may choose to apply the differences even where there is an identified source/target mismatch.