An object and its related objects in the data source typically imply many objects and related objects in the CIM. Therefore, certain mapping operators may return many values (a vector of values) instead of a single value. Usually these operators will result in a multiplicity of the resulting CIM construct to support each of the values in the vector. Note that if any of the property mappings of a class generate a multiplicity, all properties in the class will respect that multiplicity.

Vector value operators include Characters, NormalOpens, and the Group operator described below. The ”refactor” attribute helps to define the related objects and relationships resulting from multiplicities in the CIM output. The behavior of the refactor attribute depends on the context of its use.

Group Operator

The Group operator simplifies the mapping of related objects in the CIM.

For example, a Transformer feature in the ArcFM GIS implies a PowerTransformer object in the CIM. Each PowerTransformer has two related TransformerWinding objects, and each TransformerWinding object has a name property derived from the value of the Transformer’s ID. The name of the high voltage winding is the ID followed by “:primary”, and the name of the low voltage winding is the ID followed by “:secondary”.

Below, the name property is defined as the concatenation of the FacilityID field with a constant value. Because the definition specifies a group of two constant values, the export generates two name properties and refactors the TransformerWinding properties to generate two TransformerWinding objects related to the PowerTransformer.

  <cimClass name="cim:TransformerWinding" inherits="cim:ConductingEquipment" forward="false">
 
   <cimProperty name="cim:TransformerWinding.windingType">
    <Group>
     <constant value="primary" />
     <constant value="secondary" />
    </Group>
   </cimProperty>

Refactor override of relationship duplication

Continuing this example, the BaseVoltage class is a related class of TransformerWinding. The Group operator shown above has already caused multiplicity of resulting TransformerWinding objects. Because the BaseVoltage mapping also has the Group operator, the default behavior is to create two BaseVoltage objects and relate both of them to each TransformerWinding object. However, the refactor = true directive overrides this behavior and causes only one of the BaseVoltage objects to be related to each TransformerWinding object.

<cimClass name="cim:TransformerWinding" inherits="cim:ConductingEquipment" forward="false">
   <cimClass name="cim:BaseVoltage" relationshipName="cim:ConductingEquipment.BaseVoltage" refactor="true">
 
    <cimProperty name="cim:IdentifiedObject.mRID">
     <Group>
      <constant value="BV" />
      <constant value="BV" />
     </Group>
     <Group>
      <Map mapRef="Voltage">
       <CheckNull default="160">
        <sourceField name="Transformer.OperatingVoltage" useDomain="false"/>
       </CheckNull>
      </Map>
      <Map mapRef="Voltage">
       <sourceField name="Transformer.LowSideVoltage" useDomain="false"/>
      </Map>
     </Group>
    </cimProperty>

Refactor override of related object duplication

In this example, the WindingTest class is also a related class to TransformerWinding. Again the Group operator has already caused multiplicity of resulting TransformerWinding objects. Because the WindingTest mapping does not have the Group operator, the default behavior is to create two WindingTest objects and relate one of them to each TransformerWinding object. However, the refactor = true directive overrides this behavior and causes only one WindingTest object to be created and related to both TransformerWinding objects.

<cimClass name="cim:WindingTest" forward="false" relationshipName="cim:From_TransformerWinding,cim:To_TransformerWinding" refactor="true">
 
    <cimProperty name="cim:IdentifiedObject.mRID">
     <sourceField name="Transformer.NAUNIQUEID" />
     <sourceField name="PhaseDesignation" />
     <constant value="WindingTest" />
    </cimProperty>