Sei sulla pagina 1di 27

Smart3D – Interference Management

Using Codeless IFC Rules

Setup, Administration & Customization Guide.

Created By:

Smart3D Automation & Strategic Accounts Team

Process Power & Marine

Intergraph Corporation
Table of Contents

Introduction ................................................................................................................................................................................................................... 3
Setup ............................................................................................................................................................................................................................. 3
Configuration File ........................................................................................................................................................................................................ 4
Change Management of Configuration File............................................................................................................................................................. 5
Rule Development / Testing Conveniences ............................................................................................................................................................ 6
Testing Modifications to Configuration file locally ......................................................................................................................................................... 6
Logging ......................................................................................................................................................................................................................... 7
Configuration File Format ........................................................................................................................................................................................... 8
<CustomClashRules> - The Root tag of the Config File ......................................................................................................................................... 8
<IgnoreObjectsForClashChecking> Rules Section ...................................................................................................................................................... 8
<IgnoreClashesBetweenObjects> Rules Section......................................................................................................................................................... 8
Rules Evaluating Single Object ....................................................................................................................................................................................... 9
Rules Evaluating Two Clashing Objects ...................................................................................................................................................................... 13
<SetClashProperties> Rules Section ........................................................................................................................................................................... 20
Control Rule Evaluation .................................................................................................................................................................................................. 21
Limit Applicability of Rules ......................................................................................................................................................................................... 21
Evaluating Rule criteria using a Related Object’s data.......................................................................................................................................... 23
<SetClashType> Rules Section .................................................................................................................................................................................... 24
<AspectToUseForClashDetection> Rules Section .................................................................................................................................................... 25
<CustomIFCRule> Rule ................................................................................................................................................................................................. 26
Optimization / Fine tuning of Rules ......................................................................................................................................................................... 27

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 2
Introduction
This document describes Setup, Administration and Customization of “Codeless IFC Rules”. It is basically an Interference rule which is
customizable using an XML configuration file, instead of code changes. This functionality allows, using simple text based rules, to
- Ignore Objects for Clash Checking
- Ignore Clashes between Objects
- Set Clash properties

This functionality is available for Smart3D versions v2009.1 and above. It can be used for Plant, Marine or MHE models.

Please note this Package is NOT applicable for Smart3D v2016 and beyond, as the equivalent functionality is delivered out-of-the-box in
v2016 and beyond. Please refer to product documentation for more details on how to switch-to/enable/use delivered product
functionality.

Setup
Need to do this only from ONE machine with access to Project Management.

1. Unzip the zip file into SymbolShare\Custom Symbols\ClashMgmt folder. You should get
- Smart3D-CodelessIFCRules.pdf.
- CodelessIFCRule.dll - [Note: Source code is NOT provided – maintained by Intergraph].
- ModelName.CodelessIFCRules.config - Sample config file (contains Codeless Rules equivalent to delivered IFCRule.dll).
- CodelessIFCRule.xls  Used in step 6 below… Bulkload File to modify your catalog to use this Codeless IFCRules
Functionality.
2. Run Update Custom Symbols Configuration command from Project Management.
3. Copy the example config file “ModelName.CodelessIFCRules.config” as “<YourModelName>.CodelessIFCRules.config”. This file
must exist in the same folder as CodelessIFCRule.dll.
4. Optional at this time - Edit your Model’s config file (copied in above step) to configure the Clash Management Rules.
5. From Project Management, Stop IFC Database Detect, wait until it finishes.
6. Bulkload the delivered CodelessIFCRule.xls in AMD mode  this sets your Model to use CodelessIFCRules functionality.
7. Run the below query on Model’s MDB
Update ITFCHKIfcSettings set PostProcessorRule='CodelessIFCRule.ProcessorRule'

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 3
Configuration File

The heart of this functionality is a config file (created & edited by steps 3 & 4 above). It provides various facilities to specify

- [pre-processing] Objects to (totally) Ignore for clash checking


- [post-processing] Clashes to Ignore (based on the two objects involved in Clash)
- [post-processing] Set InterferenceType (Ignore/Hard/Soft) for new / modified interferences.
- [pre/post processing] Optionally, you can augment this Codeless IFC Rule’s logic to invoke your own code based Custom IFC Rule to
perform pre/post processing rules – this is only run if no Rule in the Configuration File was satisfied.

This Configuration File is an XML format file. When editing this file, make sure that it
 conforms to a valid XML file syntax (note that XML tags are case sensitive), and
 conforms to the expected format (tags and attributes explained later in this document)
 Notepad++ is a good editor to edit this file – has good plugins like XMLTools which help detect/avoid XML format errors.

Later sections of this document describe the configuration file format and available rules.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 4
Change Management of Configuration File

CodelessIFCRule.dll has logic to interpret the rules specified in the configuration file - thus, any changes to the configuration file are
equivalent to change of logic. The question whether the changes require reprocessing existing clashes or not can only be answered by the
person making changes. (Same point applies to any logic changes in your CustomIFCRule defined in the config file if any).

For this reason, changes to the Config file must be kept under strict admin control (achieved with standard windows file permissions) –
readonly for all, editable for Model administrator(s). Also, ensure you don’t lose your config file – keep backups and/or revisions.

The person changing the rules, the Clash Rules specialist, should know the effect of the changes on existing clashes – i.e. whether or not
the existing clashes (processed / ignored) are to be re-evaluated with new rules. For example, if you wrote a new rule for a future modeling
scenario, you would have no existing clashes. On the other hand, you may have changed rules in such a way that your existing clashes
need to be re-processed.

If you decided that your (processed / ignored) clashes need NOT be reprocessed, you don’t have to do anything more.

If you decided that your (processed / ignored) clashes need to be reprocessed, you need to do the following steps.

