The paragraph "NOTE A value that is representing a percentage can use the unit 1 (dimensionless) and a multiplier -2 (centi)." is confusing because of the word "can".
Proposal
Discuss somewhere that a Data Object name containing "pct" shall be of type FLOAT32 and have an engineering value in the range 0.0 to 1.0 to represent values between 0 and 100 percent.
Prior to writing any value in IEC61850, the "unit.multiplier" must be consulted to determine the appropriate value to be written across the underlying protocol (note that unit.multiplier is optional in Unit).
Might also need to clarify that multiplier value cannot change without a change of the configuration version. This allows a client to cache the value of multiplier without continuously reading the multiplier associated with each access of the data object value. This also implies that each client (including GOOSE subscribers) needs to be aware of the associated multiplier.
Might also need to declare that units.multiplier should never be written because this means that any cached values of the multiplier would become stale.
Discussion
Created
Status
I disagree with comment beginning "Proposed editorial change":
1. 61850 DOPct either requires or prohibits a corresponding multiplier. It cannot be both.
The commenter seems to prefer a multiplier of "-2" to be used whereas another commenter prefers a multiplier of "0" to be used (or to prohibit the attribute DOPct.Units.multiplier).
We must choose 1 and only 1 solution. The commenter explains that the default Units.multiplier would be "-2" but only if the DOName contains "Pct" which I think is a bad idea.
2. Prohibiting ability to write to an object merely because the name contains "Pct" is a bad idea and would result in the need to "invent" a new (vendor-specific) DO in order to allow configuration
13 Dec 23
Discussion (red)
I hope that I am re-iterating what Thierry has stated below, but here in my words:
We need to clearly discriminate between the actual value stored (for a computer to be used for processing) and display units for showing it to a human user.
120% _IS_ 1.2, so the stored value (with which we want to do calculations) must be 1.2.
Or would you add a "check code" that always looks up the unit first and finds: "oh, it's a percentage, so let's divide the value by 100 to really use it"?
Whether we store the value as 1.2E0 or 120E-2 should not matter, as it is the same, namely 1.2.
I am not a fan of Excel, but it does it right in this regard: If you enter 120% (automatically formatted as "percentage") and change the number format to "Number", it will display 1.2. In calculations, the value will always be 1.2.
12 Dec 23
Discussion (red)
Proposed editorial changes to avoid confusions:
Extend note in clause 8.8 with:
A value DOPct.stVal = 120, qualified with its DOPct.units={dimesionless, -2} configuration attribute corresponds to a value of 1.2.
A DOPct without a unit attribute is not explicitly qualified, but according to IEC 61850-1-2 it is representing a percentage value. A value 120 is to be understood as 120%, i.e a ratio of 1.2.
Add clarification to the definition of the component Unit - clause 6.6 -
It is recommended that the values of the attributes of this type are read only.
12 Dec 23
Discussion (red)
The note explains the value of (SIUnit, multiplier) to expose percentage values = {unit = dimensionless, multiplier = -2}
The note can not use the word "shall" per IEC directive.
Per IEC 61850-1-2 Clause 6.1.6.4.3 , it is recommended to use the abbreviation "Pct" in the DOName when percentage values are modelled.
As value Pct.stVal = 120 is qualified with its Pct.units configuration attribute.
120 qualified with units={dimesionless, -2} corresponds to a value of 1.2
120 without units is not qualified, and it is not clear what it is standing for: 1.2, 120? It is nevertheless not proper to Pct objects.
Online changes of configuration attributes in general are not recommended; especially of the attribute "unit" as it modifies the interpretation of the object value for all sinks.
Note: DA valRef indicates the change of a configuration attribute.
A clarification to the definition of the component Unit - clause 6.6 - could be added to mention that the change of value "Unit" is not recommended.
15 Sep 23
Accepted
But by naming the attribute "Pct", it is stated that the ratio is expressed in % (per cent = per hundred).
=> There is no more room for "unit and multiplier".
I see no sense in milli-percent or kilo-percent.
19 Jul 23
Accepted
Are you saying that you expect to read "120" when the multiplier is "0"?
If true the I agree that this is very bad that we have an "wrong by 2 orders of magnitude" semantic problem
19 Jul 23
Accepted
This has much to do with our often applied bad habit to name attributes not after the QUANTITY it represents, but after the UNIT. This is semantically not entirely correct, although common (sadly).
In this case, the attribute is holding a ratio. The unit in which the ratio is expressed should come in second place. Then, the "unit and multiplier" thing could come into play.
But by naming the attribute "Pct", it is stated that the ratio is expressed in % (per cent = per hundred). There is no more room for "unit and multiplier".
Thus, I expect to read 120 in a "Pct" attribute when the ratio is actually 1.2 .
We could open a similar discussion where we have attributes like "Tmms" (time in millisecond), where we should have named it just "some time" and using the SI unit "second" (and using the multiplier 10E-3 when the value is in ms).
19 Jul 23
Accepted
It also must be made clear that "percentage" actually means "to express ratio change as unitless value. For example, if a value changes from 100 to 120 then that change is 1.20 and NOT "120.0 percent". To transfer data across the wire, it is customary (but not recommended nor required) to use "centi" for unit.multiplier (this custom reflects legacy systems where floating-point values cannot be transferred by the protocol.
The change of DA valRef does not help unless it becomes mandatory to observe this value prior to using any quantity (I know of no systems that read the value of every unit.multiplier before reading the associated instMag value).
The clarification in clause 6.6 should be "any change to unit.multiplier shall be avoided unless it can be guaranteed that every sink will be able to obtain and use the new value of unit.multiplier (this should effectively prohibit any change from the value in the ICD even by an ICT).
Also consider making it mandatory to expose DA units (in both SCL Val element as well as online data model) if the underlying value of units.multiplier is not zero.
18 Jul 23
Accepted
The note explains the value of (SIUnit, multiplier) to expose percentage values.
The note can not use the word "shall" per IEC directive.
Per IEC 61850-1-2 Clause 6.1.6.4.3 , it is recommended to use the abbreviation "Pct" in the DOName when percentage values are modelled.
Online changes of configuration attributes in general are not recommended; especially of the attribute "unit" as it modifies the interpretation of the object value for all sinks.
Note: DA valRef indicates the change of a configuration attribute.
A clarification to the definition of the component Unit - clause 6.6 - could be added to mention that the change of value "Unit" is not recommended.