[Asdf] Sensor design pattern thoughts

[Michael Koster <[e-mail]>]

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