1. Enter Project management, right click on Model’s Interference Server node, and select Properties.
2. If Stop button is active, click it to stop IFC Process, and wait until it finishes.
3. Click Close and Exit Project Management.
4. Execute below SQL Statement on the MDB of the Model.
Update ITFCHKIfcSettings set PostPPRuleversion = '00.00.0000'
5. Enter Project management, right click on Model’s Interference Server node, and select Properties.
6. A dialog box will show up – choose “Update new registered version …” option and click close.
7. Click on Start button - the software should prompt you as if the Rule Version was updated. You should take the appropriate choice as
per your situation.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 5
Rule Development / Testing Conveniences
Testing Modifications to Configuration file locally

As a Rule Development & Testing convenience, the config file is read as follows.
o Server IFC - only read once when the IFC detection process starts.
o Local IFC - read upon each modification.

Whenever the config file is read (as per above), a snapshot of rules in it are written to log file. This helps interpret the log entries.

As an administrator, there is often a need to Test changes to your CodelessIFCRules in config file before you put the changes into the
production. The following functionality in CodelessIFCRule.dll helps you for this.
o Copy your current config file as ModelName.CodelessIFCRulesTesting.config in the same folder.
o Open a Command Prompt window. (Start > Run > Cmd.exe)
o On the Command Prompt window which shows up,
 Execute this statement  set CodelessIFCRulesTesting=TRUE
 Invoke the Session file with full path from Command Prompt (just type your session file by full path and press enter)
 e.g.: D:\Test\MySession.ses
o Edit, Test and Finalize your Rules in the Testing config file with Local IFC detection.
 Best way is to delete the clashing parts and immediately UNDO. This causes local clashes to be re-evaluated.
 Note that, if your config file is incorrectly edited and fails to conform to XML well-formed-ness, you will see an error message. You
can make corrections and continue.
o Once your rule changes are tested and finalized, update your main config file accordingly, and decide if you need to reprocess existing
clashes (processed, skipped) as explained earlier.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 6
Logging

To generate a log file for the CodelessIFCRules, before starting Server IFC / Local IFC, go to appropriate %TEMP% folder for the user
login and create an empty file named as follows:
- ModelName.CodelessIFCRules.log [for general user Local IFC],
- ModelName.CodelessIFCRulesTesting.log [for Testing mode explained above],
- ModelName.CodelessIFCRules.ServerIFC.log for ServerIFC mode.

As Clashes are processed, the log file is populated (new entries are appended to it).
 In Local IFC mode, especially for Testing, it is very handy to have this log file.
 In Server IFC mode, be aware that using this option will result in the file size grow as the rule keeps appending to it.
 Depending on your situation you must either
o turn off the logging before starting Server IFC
o keep logging on but monitor file size / disk space. If you really need to keep the log, periodic archiving of log file is a good idea –
just archive the file and empty its contents.

When an object is processed, log states @2/3/2015 4:54:13 PM - ProcessObject ? [Piping Components] - 'Flange-0403'

If no rule was satisfied, log states ProcessObject -> Yes

--> Satisfied - /CustomClashRules/IgnoreObjectsForClashChecking/ByObjectType[0]


If any rule was satisfied, log states --> <ByObjectType List="Piping Welds"/>
ProcessObject -> No

When a clash is detected, log states @10/28/2014 12:44:10 AM - CreateInterference ? - [Slab] - 'Slab-0101' & [Member Part Linear] - 'MemberPart-0202'

If no rule was satisfied, log states CreateInterference -> Yes

--> Satisfied - /CustomClashRules/IgnoreClashesBetweenObjects/ByObjectType[1]


--> <ByObjectType List1="Slab" List2="Member Part *"/>
If any rule was satisfied, log states
CreateInterference -> No

Similar log entries appear for Clash Modification scenario as well as SetClashType and SetClashProperty rule evaluations.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 7
Configuration File Format

This section describes the format of the config file, expected XML tags, attributes and their function.
Review the delivered example config file to get a high level overview of the format.

The Rules are evaluated in an order which results in best performance. It is intuitive to check Rules which are faster from performance
standpoint before proceeding to complicated rules based on attributes etc. which need more processing. In simple terms, what this means
is, all ByObjectType rules are examined first, then the ByName rules, and then the ByObjectPG rules and so on (in the order they are listed
below in this document). Within each rule type, the rules are executed in the order found in the config file. Anytime a rule satisfies, the rest
of the rules are skipped.

<CustomClashRules> - The Root tag of the Config File

It is the root tag of this XML and can contain following child tags, which are groups of Rules.

IgnoreObjectsForClashChecking SetClashProperties
IgnoreClashesBetweenObjects SetClashType
AspectToUseForClashDetection
CustomIFCRule [inside above sections]

<IgnoreObjectsForClashChecking> Rules Section

This tag denotes a section of pre-processing rules – which help decide if the object is to be ignored for clash checking.
In this section, you can use one or more “Rules Evaluating Single Object” (explained later in this document).

<IgnoreClashesBetweenObjects> Rules Section

This tag denotes a section of post-processing rules - which help decide if the clash between the two objects is to be ignored.
In this section, you can use one or more “Rules Evaluating Two Clashing Objects” (explained later in this document).

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 8
Rules Evaluating Single Object

These rules evaluate one object – They can be used in following ways
- Use in <IgnoreObjectsForClashChecking> section.
- Use two rules under <ByIndividualObjectRules> in <IgnoreClashesBetweenObjects> or <SetClashProperties> sections.

Rule Tag / Use / Expected Attributes Explanation / Example


ByObjectType Below example rule satisfies Piping welds.
<ByObjectType List="Piping Welds"/>
Make decision based on Object’s Type (BOC User name).
This rule satisfies Member Parts and Piping Parts/Welds.
List attribute must specify ObjectTypes (comma separated list) <ByObjectType List="Member Part *, Piping *"/>

ByName Below rule satisfies objects having “Road” in their name.


