What makes SMC Unique? The ability to check for Logic and Behavior

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
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 Mechinical.System Classification property
Mapping the System Classification to the value of the Mechanical.System Classification property

More information on classification can be found in the articles:
– CREATING CLASSIFICATIONS IN SMC
– USING ADVANCED CLASSIFICATION IN ITO

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
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
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
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
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:

– SELF-CONFIGURING RULESETS: GATEKEEPER RULES

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
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:

Latch Approach, Pull Side Result

Advertisements
What makes SMC Unique? The ability to check for Logic and Behavior

Enhanced in v9.6: Accessible Door Rule – SOL/208

The just released version (9.6) of Solibri Model Checker (SMC) includes significant enhancements to the Accessible Door Rule – SOL/208.  The following article describes those enhancements in more detail.  The example model, ruleset, and classifications used in this article can be downloaded from the link below:

SMC Building V9.6 Door Maneuvering Clearances.zip

Prior to this release, door maneuvering requirements were limited to a single free area in front of the push side of the door (free door back side), and a single latch side area on the pull side of a door (Free Door Side).  Also, the width of the free area in front of the pull side (Free Door Front Side) and push side (Free Door Back Side) had to be entered rather than being based on the actual width of the door:

Front Approach, Pull Side Maneuvering Clearance Check in SMC v9.5
Front Approach, Pull Side Maneuvering Clearance Check in SMC v9.5

In version 9.6, now both the latch (handle) and hinge sides of a door can be checked for a free area on both the pull and push sides of the door.   Also, the width of the area in front of the pull side and push side of the door can be determined by the actual width of the door rather than a specified dimension:

Front Approach, Pull Side Maneuvering Clearance Check in SMC v9.6
Front Approach, Pull Side Maneuvering Clearance Check in SMC v9.6

Above we see a check for maneuvering clearances for a front approach on the pull side of a door based on the requirements found in the ADA standards as issued by the Department of Justice (DOJ):

404.2.4 Maneuvering Clearances.

This rule ensures that single swing doors have a maneuvering space that extends 18 inches (455 mm) minimum beyond the latch side of the door and 60 inches (1525 mm) minimum perpendicular to the doorway for a front approach on the pull side.

Using Self-Configuring (Gatekeeper) Rules to Check Maneuvering Clearances Based on Approach.

The maneuvering clearance requirements for accessibility of a door depend on the approach (front, hinge, or latch) and whether the door is equipped with a closer and latch.  The Accessible Door Rule – SOL/208 does not have a component filter table to check specific door types; however, you are able to pass specific doors to the rule through self-configuring (gatekeeper) rules.   A detailed explanation of self-configuring rulesets can be found here:

SELF-CONFIGURING RULESETS: GATEKEEPER RULES

As an example, single swing doors that have a latch approach on the pull side equipped with a closer should have a maneuvering space that extends 24 inches (915 mm) minimum beyond the latch side of the door and 54 inches (1525 mm) minimum perpendicular to the doorway.

In the image below, we see a door that leads from a corridor to a balcony that has both a closer and latch with a latch approach on the pull-side as specified by its properties under the property group “data”.

Door with a latch approach on the pull-side
Door with a closer and latch that has a latch approach on the pull-side

By classifying these doors based on their approaches and whether they have a closer and latch, these properties can be checked in the “Components to Check” filter parameters table in a gatekeeper rule to only pass those components based on those properties.

Latch Approach, Pull Side Gatekeeper Rule
Latch Approach, Pull Side Gatekeeper Rule

Here we see the previously mentioned door fails the requirements as the balcony wall intersects the required free area that extends 54″ perpendicular to the door:

Latch Approach, Pull Side Result
Latch Approach, Pull Side Result

