[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] Comment on "scaled units" in "Unit of Measure" Change Request
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. Regards, -Franc -----Oorspronkelijk bericht----- Van: email@example.com [mailto:firstname.lastname@example.org] Namens Mr. Brendan McMahon Verzonden: dinsdag 1 november 2016 17:39 Aan: email@example.com 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.