<ByName Like="*Road*"/>
Make decision based on Object’s Name
Same as above, but limit to Equipment only.
Equals or Like attribute must be specified with value to match. <ByName Like="*Road*" LimitToObjectTypes="Equipment"/>
Equals  exact match, Like wild card match
Same as above, but satisfies all except slabs.
Control: [LimitTo/Exclude]ObjectTypes <ByName Like="*Road*" ExcludeObjectTypes="Slab"/>

ByObjectPG Below rule satisfies ALL objects in Testing or GHOST PGs.


<ByObjectPG List="Testing,GHOST"/>
Make decision based on Object’s PG
Below example rule satisfies Piping Parts in SpecTest PG.
List attribute must specify one or more PG Names (comma <ByObjectPG List="SpecTest"
separated list) LimitToObjectTypes="Pipes, Piping Components, Piping
Instruments, Piping Specialty Items"/>
Control: [LimitTo/Exclude]ObjectTypes, RelationNavigationPath
Below example rule satisfies any object in SpecTest PG except
MemberParts.
<ByObjectPG List="SpecTest" ExcludeObjectTypes=
"Member Part Linear, Member Part Curve"/>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 9
Rule Tag / Use / Expected Attributes Explanation / Example
ByRangeDiagonalLimit Below example rule satisfies Slabs bigger than 100m in range.
<ByRangeDiagonalLimit LimitToObjectTypes="Slab"
Make decision based on Object’s Range Diagonal size Value="100m"/>

Value attribute must specify the limit of the Range Diagonal (like Below rule satisfies any object except Pipes > 100m in range.
Value="100m"). <ByRangeDiagonalLimit ExcludeObjectTypes ="Pipes"
Value="100m"/>
Control: [LimitTo/Exclude]ObjectTypes
Below rule satisfies any object bigger than 200m in range.
<ByRangeDiagonalLimit Value="200m"/>

BySystemPath, ByParentSystemPath, Below example rule satisfies all objects under “ExistingRoads” in
ByAssemblyPath, ByParentAssemblyPath system hierarchy.

Make decision based on Object’s <BySystemPath Like="*\ExistingRoads\*"/>


- System Path or System hierarchy parent’s System Path
- Assembly Path or Assembly hierarchy parent’s Assembly Path

Equals or Like attribute must be specified with value to match.

Control: [LimitTo/Exclude]ObjectTypes, RelationNavigationPath

ByInterfaces Below example rule satisfies sleeve type “Specialty Parts”

Make decision based on Object implementing the specified <ByInterfaces List="IJUASleeve"


interface(s) per metadata. LimitToObjectTypes="Piping Specialty Items"/>

List attribute must specify one or more Interface Names (comma Below example rule satisfies all parts which implement
separated list). Can use “*” too. “IJUACircularPlatform” except Footings.

Control: [LimitTo/Exclude]ObjectTypes, RelationNavigationPath <ByInterfaces List="IJUACircularPlatform"


ExcludeObjectTypes="Footing"/>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 10
Rule Tag / Use / Expected Attributes Explanation / Example
ByAttribute Below example rule satisfies objects with ConstructionRequirement
= Existing
Make decision based on a single attribute value of the Object
<ByAttribute Interface="IJConstructionInfo"
Interface - Name of the interface which has the Attribute. Attribute="ConstructionRequirement" Operator="EQ" Value=":3" />
Attribute - Attribute Name in Smart3D.
Operator - the operator to match the value (in Configuration File) Below example rule satisfies all Pumps with shaft diameter < 0.5in,
and the value on the Smart3D object. Operator has to be one of the optimized to only process Equipment.
following:
EQ or = GT or > GE or >= <ByAttribute LimitToObjectTypes="Equipment"
NE or <> or != LT or < LE or <= Interface="IJUAShaftDims" Attribute="ShaftDia"
Operator="LT" Value="0.5in" Tolerance="1mm" />
Like or ~ NOT Like or !~
Below example rule satisfies all Piping Parts of NPT <= 0.5in
Note that, usage of > or < symbols in xml needs escaping.
Hence prefer to use the eqvt text like GT or LT.
<ByAttributes
LimitToObjectTypes="Piping Components, Pipes,
Value – Value(s) of the Attribute to match – can specify multiple
Pipe Instruments, Pipe Specialty Items"
values (“|” separated) for operators (EQ, NE, Like or NOT Like)
RelationNavigationPath="IJRtePathGenPart%Owner[1]"
For codelisted attributes, you must specify the Short String value(s)
Interface1="IJRtePipeRun" Attribute1="NPD"
- or - prefix with “:” to specify codelist numbers.
Operator1="LE" Value1="0.5"
For united attributes, you must specify units as well.
Interface2="IJRtePipeRun" Attribute2="NPDUnitType"
Tolerance – Only applicable for numeric values, a Tolerance value
Operator2="EQ" Value2="in"/>
can be specified (along with units if applicable; DB units used
otherwise) to use in comparison.

Control: [LimitTo/Exclude]ObjectTypes, RelationNavigationPath

ByAttributes Below example rule satisfies ConstructionType = Temporary and


No-MTO objects
Make decision based on multiple attribute values of the Object
<ByAttributes
Similar to ByAttribute rule above, but for each Smart3D attribute Interface1="IJConstructionInfo" Attribute1="ConstructionType"
you must specify the Interface, Attribute, Operator Value and Operator1="EQ" Value1=":6"
optionally Tolerance … Interface2="IJMTOInfo" Attribute2="ReportingType"
For example, if you want to check two attribute values, you must Operator2="EQ" Value2=":2"
Comment="Ignore ‘Temporary’ and ‘No MTO’ objects" />

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 11
Rule Tag / Use / Expected Attributes Explanation / Example
specify the below xml attributes
Interface1, Attribute1, Operator1, Value1, RelationNavigationPath1
Interface2, Attribute2, Operator2, Value2, RelationNavigationPath2