Another method can be used if the door approach is not specified as a property of the door.  Since the requirements of one of the three approaches must be satisfied, gatekeeper rules can be used to check each requirement passing those components that fail to sub-rules.  Below we see that all doors are first checked against the requirements of a Front Approach on the pull side of the door.  Those doors that fail this check are then passed to a sub-rule that checks the requirement of a hinge approach.  Again those that fail are passed to sub-rules for an alternate requirements of a hinge approach, and finally a latch approach.  Since the balcony wall is too close in all four approach requirements, a result is found as seen below:

Checking all Approaches through Gatekeeper Rules
Checking all Approaches through Gatekeeper Rules
Enhanced in v9.6: Accessible Door Rule – SOL/208

UniFormat Check Ruleset

The following article will demonstrate how you can visualize and check components based on their UniFormat categories within Solibri Model Checker (SMC).  As an example, if you are using UniFormat II categories for cost estimation, you’ll need to ensure that the UniFormat codes in the model match the version used in your estimating sheets.  If UniFormat II is being used and you import a window library that used UniFormat 2010 to classify itself, its C1020 Interior Windows UniFormat 2010 category may cause those components to be classified as C1020 Interior Doors in UniFormat II, thereby incorrectly raising the cost of doors, while lowering window cost.  In SMC, you are not only able to check that the UniFormat description matches, but that the components classified as C1020 Interior Doors are in fact of the door component type and not windows.

Furthermore, through classification, different versions of UniFormat can be mapped to one another. Therefore, if you are using Revit, you can automatically map its specific UniFormat II codes to UniFormat 2010.

The resources and sample model used in this article are available here: UniFormat Check

Please read the ReadMe.txt file in the zip folder for information on copying resources to their proper locations.

The model used in the example is an IFC export of the rac basic sample project.rvt. The sample project from Revit is also available here: Autodesk Revit 2014 Sample Project Files

UniFormat

UniFormat is a standard used to classify components, based on their function, into hierarchical categories. It is used in specifications, such as those for Level of Development (LOD), as well as cost estimation/analysis. Since these are standardized categories common to most buildings, it provides consistency in project management, analysis, and reporting.

At the highest Level 1, general major group categories exist:

  • A SUBSTRUCTURE
  • B SHELL
  • C INTERIORS
  • D SERVICES
  • E EQUIPMENT AND FURNISHINGS
  • F SPECIAL CONSTRUCTION AND DEMOLITION
  • G BUILDING SITEWORK

These categories are divided further into different individual groups at Level 2. For example, A SUBSTRUCTURE is divided into A10 Foundations and A20 Basement. Level 3 divides them further, dividing A10 Foundations into A1010 Standard Foundations, A1020 Special Foundations, and A1030 Slab on Grade. These are further divided into Level 4 or greater categories that often differ based on the version of UniFormat used.

For example, the level 4 category for Trenches has the code A103003 in NAVFAC UNIFORMAT II, A103004 in ASTM UNIFORMAT II, an undefined number in the code A1030._ in CSI/CSC UniFormat 1998 edition, A1030400 Trenches in the UniFormat version used in Revit, and A4030, a very different code altogether, in CSI/CSC UniFormat 2010 edition.

SMC Classifications

Hierarchical classification systems that use numerical codes such as UniFormat, MasterFormat, OmmiClass, UniClass, etc. lend themselves well to Solibri Classifications through the use of classification rules that include the asterisk (*) wildcard matching character, which matches zero or more characters.   For example, A1030* matches A103003 Trenches, A103004 Trenches, A1030._ Trenches, A1030400 Trenches from the various UniFormat versions for the Trench UniFormat II category to A1030 Slab on Grade. Likewise, through the use of mapping classifications, you can map to properties in multiple locations such as Identity Data.Assembly Code or some other location where you are storing UniFormat information in your components.

The following classifications are used both to visualize and check components based on their UniFormat category:

