Confusion about building new models on top of REC

[ogiel]

Hey devs,

What would be the best way to build new models that contain multiple measurements on top of REC 3 with preferably DTDLv3. We have devices equiped with multiple sensors, for example a sensor that measures temperature, humidity and co2 (and some more things).

Options that might be it:

1. Create a model that contains a component for every value (I believe this is not possible).
2. One overlaying twin (Capability?) that extends multiple models (I believe this is possible, but can't upload v3 models as of now).
3. One twin that has relationships to specific twins for each measure.

Is it true that 2 would be the way to go (if this is possible in the first place) and is it true that uploading v3 is not possible yet? I get the following error when I try to upload the DTDLv3 version of REC_3_3, while it worked fine when it was on DTDLv2.

DocumentParseError: Failed to parse input. Error: jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object.

Thanks!

[ogiel]

I will add some information as I have been getting more confused but also found some answers.

For (1): A model with multiple components IS possible, but it is not possible to use nested components (At least I believe this is the case, since adding an Address as component works fine). So it is not possible to use one component for temperature sensor and one for humidity sensor.

For (2): I tried extending multiple models but this also gave errors (I tried to extend the temp and humidity sensor REC models). Not quite sure about he specifics again but I have never seen multiple extends in DTDLv2 but have seen some in v3.

For (3): This in my eyes still seems the worst way to go because we would need a lot of unique patch documents for a single device.

Not working example for (1):

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:sensor:Test;1",
  "@type": "Interface",
  "displayName": "Multiple Sensors Test",
  "contents": [
    {
      "@type": "Component",
      "name": "temperatureSensor",
      "schema": "dtmi:digitaltwins:rec_3_3:device:TemperatureSensor;1"
    }
  ]
}

[hammar]

Hi Fuchio,

I unfortunately cannot speak to future DTDL versions in terms of features or system support at this point, but I can talk about general RealEstateCore design principles.

It's important to note that DTDL as used in ADT and in RealEstateCore is conceptually a little different than the use in, e.g., Azure IoT Central or IoT Plug and Play, even though the modelling language is the same. In those platforms you'd typically define a single Interface which describes your physical device quite closely, and which would have Telemetrys, Propertys, Components, etc., that mirror the real device capabilities.

In RealEstateCore we adhere more to the BMS paradigm (and in the soon-to-be-released REC4, hosted at the separate repo http://github.com/RealEstateCore/rec, have explicitly adopted the Brick Schema design derived from this), where we think of the physical devices and the logical data points as disjoint sets. I.e., a physical box becomes one twin, and the data inputs/outputs on that twin become separate twins. This would be in line with your option (3) if I understand correctly.

While this may seem unwieldy when you're dealing with individual boxes, and as you note, would require multiple patches for combined sensor boxes, it is crucial in the very common scenario that you're integrating a BMS system or other system architecture that to some degree abstracts away the underlying physical setup of the building. E.g., when we are processing a BACnet network, we always deal in Points (REC3 equivalent: Capabilities), and we are very rarely interested in reading ALL of the points/capabilities on a single physical box at one time. Similarly, it allows us to assign points/capabilities directly to spaces or large industrial machinery/systems, entirely disregarding the specific data capture setup (which we might not even be privy to). E.g., we can say that OfficeRoom45 or HeatingLoopX2 has the capability TemperatureSensor.

Additionally, in our experience when you are dealing with a full building or portfolio of buildings, this approach is far more scalable. You typically have such a broad array of different data capture equipment in those buildings, that designing close-to.-reality interface declarations for all of them, is not practical. If we instead generalize to the notions of physical sensor boxes (or other capability-root twin) and a reasonable set of measurement capabilities/points, the challenge becomes a simpler one, where we need only keep track of data point relations to physical asset.

I hope this gives some input to your twin modelling work.

Best,

Karl

[ogiel]

Hi Karl,

A rather late response but I just referred back to this thread and wanted to say thanks for your detailed response. It had to sink in at first but it now makes sense, we rather have a single twin device that only tracks a temperature that has relation to a specific device (the physical box that contains multiple sensors). Given that this makes it a lot easier to combine properties, or in this case the temperature, from different physical devices.

Thank you, I will close the issue with this comment.

[ogiel]

Hi Karl, I hope you've had a nice christmas. I have one last follow up question about this regarding the digital twins query language. We have a structure comparable to the graphical representation on https://dev.realestatecore.io/docs/guides/sensor/.

Is there a way to dig into these levels of twins and getting the desired digital twins on sub-building level, without having to specify a $dtId at the start? For example (using the url to realestatecore.io as reference) we want to return every TemperatureSensor twin in the twins with Type: Level (LowerFloor and UpperFloor) without specifying that the building name is CostelloHeights. To make it a bit more clear; the end goal here would be an average temperature for each floor of a (any) building.

We have tried numerous things but keep coming back to the error that says we have to specify a $dtId on JOIN clauses, but having a single query that works on any building would be much preferred. An example of a query with $dtId is:

SELECT humsensor
FROM DIGITALTWINS
MATCH (building)-[:hasPart]->(level)-[:hasPart]->(room)-[:hasPoint]->(humsensor)
WHERE IS_OF_MODEL(humsensor, 'dtmi:org:brickschema:schema:Brick:Humidity_Sensor;1')
AND building.$dtId ='BuildingID'

Our desired query would be something like:

SELECT humsensor
FROM DIGITALTWINS
MATCH (SensorA)-[:hasPoint]->(humsensor)
WHERE IS_OF_MODEL(humsensor, 'dtmi:org:brickschema:schema:Brick:Humidity_Sensor;1')
AND IS_OF_MODEL(tempsens, 'dtmi:org:Attiq:SensorType_A;1')

Where the sensor type is a certain brand instead of a specific ID.

An easier example in our current setup is that we want to return all SensorBox twins that have a HasPoint relationship to a TemperatureSensor.

All relationship queries with JOIN clauses have it hardcoded in the examples https://learn.microsoft.com/en-us/azure/digital-twins/how-to-query-graph

Is this possible to achieve without hardcoding dtIds? Hopefully the question is not too vague.

[hammar]

@Fuchio I agree that "unrooted" generic ADT queries would be quite useful to have. Unfortunately, at this time, both MATCH and JOIN queries require at least one known twin; see https://learn.microsoft.com/en-us/azure/digital-twins/reference-query-clause-join#twins-required and https://learn.microsoft.com/en-us/azure/digital-twins/reference-query-clause-match#limitations. Sorry that I can't bring better news!