Control: [LimitTo/Exclude]ObjectTypes, RelationNavigationPath

ByFilePath Below example rule satisfies Attached DGN type Reference Files
whose path contains \Roads\ in
Make decision based on a File Path – for ignoring foreign reference <ByFilePath Like="*\Roads\*" Type="DGN" />
Files (DGN, R3D etc.)
[IgnoreObjectsForClashChecking section only] Below example rule satisfies Attached DGN type Reference Files
by given exact path RefFiles\Grade\Ground.dgn
Equals or Like attribute must specify FilePath value to match. <ByFilePath Equals="RefFiles\Grade\Ground.dgn" Type="DGN"/>
Type attribute must specify the fileType value to match (DGN etc.)

ByR3DProject, ByR3DFile Below example rule satisfies R3D objects from TestR3D project
<ByR3DProject Equals="TestR3D"/>
Make decision based on R3D Objects based on the R3D Project
name or R3D file name. Below example rule satisfies R3D Objects from R3D file named like
*doors.*
Equals or Like attribute must be specified with value to match. <ByR3DFile Like="*doors.*"/>
Control: [LimitTo/Exclude]ObjectTypes

ByRulesCombination Below example rule satisfies Underground Pipes & Components


with Construction Status = ‘Existing to be reused in place’.
Make decision based on a combination of Single Object rules
<ByRulesCombination LimitToObjectTypes="Pipes, Piping *">
You can use any of the above “Single Object Rules” under this <ByObjectPG List="Underground Piping"/>
grouping ByRulesCombination tag. <ByAttribute Interface="IJConstructionInfo"
This rule is satisfied if all rules included under this tag satisfy. Attribute="ConstructionType" Operator="EQ" Value=":17"/>
</ByRulesCombination>
Control: [LimitTo/Exclude]ObjectTypes

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 12
Rules Evaluating Two Clashing Objects

These rules evaluate two objects involved in the clash to decide if the clash qualifies based on the criteria. Such rules can be used in
<IgnoreClashesBetweenObjects> and <SetClashProperties> sections. The rules are similar in syntax & working to Rules Evaluating
Single Object, but expect criteria to be specified for evaluating both Object1 and Object2.

Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
ByObjectType Below example rule satisfies clashes involving Slabs vs Handrails

Make decision based on the Two Object Types (BOC User <ByObjectType List1="Slab" List2="Handrails"/>
name).

List1 and List2 attributes must specify one or more


ObjectTypes (comma separated list)

ByObjectTypeAndAspect <ByObjectTypeAndAspect
ObjectType1="Piping Welds" Aspect1="Maintenance"
Make decision based on ObjectType and Aspect of the two ObjectType2="Piping Welds" Aspect2="Maintenance"/>
objects involved in the clash.
Or, more concisely (since objectType1/2 are same, and Aspect1/2 are
ObjectType1, ObjectType2 - BOC username of Objects same), as below
Aspect1, Aspect2 - Clashing Aspects of the Objects
<ByObjectTypeAndAspect
You can just specify ObjectTypes if ObjectType1 and ObjectTypes="Piping Welds" Aspects="Maintenance"/>
ObjectType2 are same.Similarly, if Aspect1 and Aspect2 are
same, just specify Aspects

ByName

Make decision based on Names of the two Object

Below attributes must be specified with value to match.


Name1Equals / Name1Like (Equals  exact match) and
Name2Equals / Name2Like (Like wild card match)

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 13
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
ByObjectPG Below example rule satisfies clashes between Member Parts where at
least one of the member part is in GHOST permission group.
Make decision based on PGs of the two Object’s
<ByObjectPG List1="GHOST" List2="*"
List1 and List2 attributes must specify one or more PG Names LimitToObjectTypes="Member Part *"/>
(comma separated list)

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes,


RelationNavigationPath

BySystemPath, ByParentSystemPath Below example rule satisfies clashes between


ByAssemblyPath, ByParentAssemblyPath Piles (Member Parts under a system named Piles)
vs
Make decision based on the two Object’s Foundations (Footing/Footing Component/Slab under a system
- System Path named Foundation)
- System hierarchy parent’s System Path
- Assembly Path <ByParentSystemPath
- Assembly hierarchy parent’s Assembly Path LimitToObjectTypes1="Member Part *"
LimitToObjectTypes2="Footing,Footing Component,Slab"
Below attributes must be specified with value to match. Name1Like="*\Piles\*"
Name1Equals / Name1Like and Name2Like="*\Foundation\*"/>
Name2Equals / Name2Like

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes

ByInterfaces Below example qualifies clashes involving Welds vs Piping Parts using
interface approach
Make decision based on the clash involving two Objects based
on them implementing the specified interface(s) as per <ByInterfaces
metadata. List1="IJRtePipeWeld" List2="IJRtePiping,IJRtePathGenPart"
LimitToObjectTypes1="Piping Welds"
List1 and List2 attributes must specify one or more Interface LimitToObjectTypes2="Pipes, Piping *"/>
Names (comma separated list). Can use “*” too.

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes,


RelationNavigationPath

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 14
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
ByAttribute Below example rule qualifies clashes between Imported Slabs