Component Types
Classifies components based on their component type (e.g. Door, Suspended Ceiling, etc.).  This classification is used to determine whether the component type fits the UniFormat code.  For example, the check for UniFormat II checks components classified as C1020 Interior Doors to ensure they are doors and not windows, as UniFormat 2010 has the classification C1020 Interior Windows.
UniFormat – II vs 2010
Classifies components based on their UniFormat code and description. The classifications are one of the following:

  • UniFormat 2010: Either the code only exists in UniFormat 2010 (e.g. A40 SLABS-ON-GRADE) or else the code exists in both UniFormat II and 2010, but the description is taken from UniFormat 2010 (e.g. C1020 Interior Windows);
  • UniFormat II: Either the code only exists in UniFormat II (e.g. C20 Stairs) or else the code exists in both UniFormat II and 2010 and the description is taken from UniFormat II (e.g. C1020 Interior Doors).
  • UniFormat II and 2010: The code is the same in UniFormat II and UniFormat 2010. The descriptions are either the same (e.g. B1010 Floor Construction) or they differ but describe the same component (e.g. B30 Roofing vs B30 Exterior Horizontal Enclosure).
  • UniFormat II or 2010: The code has changed in UniFormat 2010 and the code from UniFormat II now exists in 2010 as a different classification (e.g. C1020 Interior Doors vs C1020 Interior Windows).  The description doesn’t match that from either UniFormat II or 2010, or simply doesn’t exist.
UniFormat 2010
Classifies components based on their UniFormat Code mapping classification to a UniFormat 2010 classification, if it exists.
UniFormat 2010 – Multiple Classification Names
Classifies components based on its UniFormat 2010 classification to all of its higher-level classifications.  For example C1020 Interior Windows is classified as C1020 Interior Windows, C10 Interior Construction, and C Interiors.
UniFormat 2010 from Revit UniFormat Codes
If using Revit, classifies components based on the out-of-the-box UniFormat II codes from the Identity Data.Assembly Code property to UniFormat 2010. For example, D5090900 Misc. Other Electrical Systems maps to D5080.90 Miscellaneous Electrical Supplementary Components.
UniFormat 2010 from UniFormat II
Classifies components to a UniFormat 2010 classification based on the UniFormat II classification of the component.  For example, C1020 Interior Doors is classified as C1030 Interior Doors.
UniFormat Code
Directly classifies a component using the value mapped to a UniFormat code property. This is a mapping classification that maps to the property set Identity Data.Assembly Code by default.
UniFormat Description
Directly classifies a component using the value mapped to a UniFormat description property.  This is a mapping classification that maps to the property set Identity Data.Assembly Description by default.
UniFormat II
Classifies components based on their UniFormat Code mapping classification to a UniFormat II classification if it exists.
UniFormat II Classification
UniFormat II Classification
UniFormat II – Multiple Classification Names
Classifies components based on its UniFormat II classification to all of its higher-level classifications.  For example D5020 Lighting and Branch Wiring, is classified as D5020 Lighting and Branch Wiring, D50 Electrical, and D Services.
UniFormat II - Multiple Classification Names Classification
UniFormat II – Multiple Classification Names Classification

UniFormat Checking Ruleset

The UniFormat Check ruleset checks components in the model to ensure that UniFormat codes are defined and are correct based on UniFormat II or UniFormat 2010.

Since the codes and descriptions vary depending on the version, you are initially prompted to set the ‘UniFormat Version’ user input in the To-Do dialog.

Setting the UniFormat Version
Setting the UniFormat Version

In addition, you should ensure that the UniFormat Code and UniFormat Description classifications are mapping to the correct location where the UniFormat information is stored for components.  By default, it is set to Identity Data.Assembly Code and Identity Data.Assembly Description respectively, from Revit 2013 or later.  However, older Revit models could store the information under the property set Pset_Revit_Type_Identity Data or if you are using ArchiCAD, the UniFormat information is likely in the form of an IFC Classification IFC Classification Icon.

Once the UniFormat Version is set, the ruleset should look similar to this:

UniFormat Check - UniFormat II
UniFormat Check – UniFormat II

The rule Components must have a UniFormat code checks the UniFormat Code classification of components to ensure that a UniFormat code has been defined, regardless of what it is. Looking at the results we see that 149 components fail this check, and do not have a value for a UniFormat Code:

