Re: [T2TRG] [One Data Model Group] [Asdf] Representation issues and protocol bindings

[Bruce Nordman <[e-mail]>]

I am all in favor of using SI units, and existing good mechanisms for
encoding them (I assume SenML is a good choice), but once we have
established the name and meaning of a characteristic, we are almost done.
I think the bigger problem is when there are divergent structures for
describing a device or its capabilities, with different meanings and
namings (or worse, same name but different meanings).

This particularly comes up with devices that are similar but different.
Consider an electric resistance water heater that has a capacity value.  It
has just one as all electricity consumption is converted to heat in the
water. If another protocol addresses heat pump water heaters, then the
input and output capacities are different, and both (and the efficiency)
vary with both the water and air temperature.

In other cases, the interaction model is different. For example, I have
worked for a long time on the topic of 'energy reporting' - individual
devices tracking and reporting on their own energy use. Some models for
this have the end-use device keep track of time-series data, which requires
the ability of central devices to configure the timing of such data
collection. Another interaction model is that the central device is
responsible for the time-series data, so that the only interaction with the
end-use device is requests from the central device for their data. Thus the
information to be passed is dependent on the interaction model.

I'm sure there are many such instances in network technology of this.  I
remember years ago using uucp email addresses that did source routing of
the email, which is fundamentally different from the DNS based email we use
today.

The number of such problem domains is large, some may be intractable, and
others will take years for domain experts to solve. However, I think there
are a good number of ones that are addressable and can provide great value
to standardize and are worth addressing.  Some of these are domain-specific
to a particular device type, but others are 'horizontal' across many or all
(e.g. energy reporting, device types).  Creating a list of possible topics
to address, and prioritizing it to identify a small number to address
initially, seems worth doing. This to be a modest side-project, not to
distract from the current central flow of ODM work, but possibly growing
once other work is more complete.

Thanks,

--Bruce

On Tue, Sep 1, 2020 at 6:33 AM One Data Model Group <[e-mail]>
wrote:

>
>
> On Mon, Aug 31, 2020 at 4:19 PM Carsten Bormann <[e-mail]> wrote:
>
>> I think it is already relatively easy to find the right level of
>> abstraction for information that can be expressed in SI units.
>> (Units can be specified in SDF 1.0.)
>>
>> SenML (RFC 8428) got that right, so I think we can follow that example in
>> SDF.
>> We did have to make a little bit of a compromise (adding scaling prefixes
>> in RFC 8798) in areas where the natural units are habitually scaled (there
>> aren’t many electricity meters indicating J — it’s always kWh), but even
>> here it should be easy to agree on a natural unit between domain experts.
>>
>
>  SenML's primary units and secondary (scaled) units did get that right,
> with nomenclature and values that make sense to subject matter experts:
>
> {"u":"%RH", "v":20},
>
> {"u":"lon", "v":24.30621},
>
> {"u":"lat", "v":60.07965},
>
> {"n":"temperature","u":"Cel","v":25.2},
>
> {"n":"EGT", "u":"Fahr", "v":1374}
>
>
> (I made the last one up - the U.S. should have gone metric back in the 1970's, but it didn't.  In this backward part of the world subject matter experts
>
> might appreciate a familiar secondary unit of temperature.  "F" was already taken for farad, so ...)
>
>
> But the problem remains how the ecosystem specifications can relate to the
>> converged model if that had to abstract some more.  And that’s where the
>> binding comes in.  To make ecosystem experts feel at home, we probably need
>> to make this rather accessible.
>
> For information that is a ratio to a reference value (e.g., a lamp an
>> undefined metric of which can be set to a value between 0 to 100 %), SenML
>> has “/”  (the dimensionless unit).  So we would normally not use
>> percentages (or permille, or ppm, …), but a number that is typically
>> clamped between 0 and 1.  Of course, most ecosystems will scale this to get
>> an integer representation, and that is probably the largest source of
>> variation (*).
>>
>
> Are there separate problems to be solved?
> 1) Devices that could but for some reason don't send/receive data in
> meaningful units (e.g., uint8 values from 0 .. 255 or 0..100) instead of 38
> %RH?
> 2) Devices for which it is impossible to use absolute units (3.7 volts on
> a 10v dimmer circuit -> uint8 37 on a scale of 0-100 -> 0,37 dimensionless
> -> some level of room illumination that architects and occupational health
> people need to measure but consumers don't care about and the controller
> can't know)
> 3) Devices for which meaningful units haven't been defined?
>
>
>> Also, RFC 8798 is limited to linear scales (scale/offset).  For sound and
>> RF power levels we can cheat with dB.  For lighting, the models are more
>> complicated (which led to gamma and all that).  If different ecosystems use
>> different models here, there may be no straightforward way to do the
>> conversions.  So we have to be prepared to express these anyway.
>>
>
> A parametric model might be useful for problems 1 and 2.  Linear scales
> define min and max values for data (transmitted bits) and information
> (subject-meaningful values):
>
> -128  ->  -40.0 Cel
>  127 -> 300.0 Cel
>
> or
>
>   0 -> -40.0 Cel
> 65,536 -> 300.0 Cel
>
> But for SDF that could be generalized to allow calibration points, the way
> gradients in an image editor specify at least start and end colors, but may
> also add intermediate values.  The domain of the transfer function is
> scalar and integer or real, but the range is always real and could be
> non-linear and multi-dimensional:
>
> 0 -> (0.4, 0.8, 0.25)           min domain value
> 25 -> (0.5, 0.8, 0.9)           intermediate control point(s)
> 100 -> (0.0, 0.0, 0.1)         max domain value
>
> After doing linear interpolation to get the range values between control
> points, an output function selected from a list could be applied.  The
> initial list of output functions might be quite small - I can't think of
> any good examples other than linear and log:
>
> 1: linear: y = x
> 2: exponential: y = e^x
>
> The parametric model of a mapping table followed by an optional output
> curve might cover 95% of use cases instead of 80%.  Is it simple enough for
> an SDF description?
>
> Regards,
> Dave
>
>


-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
[e-mail]
510-486-7089; m: 510-501-7943
m: 510-501-7943