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

["Wouter van der Beek (wovander)" <[e-mail]>]

Hi Bruce

3 different things here.

  1.  Standardize the units that is being measured/actuated.
     *   Everyone knows the Arianne rocket disaster, e.g. 2 pieces of code using different units
     *   Avoid this by not having the units on the wire, but have the units standardized per model
     *   By design use indeed SI..
  2.  Temperature sensor/actuator can be used in various conditions
     *   Design it only once
     *   Use it in all settings

                                                               i.      It needs justification to do something else

     *   Infrastructure, e.g. who is using the model can have additional data to describe how the sensor/actuator is being used.

                                                               i.      Such mechanism could be described with SDF as well

     *   Examples of OCF: fridge/freezer is a single device, but has for each zone a temperature sensor and a temperature set point.. how to distinguish these: semantic tags, e.g. extra data to say which one is which, but they all function the same..
  1.  Time series, composable things
     *   This can be achieved by creating lists/arrays with additional info of measurements of sensors
     *   Additional info

                                                               i.      Time

                                                             ii.      Semantic tags from above

                                                           iii.      ..

     *   This also starts with having the “most simple” sensor/actuator

I think 2 and 3 are topics when we have the first set of sensors/actuators have been done.
e.g. do the simple stuff first to get the journey started.

Kind Regards,
Wouter

From: One Data Model Group <[e-mail]> On Behalf Of Bruce Nordman
Sent: Tuesday, September 1, 2020 5:00 PM
To: One Data Model Group <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [One Data Model Group] [Asdf] Representation issues and protocol bindings

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]<mailto:[e-mail]>> wrote:


On Mon, Aug 31, 2020 at 4:19 PM Carsten Bormann <[e-mail]<mailto:[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]<mailto:[e-mail]>
510-486-7089; m: 510-501-7943
m: 510-501-7943