Components without a UniFormat code
Components without a UniFormat code

By selecting Show Passed in the Checked Components View, we see the 108 components isolated in the model that passed the check and do have a UniFormat code:

Components with a UniFormat code
Components with a UniFormat code

The rule Sub-Components must have a UniFormat code checks the UniFormat Code classification of components that decompose other components such as the railings of a stair component or the doors, plates, and members of a curtain wall, to ensure that a UniFormat code has been defined, regardless of what it is. Looking at the results we see that none of the 201 sub-components pass this check, as these do not have a value for a UniFormat code:

Sub-components without a UniFormat code
Sub-components without a UniFormat code

The UniFormat II ruleset further checks the actual values of the UniFormat codes and descriptions of components that have a UniFormat code defined to ensure they are valid from UniFormat II.

The rule UniFormat code must match UniFormat II checks the code against the UniFormat II classification to ensure that it matches a code from UniFormat II as well as checks the code and description against the UniFormat II vs 2010 classification to ensure that they either exist only in UniFormat II or in both UniFormat II and 2010. By setting the UniformatClassifications.txt file in Revit to one with UniFormat 2010 codes, and exporting to a different model, we see that it is able to detect that a door has an incorrect UniFormat II description:

Incorrect UniFormat description From UniFormat 2010
Incorrect UniFormat description From UniFormat 2010

The UniFormat codes exist in UniFormat II and UniFormat 2010 ruleset, checks the codes and descriptions of only those codes that exist in both versions of UniFormat II and UniFormat for components that had their code and/or their description changed.  If also possible, it checks the component type using the Component Type classification of the components.

For example, the rule C1020 Interior Doors – UniFormat Description checks components that have the UniFormat code C1020 to also have the UniFormat description ‘Interior Doors’ from UniFormat II. The rule C1020 Interior Doors – Component Types checks components that have the UniFormat II code ‘C1020 – Interior Doors’ are not of the component type ‘Window’ or ‘Plate’. These window and plate components could potentially have had the UniFormat 2010 code ‘C1020 – Interior Windows‘ set.  In UniFormat II, interior windows typically are under the UniFormat code ‘C1010 – Partitions‘.

In the example above, the doors that have the UniFormat code C1020, fail the description check, as they have the incorrect description ‘Interior Windows‘, but pass the Component Type check, as they are still doors, and not plates or windows.

The rules under the UniFormat codes exist in UniFormat II and UniFormat 2010 ruleset are self-configurable gatekeeper rules, and are only present in the checking window if those components exist.  The following shows the rules that check UniFormat categories that have had their code and/or descriptions changed from UniFormat II in UniFormat 2010.

UniFormat codes exist in both UniFormat II and UniFormat 2010
UniFormat codes exist in both UniFormat II and UniFormat 2010

Mapping UniFormat II to 2010

The Assembly Code property used in Revit are versions of a UniFormat II code. Through classification rules, these codes can be mapped to their respective UniFormat 2010 categories.  The following shows an ITO that reports the original UniFormat code and description from the assembly code and description along with the mapped UniFormat 2010 category using the UniFormat 2010 from Revit UniFormat Codes classification.

UniFormat 2010 categories from Revit UniFormat II codes
UniFormat 2010 categories from Revit UniFormat II codes
UniFormat Check Ruleset

Self-Configuring Rulesets: Gatekeeper Rules

In the article Self-Configuring Rulesets with User Input, we introduced self-configuring rulesets through the use of user input, which allows rulesets to configure themselves based on a property of a model set by the user in Solibri Model Checker (SMC).  These self-configuring rulesets are also called “Gatekeeper” rules, as these rules have the ability to pass only specific components based on some condition to sub rules for further checking.

In the following example, we will check a requirement that any space over 500 sq. ft. and that contains a boiler, incinerator, or furnace must have 2 doors to exit from.  No individual rule template can check for all three of these conditions.  Instead, we will use three different rule templates and create a nested self-configuring “gatekeeper” ruleset to pass the components based on specific conditions to sub rules to further check each condition.

