CIM Issues » CIM Joint Issues

To inform the broader discussion across the working groups I [Todd] am adding how WG13 has approached this to date as well as prior discussions/decisions/proposals on the WG13 side of things:

Prior Discussion/Decisions:

Oslo 14 June 2023
Considering that we expect to have models that include distribution and transmission grids, the recommendation is to remove multipliers in the profiles. It will be a breaking change.

There are 3 ways how to implement this:

1) delete .multiplier from the canonical UML. This implies that the multiplier is 1. This needs discussion with other TFs
2) fix the .multiplier to "none" in the canonical UML. This means that the multiplier is 1. This needs discussion with other TFs
3) fix the .multiplier to "none" in the profile, which means we need to pay attention when creating profiles so that all profiles are consistent. The advantage of this option is that there could be different approaches between different TFs

Preferred option is option 1, but due to 61850 harmonization perhaps option 2 is better.
TF13 may implement option 3 first.

This will not apply to hours, minutes, seconds

An email will need to be sent to WG13 to check the support for this agreement.

TF13, call 12-Jul-2023:
- Agreed to apply option 3 for all TF13 profiles for CIM18
- Before closing the issue make sure there is a joint issue to inform other TFs

WG13 proposal currently used "internally":
Simplistic solution is to align on one mutiplier (say 1) and only exchange meter, using the decimal in the actual exchange to express the value properly. This puts more stress on a user interface presenting the data differently than how it is exchanged.

Assign to Units of Measure Subgroup

Release Notes from WG13's recent updates

We updated all profiles to have "none" as multiplier in the CIMDatatype. This means that values are exchanged in their base SI unit and will need to use engineering notation, e.g. SwPowerFlow.p in SV profile was defined as MW and 100.6 MW are exchanged in xml as <SvPowerFlow.p>100.6<SvPowerFlow.p>. After the change in the profiles the instance data is <SvPowerFlow.p> 100.6E6 <SvPowerFlow.p>

The following changes were applied:
- in EQ profile - 452 and 600: ActivePower, ActivePowerPerCurrentFlow, ActivePowerPerFrequency, ApparentPower, Length, ReactivePower
, RealEnergy, Voltage
- in SC profile - 452 and 600: ActivePower, Length, Voltage
- in SSH - 456 and 600: ActivePower, ApparentPower, ReactivePower, RealEnergy, Voltage
- in SV profile 0 456 and 600: ActivePower, ReactivePower, Voltage

IEC 61970-457 Ed2 is not updated as it is in FDIS. Most probably an amendment will need to be launched after the approval of the FDIS

Reviewed again during TF13 Weekly call 02-Apr-2025. What follows has been copied from the MoM for that meeting:

Agenda item #1: Revisit updates for the dataype/units in prep for Nanjing [Svein]

• It would be good to know what background information is needed for Nanjing - and also if we are going the right way.
• You can find the same information here: Define Unit Datatype · Issue #24 · Sveino/CIM4Diagram [github.com]
• The following is proposed for defining Unit datatype in CIM.

The units are currently defined as:

CIM Unit datatype include:

• multiplier - sometime are they fixed. Most time are they not defined (open)
• Unit - always fixed
• value

In the CIM/XML (and the plan for JSON-LD) are only the value exchanged in the instance file. The current way is semantic unsound and SHALL be fixed. The question is how?

The proposal is that we make all multipler fixed in the RDF-based exchanges. The default would be that multiplier becomes none - meaning that it will use only base unit, e.g. W.

To be backwards compatible we have to create a datatype that reflect all the CIM Unit datatypes that difference from none.

We current have:

We would need to create one that represents Mega Watt - follow the naming standard for KiloActivePower, it would be MegaActivePower alternative naming could be: [M]ActivePower or ActivePower[M] - not sure if [] are good to use.

Now the multiplier is defined by the full profile, but we shall allow for having different unit multiplier on each individual attribute.

In addition, we would like to align CIM Unit Datatype with QUDT [qudt.org]. There is the option of replace the CIM Unit Datatype with QUDT. However, then this change would affect our XSD based profiles as well. The locking of multipler and the harmonisation will with this proposal only affect the RDF based profiles.

Harmonisation will also make it backwards compatible. The long-term goal could be to fully rely on QUDT.

The proposal is that MegaActivePower would be described with the following RDFS (in TTL format – “turtle”):

GeneratingUnit.nominalP RDFS example:

cim:UnitSymbol.W a cim:UnitSymbol ;
    rdfs:label "W" ;
    rdfs:comment "Real power in watts (J/s). Electrical power may have real and reactive components. The real portion of electrical power (I²R or VIcos(phi)), is expressed in Watts. See also apparent power and reactive power."@en ;
    cims:stereotype cims:enumerationValue ;
    skos:exactMatch unit:W .

cim:MegaActivePower skos:exactMatch quantitykind:ActivePower .
    cim:GeneratingUnit.nominalP a owl:DatatypeProperty, owl:FunctionalProperty ;
    rdfs:label "nominalP" ;
    rdfs:comment """The nominal power of the generating unit.  Used to give precise meaning to percentage based attributes such as the governor speed change droop (governorSCD attribute).
The attribute shall be a positive value equal to or less than RotatingMachine.ratedS."""@en ;
    cim:unitMultiplier cim:UnitMultiplier.M ;
    cim:unitSymbol cim:UnitSymbol.W ;
    cims:multiplicity cims:M:0..1 ;
    cims:stereotype uml:attribute ;
    qudt:hasQuantityKind cim:MegaActivePower ;
    qudt:hasUnit unit:MegaW ;
    rdfs:domain cim:GeneratingUnit ;
    rdfs:range xsd:float .

DECISIONS
From today’s review:

• We want to keep the old one (i.e. ActivePower) and the attributes.
• But we will be introducing qudt so we will have a way to “transform’ to the new.