[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
Such groups as the European Federation of Energy Traders (EFET) might not agree as to what standards are used for energy markets… The FIX Protocol OTC Energy Committee is another place to observe developing rather than legacy market models for transactive energy.
If we look to the OCPP Charter, we should look beyond mere centrally managed sales of power. The charter calls out the entire transactive energy market, including DR aggregators. Although not specifically called
out, this suggests that OCPP should be able to support charging aggregators participating in any ancillary services markets. As the central hub-and-spoke model evolves to embrace ever more distributed energy sources, the ability of charge points to respond
to local markets for ancillary services will become more critical and valuable.
The OpenADR markets seem to be coalescing around OpenADR, a profile of OASIS Energy Interoperation, which addresses this information using the information model of EMIX (Energy Market Information Exchange) (http://docs.oasis-open.org/emix/emix/v1.0/cs02/emix-v1.0-cs02.html). EMIX presents a general model for a resource (commodity) whose value is determined by time of delivery. (See section 3).
It is likely that as we get past these first parts of the conversation, we will turn to issues such as Availability (https://www.rfc-editor.org/rfc/rfc7953.txt) to properly value a promise to response within certain time windows, or alternately, to exclude a response from the market for a certain period, whether one-time or recurring.
Whatever we do, it should have a compatible information model, potentially transformable into that of EMIX, and it should support more commodity types than pure Power, and it should respect schedules when pricing those commodities.
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.