You can download this example as a .smc file from the link here: Boiler_Rooms.smc

Example 1 – Creating Nested Gatekeeper Rules

In this example, we’ll show how nested gatekeeper rules can be used to check components for multiple conditions using multiple rule templates:

  1. Open the Boiler_Rooms.smc file in SMC and click the Checking Layout tab.
  2. In the Checking View, expand the Example 1 ruleset folder, select Space must reference 2 or more doors, and look at the results in the Results View:
    Space must reference 2 or more doors - Results
    Space must reference 2 or more doors – Results

    Rooms 1, 3, and 7 only have a single door and fail this check.

  3. Open the rule parameters for this rule:
    Space must reference 2 or more doors - Rule Parameters
    Space must reference 2 or more doors – Rule Parameters

    The SOL/231 – Comparison Between Property Values rule template was used to check that at least two doors have a Referencing relation to a space.  Remember, in the Components to Check Filter Parameters table, we exclude any spaces that have a space group classification defined, as those spaces are areas rather than rooms.

  4. In the Checking View, select Space must not contain a boiler, incinerator, or furnace and look at the results in the Results View:
    Space must not contain a boiler, incinerator, or furnace - Results
    Space must not contain a boiler, incinerator, or furnace – Results

    Rooms 1, 2, 3, 7, 8, and 9 all contain boiler components and fail this check.

  5. Open the rule parameters for this rule:
    Space must not contain a boiler, incinerator, or furnace - Rule Parameters
    Space must not contain a boiler, incinerator, or furnace – Rule Parameters

    The SOL/225 – Number of Components in Space rule template was used to ensure that there is a maximum of 0 components classified as Boilers, Furnaces, or Incinerators in all spaces.  The Space Usage classification is used in the rule parameters; however, since the cells have the asterisks (*) wildcard matching character, all spaces will be checked.  The Boilers, Incinerators, and Furnaces classification is simply classifying any component as such based on the name of the component, as seen in the classification rules:

    Boilers, Incinerators, and Furnaces - Classification Rules
    Boilers, Incinerators, and Furnaces – Classification Rules
  6. In the Checking View, select Space area must be less than 500 sq ft and look at the results in the Results View:
    Space area must be less than 500 sq ft - Results
    Space area must be less than 500 sq ft – Results

    Rooms 1, 2, 3, 4, 5, and 6 all have an area of 625 sq ft and fail this check.

  7. Open the rule parameters for this rule:
    Space area must be less than 500 sq ft - Rule Parameters
    Space area must be less than 500 sq ft – Rule Parameters

    The SOL/132 – Space Area rule template was used to check that all spaces have a maximum area of 500 sq ft.

  8. Click File > Ruleset Manager
  9. In the Ruleset Folders View, expand Rulesets Open in SMC > Gatekeeper Example > Example 1 and select Space must not contain a boiler, incinerator, or furnace

    Rulesets Folder - Rulesets Open in SMC
    Rulesets Folder – Rulesets Open in SMC

    A self-configuring rule is created by dragging another rule or ruleset onto the rule within the Workspace View that acts as the self-configuring rule.  The Sub Rule Options in the Info View is then set to one of the four options.  The last two options, Check only failed components and Check only passed components, are used for “Gatekeeper” rules, as these rules will only pass specific components to sub rules based on whether those components pass or fail the check.

    In this example, the gatekeeper rule was created by dragging the Space must reference 2 or more doors rule from the Ruleset Folders View onto the Space must not contain a boiler, incinerator, or furnace rule in the Workspace View. The Space Area must be less than 500 sq ft rule from the Ruleset Folders View was then dragged onto the Space must reference 2 or more doors rule in the Workspace View.  The Sub Rule Options for both nested gatekeeper rules were set to Check only failed components.

    Creating Self-Configuring Rules
    Creating Self-Configuring Rules
  10. In the Info View, you see this is a self-configuring gatekeeper rule with the sub rule option set to Check only failed components.

    Check Only Failed Components
    Check Only Failed Components

    Therefore, the sub rules will only check the spaces 1, 2, 3, 7, 8, and 9 that have a boiler, incinerator, or furnaces and fail this check.  If you look at Info View for the sub rule Space must reference 2 or more doors, it too is a gatekeeper that passes the spaces 1 and 7 that only have a single door and fail the check to its sub rule. That sub rule checks spaces 1 and 7 to ensure that they are less than 500 sq ft, and space 1 then fails the overall check as it is 625 sq ft.

  11. Click the Return to Solibri Model Checker Return to Solibri Model Checker button button, and in the Checking View, select the sub rule Space area must be less than 500 sq ft.
    Space area must be less than 500 sq ft - Sub Rule Results
    Space area must be less than 500 sq ft – Sub Rule Results

    In the Results View, only space 1 fails all three conditions.

  12. Expand the remaining two gatekeeper rules and check their results.  The same space 1 is returned as a result; however, the description of the issue in the Info View depends on the leaf sub rule that is checked:
    Space must reference 2 or more doors - Sub Rule Results
    Space must reference 2 or more doors – Sub Rule Results

    Space must not contain a boiler, incinerator, or furnace  - Sub Rule Results
    Space must not contain a boiler, incinerator, or furnace – Sub Rule Results

