Point lastKnownValue

[cbupp]

Looking at the Point models, i see that "lastKnownValue" is now set at the root model.

In REC3.3, I thought it was nice that the value's type was enforced at the last logic inherited model. For example, the BinaryState Capability set the lastValue property to boolean.

I'm curious the thoughts around storing floats and boolean as string.

We had been exploring created BACNetScheduleSetpoint extensions, that were able to capture a more complex lastValue using an object that took into account the different rules about BACNet schedules (Special Events, etc). Maybe we capture this outside of the Brick:Point inheritance.

[hammar]

We (REC tech committee) see the value of more explicit semantics for lastKnownValue, both in terms of schema and in terms of units/quantitative types, and discussions on how this might be resolved are ongoing.

It is a little challenging because we want to be compliant with Brick data, and in Brick, Point.lastKnownValue is untyped and allows any datatype filler (we're only using string in DTDL models since DTDL does not allow Properties with such undefined schemas, and since string is therefore the most generic option available to us). Consequntly, valid Brick graphs might become invalid REC-DTDL graphs.

Probably the best solution is to make upstream Brick more explicit on this, in which case REC can follow suit. I'll discuss with them and see if this is an option.

[hammar]

We had a discussion with the Brick colleagues yesterday, and they are in agreement that this could be made more explicit in upstream Brick also. We're together with them working on a solution that should land withing a couple of weeks or so. However, it should be noted that Brick wants to be descriptive rather than prescriptive: there is simply too much variation in buildings all around the world to be too strict about this. So we'll probably end up with the extremely obvious cases being fully covered (e.g., Temperature is always numeric) but cases where there may be variation in the wild (e.g., positions of valves or such) will remain open-ended (strings in DTDL, untyped in SHACL).

Semantic types and units are also under consideration for the DTDL version, with roughly similar time frames.

[hammar]

Latest update: PR #159 contains values on sensors. Next step is to get it on the other Point subclasses as well. For now, this is not upstream in Brick, they were evaluating other options for representing this, so it is a little fluid still.

[cbupp]

@hammar - That's great! I'll review the PR this week!

[hammar]

Additional update: PR #159 used object schemas for lastKnownValue, which prevented the use of semantic types for that value. Now looking into a DTDL Component-based solution instead, for more expressive semantics.

[cbupp]

I'd be interested to hear your thoughts on the component-based solution. My team is in need of more expressive semantics, and the current specification of lastKnownValue with the Setpoint limits my current effort.

We're trying to model BACnet Controllers and BACnet Schedules using an extension of Setpoint.

[cbupp]

Here's an UML example that shows my current thinking of representing more complex IoT scenarios. For this implementation, instead of using components (which have nesting limits in Azure Digital Twin), I'm using an "Object" type.

In this example, I'm representing positions for mobile equipment (equipment that is expected to move). The Asset Tags also transmit a status message that contains firmware, battery voltage, and temperature information.

[hammar]

Just wanted to let you know this isn't in any way forgotten. Was hoping to get into it today but had a migraine attack so things got delayed. Hope to read through, think on, and respond to your suggestions by early next week.

[hammar]

Hi again,

A reason that we saw for using Components for lastKnownValue is that these have Interfaces as schemas. That provides two benefits over using simple object schemas:

1. It allows for defining Properties below that lastKnownValue component that are semantically typed. So we might be able to say that lastKnownValue.value is not only a double, but in fact a kiloWattHour double. This precision we believe to be useful in many future scenarios we'll be facing.
2. It allows for that Interface declaration to be instantiated into twins directly, also outside of the containing Sensor point. At first glance, this seems to only muddle the situation (having multiple ways of representing the same data), but since we build the REC4 API directly from the ontology, this automatically adds restful API endpoints representing these individual observations (e.g., https://API_URL/EnergyObservation), which is something we've had in earlier REC versions and which users have been requesting.

For a suggested solution under discussion, see: 9961031#diff-eb8900bb4ae8ae9739f83c4ff999909e66dd72987d6ab5f160b004a1d98c0d8f

The Component nesting challenge is an interesting one, if we were to want to do reuse by "Components all the way down", but I don't believe that's been suggested by anyone yet. Could you see other blockers to your use case if we were to go with the above proposed Component solution?

A general reflection: we need to straddle the divide between utility on the one hand and over-prescriptive semantics on the other. In Brick, they've stayed away from defining the specific payload semantics of different types of points, and instead stayed on the more descriptive layer (not a bad choice by any means). By getting into the lastKnownValue details, we're now getting a little more prescriptive, but given the delimitations of DTDL field overloading (i.e., it not being allowed at all), there's difficulty in this. We want to provide enough semantics to be useful, but not so much as to limit reusability of the models. Some Points (e.g., "Air_Temperature_Sensor") are fairly unambiguous and we can make opinionated choices, whereas others (such as your tag status) could actually encompass multiple subfields, and are sure to be modelled differently by different users. If it were 100 % a REC choice we could of course make the rules as we saw fit (e.g., "all single points must be resolvable to a single primitive field, else should instead be multiple points on a parent asset), but as we also are aligning against the Brick Point hierarchy, we don't have that luxury. In summary: this is a balancing act, and I for one am very happy that we get your (and other community members') comments and ideas on how to best land this. Thank you!

[cbupp]

@hammar - I hope you're feeling better, and thank you for your response.

Components make sense for the reasons you specified. My use cases can align to that. Though, for complex types needed to express further logical groupings, users of Azure Digital Twin would need to use Objects inside of the defined components.

Regarding the suggested solution you linked: I like the idea of "ObservationEvent"!