Solibri Model Checker (SMC) allows for simple, discrete, property checks of components and spaces, such as verifying that certain types of components and spaces have a specific property defined (e.g. Fire Rating) and the property is valid (e.g. 2-HR). These simpler types of property checks are useful for validating information related to COBie, Level of Development (LOD), Quantity Takeoff, etc. Likewise, you can check a model geometrically to ensure certain types of components or disciplines of models don't have interference with one another, such as duct and pipe running into structural beams and columns, or a check for required clearances in front of windows or electrical panels.
However, SMC also allows for complex conditional checks that involve logic and behavior to verify that if a component or space has some property, condition, relationship, and/or behavior then that component or space must also pass certain other requirements. In short, knowing that specific information is required to accompany model elements is important, but being able to analyze the IMPACT of that information and how it can affect building performance is where the real value of SMC is established. In this article, we'll describe how you are able to set up more complex checks in this way.
A Logical check: Plumbing above Electrical Rooms
In the first example, we will focus on a check to ensure that plumbing such as domestic cold or hot water and sewer does not run above electrical rooms, as this could cause serious issues if this plumbing leaks or bursts above spaces containing electrical components.
A logical statement to check against the model is: "IF a space is an electrical room THEN no plumbing system that is of type cold water domestic, hot water domestic, or sanitary should run above that space."
In order to find spaces in the model that are electrical rooms, classification is used to map those spaces either by their name or some other distinguishing characteristic such as an OmniClass number. Below we see the mapping of any space that starts with "ELEC" to the classification "Electrical":
Spaces with names that start with "ELEC" map to the Electrical classification
To check if plumbing is of type Domestic Cold/Hot Water or Sanitary, we need to know what property set/property pair stores that information. Again, using classification allows us to map to that property location and set the Classification to the value of the property automatically. Below, the "System Type" classification sets a classification name for any component base on the value of the "System Classification" property found under the property set "Mechanical":
Mapping the System Classification to the value of the Mechanical.System Classification property
These classifications are used in the rule parameters of the SOL/222 - Component Distance rule template below:
Plumbing must be a minimum distance of 5' above Electrical rooms
This rule checks that any component that has a System Classification that is classified as Domestic Cold Water, Domestic Hot Water, or Sanitary has a minimum distance of 5' above any space classified as "Electrical".
After running a check on a model, there is a result in which a pipe on the Sanitary system is running 3" inches above the space in the model.
An issue where Sanitary pipe is 3" above Electrical space
Another view shows that the pipe runs above the suspended ceiling across this electrical room that has electrical panels:
Another view of the result
Advanced Logical Checks using Gatekeeper Rules
Rather than using the name of the space to determine if it is an electrical room, the SOL/225 – Number of Components in Space rule template could be used to return any spaces that contain electrical equipment as a result. Using this as a Gatekeeper rule, the spaces returned as results are then fed to the sub-rule SOL/222 - Component Distance as the source component to ensure any plumbing has a minimum distance of 5' above those spaces.
Gatekeeper rules also allow SMC to chain multiple conditions together. Below is the example from the article Self-Configuring Rulesets: Gatekeeper Rules that checks that any space over 500 sq. ft. and that contains a boiler, incinerator, or furnace must have 2 exit doors.
Gatekeeper Rule with multiple chained sub-rules
The logical statement based on the chained gatekeeper rules and their results is:
IF a space is more than 500 sq. ft. and IF the space contains a boiler, incinerator, or a furnace THEN that space must reference 2 or more doors.
More information on Self-Configuring/Gatekeeper rules can be found here:
The behavior of door components for accessibility Checks
Door components have an operation property defined. This property defines the behavior of the door as to whether it is a sliding, folding, or swinging door. If it is a swinging door, the operation also states if the door swings left or right. There is also a behavior on the part of a person opening the door, in terms of pulling or pushing the door open and whether the door is normally approached from the front, latch, or hinge based on their room.
The article,
Enhanced in v9.6: Accessible Door Rule – SOL/208, provides a detailed look at modeling doors to have their behavior included and a ruleset can be used to check maneuvering clearance of accessible doors based on the logic of how the door is approached.
Below is a single-swing-right door that has the behavior of how it is approached from the push and pull sides included in the Data property set. On the push side, it is approached from the front. On the pull side, it is approached from the latch.
Door with a latch approach on the pull-side
Again, a gatekeeper rule is used as a logical check to return any doors as results IF they have a latch approach on the pull side and IF they have a closer attached. Those door results are then passed to the sub-rule that checks for the clearance areas in front of the door, and past the latch based on that type of approach.
Below you can see a result where there is not enough clearance perpendicular to the door:
WordPress.com
no longer exists on the slide because there is no longer a result that exists, as the issue was fixed. Since the issue no longer exists, the SMC user can set the status to closed and a BCF comment is generated automatically that saves the date and user that closed the issue with the comment "Status changed from Resolved to Closed".
