Re: [Asdf] [One Data Model Group] Sensor design pattern thoughts

[Szymon Słupik <[e-mail]>]

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
[phone]

[image: Silvair]
ul. Jasnogórska 44
31-358 Kraków
Poland

www.silvair.com

[image: Facebook] <https://www.facebook.com/meetsilvair/>   [image:
LinkedIn] <https://www.linkedin.com/company/meetsilvair/>   [image: Twitter]
<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 <[e-mail]>
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
>
> 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
>
>