Subject: [Asdf] Sensor design pattern thoughts

From: Michael Koster <[email-masked]>
Date: Mon, 3 May 2021 11:39:11 -0700

Hi,

Here are some follow-on thoughts from today's OneDM discussion about sensor modeling and sensor types, quantities, and units.

asdf cc'd for interest 

I think, to some extent, the ambiguity around handling quantities and units comes from multiple sources:

- We don't have a good system model

In the general sense, the system model is underspecified. We are modeling systems of interconnected devices, not physical systems with devices installed at well-defined instrumentation and control points. We might compensate by building more into the models, based on assumptions of autonomy and agency in the system, both computational agency as well as descriptive/configuration agency. We assume that devices need to be able to discover each other and interoperate autonomously. We see system intermediaries as a sign of architectural weakness, and somehow extend that to external system models.

So the models end up embodying some of what might be system level information, and the boundary is unclear. Ideally the model organization would support the pattern found in the O&M ontology, roughly:

Physical feature (FoI) <--> measurement situation (sensing element) <--> sensing process (logial affordances, q+u, scale) <--> communication system (device and network) <--> application logic

I used to think we could bypass a lot of this for "simple IoT devices", but I'm beginning to see the advantage of decoupling the relationships in the modeling to make it easier for those who just want simple devices. In OneDM we model the logical affordances. We might consider scales, quantities, and units to be part of instance bindings, especially as these can easily be converted and adapted.

- It's not clear where the product/instance constraints and customization is introduced.

Does an IPSO Smart Object model represent a device or a function block? Well, obviously it's a function block. Hmm but it seems to encapsulate a lot of the system features like specialization around a particular measurement quantity. For example, an industrial temperature transmitter is a specific product that contains some specialized sensing element with common configuration, processing, and communication. Most of the product is interchangeable and only gets the specialization when it's assembled.

Our models are similar. Having units and range information allows customization, and we define a "Temperature Sensor" as an object type. What is the particular tradeoff being made here? Temperature sensor in many ways seems more like a composed type than a building block. Temperature sensing seems to be a specialization that may add some unique qualities but for the most part only sets the quantities, units, and range.

A good counterpoint is concentration sensing in mixtures. There are only a few units (mol/mol, ppm...), but many potential components (CO, CO2, O2, methane, total HC, and so on). Here is seems to make sense to define a concentration sensor and provide a category enum for what material is being sensed.

Maybe it would make sense to move some specialization to the sdfThing layer as a practice, and think about maximum reuse of object definitions. What if we had generic sensing building blocks and a good type system for quantities and units that can become part of a system model and device models. Then we can assemble product descriptions for things on the shelf, as well as measurement descriptions that are agnostic to the product or device being used.

Maybe there will be interoperability levels, with conformance to the more abstract object building blocks (affordances) on a fundamental level, and constrained object/thing definitions (units, quantities, etc.) working on a more practical level. 

Best regards,

Michael

---

From: Szymon Słupik <[email-masked]>
Date: Wed, 5 May 2021 17:33:37 +0200

Hi Michael,

This is a very valid discussion.

I have always been wondering how we are going to map Bluetooth mesh sensors
to SDF.

Bluetooth defines today 183 so called "Properties", each representing an
atomic sensor. A Property defines the context for data, such as "Outdoor
Temperature" and points to the underlying Characteristic (which defines the
data format, such as Temperature 8 (which defines ranges, resolution,
special values such as "unknown"), which in turn points to a Unit (degree
Celsius).

A physical sensor device may include any combination of the 183 properties,
so the total number of combinations is 183! (~1.4e+345). This is of
course not doable to define in SDF any potential combination. The only way
is to define the rules for producing an SDF definition from a Bluetooth
definition of a given sensor).

Best

Szymon Slupik
President, CTO
+1-415-696-9111

ul. Jasnogórska 44
31-358 Kraków
Poland

www.silvair.com

 <https://www.facebook.com/meetsilvair/>   [image:
LinkedIn] <https://www.linkedin.com/company/meetsilvair/>   
<https://twitter.com/meetsilvair>

NOTICE TO RECIPIENT
We inform you that Silvair sp. z o.o. with its registered office in Cracow
(31-358), at Jasnogórska Street 44 is the controller of your personal data.
You can find more information about processing personal data and your
rights here
<https://silvair.com/media/filer_public/e5/ba/e5ba1ed2-84e6-47da-8277-f10df2eed7cc/information_on_personal_data_processing_of_representative_of_entity_mail_contacts_to_establish_maintain_business_relationshipsfn.pdf>.

This e-mail message and any documents accompanying it contain information
that belongs to SILVAIR. This e-mail is meant for only the intended
recipient of the transmission, and may be a communication privileged by
law, confidential and/or otherwise protected from disclosure. If you
received this e-mail in error and you are not the intended recipient, any
review, use, dissemination, distribution, or copying of this e-mail or
attachment is strictly prohibited. Please notify us immediately of the
error by return e-mail and please delete this message from your system.

