To create a Brick tag dictionary, establish a Fox connection to the station. In the brick palette, select the Brick component and add it to the TagDictionaryService container on the station.
Overview
A Brick schema organizes entities of a building into a class hierarchy, where each level is a more specific version of its
parent. In Brick, the types are defined as a hierarchy of classes.
The Brick tag dictionary contains a library of tags, tag groups, relations, and rules that enable a
Niagara station to be modelled using Brick semantics defined in the Brick ontology. As a station is being constructed, these dictionary
elements can be applied, or they can be applied to components of an existing station. The Brick tag dictionary does not contain
any custom properties or actions, and it has no custom views associated.
Module information: The brick-rt module, which needs to be installed on your station, implements a
Niagara Smart tag dictionary to support modelling a system using the Brick schema. This module has a dependency in the tagdictionary-rt module, which is required for any tag dictionary.
The Brick tag dictionary contains the following definitions for tags, tag groups, relations, and tag rules:
- Brick subclasses: Brick schema entities can be declared a subclass of another entity. These are modeled as either tag groups or smart tags
in the dictionary.
- Brick
hasAssociatedTag: Many Brick schema entities have a hasAssociatedTag property. Most of these are modeled in the dictionary as tag groups. Many are implemented as tag rules, where additional
tags are implied. For example, the Brick water entity has tags Fluid and Liquid, which are implied if the bk:water tag is added to a component.
- Brick Id: By default, the bk:id tag is automatically applied to any control point in the station using a smart tag. It is a string tag, and its value is
a UUID generated from a combination of a station name and a slot path. This ensures a unique Id value for stations within
a
Supervisor system. However, if there are multiple systems with the same station name that contain control points with the same slot
path, these will have the same UUID value.
- Brick inverse relations: Most of the relationships defined in the Brick schema have associated inverse relationships. For example, if one entity
has a bk:isPartOf relationship to another entity, there is an associated inverse bk:hasPart relationship. In these cases, when you apply one of these relations between two entities in a station, the dictionary rules
will imply the inverse relation between those two entities.
NOTE: The Haystack smart tag dictionary and the Brick tag dictionary can run simultaneously.