RFC: Access control systems

[jbkoh]

(This is WIP. 90% done. I will add an example graph in a diagram with the proposed concepts below to finalize it. Happy to receive comments from the current status too.)

Access control system is one of the key concepts in building systems providing information about occupants movement as well as managing security policies in buildings.

Example systems:

• Honeywell: https://www.security.honeywell.com/All-Categories/access-control-systems/
• Bosch: https://www.boschsecurity.com/xc/en/solutions/access-control-systems/
• Openpath: https://www.openpath.com/

Example use cases:

• Infer the number of people within a specific area
• Inform a user the location of gates for accessing a specific area
• Identify malfunctioning access control devices (e.g., a stuck latch) for security assurance.

How to model?

Let's start with some floor plan with possible configuration.

Assumptions

• The black lines are walls.
• Door 1, 2, and 4 have a lock controlled by their card readers (or more specifically a controller associated with card readers.)

We can exemplify answers for the above use case.

• The number of possible people within Space 1 and Space 2 together would be the people who have entered Door 1 and Door 3.
• To get into Room 3, a user should be permitted for (Card Reader1 || Card Reader 2) && Card Reader 3. For a person in Room3 to get into Room 1, no permission is needed.
• To infer how many people could have been in Space 1 and Space 2 together, we should be able to count people entering Door 1 and Door 3
• To understand whether Space 3 is secured, we should be able to know whether the door's current status is in sync with the card readers or related controller's status.

Those observations bring several new concepts to be added. We need to model:

• Doors and their sides,
• The concept of a set of spaces accessible without passing an additional access controller, and
• Relationships between doors and their controllers.

Each of the new concepts has their own challenges.

Door

Door is a new concept to Brick. Let's check how other ontologies model it.

• In IFC, IfcDoor's relationships to other components are modeled this way:

  IfcWall <-- IfcRelVoidsElement --> IfcOpeningElement, then the door is inserted within the opening by IfcOpeningElement <-- IfcRelFillsElement --> IfcDoor. In plain English, it models an opening on a wall and place a door in that opening.

• In BOT, a door is just an element but not specifically defined. Doors' sides are modeled as interfaces.
• In REC, a door is a subclass of barriers, and a barrier may have two relationships to spaces as toSpace and fromSpace.

Our requirements for doors are

• define "sides" explicitly to understand which side the card reader and its related points are associated with a door.
  • toSpace and fromSpace may not be ideal given that barriers are bidirectional in nature and even some barriers have locking functions in both ways (e.g., subway gates)
• assuming doors are a type of Equipment (all the existing ontologies model that way), we need to be able to position the door with hasLocation, but the location should be more fine-grained than just generic spaces like rooms.

I'm proposing those:

• brick:Door rdfs:subClassOf brick:Equipment.. This corresponds to all the concepts from the other ontologies.
• brick:Opening rdfs:subClassOf brick:Location. This corresponds to IfcOpeningElement in IFC, though we don't model walls.
• brick:Entry rdfs:subClassOf brick:Location. : This corresponds to bot:Interface but at the location level. This become a part of both an Opening and a Space. You can think of it as a hypothetical space representing the side of the opening or a place to put a door mat (analogously). This is a simplified version of an architectural model like IFC, though I'm open to any other proposals for modeling directions and possible association.

An example graph out of this

:door4 a brick:Door.
:opening4 a brick:Opening.
:entry4_1 a brick:Entry;
  brick:isPartOf brick:opening4;
  brick:isPartOf brikc:space3.
:entry4_2 a brick:Entry;
  brick:isPartOf brick:opening4;
  brick:isPartOf brikc:space2.

Access Control Zone

We need to model a collection of location that are accessible through an access control device. It's analogous to a VAV feeding air to an HVAC Zone which may consists of several spaces. The difference is that an access control device is controlling only an entry other than the entire set of spaces. Still, it'd make sense to group spaces as a single Access Control Zone other than letting users traverse associated spaces, which is hard to model anyway.

I'm proposing those:

• brick:Acces_Control_Zone rdfs:subClassOf brick:Zone: A group of spaces that are connected through without any access control devices. An example graph out of this

  
  :acz3 brick:hasPart :space3.
  :space3 brick:hasPart :room3;
  brick:hasPart :room4.

:acz3 brick:hasPart :entry4_1.