On Mon, May 3, 2021 at 8:39 PM One Data Model Group <[email-masked]>
wrote:

> Hi,
>
> Here are some follow-on thoughts from today's OneDM discussion about
> sensor modeling and sensor types, quantities, and units.
>
> asdf cc'd for interest
>
> In the general sense, the system model is underspecified. We are modeling
> systems of interconnected devices, not physical systems with devices
> installed at well-defined instrumentation and control points. We might
> compensate by building more into the models, based on assumptions of
> autonomy and agency in the system, both computational agency as well as
> descriptive/configuration agency. We assume that devices need to be able to
> discover each other and interoperate autonomously. We see system
> intermediaries as a sign of architectural weakness, and somehow extend that
> to external system models.
>
> So the models end up embodying some of what might be system level
> information, and the boundary is unclear. Ideally the model organization
> would support the pattern found in the O&M ontology, roughly:
>
> Physical feature (FoI) <--> measurement situation (sensing element) <-->
> sensing process (logial affordances, q+u, scale) <--> communication system
> (device and network) <--> application logic
>
> I used to think we could bypass a lot of this for "simple IoT devices",
> but I'm beginning to see the advantage of decoupling the relationships in
> the modeling to make it easier for those who just want simple devices. In
> OneDM we model the logical affordances. We might consider scales,
> quantities, and units to be part of instance bindings, especially as these
> can easily be converted and adapted.
>
> Does an IPSO Smart Object model represent a device or a function block?
> Well, obviously it's a function block. Hmm but it seems to encapsulate a
> lot of the system features like specialization around a particular
> measurement quantity. For example, an industrial temperature transmitter is
> a specific product that contains some specialized sensing element with
> common configuration, processing, and communication. Most of the product is
> interchangeable and only gets the specialization when it's assembled.
>
> Our models are similar. Having units and range information allows
> customization, and we define a "Temperature Sensor" as an object type. What
> is the particular tradeoff being made here? Temperature sensor in many ways
> seems more like a composed type than a building block. Temperature sensing
> seems to be a specialization that may add some unique qualities but for the
> most part only sets the quantities, units, and range.
>
> A good counterpoint is concentration sensing in mixtures. There are only a
> few units (mol/mol, ppm...), but many potential components (CO, CO2, O2,
> methane, total HC, and so on). Here is seems to make sense to define a
> concentration sensor and provide a category enum for what material is being
> sensed.
>
> Maybe it would make sense to move some specialization to the sdfThing
> layer as a practice, and think about maximum reuse of object definitions.
> What if we had generic sensing building blocks and a good type system for
> quantities and units that can become part of a system model and device
> models. Then we can assemble product descriptions for things on the shelf,
> as well as measurement descriptions that are agnostic to the product or
> device being used.
>
> Maybe there will be interoperability levels, with conformance to the more
> abstract object building blocks (affordances) on a fundamental level, and
> constrained object/thing definitions (units, quantities, etc.) working on a
> more practical level.
>
> Best regards,
>
> Michael
>
>

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 5 May 2021 10:13:43 -0700

As someone who thinks about the world through the lens of energy use, to me
a "device " (and I know that term has different meanings for different
disciplines) is something with a power cord and hopefully an IP address.
Stand-alone sensors are often not such a 'device' - they might not consume
mains power, and might relay their data to an IP device over a non-IP
communications path, but should be able to be brought into the IP domain
and SDF in a consistent way.
A sensor of course might also be integral to a regular device (e.g. my TV
might have an ambient light sensor and be able to report that).

Is there some reference structure of what types of objects might exist and
their characteristics/capabilities?
It seems highly advantageous if we have a common taxonomy and terminology
around this, that crosses many standards.

--Bruce

On Wed, May 5, 2021 at 8:34 AM Szymon Słupik <[email-masked]> wrote:

> I have always been wondering how we are going to map Bluetooth mesh
> sensors to SDF.
>
> A physical sensor device may include any combination of the 183
> properties, so the total number of combinations is 183! (~1.4e+345). This
> is of course not doable to define in SDF any potential combination. The
> only way is to define the rules for producing an SDF definition from a
> Bluetooth definition of a given sensor).
>
> Best
>
> Szymon Slupik
> President, CTO
> +1-415-696-9111
>
> ul. Jasnogórska 44
> 31-358 Kraków
> Poland
>
> www.silvair.com
>
> LinkedIn] <https://www.linkedin.com/company/meetsilvair/>   [image:
> Twitter] <https://twitter.com/meetsilvair>
>
> NOTICE TO RECIPIENT
>> A good counterpoint is concentration sensing in mixtures. There are only
>> a few units (mol/mol, ppm...), but many potential components (CO, CO2, O2,

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