Example 2 – Input and Output of Gatekeeper Rules

In this example, we’ll show that gatekeeper rules have specific input and output components that can be passed in from parent rules and passed out to sub rules.  We add an additional requirement to check for boilers, incinerators, and furnaces that are greater than 600 000 Btu.  The requirement is now: Any space that is over 500 sq ft and contains a boiler, incinerator, or furnace that exceeds 600 000 Btu must have 2 doors to exit from.

  1. In the Checking View, expand the Example 2 ruleset folder, select Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) , and look at the results in the Results View:
    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) - Results
    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) – Results

    All six boilers in the model are greater than 11.95 bhp and fail this check.

    Note: 11.95 bhp = 600,000 Btu.

  2. Open the rule parameters for this rule:
    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) -Rule Parameters
    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) -Rule Parameters

    This rule checks to ensure the BHP property of the Mechanical property set is less than or equal to 11.95 for all components classified as a Boiler, Furnace, and Incinerator.

  3. In the Checking View, expand the first gatekeeper rule Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) and select the leaf sub rule Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) to view its results in the Results View:

    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) - Sub Rule Results
    Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) – Sub Rule Results

    In the Checking View, and Results View, this rule passed the check even though space 1 should obviously still fail as the boiler in that space is greater than 11.95 bhp.  If you click the Add View ADD_VIEW button and select the Checked Components View, you’ll see why.  In the Checked Components View, select Show All Checked and the view shows that no components were checked. Therefore, the rule, passes the check, since there are no components with issues.  Its parent gatekeeper rule, Space must not contain a boiler, incinerator, or furnace, only passes Space components to the leaf sub rule. However, that leaf sub rule is not checking Space components.  It is checking any component that was classified as a Boiler, Incinerator, or Furnace, and none of these components were passed into it as input.

    This is a very important concept to understand when setting up your gatekeeper rules:  If you use the Check all failed components or Check all passed component sub rule options, the output component type of the parent gatekeeper rule must match the input of the child sub rule.

  4. In the Checking View, expand the Example 1 ruleset folder and select the Space must not contain a boiler, incinerator, or furnace rule.  In the Checked Components view, click the Switch to Component Hierarchy COMPONENT_HIERARCHY button, and you’ll see that only Space components are listed as results that failed:

    Space must not contain a boiler, incinerator, or furnace - Failed Components
    Space must not contain a boiler, incinerator, or furnace – Failed Components
  5. In the Checking View, expand the Example 2 ruleset folder, expand the second gatekeeper rule Boiler, incinerator, or furnace must be less than 11.95 bhp (400,000 Btu) and select the leaf sub rule Space must not contain a boiler, incinerator, or furnace >400,000 Btu to view its results in the Results View:

    Space must not contain a boiler, incinerator, or furnace > 400,000 Btu - Sub Rule Results
    Space must not contain a boiler, incinerator, or furnace > 400,000 Btu – Sub Rule Results


    It is correctly reporting space 1 as an issue.

  6. Open the rule parameters for this rule:
    Space must not contain a boiler, incinerator, or furnace > 400,000 Btu - Rule Parameters
    Space must not contain a boiler, incinerator, or furnace > 400,000 Btu – Rule Parameters

    The problem in checking was resolved by using a Component Classification named Boilers, Incinerators, and Furnaces with Power that not only classifies these components based on their Name, but also classifies them based on their BHP property:

    Boilers, Incinerators, and Furnaces with Power - Classification Rules
    Boilers, Incinerators, and Furnaces with Power – Classification Rules

    Only boilers, incinerators, or furnaces that have a BHP value greater than 11.95 are checked if they are contained in the spaces 1 and 4 passed in as input.  As only space 1 has one of those boilers, it fails and is the result listed in the Results View.

