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

[Bruce Nordman <[e-mail]>]

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

> 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
>>
>>

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