CIM Issues #6584

Handling unit multiplier needs joint WG concensus on approach

Added by Todd Viegut 4 months ago. Updated 4 months ago.

Solution Version:
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
WG13, WG14, WG16, WG21
Todd Viegut
Origination Date:
Origination ID:
Originally Assigned To:


Handling unit multiplier

WG13 needed a policy with respect to how unit multpliers are to be exchanged. For example CDPSM has need for Length to be in km for line length, but in meters for conductor spacing. IEC 61970-552 does not provide for the exchange of unit symbols or unit multpliers. Therefore, manual documentation is required in profiles. Possibly different model parts assembled together may have different unit multipliers such as combining a distribution and transmission model together. With current work in progress for the upcoming IEC 61970-301 Ed 8.0 (i.e. CIM18) and the accompanying editions of IEC 61970-452, IEC 61970-456, etc. there is the planned introduction of the new unbalanced profiles which will require concensus on an approach.

WG13 has issue: for addressing this cross-cutting concern within the context of WG13. This CIM Joint issue is to raise visibility across WG14, WG16, WG21 so that we have a common understanding/policy for how we will address this.


Updated by Todd Viegut 4 months ago

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


Updated by Todd Viegut 4 months ago

  • Subject changed from Handling unit multiplier needs to Handling unit multiplier needs joint WG concensus on approach

Also available in: Atom PDF