introduce specific relationships for Controller: controls, concerns and hosts

[fennibay]

Currently brick:Controller doesn't have any specific relationships defined, it just inherits its relationships from brick:Equipment.

I propose introducing some Controller-specific relationships that a Building Automation Controller would have, because of the control logic it contains:

• controls: A controller can reside outside of the equipment (e.g. control cabinet). Even when it is part of an equipment, it is not straightforward to come to the conclusion which part of the equipment it is controlling. So a controls relationship from brick:Controller to brick:Equipment would be useful.
• concerns: A controller controls an equipment that influences (feeds) a rec:Space (we will use rec:Zone specifically). It would be useful to shorten this path and introduce a concerns relationship from brick:Controller to rec:Space (alternatively rec:Zone).
• hosts: A collection of entities can be hosted on a Controller (e.g. sensors, zones, light groups etc.), the hosts relationship from brick:Controller to brick:Collection would allow this. This is also a preparation for future introduction of functions.

I am already providing this draft-PR to demonstrate the idea concretely. I'm open for any other proposals.

Related: #667

/cc @ektrah

[gtfierro]

Thanks for opening the issue! We had a discussion today and I captured some of this above in the diagram.

The controls relationship makes sense, and there was no push back from the group on this.

The concerns relationship also makes sense. We wondered if it could be inferred to simplify modeling. For example, does the following always hold?

?controller controls ?equip .
?equip feeds ?zone .
=> implies ?controller concerns ?zone

We had the most discussion on the hosts relationship. We imagined two ways of doing this modeling: first, Controller hosts Point could directly relate a point to a controller; I like the simplicity of the model, but it doesn't capture nested point groups. Alternatively, as you've suggested here, we could create a Collection of Points which is hosted by a controller. I imagine these could be recursively nested too!

:C1 hosts :pointgroup1, :pointgroup2 .
:pointgroup1 hasMember :pointgroup3 .
:pointgroup2 hasMember :SAT1, :RAT1 .
:pointgroup3 hasMember :MixedAirTemp1 .

As an aside, this also raises the question if we want to re-adopt the hasMember relation from REC to handle collection membership.

Is this what you had in mind?

[fennibay]

Hi @gtfierro, thanks for the detailed answer!

The controls relationship makes sense, and there was no push back from the group on this.

Great 😃

The concerns relationship also makes sense. We wondered if it could be inferred to simplify modeling. For example, does the following always hold?

?controller controls ?equip .
?equip feeds ?zone .
=> implies ?controller concerns ?zone

I think yes. We can also introduce the relationship now and think about the inference later, but looks good to me.

We had the most discussion on the hosts relationship. We imagined two ways of doing this modeling: first, Controller hosts Point could directly relate a point to a controller; I like the simplicity of the model, but it doesn't capture nested point groups. Alternatively, as you've suggested here, we could create a Collection of Points which is hosted by a controller. I imagine these could be recursively nested too!

It could definitely apply to points, as well. In order to keep the amount of data low, in our application we tend to just host the top parent and the hosting of the rest (subcollection, subequipment and ultimately points) is implied. Conceptually it is correct to say that the points are also hosted, practically it might get too verbose. This could also be handled with inferencing.

As an aside, this also raises the question if we want to re-adopt the hasMember relation from REC to handle collection membership.

I don't know the details of this question. Is this about #460?

Is this what you had in mind?

Yes 🙂

[gtfierro]

@fennibay I hope you're able to join us for the discussion next week!

We were wondering if you could share some of the intended use cases for modeling Controllers in Brick: do you have examples of the competency questions/use cases, or example systems that you hope to represent? There's potentially a great deal of complexity in how people organize points, routers, software, etc on a physical controller. We want to make sure we are capturing everything we need to capture in the model.

BMS products often organize their UIs by controller; there can be several levels of these owing to software/logical controllers. Because of this, we were considering a distinction between the physical controller (brick:Controller) and logical controller (brick:LogicalController?). There are a few ways we could do this, but we got caught up in what exactly the logical controller relates to: is it an "application"/software package running on a physical controller? Or just a point group? Maybe we just treat brick:Equipment as logical controllers so we don't need an independent concept for it?

You can see how we need some use cases to help focus the discussion :). What are your thoughts?

[fennibay]

Thank you @gtfierro, yes, I plan to be there this Thursday. Looking fwd 🙂

Here some use cases:

• Equipment and building graphics: Show data points on the graphics. The access to the data points requires information about the controller hosting them. And this controller might be sitting outside of the equipment or room, in a control cabinet. We'd like to have a specific relationship showing the controls and hosts relationships.
• Fault detection: When there is a fault we'd like to see the controller/s controlling the faulty equipment, or if a zone is affected by the fault (too hot/too cold), we'd like to see which controllers are concerning that zone.
• Gateways and multi-system integration: e.g. when primary and room systems are integrated, this is based on the physical equipment structure (ducts and pipes, feeds); but the accompanying process data exchange is between the controllers hosting these points or controlling the equipment.

I think for such use cases a model of the brick:Controller with these external relationships would be sufficient.

Regarding brick:LogicalController, do you mean a SW controller or the piece of SW that runs in the brick:Controller and runs the actual control logic?

I'd be happy to learn more.

[gtfierro]

@fennibay if you can provide some examples, then I will turn around the implementation of the controller model.

For "competency questions": this should be at least, a natural language expression of what you are trying to get out of the model. If the model we develop is successful, then we should be able to write SPARQL queries to answer the question.

"What is the physical location of the controller hosting the temperature sensor for Room 123?" for example.

"What are all the controllers hosting the points that concern(?) this too-hot HVAC zone?"

[gtfierro]

I've put my implementation in #724 . IT uses @fennibay's initial commit to start