Make decision based on property values (one each) of the two <ByAttribute LimitToObjectTypes="Slab"
Objects Interface1="IJUASlabGeneralType" Attribute1="Composition"
Operator1="EQ" Value1="Imported_Slab"
Note that, you cannot use ByAttributes rule in Two Clashing Interface2="IJUASlabGeneralType" Attribute2="Composition"
Objects scenario. To decide based on multiple properties, use Operator2="EQ" Value2="Imported_Slab"/>
ByRulesCombination rule with multiple ByAttribute rules in it. Below example rule qualifies clashes between Braces and
Slab/Footing/Footing Component
Interface1, Attribute1, Operator1, Value1, Tolerance1 <ByAttribute
Interface2, Attribute2, Operator2, Value2, Tolerance2 LimitToObjectTypes1="Member Part *"
Names of the Interfaces, Attributes, Operators, Values and LimitToObjectTypes2="Slab, Footing, Footing Component"
Tolerances pertaining to the two properties. Refer to Interface1="ISPSMemberType" Attribute1="TypeCategory"
ByAttribute Rule in “Rules Evaluating Single Object” section Operator1="EQ" Value1="Brace"
for details on the expected attributes. Interface2="*" Attribute2="*" Operator2="EQ" Value2="*"/>

This rule qualifies clashes of Braces vs Beams/Columns/Braces


<ByAttribute
Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes,
Interface1="ISPSMemberType" Attribute1="TypeCategory"
RelationNavigationPath
Operator1="EQ" Value1="Brace"
Interface2="ISPSMemberType" Attribute2="TypeCategory"
Operator2="EQ" Value2="Beam|Column|Brace"/>

ByR3DProject, ByR3DFile Below example rule satisfies clashes between R3D objects from
R3DBuildings and R3DFacilities projects
Make decision on a clash involving R3D Objects based on the
R3D Project name or R3D file name they come from. <ByR3DProject Name1Equals=" R3DBuildings" Name2Equals="
R3DFacilities"/>
Name1Equals/Name1Like and Name2Equals/Name2Like
attributes must be specified with R3DProject name or R3D File Below example rule satisfies clashes between R3D Objects from R3D
name to match. file named like *doors.* and *doorframes.*

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes <ByR3DFile Name1Like="*doors.*" Name2Like="*doorframes.*"/>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 15
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
ByCommonAttributeValues For example, if you model stairs using individual unconnected
members, but set common attribute values to identify such group of
Make decision based on a clash involving two objects based on objects as a stair, then below rule satisfies clashes between such
them having the Common Attribute values for given (one or individual members making up a stair.
more) properties.
<ByCommonAttributeValues
Interface1, Interface2, Interface3 … - Names of the interfaces ObjectTypesList="Member Part Linear, Member Part Curve"
corresponding to the Attribute1, Attribute2, … Interface1="IJUABuilding" Attribute1="BuildingID"
Attribute1, Attribute2, Attribute3 … - Attribute Names. Interface2="IJUAStairsByPieces" Attribute2="StairID"/>

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes,


RelationNavigationPath

ByCommonAncestor Below rule satisfies clashes between welds of same Pipeline.

Make decision based on a the two objects having the Common <ByCommonAncestor LimitToObjectTypes="Piping Welds"
System Ancestor AncestorInterfaces="IJPipelineSystem" />

AncestorInterfaces - Names of the interfaces to be satisfied


by the object’s ancestor in system hierarchy.

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes

Interconnected This rule is typically used for Pipes adjacent to elbow/tee/branch


component clashing on insulation aspect.
Eliminate clashes between route parts connected by one
intermediate part but clashing in different aspects. This rule qualifies clashes between interconnected parts in Insulation
aspect, both for Pipes and Ducts.
Must specify below attributes
ObjectTypes - object types to consider <Interconnected ObjectTypes="Pipes, Ducts"
ClashingAspect – aspect to consider. ClashingAspect="Insulation" />

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 16
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
RangeBoxesDoNotOverlapAfterTrimming These tags are useful to eliminate touching or slight overlap clashes
between two objects in Simple Physical Aspect (and also clashes
Make decision by checking if the Object’s rangeBoxes, if shrunk involving Insulation aspect of Piping/Duct/Equipment parts with other
by given tolerance, are still overlapping or not. objects like steel).
For example, imagine a Pipe resting or slightly overlapping the steel
Trim1 and Trim2, specifying the tolerance to trim the member beneath. You can specify Trim values to apply, to get the
RangeBoxes. effect of specifying Negative Clearance.

The below rule is also available from <RangeBoxesDoNotOverlapAfterTrimming


- v2011 R1 HotFix28(09.01.30.0091) and above Trim1="2mm" Trim2="2mm"
- v2014 HotFix08 (v10.00.73.0055) and above LimitToObjectTypes1="Pipes, Piping*"
- v2014 R1 (v10.01.15.0049) and above LimitToObjectTypes2="Member Part *"/>

Note that, RangeBox, by definition, implies the extents of the objects


OrientedRangeBoxesDoNotOverlapAfterTrimming
along global X,Y,Z directions. It will be bigger for objects which are in
skewed directions (i.e. not along global X,Y,Z axis). Therefore, this rule
Trim1 and Trim2, specifying the tolerance to trim the
may be of good help only for cases like horizontal Pipe slightly-
OrientedRangeBoxes.
overlapping steel below, or similar configurations in other global
directions. On the other hand, OrientedRangeBox, is a tight box in any
Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes
orientation. This is more helpful than just RangeBox. Below rules help
in such Pipe-steel slight overlap clashes in skewed directions.

<OrientedRangeBoxesDoNotOverlapAfterTrimming
Trim1="2mm" Trim2="2mm"
LimitToObjectTypes1="Pipes, Piping*"
LimitToObjectTypes2="Member Part *"/>

Also note that, Range typically does not include Insulation. But, these
two Rules handle insulation thickness for Piping / Duct / Equipment
parts by expanding their Simple physical Range by Insulation thickness
all-around, thus handling small-overlap clashes involving insulation of
Piping / Duct / Equipment parts with other parts. For all other object
types, these Rules cannot work for clashes involving non-simple-
physical aspects.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 17
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
SlabPenetration Below example rule shows how to ignore a clash involving penetration
of a Grating Slab by either Pipe <3in, or Handrail, or Member Part
Make decision by checking if the clash situation involves an (column or brace type)
Object penetrating a slab.
<SlabPenetration
Must specify SlabTypes="Grating"
SlabTypes: Comma separated list of Slab Types (Catalog ObjectTypesList="Pipes,Handrails,Member Part *"
part numbers of Slab) PipeNPDLessThanOrEqualTo="3in"
ObjectTypesList: Comma Separated list of Object Types MemberTypeCategoryList="Column,Brace"/>
penetrating the slab
PipeNPDLessThanOrEqualTo: NPD of the pipe, (for
penetrating Pipe situation)
MemberTypeCategoryList: List of MemberType Categories
to ignore (for penetrating Member Part situation)

