Forward and Backward Relations in SMC

In Solibri Model Checker (SMC), relationships exist between components and are reflected as “Relations”.  These are similar to properties and are grouped into folders within the Relations tab of the Info view. These relationships can be termed ‘forward, backward, or forward and backward’. We’ll explain what this means to you, as an SMC user. In […]

In Solibri Model Checker (SMC), relationships exist between components and are reflected as “Relations”.  These are similar to properties and are grouped into folders within the Relations tab of the Info view. These relationships can be termed ‘forward, backward, or forward and backward’. We’ll explain what this means to you, as an SMC user.

In the previous article, Using the Decomposes Relation Property, we used the example of a stair to explain the forward and backward Decomposes relation between the stair assembly and the stair runs, landings, and railings that make up that assembly.

In this article, we’ll focus on some other relations and explain their forward and backward direction.

For more information on relations within SMC, please see the help topic:

SMC Help – Relations

The Containment Relation

As the name suggests, the containment relation is present when one component contains another component.  For example, a Building component contains Floors, Floors contain components such as Spaces, and Spaces contain other components.

Looking at the structure of the sample model (SMC Buildng.smc) that comes with SMC, you see that the Ground floor contains a space Men[104].  That space contains two Sanitary Terminal components, which are a toilet and a sink.

If you select the Men[104] space, in the Relations tab of the Info view, you’ll see the containment relation for the space.

Notice there are arrow icons in front of the listed relations that denote the direction of the relation.  A forward direction is denoted by the  forward (pointing to the right) icon, and a backward direction is denoted by the backward (pointing to the left) icon.  Since the Space is a sub-element of the Ground floor, this containment relation has a backward direction, and since the Space contains the sanitary terminals, these containment relations have a forward direction. Essentially, as you get more granular, you have forward relations, and as you refer to those elements ‘upstream’ you are expressing backward relations.

If you select the ground floor, it will have a  forward containment relation to the Mens[104] space.

So logically, if Component A has a forward relation of some relation type to Component B, then Component B has a  backward relation of that same relation type to Component A. The result is a hierarchy of the related model components.

Relations are used in the rule Comparison Between Property Values [SOL/171], by selecting “Related Component” in the Components to Compare drop-down.

In the example of this rule below, the parameters are specified to check that there is at least 1 toilet on each floor.  Since we are checking floors, Floor is set in the Components to Check table.  We are using the Containment relation, so Related Component is selected in the Components to Compare dropdown, Containment is set as the type, and the Forward direction is selected.  The Follow Relation Chain checkbox is marked because there isn’t a direct containment relation to the floor and the Toilets. Instead, a floor contains the space and the space contains the toilet.  Lastly, since we are looking for at least 1 toilet on each floor, components classified as Toilet Seat is listed in the Components to compare using a count quantifier greater than or equal to the target value 1.

The only result returned is for the Roof floor which logically doesn’t require a toilet.  This floor could be ignored in the Components to Check table in the rule parameters or the result can simply be approved.

Doors, Openings, Walls and the Void/Filling relation

Rather than a direct containment relation, doors, and walls have a Filling and Void relationship to an opening component respectively.

If you select a door in a model, you’ll find that it has a  forward Filling relation to an opening component, since the door “fills” the opening.  However, there is no direct relation listed between the door and the wall.

If you double-click the opening listed in the Info view it will become selected. You’ll see the    backward Filling relation to the door and also a  forward Void relation to the wall.

Since there are two different relation types, a single Comparison Between Property Values [SOL/171] rule cannot be used to compare walls to doors.  Instead, a gatekeeper rule can be used to return the opening of a wall, which passes those openings to a sub-rule to check the door that fills the opening.

We’ll use a simple check to ensure that 1-hr fire rated walls have 1-hr fire rated doors. This example can be found here:

Fire Rating – Relations.smc

The file consists of 4 walls that have doors attached:

Below you can see which walls and doors have a 1-hr rating as those without a rating are hidden.  Only the third wall from the left is a 1-hr fire rated wall that doesn’t have a 1-hr fire rated door:

After running a check, only that wall/opening is listed as a result:

To create the ruleset, the “Gatekeeper: Openings in 1-hr Walls” has the following parameters filled in to return as results any openings that do not have a forward void relationship to a wall with a 1-hr fire rating:

Since only openings that fill 1-hr fire rated walls pass this check, “Check only passed components” is marked for this gatekeeper rule in the Ruleset Manager.

Those openings are passed to the sub-rule “1-hr Components must fill Openings.”  This rule checks that those openings have a backward filling relation to a door that has a 1-hr fire rating.  Notice this is a backward relation since the door fills the opening.

The result is any opening that creates a void in a 1-hr wall that does not have a 1-hr door filling that opening.

Decomposes Relation in Information Takeoff (ITO)

Relations can be used in ITO to group components by their related component.  In the example below, there are beam assemblies that group multiple beams.  The total lengths of these grouped beams are listed for each assembly along with their counts. For example assembly with id 185923 has 7 beams that have a total length of 192′- 3 7/8″.

The Decomposes relation is used for components such as stairs, beam assemblies, and curtain walls that are can be made up of differing components. For example, stairs can be made up stair runs, landings, and railings.  Beam assemblies can be made up of multiple beams. Curtain walls can be made up of panels (windows) mullions (members), and doors. These examples are a subset of commonly found components that can be assemblies with a Decomposes relation.

To create this ITO we create a new ITO Definition to report only Assembly components.

Right-click on the Type column and select New Column to group and report assemblies by their Building Authoring Tool (BAT) ID.

As we don’t wish to report the Type, this column is edited by right-clicking the column and selecting Edit.  We select Relation as the Column type, Decomposes as the relation, Forward as the direction, and Grouping to group the beams to find their total length.

Right-click the Count column, and select new column to create a column that reports the total length of the beams in each assembly.  Select Quantity for column type, Length for the Quantity, leave grouping unmarked and Sum for the Function.

This example can be found through the link below:

Decomposes – ITO.smc