Subject: AW: [ocpp] Comment on "scaled units" in "Unit of Measure" Change Request
Hello Franc, Hello Brendan,
I am not an expert on the energy market, but I am asking me why shout OCPP reinvent thinks. In energy market the IEC 62056 is used for data exchange. I propose to use the same structure and make a reference to the IEC Standard:
scaler_unit Provides information on the unit and the scaler of the value.
scal_unit_type ::= structure
This is the exponent (to the base of 10) of the multiplication factor.
REMARK If the value is not numerical, then the scaler shall be set to 0.
Enumeration defining the physical unit; for details see Table 3 below.
For details on units see Page 33:
I fully agree with Brendan's comments. The k-prefix is not there to save bytes, but is there because units like kW and kWh are the standard in this domain.
Verzonden: dinsdag 1 november 2016 17:39
Onderwerp: [ocpp] Comment on "scaled units" in "Unit of Measure" Change Request
Robert de Leeuw noted that the question was asked at the recent F2F meeting: "Why do we need the 'k' versions of some units in OCPP?" (e.g. kWh, kW, kPa)
The following is a commentary on the historical basis for this decision, based on my involvement in the development of OCPP 1.5.
The main reason for k prefix is that Wh (watt * hours) is an unnatural unit in electrical and electronic engineering that is rarely, if ever, used in practice: if dealing at that scale of energy, it is normal to use the (smaller) SI unit (Joule = Watt * second) or the larger kWh, that (although non-SI) is the de-facto universal standard for electrical energy billing.
Similarly, in electrical engineering (as distinct from low-power electronic engineering), VA (Volt-Amps) and VAr (Volt-Amps reactive) are rarely used in comparison to kVA and kVAr.
This is basically the same argument that is used for other SI units that happen to be unnaturally small for everyday or engineering purposes, such as the Pascal, the SI derived unit of pressure that is so small compared with common pressures such as atmospheric pressure that it is almost always encountered as hPa,kPa, or MPa (hectopascals, kilopascals, megapascals).
My understanding/assumption is that since the only metered/measured quantity that the earliest version of OCPP could communicate was metered consumed electrical energy that was measured by digital energy meters that had a resolution typically going down to thousandths of the industry standard billing unit (kWh), and that it seemed like a good idea at the time to send in the meter readings in (StartTransaction, StopTransaction, and MeterValues) as an integer value in Watt-hours, thereby avoiding all the possible complications of decimal fraction representation, which varies by culture ( , versus . separator).
Since it is not reasonable to force all values of quantities that are meterable/measurable in charge points to be non-fractional without resorting to further unnatural units (e.g. using milliamps instead of Amps just to get practical tenth-of-an-amp resolution), OCPP has since version 1.5 allowed decimal fractional numeric values, and thereby implicitly adopted XML Schema decimal data type canonical representation of decimal fractions.
In practice, it is often the case that both base and k versions of the same quantity could be in use in parallel for different things in a charge point at same time, and may be reportable as MeterValues and/or through the device model (e.g. rated DC power output of a (battery) backup power supply, or ancillary (LED) lighting might naturally be in Watts, but maximum output power from a charging socket/connector would naturally be in kilowatts; measured electrical resistance of a safety earth/ground path would be in ohms, but safety insulation resistance checks would naturally be reported in megaohms).
To my knowledge, the introduction of unit multipliers such as k was never about saving a couple of bytes on the wire: it was to reflect what would be the natural units in which certain quantities would be measured and processed by industry standard electrical/electronic equipment.