WithinToleranceToMemberPartEnd This rule qualifies clashes involving any object with columns/braces,
within 10in from their end.
Make decision by checking if the clash involves a member part,
and it is within certain tolerance from the end of the member <WithinToleranceToMemberPartEnd Tolerance="10in"
part. ObjectTypesList="*" MemberTypeCategoryList="Column,Brace"/>

Must specify
Tolerance: Max Distance (Tolerance) between Member End
and Clash.
ObjectTypesList: List of other ObjectTypes to limit this check
to (can use *).
MemberTypeCategoryList: List of MemberType Categories.

ByIndividualObjectRules The biggest use of this kind of rules is to be able to combine different
type of rules (for example one going by Attributes and one going by PG)
Make decision on a clash based on two Single Object rules and be able to decide on the Clash.

You must use two (and only two) “Rules Evaluating Single This rule qualifies clashes between Welds and Sleeves
Object” under this tag like below. <ByIndividualObjectRules LimitToObjectTypes=" Piping Welds, Piping
Specialty Items">
<ByIndividualObjectRules> <ByObjectType List="Piping Welds"/>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 18
Rule Tag / Use / Expected Attributes Rule Tag / Use / Expected Attributes
<Rule#1 Criteria attributes for Rule#1/> <ByInterfaces List="IJUASleeve"
<Rule#2 Criteria attributes for Rule#2/> LimitToObjectTypes="Piping Specialty Items"/>
</ByIndividualObjectRules> </ByIndividualObjectRules>

This rule is satisfied if


- Rule #1 satisfies ObjectA, and
- Rule #2 satisfies ObjectB or vice versa.

Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes

ByRulesCombination This rule qualifies clashes between Approved Underground CableTray


& Approved Underground Equipment Pits both with ‘Existing to be
Make decision based on a combination of “Rules Evaluating reused in place’ construction type.
Two Clashing Object” rules
<ByRulesCombination LimitToObjectTypes1="Cable Trays"
You can use one or more “Rules Evaluating Two Clashing LimitToObjectTypes2=Equipment">
Objects” rules under this tag. <ByObjectPG List1="Underground Cabletray" List2="Underground
This rule is satisfied if all underlying rules satisfy. Equipment"/>
<ByAttribute Interface1="IJConstructionInfo"
Control: [LimitTo/Exclude]ObjectTypes, ExcludeClashes Attribute1="ConstructionType" Operator1="EQ" Value1=":17"
Interface2="IJConstructionInfo" Attribute2="ConstructionType"
An important point here to note is, the underlying sub-rules are Operator2="EQ" Value2=":17"/>
still run atomically – that is, <ByAttribute Interface1="IJDObject" Attribute1="ApprovalStatus"
- In one sub-rule objectA/objectB of clash may satisfy the Operator1="EQ" Value1=":8" Interface2="IJDObject"
rule’s part1/part2 criteria respectively, and, Attribute2="ApprovalStatus" Operator2="EQ" Value2=":8"/>
- In another sub-rule objectA/objectB of clash may satisfy the </ByRulesCombination>
rule’s part2/part1 criteria respectively
In this situation, there is no current means to force match both
sub-rules with specific object references. This has to be
enforced by using the correct LimitToObjectTypes criteria on
each sub-rule.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 19
<SetClashProperties> Rules Section

This tag denotes a section of rules which help set the Clash properties (ClashStatus and ClashRemarks) based on objects involved in
clash, if the clash satisfies the specified criteria.
In this section you can use one or more “Rules evaluating Two Clashing Objects” (explained earlier in this document).

The rules under this SetClashProperties Tag are similar to rules under IgnoreClashesBetweenObjects. If a clash was not ignored
by any of those rules, then rules under this SetClashProperties section are evaluated to see if any rule satisfies the criteria. If a rule was
satisfied, the clash properties (ClashStatus, ClashRemarks) specified with that rule are applied to the clash.

An existing clash with its ClashRemarks beginning with “L-“ (indicates Locked by Reviewer) will NOT be processed by these
SetClashProperties rules. This is to facilitate use cases where clash reviewer manually overrides clash properties and does not want
these SetClashProperties rules end up resetting such overrides when a clash is re-evaluated upon object modifications.

To be meaningful, it is expected that at least one of following attributes be provided with such rules:

ClashStatus: Specify the Status value to set on the Clash. Can be “Undefined” or “Edit” or “None”, or their numeric values preceded
with a colon like “:1” or “:2” or “:3” respectively.

ClashRemarks: Specify the Remarks text to set on the clash. The below placeholders can be used in the text of ClashRemarks.
LastModifiedObjectUserName, FirstModifiedObjectUserName, Object1ModifiedByUserName, Object2ModifiedByUserName,
LastModifiedObjectPermissionGroup, FirstModifiedObjectPermissionGroup, Object1PermissionGroup, Object2PermissionGroup

A DataPlaceholder must be used in enclosing {{ and }} like {{LastModifiedObjectUserName}}, see below example

<SetClashProperties>
<ByObjectType List1="Piping Welds" List2="Piping Welds"
ClashStatus="None" ClashRemarks="Ignore Clashes between Piping Welds"/>

<ByObjectType List1="Pipes, Piping *" List2="Pipes, Piping *"