Example 3 – An Alternate Method Using General Intersection

  1. In the Checking View, expand the Example 3 ruleset folder and select Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU (General Intersection Rule) to view the results in the Results View:
    Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU - Results
    Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU – Results

    Only the spaces 1, 2, and 3 that are greater than 500 sq ft and contain a boiler greater than 11.95 bhp fail the check.

  2. Open the rule parameters for this rule:
    Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU - Rule Parameters
    Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU – Rule Parameters

    This rule uses the SOL/1 – General Intersection Rule rule template that has two Filter Parameter tables.  This rule filters spaces that are greater than 500 sq ft that are not space groups in the Component 1 Filter Parameter table, and filters any components that are Boilers, Incinerators, or Furnaces that are greater than 11.95 bhp.  Any components from the Component 1 filter Parameter Table that are inside any components from the Component 2 Filter Parameter table fail and those components are returned as results.   This allows three conditions to be checked:

    1. The space area is greater than 500 sq ft
    2. The Boiler, Incinerator, or Furnace is greater than 600,000 Btu
    3. The Boiler, Incinerator, or Furnace is inside the space.
  3. Expand the gatekeeper rule Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU (General Intersection Rule) and select the leaf sub rule Space must reference 2 or more doors to view its results in the Results View:

    Space must reference 2 or more doors - General Intersection Sub Rule Results
    Space must reference 2 or more doors – General Intersection Sub Rule Results

    Of spaces 1, 2, and 3 that were passed in as input, only space 1 has a single door and fails the check.

    NOTE: Not only did the parent Space > 500 sq ft must not contain boiler, incinerator, or furnace > 400,000 BTU (General Intersection Rule) gatekeeper rule pass the intersecting spaces from the Component 1 Filter Parameter table in the rule parameters to the sub rule Space must reference 2 or more doors, it also passed the boilers, incinerators, and furnaces greater than 400,000 Btu from the Component 2 Filter Parameter table that were inside those intersecting spaces.  However, the Components to Check Filter Parameter table from the Space must reference 2 or more doors sub rule only checks space components.  Therefore, only spaces are returned as results.  Again, it is also important to understand what components are passed into rule parameters of sub rules of gatekeeper rules and what components are passed out of rule parameters from parent gatekeeper rules.

Gatekeeper Rule Template Input/Output Table

The following table provides the component types and in some cases the rule parameters of the input and output of gatekeeper rules for all rule templates in SMC.  The input column is what components are passed into a sub rule and the output column is what components are passed out from the parent gatekeeper rules:

