Re: [Asdf] PR#22: Actually define scaleMinimum and scaleMaximum

[Carsten Bormann <[e-mail]>]

So why do we need two SDF property definitions to represent this single property?

We probably want to have all three qualities:

dataMinimum..dataMaximum (here 0..1023), as an integer (“multipleOf = 1”)
measurementMinimum..measurementMaximum (here 0..2000), as an abstract value only (compute the multipleOf from these four corners)
quantityMinimum..quantityMaximum (here 0..2e-3), again as an abstract value only

There may be no need to actually express measurementMinimum..measurementMaximum unless the whole thing is composed from a data model and a mapping/binding.

How would that composition split?

If the data model knows this is about a specific quantity (say temperature), it would give the unit for that quantity.
The actual quantityMinimum..quantityMaximum may be a specific property of the sensor, or it may be hardcoded in the model.

If the SDF model only has the measurement level (measurementMinimum..measurementMaximum), then it becomes (contextual) binding information how to obtain the unit, quantityMinimum..quantityMaximum.

(The below example says 0..1024, which is also interesting, because in practice you wouldn’t get 1024, only 1023, out of a 10-bit ADC.  
In the linear transform, 1024 might still map to 0.002, so that quantity value would actually be off-scale!)

Grüße, Carsten



> On 8. Mar 2021, at 00:15, Michael Koster <[e-mail]> wrote:
> 
> 
> I think we're in agreement. My 4-20 mA example is the ADC rationalization that happens in the PID controller, and the Modbus decimal value scaling is what happens in the client. The model works for both cases, and I do have some SDF models for building C++ code that scale raw a/d counts to values using the same vocabulary. There is a case where one SDF file describes the a/d scaling to a modbus (decimal) integer, then another to scale the modbus value to the correct decimal scale.
> 
> "ihv_counts" : {
>  "type": "number",
>  "minimum": 0,
>  "maximum": 1024,
>  "multipleOf" :1,
>  "scaleMinimum": 0,
>  "scaleMaximum": 2000
> }
> 
>        "IHVData": {
>          "type": "number",
>          "units": "A",
>          "minimum": 0,
>          "maximum": 2000,
>          "multipleOf": 1,
>          "scaleMinimum": 0,
>          "scaleMaximum": 0.002
>        },
> 
> 
> 
> 
>> On Mar 7, 2021, at 2:42 PM, Carsten Bormann <[e-mail]> wrote:
>> 
>> On 2021-03-07, at 23:14, Michael Koster <[e-mail]> wrote:
>>> 
>>> Another point to be made here, is that all of these constraints are usually applied in the binding, when the SDF model is mapped to an implementation. In the base model we might only indicate number and that it is a Voltage unit, the assignment of raw values *and* scaled values are done in the binding.
>> 
>> One of the reasons for doing a data model is that we want to be able to interpret data when it has become detached from the physical device.  In which case you are better off when the value given is already referenced to a unit.  This was the idea behind SenML.
>> 
>> Now if I have a 4–20 mA ADC, that may be all the data I get, so I need some context information to know the range that this actually stands for.
>> This is one of the points of adding a mapping (binding): Being able to provide this context.
>> 
>> So we have:
>> 
>> — data item transferred: 0..65535
>> - measured value: 4..20 mA
>> — indicated sensor reading: 700..1100 K
>> 
>> (This ignores off-scale detection etc.)
>> 
>> I do like being able to put down the ranges to be mapped and essentially use the formula in https://raw.githack.com/ietf-wg-asdf/SDF/scaleminmax/sdf.html#section-4.7-10 for computing the linear transform.
>> 
>> The data model (really: information model) of a temperature sensor should talk about 700..1100 K.  The data model of an instrumentation ADC should talk about 4..20 mA and rely on additional information given by the usage context mapping (binding) to derive the 700..1100 K.  The mapping (binding) information to a bluetooth characteristic may tell you this range is represented by 0..65535.
>> 
>> Grüße, Carsten
>> 
>