ClashRemarks="To be resolved by {{LastModifiedObjectUserName}}"/>
</SetClashProperties>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 20
Control Rule Evaluation

Limit Applicability of Rules

Wherever applicable, rules can be made to apply only for a specific clash situation by using below attributes which provide additional
“screening” criteria. If this screening criteria is not met, the rule is NOT evaluated. Usage of this criteria wherever required will result in
better performance by eliminating the need to evaluate them when the pre-screening criteria is not met.

Attribute for additional screening When to use


ExcludeClashes Useful if you want the clash between certain ObjectTypes (objects from List1
clashing with objects from List2) to be not evaluated by a rule.
(Only usable in Rules evaluating two objects)
With ExcludeClashes, the Rule is only evaluated if the clash doesn’t involve
Value as "ObjectTypesList1 / ObjectTypesList2" those objectTypes.
(Below in Rules evaluating one or two objects) With LimitToObjectTypes/1/2 the Rule is only evaluated if the objectTypeA/B
LimitToObjectTypes or ExcludeObjectTypes satisfy the list(s).
or
(Below only in Rules evaluating two objects) With ExcludeObjectTypes/1/2 the Rule is only evaluated if the objectTypeA/B do
LimitToObjectTypes1 and LimitToObjectTypes2 not satisfy the list(s).
or
ExcludeObjectTypes1 and ExcludeObjectTypes2 Below example rule helps ignore clashes between Pipe Welds and Piping Parts by
or using the Interfaces approach. Notice the use of LimitToObjectTypes feature
LimitToObjectTypes1 and ExcludeObjectTypes2 <ByInterfaces List1="IJRtePipeWeld" List2="IJRtePipePart"
or LimitToObjectTypes1="Piping Welds"
ExcludeObjectTypes1 and LimitToObjectTypes2 LimitToObjectTypes2="Pipes, Piping *"/>

Value is specified as list of one or more


ObjectTypes

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 21
Below example rule helps ignore clashes between Clash Situation Rule
Non-{Equipment/Equipment Foundation} objects named X Ignores ?
and Eqp X / Slab Y No
Non-{Slab, Plate} objects named Y. Eqp X / Pipe Y No
Conduit X / CableTray Y Yes
<ByName Name1="X" ExcludeObjectTypes1="Equipment, Equipment Foundation" Conduit X / Pipe Y Yes
Name2="Y" ExcludeObjectTypes2="Slab, Plate"/> Slab X / Eqp Y Yes
Slab X / Pipe Y Yes
Pipe X / Slab Y No

Clash Situation Rule Rule


Below example rule helps ignore clashes between Objects named X and Y, but Evaluated Ignores ?
Eqp X / Slab Y Yes
doesn’t apply on clashes involving {Equipment or Equipment Foundation} vs {Slab or
Plate}
Eqp X / Slab X Yes
Eqp X / Pipe Y No Yes
<ByName Eqp Y / Pipe X No Yes
Name1="X" Name2="Y" Conduit X / CableTray Y No Yes
ExcludeClashes="Equipment, Equipment Foundation / Slab, Plate"/> Conduit X / Pipe Y No Yes
Slab X / Eqp Y Yes
Slab X / Pipe Y No Yes
Slab A / Pipe Z No No
Eqp X / Plate Y Yes
Eqp Y / Plate X Yes
Eqp A / Plate Z Yes

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 22
Evaluating Rule criteria using a Related Object’s data

As an advanced option, many Single Object Rules and Two Object Rules permit you to evaluate Rule Criteria using an object related to the
object being evaluated. This is achieved by specifying the RelationNavigationPath (or RelationNavigationPath1/2) value as an
expression which tells how to reach the related object from the object being evaluated. The syntax of the expression used to specify the
RelationNavigationPath is defined below (This expression format is similar to functionality in Smart3D Automation Toolkit’s
SelectSetBrowser – just replace % with > and you can test your expressions in Select Set Browser)

RelationNavigationPath Meaning
Expression
InterfaceName%RoleName[n] From the object, navigates the relationship defined by InterfaceName & RoleName, and picks the nth
object in the related objects.

Examples: Pipe Parts to Run - IJRtePathGenPart%Owner[1]


Interface%Role(FilterInterface)[n] From the object, navigates the relationship defined by Interface & Role, filters objects implementing
FilterInterface in that list and picks nth such object.
Interface1%Role1(Interface2)[m]: Navigates related objects for Interface1%Role1, picks mth object implementing Interface2, and…
Interface3%Role3[n]: From that object Navigates Interface3>Role3 and picks nth object, and …
Interface4%Role4[p] From that object Navigates Interface4>Role4 and picks pth object.

Example: Pipe Parts to Pipeline - IJRtePathGenPart%Owner[1]:IJSystemChild%SystemParent[1]

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 23
<SetClashType> Rules Section

This tag denotes a section of rules which help change the clash category from the default value determined by internal rules per standard
Interference Check behavior. You can only use one or more “ByDefiningInterfacesAndAspect” rules in this section.

Rule Tag / Use / Expected Attributes Explanation / Example

ByDefiningInterfacesAndAspect This rule makes Piping(Physical aspect) vs Equipment(Maintenance aspect)  SOFT


<ByDefiningInterfacesAndAspect Type = "SOFT"
Set Clash Type based on involved Objects and DefiningInterfacesList1="IJRtePiping" Aspect1="Simple Physical"
Aspects DefiningInterfacesList2="IJEquipmentFurnishings" Aspect2="Maintenance"/>

