In a Building Information Model (BIM), it is common to model spaces defined as gross areas, apartment areas, departments, etc. that group other spaces. This is accomplished in Revit through area plans, and the IFC exporter in Revit provides area information in the “Other” property set.
Below is a gross area space named Circulation that contains circulation rooms (as defined in Revit) such as Lobby 102, Stair 132, and Corridor 107, listed in the Space Grouping view:
Notice in the Info view, the “Other” property set contains the Area Scheme ID and Category properties. The Area Scheme ID provides the name of the area scheme, such as Gross Area, Apartment, etc., and the Category property states whether the space is a room, space, or area. Also, notice in the Space Grouping view, the Space Group Type column lists Gross Building, which is the same value as the Area Scheme ID. This value is the classification name from the Space Grouping classification.
If the Corridor 107 room is selected, the Area Scheme ID property is not defined because the category of the space is a room and not an area.
These properties in the Other property set make it simple to classify space groups in SMC using classification rules in the Space Grouping classification. Below, we’ve added a row to the classification rules that matches any spaces that have the value “Areas” in the Other.Category property. Those area spaces will have their classification name set to whatever the value is of the Other.Area Scheme ID.
You can download this modified space group classification from the link below to try with your own Revit models that contain area plans:
In an earlier article, Creating Classifications in SMC, we briefly touched on using wildcards characters in classification rules. This article will provide more details on their use and provide tips to avoid misclassifications.
There are two wildcard matching characters that can be used in classification rules: * and ?
*– Matches 0 or more characters ? – Matches exactly 1 character
The best way to learn their use is by looking over some of the existing, complex classifications that come with SMC. One is the latest, updated “Building Elements” classification that classifies components based on their properties to a Uniformat II classification.
Open the SMC Building.smc example project that comes with SMC, and check the classification settings of the Building Elements classification.
Notice many of the cells in the table contain only a single asterisk (*). This means to ignore the cell and whatever the value is of that property isn’t required to match anything specific to classify the component. As an example, notice the first 3 rows for column, pile, and footing components. It doesn’t indicate what the value is of the type, layer, and name properties. These components will always be classified as “A2010 Basement Excavation”. In fact, the Name column contains asterisks for all rows and could simply be removed from the table without affecting the classification. However, it was left in, as your building authoring tool and its libraries may have component names that more easily and effectively can be used to classify objects to UniFormat II, and you may wish to add your own rows to classify, based on Name.
It is important to note that asterisks must be used rather than leaving a cell blank to ignore the value. If the cell is left blank, that row would only match if the value of the property was an actual empty string or missing value. As such, you would only use a blank cell to classify a component based on a missing property value.
Notice also that wall components are classified as B2010 Exterior walls in the 5th row of the table.
However, if you look at how the walls are classified in the model, some are classified as B2011 Exterior wall construction, B2015 Balcony walls and Handrails, and C1010 Partitions. This is because the best match radio button is selected in the bottom of the classification rules. If you switch the settings to First Match, you’ll see that all walls are then classified as B2010 Exterior Walls.
When Best Match is used, whatever classification row has the most characters matching is the one used to classify.
Notice the rows that classify walls as C1010 Partitions. Any walls with a type value that starts with “Basic Wall:” and thereafter contains the word “Interior” is classified as C1010 Partition. This is due to the cell containing “Basic Wall: *Interior*“. The same holds true for walls with a type value that starts with “IW” using the matching cell “IW*“.
Notice the rows for walls with type values that start with “EW”. The rows that contain dashes and a number are more precise wall classifications, such as EW-3 which is classified as B2015 Balcony walls and Handrails.
However, if the number is anything other than 2, 3, or 4, but the type value still starts with EW, the wall is classified as B2011 Exterior Wall Construction.
In the previous article Disciplines in SMC, we explained how the discipline of a file opened in Solibri Model Checker (SMC) is useful in the color mapping of components and use in rule filters. Currently, these disciplines are hard coded and limited to those in the list below:
The discussion of disciplines arises during coordination when checking for intersections between systems. Namely, what discipline to set files to as they are added to the federated model and what disciplines to check against each other using the general intersection rule in SMC. Classification within SMC makes it simple to automatically map your files using your own naming convention to any custom discipline you would like to create.
For example, you may have a different naming convention of disciplines and use the term “Mechanical” rather than “HVAC”. Also, you may have a “Communications” model that is differentiated from the “Electrical” model(s), for which a discipline doesn’t exist within SMC.
This example model was created by exporting the Architectural, MEP, and Structural versions of the advanced sample project that comes with Revit 2016. For the MEP sample project, we also isolated components during each IFC export based on the discipline of Mechanical, Electrical, and Plumbing to further divide the entire federated model into 5 IFC files based on each discipline.
When you first open all 5 IFC files, the Ensure Model Disciplines window will open to allow you to set the short name and discipline from a set list in SMC.
Short names are always manually entered or left to their A-Z defaults. However, the discipline can be automatically mapped based on the application that created the file, or the file name. The file was exported from Revit 2016, which is a building authoring tool that can contain components from any discipline, unlike other applications that specialize in a specific discipline, such as Tekla Structures, Revit Architecture, Revit Structure, etc. As such, it simply defaults to the Architectural discipline. The out-of-the-box File Name mapping is left as *.* and to ignore the file name, as it is up to the user to define their own mappings based on their own file naming convention.
We’ll manually set the short name to the first letter of the discipline and set the discipline to one of the hard coded disciplines in SMC. For instance, we map the Mechanical file to HVAC and the Fire Protection model to Sprinkler. This will allow you to use the out of the out-of-the-box interference detection rules that come with SMC to check discipline against discipline.
For example, one such rule checks all Building Services components that intersect with beams and columns from Structural models. Below, we see in the results view there are 207 intersections with beams and 30 with columns. In the Checked Components view, these intersections occur in the electrical, mechanical, plumbing, and structural models.
Opening the rule parameters of this rule, in the component filter table for Component 1, only beams and columns from disciplines related to Structural components (Prefab Concrete, Steel Structure, Structural) are checked. For Component 2, any component excluding Covering, Space, Cable from disciplines related to Building Services (Air Conditioning, Building Services, Cooling, Electrical, etc.) are checked.
Listing all the various disciplines that fall under the category of Structural vs Building Services models leaves flexibility for users for what they select as their disciplines when they first load their models.
You are able to isolate the results by discipline though selecting the file(s) of that discipline in the Checked Components view, setting the file(s) to the selection basket, and selecting Filter with Selection Basket (some) in the Results view. Below, we see there are 169 intersections with beams and 16 intersections with columns between the HVAC model and the Structural model.
The intersections between just the electrical model and structural model can be viewed using this same method as seen below:
Depending on the number of files, disciplines, and naming conventions, you may find that you wish to fine tune your interference detection checks to individual disciplines and/or even disciplines, such as “Communications,” that are not included in the hard coded ones. This can be achieved through the use of classification.
Open the Classification view by clicking Add View > Classification . You’ll find a “Discipline by File Name” classification is loaded. If you expand the classification, you’ll find that components in the model are classified by their discipline:
Open the settings of the Classification by selecting the classification and clicking the Settings button. In the Components filter parameters table, you see that all components are to be classified. In the Default Classification Names, you see a listing of various disciplines. You can add to or remove these depending on your own requirements. Show Unclassified is marked to make it easy to see if any components in the model haven’t been classified to a discipline.
Click the Classification Rules tab to view how the file name is used to map to a specific discipline. Every component has a Model parameter in the Identification property group, which is the short name and file name of the model that component resides in. For example, if “ELEC” appears anywhere in the file name, the components in the model are mapped to Electrical. This is achieved using “*ELEC*” to match the value of the Model parameter. If you specify the discipline in the file naming using a single character separated by underscores (_) or dashes (-), such as in the name “01_A_RME_Advanced_Sample_Project,” those components are classified as Architectural using “*_A_*” to match the value of the Model parameter. Lastly, you can specify the discipline in the file name using a single character at the beginning of the file name preceding a dash or underscore. However, since the short name of a file precedes the file name in the Model parameter, “(*) P-*” is used to match the value “(P) P-rme_advanced_sample_project” to Plumbing.
Depending on your own naming convention and disciplines, you can modify the values in the Model column to match your file names accordingly.
In the Checking view, if you select the rule STRUCT vs MECH, the same results are listed for Beams and Columns in the Results view as the out-of-the-box rule “Building Services and Beams and Column” when filtering by selection basket after selecting the HVAC model, seen in the prior screenshot.
Likewise, if you select the rule STRUCT VS ELEC, you’ll see the same results as previously seen in the “Building Services and Beams and Column” after selecting the Electrical model and filtering by the selection basket.
If you open the rule parameters of the STRUCT VS MECH rule, you’ll see that rather than using the Discipline parameter, the “Discipline by File Name” classification is used to filter what components to include.
Creating your own discipline classifications can make it easier when setting up your coordination rules based on disciplines if you have disciplines outside the ones available out of the box in SMC. Using classification rules, you can automatically map your files based on their filename to those disciplines.
The recently released Solibri Model Checker (SMC) version 9.6 introduces support for “Date” properties. Rather than plain text, these properties include Month, Day, Year and Time of Day information from IfcDate properties. This allows components to be classified and visualized based on schedule information, as well as checks to be run against workflow schedules via rulesets. The following article provides details on how to set up the visual display of date properties in the settings of SMC, create date-based schedule classification, and generate Information Takeoffs that group components based on a construction schedule.
Date Unit Settings
SMC allows you to customize the date and time formatting, based on your own localization by clicking File > Settings > Units. For example, in the United States, dates are often formatted as MM/DD/YYYY as seen in the settings below:
This results in all date information in SMC being displayed in this format, as seen in the Info View below:
In many other countries, dates are formatted as DD/MM/YYYY, which is one of 18 settings that can be chosen from the File > Settings > Units > Date Format dropdown:
Through this date format setting, all dates are displayed as DD/MM/YYYY as seen below:
Classifications Using Date Information
The Classification View has been enhanced to support Date information in SMC. For more information on Classification in Solibri Model Checker, please follow the link below:
In the ClassificationSettings, a Use Dates as Classification Names checkbox has been added. When selected, only dates can be used as classification names, and a date picker is provided to ensure a valid date is entered in the Classification View screens.
When creating any classification, SMC will look at a property of a component and based on the value (in this case, the date) generate distinct date classifications for use in SMC.
To begin using date information in a Classification, first ensure the date information is present in the model. In this example, the date information is coming from the WORKFLOW information tab. Each component in the model should contain this schedule information.
Switch to the Information Takeoff view to display the Classificationwindow. From here, we can generate new Classifications using the date information.
Select ClassificationSettings. In this example, the Classification is using the property PLANNED_START_E to define the classifications, and the Classification Name will be the same as the value of the property (in this case, the date).
If the PLANNED_START_E date changes with new updates of the model, the Schedule Classification will also change to reflect the new dates.
In Classification Settings you can create a date constraint to limit the dates that are classified by double clicking on the PLANNED_START_E column. Below, the constraint has been set to only create a Classification for dates between March 31, 2015, and April 30, 2015.
As a result, the only displayed Classifications listed under Schedule are dates within the specified date range.
In addition to being a useful tool for managing the model and checking schedule compliance, Schedule Classifications can also be used in an Information Takeoff. The construction of components can be visualized by selecting rows sorted by construction start date. Other quantity information such as counts of doors or windows, or lengths of beams can be added as columns as well, to provide schedule-based quantity takeoffs.
The newly released version (9.6) of Solibri Model Checker (SMC) includes an option to create presentation slides directly from information takeoff definitions. The Information Takeoff view in SMC is a perspective that allows a user to visualize and aggregate model components based on their property information. After generating an Information Takeoff, you might wish to generate a set of slides or views showing each row, or selective rows of the Information Takeoff results. These slides can remain in the model for later use in review sessions, or they can be exported in a formatted report.
The following article demonstrates this capability through a scheduling Information Takeoff that groups components based on their start dates of construction. In addition to automatic slide creation through Information Takeoff, version (9.6) introduced the entirely new ‘Date’ unit type. These separate new capabilities complement each other well in version (9.6). A more detailed explanation on date information in SMC can be found here:
To begin, run an Information Takeoff (ITO) and generate the results you would like to visualize (for help using ITO, select the video icon in the upper right corner of the Information Takeoff view to watch a short video explanation).
When done, the model should be color-coded based on the properties defined in the takeoff. In the example below, a takeoff has been run separating all model components by start date:
Select individual rows of the Takeoff to display the components built on each date, separately.
These individual row displays can be auto-generated as slides/views from the Communication Tab.
From the Communication Tab, select “Create Presentation.”
You will see the options to generate a slide “From Information Takeoff Results.”
The Presentation from Schedule Visualization Window dialog will open.
The following is a listing of the various options of the Presentation from Schedule visualization dialog:
Create Issues From Rows:
Create Issues fromRows: If you would like to see the views as they are displayed when selecting a single row in Information Takeoff, choose the option to view “Each Individual Row.”
Include Previous Rows: Select this option if you would like the views to be cumulative, so the previous rows are added to the new view. For example, if you want the first slide to display the footing built on 2015-04-29 and the second slide to include both the footings and the columns that are built on 2015-04-29, choose the option to “Include Previous Rows.”
Define Issue Details By Template Columns: These options allows the user to decide which Column from the Information Takeoff View will be used as the Title and Description for the slides/views.
Components and Visualization
Link Components to Issue: Components in the slide will be linked to the view for later use in the Detailed Report (XLS) option.
Autozoom to Components: Positions the view as close-in as possible to fill the 3D window with the relevant components.
Under Create Issues From Rows, select Include Previous Rows, and then click Create.
The slides displayed now reflect the individual rows from the Information Takeoff. These slides will remain with the .SMC model for future use, and can also be exported via the “Report” button.
From Report, Select the XLS button and select Ok (For this example, we will generate an XLS report, but note that other options, such as PDF and BCF are available as well).
Excel will automatically open and display the new XLS report, reflecting the slideshow that has been generated in SMC using Information Takeoff.
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.
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:
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.
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:
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.
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.
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.
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.
Classifies components based on their UniFormat Code mapping classification to a UniFormat II classification if it exists.
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 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.
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 .
Once the UniFormat Version is set, the ruleset should look similar to this:
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:
By selecting ShowPassed in the Checked Components View, we see the 108 components isolated in the model that passed the check and do have 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:
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:
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.
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.
The COBie Platform and COBie-US Resources extensions verify and validate COBie information within your model, based on US requirements, as well as exporting this validated information into a COBie XLSX spreadsheet. This article provides an introduction to those who haven’t used these extensions before in Solibri Model Checker (SMC).
This file is an IFC exported from Revit 2014 of the Native BIM File provided by Autodesk for the January 2014 buildingSMART alliance Challenge. Information on this can be found here: January 2014 bSa Challenge: Autodesk
COBie information was populated in the model using the COBie Extension for Revit. Information on this extension as well as the download can be found here: BIM Interoperability
There are many resources required in order to validate your COBie information and generate your COBie spreadsheets within SMC. The roles included in the COBie-US Resources extension link to those resources in order to automatically load the correct ones based on your requirements of COBie.
Click File > Settings > General and check if the Show RoleSelection checkbox is marked. If it is not marked, mark the checkbox, close, and reopen SMC to enable the Role Selection wizard.
Click File > Open and open COBieChallenge2014_Arch+MEPFinalA_optimized.zip.
In the Ensure Model Disciplines dialog that opens, select Architectural, and click OK.
The 3D View displaysa medical clinic that includes both architectural and MEP components. The structural model wasn’t included in this combined model, which is why the model is missing roofs and slabs. If you select one of the components using the Info Tool, such as the chiller in the image above, the Data tab of the Info View lists COBie information that was populated using the COBie extension for Revit.
Click the Checking Layout tab and the Please Choose a Role dialog will open. Mark the COBie-US OmniClass 2006 role and click Next.
Leave all three rulesets selected and click OK to open the rulesets along with the default classifications and ITO definitions associated with the role.
COBie uses a classification system to categorize a facility, space, element, and product, which correspond to items listed in the Facility, Space, System, and Type sheets respectively. This role opens the Rulesets, Classifications, and ITO definitions associated with the US requirements for COBie using the 2006 version of the OmniClass classification system for the categorization of components in the model. OmniClass is a hierarchical classification system that uses numeric codes to classify items. These classification tables were released in 2006 and updated in 2012 with different numeric codes, which is why there is a 2006 and 2012 listing in the role selection dialog. This example model uses codes that were released in 2006, which is why the role was set to COBie-US OmniClass 2006. More information on OmniClass can be found here: http://www.omniclass.org/
Classification – MAp to COBie Data Within the Model
There are over 60 classifications included in the COBie-US Resources extension. Most of these classifications are simply mappings to the locations where COBie information will likely reside in a model. Some also classify objects based on values being valid and from the PickList worksheet of the COBie spreadsheet. These classifications are used in rulesets to ensure that the COBie information is present and valid. Also, these classifications are used to populate the COBie spreadsheet.
Click the Model Layout tab
Click the AddView button and select Classification if the ClassificationView isn’t already open.
In the Classification View, scroll down the list to find the classification COBie Type – ModelNumber and expand this classification.
Double click the 250-150000 classification, expand the classification, and select the components that have been classified with this Model Number. The camera in the 3D View should zoom to the 3 paper towel dispensers that have this model number. In the Data tab of the InfoView, you’ll find a property with the name COBie.Type.ModelNumber that has a value 250-150000.
Select the COBie Type – ModelNumber classification and click the Classification Settings button.
In the ClassificationRules table, either the wildcard matching characters * or ?* are listed in the cells of the ArchiCADMapping, RevitMapping, and Name columns. Also, =3, =2, and n/a are listed in the cells of the Classification Name column. The ClassificationMethod is set to FirstMatch; therefore, the first row checks a component to see if there is a value present in the location from the Revit Mapping column using the ?* wildcard matching characters. If so, that value from the third column is set as the classification name for the component, using the value =3 in the ClassificationName column. If no value exists in the location from the RevitMapping column, the second row checks if a value exists from the ArchiCADMapping column. If so, the classification rule sets the classification name of the component to that value from the ArchiCADMapping column. If no value exists in either location, the third row checks if a Name exists for the component, and if there is, sets the classification name of the component to N/A, since no model number exists for the component.
Double click the RevitMapping column header.
In the SelectProperty dialog, the property set location is the propertynameCOBie.Type.ModelNumber from the propertysetData. This is the same location previously noted in the InfoView and the location that the COBieExtensionforRevit places this specific COBie property for components in a model.
Double click the ArchiCADMapping column header.
In the SelectProperty dialog, the property set location is the propertynameModelLabel from the propertysetPset_ManufacturerTypeInformation. This is the location specified in the GRAPHISOFT ArchiCAD and COBie 2 document, which bases the location on the COBie – IFC Mapping rules found in the Responsibility Matrix Version 17 document. These documents can be found online in the links below:
– GRAPHISOFT ArchiCAD and COBie 2 – COBie Responsibility Matrix
Whether using ArchiCAD or Revit, this classification should map to the location of the ModelNumber COBie property in your IFC model. If your model uses a different location than these, you are able to add an additional column for that location of the property and add an additional row to the top of the classification rules to map the classification name of components to that location.
In the ClassificationView, scroll to, expand and select the COBie Space – Category – OmniClass 2006 > 13-15 11 34 11: Office Classification.
In the 3D View, all rooms that are classified as offices through the use of an OmniClass 2006 classification code are isolated and colored grey.
With the COBie Space – Category – OmniClass 2006 classification selected, click the Classification Settings button.
In the listing of classification rules, there is a row that maps a value 13?15?11?34?11* from the location specified in the RevitMapping column to the classification name 13-15 11 34 11: Office. Since OmniClass codes may use a notation that separates the digits with periods (e.g 22.214.171.124.11), the question mark (?) wildcard matching character is used. So long as there is a single character, which could be a space, dash (-), or period (.), this wildcard matches that character. There is an asterisks (*) at the end of the code since the code may include the description (e.g. 13-15 11 34 11: Office). More information on these wildcard matching characters used in classification can be found in the article: Creating Classifications in SMC
Double-click the RevitMapping column header.
In the SelectProperty dialog, the property location is the propertynameCOBie.Space.Category from the propertysetData. This is the property location that the COBieExtensionforRevit places the Category COBie property for spaces in a model.
NOTE: If you double-click the ArchiCADMapping column, it maps to a random classification that currently exists in this model, since the classification it is supposed to map to doesn’t exist in this model. However, if you open an IFC exported from ArchiCAD that was created using the processes outlined in the GRAPHISOFTArchiCADandCOBie2 document, this column maps to the OCCS – Space by Function classification, which is an IFC Classification that is included in the IFC model.
Rulesets – Verify COBie Information within the Model
Both the COBie-US OmniClass 2006 and COBie-US OmniClass 2012 roles include three default rulesets to verify/validate that the COBie information in the model exists, by checking that a property exists and a value is defined for it. In addition, these rulesets also have the ability to check that the value of the properties are valid, by checking that the value is one of those that exists in the PickList worksheet of the COBie spreadsheet, or that the value is unique where required:
COBie Extension for Revit: This Ruleset verifies that COBie properties have been defined in an IFC exported from Revit 2014 or later using the COBie Extension for Revit.
Responsibility Matrix Version 17: This Ruleset verifies that COBie properties have been defined in a model based on the COBie – IFC mapping rule Responsibility Matrix version 17.
COBie-US Property Verification: This Ruleset verifies that COBie properties have been defined in a model either through the COBie extension for Revit or based on the COBie – IFC mapping rule Responsibility Matrix version 17.
NOTE: Since the locations of COBie properties differ between the COBie Extension for Revit and Responsibility Matrix Version 17, if you are using the COBie Extension for Revit, it is recommended that you open the COBie Extension for Revit ruleset in SMC, and not the Responsibility Matrix Version 17ruleset. Likewise, if you are populating your COBie information based on IFC Mapping Rules of the Responsibility Matrix Version 17 document, it is recommended that you open the Responsibility Matrix Version 17 ruleset, and not the COBie Extension for Revit ruleset. However, the COBie-US Property Verification checks COBie information using the COBie mapping classifications mentioned in the previous section, and should be opened in either case.
Click the CheckingLayout tab.
In the CheckingView, click the Check button.
Expand the COBie Extension for Revit > Space ruleset and select the rule COBie.Space.Category.
This rule passes without any results since all 269 rooms in this model have a space category defined in the property COBie.Space.Category of the property set Data. In the CheckedComponentsView, you can verify all 269 spaces in the model were checked and passed the check of this rule. In the Info View, the description of the rule states where this COBie property resides in a model that was created using the COBie Extension for Revit.
In the CheckingView, expand the COBie Extension for Revit > Type ruleset and select the rule COBie.Type.ModelNumber.
In the ResultsView, results are grouped by the component type of the components that are missing a ModelNumber value in the COBie.Type.ModelNumber property of the Data property set. For example, none of the Air Terminals in this model have a Model Number. In the CheckedComponentsView, 51 components in the model are shown as passing this check, as those components have a value defined in the Data.COBie.Type.ModelNumber property
In the CheckingView, expand the Responsibility Matrix Version 17 (OmniClass 2006) > Type ruleset and select the rule [ModelNumber]: Is defined for Types.
In the ResultsView, all components have failed this check, including the 51 components that passed the previously mentioned check, since the COBieExtensionforRevit populates the property Data.COBie.Type.ModelNumber, rather than the property Pset_ManufacturerTypeInformation.ModelLabel as defined in the ResponsibilityMatrixVersion17 document.
In the CheckingView, expand the COBie-US Property Verification (OmniClass 2006) > Type ruleset and select the rule [AssetType] Exists in the Type-AssetType PickList.
In Picklist sheet of the COBie spreadsheet, the AssetType column lists only Fixed or Moveable as acceptable values for the AssetType property in the Type sheet.
The rule parameters of this rule ensures that components have one of these two values defined.
In the ResultsView, one of the doors in this model does not have a value of either Fixed or Moveable for the COBie property AssetType. This is an example of rules within SMC not only checking that information is populated, but also validating those values based on what is allowed as stated from the Picklist worksheet.
In the CheckingView, expand the COBie-US Property Verification (OmniClass 2006) > Space ruleset, right-click the rule [Name] : Is Unique for Spaces, and select Rule Parameters.
The values in the Name column have to be unique in the Space worksheet of a COBie spreadsheet. The [Name] : Is unique for Spaces rule returns any spaces that don’t have a unique name as results. In addition, if the room numbers in your model are to follow a special naming format (e.g. A104C), you can modify the Format section of the rule parameters with your own requirements.NOTE: The Name column in the Space worksheet is normally populated with room numbers. The room names in a model normally populate the Description column in the Space worksheet.
The COBie View: Visualize COBie information within a Model
The COBie View displays COBie information within your model similar to what is seen in a COBie Spreadsheet. In addition, you are able to select the rows within the COBie View to zoom to and isolate the components that correspond to those rows.
Click the COBieLayout tab.
Click the AddView button and select InformationTakeoff
Dock the InformationTakeoffView above the COBie View. SMC should look similar to the image below:
In the COBie View, click the Click to open COBie Settings… button.
In the Open COBie Settings dialog, select COBie – OmniClass 2006.xml from the Resources tab and click Open.
In the COBie View, click the COBie Settings button.
In the Resources table of the COBie Settings dialog, notice the COBie sheets map to ITO definitions in order to populate information within the COBie spreadsheet.
Click the cells that say Fill Automatically in the Fill column for the Attribute and Coordinate sheets and set their values to Do not Fill.
In order to save time during the population of the COBie spreadsheet, for this example, we leave these sheets unfilled.
Click the Attributes tab of the COBie Settings dialog.
In the IncludedPropertySets tab, multi-select all attributes in the list and click the Exclude -> button to remove them from the list. Click OK.
In the COBieView, click the Calculate button. SMC will open the ITO definitions that map to the sheets as specified in the COBie Settings dialog, and will begin populating the sheets in the COBie view. You’ll see a progress bar at the bottom of the screen stating that Information Takeoff Definitions are being calculated.
Click the Component sheet at the bottom of the COBieView.
Double click some of the items from the rows listed. For example, in the image below, we double clicked the Towel Dispenser component with the name 100_453335.
Upon double clicking the row, the camera zooms within the 3Dview to that component and isolates it along with the space where it resides. This component is also selected with the InfoTool, to view its property information within the Info View.
Notice the red arrows that denote flow of COBie information from the property of the component in the InfoView to the cell in a worksheet within the COBieView. The value for the Data.COBie.Component.Description property is the classification name of the component in the COBieComponent – Description classification. This classification name is what populates the value in the Description column for the component in the COBieComponent ITO definition within the InformationTakeoff View. The Component sheet within the COBie view maps to the COBieComponent ITO definition to populate the sheet. Through this flow of information, should you need to change the location of a COBie property, you only need to modify the classification rules for that COBie property by adding a column for the property location and an additional row at the top of the classification rules list to set the classification name to the value within that column.
Reporting – Export COBie Information to an XLSX Spreadsheet
Once you have validated and calculated the COBie information within the model you are ready to export to a standard XLSX COBie spreadsheet.
In the COBieView, click the Report button.
Provide a location to save to and a file name and click OK.
Once the spreadsheet finishes exporting it automatically opens in your default XLSX viewer.