:opening4 doesn't belong to any access control zones.

### Equipment
I propose those:
- `brick:Lock`: This is a part of a Door and can be controlled by a Relay.
    - `brick:ControllableLock` may be useful in case a user needs to model manual locks as well.
- `brick:Relay`: A electronic circuit switching the status of a device. It's analogous to VFDs for motor-based equipment. In case a lock is controlled by a relay, Lock hasPart Relay (again, analogous to Fan hasPart VFD)
- `brick:Access_Card_Reader`: A badge reader to activate the associated lock for permitted tenants. 
- `brick:Access_Control_Unit`: A virtual/physical unit dedicated to control an Entry, analogous to HVAC terminal units. Unlike boxed equipment like VAVs, access control units are often not a standalone single device, but rather some parts like a lock, a relay, a card reader, and a controller. Even in some cases, a controller controls locks and card readers for multiple doors. However, I do see a value of defining a standalone device for collecting those parts, especially for defining a relationship of those parts with actual entry (analogous to a VAV feeding a Zone.)
- `brick:controlsAccess` between an Access_Control_Unit and an Entry. I'm not tied to this specific wording but couldn't find a better one. This is analogous to feeds.

### Points
- `brick:Contact_Sensor`: Detect whether a door is closed or not.
- `brick:Relay_Command`: Controls a Relay controlling the Lock.
- `brick:Access_Activity_Status`: Logs tenants access to the Entry. Each activity contains a tenant and whether they were approved or not for the access.

[gtfierro]

Thanks for the detailed proposal! I will review over the next couple days, but I wonder if we can build on the BOT or REC ontology for many of the door-related components? I didn't see any justification for why we aren't using those models. I could also see the building topology you are modeling here as part of an extension to Brick, rather than part of the Brick core (at least for v1.3) -- what do you think?

[jbkoh]

Those other ontologies are described above, but let me clarify the reasoning here a bit more

• REC models doors as a uni-directional component and does not model sides of doors which are important for associating access control devices explicitly with the door's direction.
• BOT doesn't provide best practices for doors and its definitions are confusing as an example of bot:Interface is "(3) A door between one room and another.", while bot:Interface is disjoint with bot:Element which is the parent class of doors. In my understanding of the definition, a door may have interfaces for each zone (room), which I adapted in my proposal as Entry. I adapted it to reuse our top level concepts instead of introducing Interface. Happy to discuss it further if there is proposal on this.

[jbkoh]

I don't mind skipping this in 1.3.0 release, though I'd like to have an agreeable outcome out of this discussion. I think it should be a part of core Brick though. Access control systems are one of the common subsystems in buildings.

[nikosandronikos]

Great to see the addition of Relay equipment. These will also form a core part of lighting control systems and included in Lighting Zones. For example, in retro fits where the existing dumb luminaires are to be kept and controlled by newer hardware via Relay.

[nlk-jan]

Interesting stuff indeed. Just found out that this group exists.

My 2 cents: The concept of access control is to have two zones with different access levels. Access control is about managing the flow in both directions (which can be individually controlled). The side of the door as a concept is not necessary. The equipment is related to the space where it is located. The schema sample Door 2, has two sides: Space 1 and Space 2, Door 2:Space1, and Door 2: Space 2 are having the equipment needed. To be able to model the situation fully I would suggest starting from general Space 0 which is currently not displayed, but it is needed as it is the baseline.

[epaulson]

Getting back to this after a long summer and fall.

Just FYI, we already have a brick:Access_Reader - it was added in #121 though we didn't explicitly say 'access_card_reader' as the name, but 'control' is a tag. (The skos definition got dropped when we moved everything into the definitions.csv file, I'll fix that). I also left in the comments of equipment.py a placeholder for a brick:Access_Control_Panel which I think is what you mean by 'Access control unit'? (there's a bunch of other things in equipment.py as TODOs as well)

I assume brick:controlsAccess is not equipment but is a new relationship, which does seem like we're going to need.

I think I like brick:Access_Activity_Status, because we don't really have a good 'point' for any of these things but they're certainly going to be spewing out telemetry data (on MQTT streams or something else), but I could also be OK with a generic new relationship of 'telemetry data' that points at a ref:ExternalReference of some kind - something that we can hang off of anything even if it's not a traditional 'point', but that might be getting kind of radical.