Must specify below attributes This rule makes Piping(any aspect) vs Any Object(Operation aspect)  HARD
<ByDefiningInterfacesAndAspect Type="HARD"
- DefiningInterfacesList1, DefiningInterfacesList1 = "IJRtePiping" Aspect1="*"
DefiningInterfacesList2: List of the DefiningInterfacesList2 ="*" Aspect2="Operation"/>
interfaces which help narrow down object1’s
type and object2’s type. Combination of LimitToObjectTypes option and wild cards will let you do something like
Can specify “*” to match all objects. below to yield the same result as the example rules above.
<ByDefiningInterfacesAndAspect Type = "SOFT"
- Aspect1, Aspect2 DefiningInterfacesList1="*" Aspect1="Simple Physical"
Aspect of the object1 and object2 to match LimitToObjectTypes1="Pipes, Piping *"
(only ONE aspect expected, not a list) DefiningInterfacesList2="*" Aspect2="Maintenance"
LimitToObjectTypes2="Equipment"/>
- Type – ClashType to set – specify
HARD or SOFT or IGNORE. <ByDefiningInterfacesAndAspect Type="HARD"
DefiningInterfacesList1="*" Aspect1="*" LimitToObjectTypes1="Pipes, Piping *"
Control: [LimitTo/Exclude]ObjectTypes, DefiningInterfacesList2="*" Aspect2="Operation" LimitToObjectTypes2="*"/>
ExcludeClashes, RelationNavigationPath
This rule makes Member Parts(Fireproofing Insulation) vs Anything(Physical)  HARD
<ByDefiningInterfacesAndAspect Type="HARD"
DefiningInterfacesList1="*" Aspect1="*" LimitToObjectTypes1="Insulation"
DefiningInterfacesList2="*" Aspect2="Simple Physical" LimitToObjectTypes2="*"/>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 24
<AspectToUseForClashDetection> Rules Section

This tag denotes a section of rules to override the aspects used for clash detection; configurable using two sub tags – Default, and
ByObjectType.
The Default tag specifies the default Aspect to use for objects in the Clash calculation - By default, “Detailed physical” aspect of the object
is used.
The ByObjectType tag, specifies a List attribute with comma separated list of ObjectTypes, and an Aspect attribute specifying the aspect
to use for those ObjectTypes. This lets you override the default aspect, e.g. “Simple physical” aspect for those ObjectTypes. Here are the
typical rule entries.

<AspectToUseForClashDetection>
<Default Aspect="Detailed physical" />
<ByObjectType List = "Pipe Supports, Duct Supports, Cable Tray Supports" Aspect="Simple physical"/>
</AspectToUseForClashDetection>

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 25
<CustomIFCRule> Rule

This tag lets you write programmatic rules if you cannot achieve the same using codeless rules in the configuration file. Basically you
can configure custom (VB6) IFCRule ProgIDs of your own. You can use this <CustomIFCRule> tag in
<IgnoreObjectsForClashChecking>, <IgnoreClashesBetweenObjects> and <AspectToUseForClashDetection> sections. The below
steps explain how to do this.

1. Write your custom ProgID and implement the IFC Rule interfaces (IJDInterferenceRule, IJDInterferencePrePrcsrRule,
IJDIntfPrePrcsrRuleForeign)

2. Specify the ProgID string of your Custom IFC Rule in the ProgID attribute on this [CustomIFCRule] tag in the desired section.

Notes
2.1. You can also use the screening criteria attributes [LimitTo | Exclude]ObjectTypes/ExcludeClashes to limit the evaluation of a
rule to few ObjectTypes (it is highly recommended in this case for performance reasons, if your Custom Code based rule is
written specifically to only handle certain ObjectTypes).
2.2. You can specify multiple CustomIFCRule rules with different screening criteria – this facilitates writing focused and separate
Coded rules (separate progIDs) for some specific clash situations. The first qualifying rule’s result will be used.

<CustomIFCRule ProgID="MyCustomIFCRule.ProcessorRuleA" LimitToObjectTypes="<specifyA1,2,3>"/>


<CustomIFCRule ProgID="MyCustomIFCRule.ProcessorRuleB" LimitToObjectTypes="<specifyB1,2,3>"/>

3. Deploy the Custom IFC Rule DLL(s) in the same folder (SymbolShare\Custom Symbols\ClashMgmt)

4. Run “Update Custom Symbol Configuration” from ProjMgmt task.

5. If no text based rule ignores your object or clash, and if your object type(s) satisfy the [LimitTo | Exclude] ObjectTypes /
ExcludeClashes criteria specified if any – the custom ProgID is invoked. If the Custom ProgID returns false, then the object/clash is
ignored.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 26
Optimization / Fine tuning of Rules

 As described in above sections, several of the rules let you specify ObjectTypes as part of the rule criteria.

To know the exact string to use for such ObjectTypes attribute, you can refer to “Classification TopNodes” node in MetaDataBrowser. Make
sure you provide the value from the “User Name” field.

You must only use exact ObjectTypes like “Piping


Components”. Higher level BOC nodes, like “Piping” are not
honored.

You can use Wildcards – like “Piping *” can cater for


“Piping Components, Piping Specialty Items, Piping
Instruments, Piping Welds”.

The exact ObjectType of the object is written in the CodelessIFCRule log file like below when the object is processed, so you can refer
the log file as well to know what ObjectType to use.
@2/3/2015 4:54:13 PM - ProcessObject ? [Piping Components] - 'Flange-0403'

@10/28/2014 12:44:10 AM - CreateInterference ? - [Slab] - 'Slab-0101' & [Member Part Linear] - 'MemberPart-0202'

 For Post Processing Rules which support “LimitToObjectTypes1 and LimitToObjectTypes2”, if your situation is such that their values
are going to be identical, you can simplify by just specifying LimitToObjectTypes (similarly for ExcludeObjectTypes).

 Several of the rules support wild cards for other Rule Criteria attributes as well.

To know how wild cards can be specified, see section named “Advanced String Comparisons Using the Like Operator” in
http://www.vb6.us/tutorials/conditional-expressions-visual-basic-tutorial.

Smart3D – Interference management Using Codeless IFC Rules Setup, Administration & Customization Guide 27

Potrebbero piacerti anche