Tag Rule Input Output
SOL/208 Accessible Door Rule Doors and Openings Doors and Openings
SOL/207 Accessible Ramp Rule Ramps Ramps
SOL/210 Accessible Stair Rule Stairs Stairs
SOL/211 Accessible Window Rule Windows Windows
SOL/209 Free Floor Space Spaces Spaces
SOL/233 Allowed Beam Intersections Beams for the Checked Components Filter Parameter table Beams from the Checked Components Filter Parameter table and any components from the Components in Allowed Area Filter Parameter table
SOL/215 Allowed Profiles Beams, Columns, and Members Beams, Columns, and Members
SOL/224 Architectural Components are Filled Any non-container components for the Architectural Building Components Filter Parameter table Any non-container components from the Architectural Building Components Filter Parameter table
SOL/212 Building Envelope Validation Building All walls from the building envelope
SOL/231 Comparison Between Property Values Any components for the Checked Components and Compared Components Filter Parameter tables Any components from the Checked Components and Compared Components Filter Parameter tables
SOL/222 Component Distance Any non-container components for the Source Component Filter Parameter table Any non-container components from the Source Component Filter Parameter table
SOL/171 Component Property Values Must Be Consistent  Any components  Any components
SOL/25 Components Must Be Connected to Spaces Windows, Doors, and Openings  Windows, Doors, and Openings
SOL/21 Components Must Have Unique Identifier  Any components  Any components
SOL/23 Components Must Touch Other Components Any non-container components for the Checked Components Filter Parameter table Any non-container components from the Checked Components Filter Parameter table
SOL/161 Distances Between Spaces Spaces Spaces
SOL/218 Element Hole Validation Rule Beams, Columns, and Members Beams, Columns, and Members
SOL/179 Escape Route Analysis Spaces Spaces
SOL/190 Fire Compartment Area Must Be within Limits Floors Floors
SOL/172 Fire Walls Must Have Correct Wall, Door, and Window Types Floors Floors
SOL/111 Floor and Gross Area Analysis Floors Floors
SOL/220 Floor Distance Any non-container components Any non-container components
SOL/228 Floor Names Must Be Consecutive Buildings Buildings
SOL/226 Free Area in Front of Components Any non-container components Any non-container components
SOL/1 General Intersection Rule Any non-container components for the Component 1 Filter Parameter table Any non-container components from the Component 1 and Component 2 Filter Parameter table
SOL/17 Layer of Component Must Be from Agreed List Any non-container components Any non-container components
SOL/232 Manual Checking Rule N/A: CHECKS ALL MODEL COMPONENTS N/A: CANNOT BE USED AS GATEKEEPER
SOL/206 Model Comparison Any components for the Checked Components Filter Parameter table Any components from the Checked Components Filter Parameter table
SOL/11 Model Should Have Components Buildings Any non-container components
SOL/176 Model Structure Buildings, Doors, Floors, and Windows Buildings, Doors, Floors, and Windows
SOL/225 Number of Components in Space Spaces Spaces
SOL/230 Property Rule Template with Component Filters Any components Any components
SOL/9 Property Values Must Be from Agreed List Any components Any components
SOL/203 Required Property Sets Any components Any components
SOL/213 Shelf Running Metre Rule Spaces Spaces
SOL/132 Space Area Spaces Spaces
SOL/38 Space Count on Each Floor Floors Floors
SOL/175 Space Group Containment Spaces Spaces
SOL/36 Space Requirements Spaces Spaces
SOL/202 Space Validation Spaces Spaces
SOL/191 Spaces Must Be Included in Fire Compartments Floors Spaces
SOL/162 Spaces Must Be Included in Space Groups Spaces Spaces
SOL/19 Spaces Must Have Enough Window Area Spaces Spaces
SOL/223 Structural Components Fit in Architectural Ones Any non-container components for the Structural Building Components Filter Parameter table Any non-container components from the Structural Building Components Filter Parameter table
SOL/37 Total Space Area on Each Floor Floors Floors
SOL/221 Wall Distance Walls Walls
SOL/216 Wall Validation Walls Walls
Self-Configuring Rulesets: Gatekeeper Rules