CCI stands for Construction Classification International (CCI) and represents the construction classification system for the whole building lifecycle. The CCI classification framework is based on ISO 12006-2 and tables are divided into two key groups: (a) CCI core tables (Built space, Construction complex, Construction entity, Construction element: Functional system, Technical system, Component) and (b) localized tables (all other tables). Therefore CCI-EE represents CCI core tables + localized tables from the sections of construction process and construction resource. CCI core tables are based on IEC/ISO 81346 standards, while CCI-EE tables on other standards, guidelines which partly have been used before the CCI-EE applications. CCI core tables can be accessed from https://cci-collaboration.org/ and CCI-EE tables (also with English terms/definitions) from https://ehituskeskus.ee/kasulikku/cci/.
In this post we take a look how CCI/CCI-EE can be applied through various software applications which are commonly used in construction lifecycle tasks, covering both, buildings as well as infrastructure. The core idea is to ensure the same classfication structure from various platforms once exported into various open data formats.
The current list of software platforms:
- Templates (draft)
- Classification examples
- Autodesk AutoCAD
- Autodesk AutoCAD Architecture / MEP
- Autodesk Civil 3D
- Autodesk Revit
- Autodesk AutoCAD Architecture/MEP and Civil 3D: CCI-template-ENG-ACAD_CCI-EE-2022.01.0.1.dwt
- Autodesk Revit: CCI-template-ENG-Revit-BIT_CCI-EE-2022.01.0.1.xlsx (SP_ClassificationManager.txt)
- Autodesk Revit: Shared-Parameters-ENG-Revit_CCI-EE-2022.01.0.1.txt
- Autodesk AutoCAD Architecture/MEP and Civil 3D: CCI-template-EST-ACAD_CCI-EE-2022.01.0.1.dwt
- Autodesk Revit: CCI-template-EST-Revit-BIT_CCI-EE-2022.01.0.1.xlsx
- Autodesk Revit: Shared-Parameters-EST-Revit_CCI-EE-2022.01.0.1.txt
Note: Sample templates for AutoCAD Architecture, AutoCAD MEP, Autodesk Civil 3D are based on default templates into where CCI (CCI-EE) sections are added: Property Set Definitions, List Definitions, Classification Definitions.
Note: Sample “template” for Autodesk Revit is a Excel file to be used with BIM Interoperability Tools (Classification Manager). In addition (depending on Revit & BIM Interoperability Tools version) you may need to copy SP_ClassificationManager.txt shared parameter file into: C:\Program Files (x86)\Autodesk\BIT\2022\Resources\ (this is known bug in Revit 2022 and hopefully it will be fixed soon and updated also in this post).
Note: File names include the reference to CCI / CCI-EE table version. For example, template “CCI-template-ENG-C3D_CCI-EE-2022.01.0.1.dwt” is updated according to CCI-EE Excel file version: CCI-EE-2022.01.0.1.xls.
In this section sample products are tested according to provided templates.
Autodesk AutoCAD fits into various modelling tasks and it can be used to generate various data for BIM/FM models but as it does not support the addition of property sets and/or classification system that can be exported into IFC, it is skipped in here, but we come back to that later, because general 2D/3D components can be classified through AutoCAD vertical applications like AutoCAD Architecture, AutoCAD MEP, Autodesk Civil 3D. It is also important to mention that as there are many platforms that use AutoCAD as its base platform, that those workflows should be also “upgraded” into verticals or some additional plugin should be used.
AutoCAD Architecture / MEP
AutoCAD Architecture / MEP is well-known, construction-component-based, modelling platform before the Autodesk Revit came along (from Autodesk side). And to some extent it is still commonly used, as there are plenty of other software applications that use it as a base product (ex. hsbcad, MagiCAD). It also supports IFC export.
General for AutoCAD Architecture / MEP / Autodesk Civil 3D: The key in here is to use Style Manager. Under the node Multi-purpose Objects > Classification Definitions, you define those classification definitions based on CCI (CCI-EE) tables.
As each definition should have some unique value, this is given through properties table (see: CCI-EE, RI table), in where we can find all available properties listed. For example, CCI Component table code is coming from the section AC, and has a unique code of AC075.
The name also includes some text which is as short as possible but the key is to make it understandable/readable from different packages/software/viewers etc. Therefore, Classification Definition AC075_cciCOcode is so called parameter name which uniquely identifies its content and will be userd across other platforms as well. Content of the definition is directly coming from CCI-EE, CO table and includes class code + term which helps to apply it onto objects at later stage. Those Classification Definitions can be applied to various design object types through a tab Applies To.
Those classification values can be then applied through Properties palette and once exported into IFC, it will be added into IfcClassificationReference section.
IfcClassficationReference after export as seen in Trimble Connect.
General for AutoCAD Architecture / MEP / Autodesk Civil 3D: In addition to Classification Definitions, List Definitions are also added into the template. This simplifies to generate level codes (reference designation system) in Property Set Definitions.
General for AutoCAD Architecture / MEP / Autodesk Civil 3D: In addition, Style Manager is used to generate various sample Property Set Definitions (available in Templates). Property Set Definition name will start with the section name (data template) from CCI-EE, RI table and will include a number to make that set unique which defines the list of properties as well as default units etc. Down below performance related properties are included and each property starts with their unique class code which makes them comparable across the platforms. Name after the unique class code is again a short, recognizable (human readable) name that follows the CCI-EE, RI table but should not be misleading.
Some other property sets are generated according to CCI-EE, RI table (for example name/type related information is coming from section AN).
For reference designations in where multiple codes are put together, another property set is generated and because it is coming from CCI-EE, RI section AC, its name starts with AC + some number to make it unique.
Those reference designations are usually calculated and will include the template of the complete string. It also uses the Classification Definition code as its base and will add properties as needed. Different levels can be created and those are listed in AC section (CCI-EE, RI table).
Those Property Set Definitions can be generated for all objects or you create separate RDS Property Set Definition for different object types. But you should use different names, like AC01_RDS(component1), AC02_RDS(component2), … AC76(componentN)… And those Property Set Definition templates should be carefully generated to keep their meaning in different products. So, AC01_SomeName refers to some IT system requirement, Exchange Information Requirements and it includes same properties across the used software platforms to ensure the consistency. Same is true for all other Property Set Definitions, in where those can be generated based on object types, project stage according to ISO 19650 series.
Once defined this information is automatically put together in Properties palette but some information can be easily manipulated. For example, type/number as well as the reference designation (level code) will change if the classification code is changed (whatever the reason). Pump as modelled in AutoCAD MEP (multi-view block).
Reference designation code (level code) follows some agreed template. In here it is currently in state that includes CCI, as well as CCI-EE local tables.
Once exported, the pump related information is shared in between IfcClassificationReference and data templates sections.
Note that the pump efficiency is simulating the occasion, when it is not yet known value and the placeholder # is used.
This same logic can be now applied to various components, AutoCAD Architecture or AutoCAD MEP related objects. Depending on component type, it will reflect the different part of the CCI table (space, entity, functional system, technical system, component). For example, an entity is simulated through Autodesk Civil 3D export, as the context of the built area is built there (see the next section) while spaces can be simulated with a Space tool in AutoCAD Architecture/MEP or in Civil 3D as an extra Surface.
Entity as a building. Note, in here we have a simple building’s outer shape as a Solid object (as modelled in AutoCAD), but it can be classified and exported into IFC only in AutoCAD vertical products (AutoCAD Architecture/MEP, Civil 3D). Although it can be modelled also in vanilla AutoCAD (3D) as well.
Parking lot (generated as a surface) as an entity which includes parking spaces.
Wall (as modelled in AutoCAD Architecture) as a technical system (which also includes a window).
Please note that all images are preliminary examples and represents very simple scene to focus onto basics. But the workflow will be the same as we generate our models/projects according to CCI (CCI-EE) classfications system.
Autodesk Civil 3D
Formerly also called as AutoCAD Civil 3D which clearly indicates that it uses AutoCAD as a base product but as it is meant for civil engineering tasks (domain) it clearly differentiate itself from other AutoCAD based products. And again, Autodesk Civil 3D can be a core product for various other vendors (Trimble Novapoint) whose products are built on top of it (may use also AutoCAD, AutoCAD Map 3D – but as stated before, those are with limited support in terms of IFC export support).
The key in here is also to use Style Manager. Note that in Civil 3D there are many more object types. Please also check other parts which were explained in section AutoCAD Architecture / MEP (incl List Definitions, Property Set Definitions – which are also available in Civil 3D template as examples).
Therefore if we want to classify a road that is in a planned stage (no actual road, only a road line is defined) we can use an alignment to draw it and add a classification through Entities table (CE table).
As with the Architecture / MEP example, we can add property sets through various data templates which gather parameters according to an owner / client needs or according to project stage requreiments.
Once this preliminary road is developed further and include a corridor model, it will still be the same road in terms of entity.
But properties will change that can include additional information. Also, that road as an entity can be broken down into component levels (curb, construction layers as surfaces etc.). In that case we can include component code as well. For example the paving code for a road top construction layer.
To be able to map in which stage some planned/design/built object is, additional level codes are added into properties section.
And those are aligned into a complete reference designation code as follows. You do not have to use that long code alone. The idea behind of level codes are that you can break the long code into several parts as needed.
If we come back to the road, which is in planned stage we can add the following coding:
AC125_cciPAcode: <PA>EAG (pre-design process, project administration, sketching)
AC095_cciRAcode: <RA>ABA (developers, designers, planner)
AC145_cciPPcode: <PP>### (not yet defined)
Note: There are multiple ways how reference designation codes are formed. For example, in addition to a fixed property name, you may want to include a table name into the code itself: Instead of writing just EAG from PA table, you may want to include the table identifier in front of the code: <PA>EAG (in that case it is clearly indicated from which table this comes). Also automatic code building is then different (will you include the fixed table code + code from the input field, or you type it in with both values). Down below you see an example of that same road alignment as described above.
Autodesk Revit is a key modelling package from Autodesk for buildings, structures, engineering systems (indoor) as well as for structures which belong into infrastructure domain (ex. bridges, noise walls etc.).
The key in here is using BIM Interoperability Tools which includes Classification Manager. But as it simplifies the classification task in itself, additional workflows through parameter definitions/rules can be used to shape the information export as needed.
How to start?
Download the template (see above, as MS Excel file), open Autodesk Revit, ensure that you have installed BIM Interoperability Tools, click: Classification Manager > Setup
Browse that downloaded MS Excel file and click Finish.
Classification tables are now assigned to the project. Click the second button: BIM Interoperability Tools > Classification Manager > Assign.
Pay attention to that at this step additional properties are added to the project which enable to assign values to them. As no objects are selected, only entity-based tables are shown, like CCI table CC and CCI table CE. Those are CCI core tables. Select Facility from the left icon menu and then CCI table CE. Navigate or search a proper classification code. In this case we will use AAA – Single-family house. Select the row, click Assign button. You will see the message that the assignment has been done. If you see the error message, the most common case is that you do not have property available or that property is not assigned with entity/component level.
You do not need to close dialog if you want to continue with the classification process. But before we continue, let’s have a look from where this code is now visible. Click Manage > Settings > Project Information.
You can see that entity has been classified in this dialog.
Pay attention to that classification code property names are coming from the MS Excel file table <RI>.
Close the properties dialog. Pay attention to that if you do need to reassign some other value to the same entity/component, you need to ensure that overwrite is allowed. Otherwise, it will be skipped.
Let’s continue with the classification procedure. Shift the dialog so that you can select some component. Hereby a window is selected.
The selection of CCI tables will change. Now you can choose between those tables that are component level. Different tabs represent different CCI / CCI-EE table. Let’s select CCI table CO. Search the code, you can enter a keyword or manually find it. Select the row and click Assign.
Close Classification Manager dialog. Select the window and check properties. You will see that a code and term are assigned. By default, those properties are type based. At some point you may need to use instance-based properties. For example, all windows with the same type are now classified. But if additional classification codes should be addressed then we mostly talk about properties anyway and those properties can be defined as instance based. Of course, you can make a change at all classification levels in where properties are assigned as instanced properties and not as type properties.
Similarly you can add additional properties that defined the component from different aspects as required (incl performance properties, acoustic properties etc.).
IFC export with classification codes
Before we move forward and check how those class codes are presented in IFC, we need to understand the classification property in terms of IFC. As before, we can include the classification code through the IfcClassificationReference or through a parameter/property. It is best practice that general classification code is available under IfcClassificationReference and other, classification related properties are under property/data sections.
To be able to bring in the IfcClassificationReference connection, we define/add one additional property under IFC Parameters section. We add it because once in a while we have a classification code added at component level and sometimes at space/room object level and we need a unified parameter for that. We pick a parameter name from <RI> table. In here, the parameter name AN162_Identification is used. This parameter is later connected into IfcClassificationReference and the name in there doesn’t matter, as the value is reassigned during IFC export.
Once added, property is shown depending on its type (instance or type). As we have selected Type this time, it can be seen once we open Type Properties dialog. Note that a AN162_Identification in here is filled in manually. And the code and term are separated with a semicolon: QQA: Window (both should work, space after a colon or ‘no space’).
Before we export the IFC, we need to point to the parameter which takes over the IfcClassificationReference part. Select Export > IFC. Let’s modify the <In-Session Setup> but you can create a separate one. Click Modify Setup > Property Sets > Classification Settings…
You can now fill in additional classification related properties (incl table version, reference to the classification system etc.). Classification field name = AN162_Identification, this is the key part for IfcClassificationReference section.
Note: Classification Settings are assigned as follows (note that IFC 2×3 and IFC 4.3 does introduce some changes):
- Name – IfcClassification.Name
- Source (Publisher) – IfcClassification.Source
- Edition – IfcClassification.Edition
- Edition date – IfcClassification.EditionDate (not exported in current version, IFC 2×3)
- Documentation location – IfcClassificationReference.Location
- Classification field name – parameter name from where class code and term are extracted (code:term)
As found from the exported IFC when opened in text editor:
- #68413= IFCCLASSIFICATION(‘Ehituskeskus’,’2021.06.0.1′,$,’CCI-EE’);
- #68414= IFCCLASSIFICATIONREFERENCE(‘www.ehituskeskus.ee’,’QQA’,’Window’,#68413);
IFC 4.x (IFC 4.3 does introduce some changes)
- #48677= IFCCLASSIFICATION(‘Ehituskeskus’,’2021.06.0.1′,$,’CCI-EE’,$,$,$); (differences in terms of IFC 4.3, check webpage)
- #48678= IFCCLASSIFICATIONREFERENCE(‘www.ehituskeskus.ee’,’QQA’,’Window’,#48677,$,$); (differences in terms of IFC 4.3, check webpage)
Export the IFC file (ensure that you have selected valid property sets) and check the IFC in a viewer. We keep the same IFC viewer as before: Trimble Connect.
Please note that IFC viewer may show those parameter names differently:
- Location – www.ehituskeskus.ee – IfcClassificationReference.Location
- ItemReference – QQA – IfcClassificationReference.ItemReference
- Name – Window – IfcClassificationReference.Name
- RelatingClassification.Source – Ehituskeskus – IfcClassification.Source
- RelatingClassification.Edition – 2021.06.0.1 – IfcClassification.Edition
- RelatingClassification.Name – CCI-EE – IfcClassification.Name
Note different sections: Data and IfcClassificationReference
Usually we do not need to present the same data twice. And it will be connected as much as possible (as shown before in where parameter value from IfcClassificationReference was read by a parameter in properties section). So, in this case it may be seen an unnecessary to include the window classification code under Data as well as under IfcClassificationReference. Hereby we want to point out the different ways to do it.
Pay attention to that different IFC viewer may present the same data in different sections. For example, BIMcollab does not have a section called IfcClassificationReference, instead it will reflect that part under the first tab, Summary.
Solibri Anywhere shows this data under Classification tab.
BIMvision shows this data under Classification tab as well.
In terms of entity, this information is not shown directly but can be acquired from the IFC file as:
Which is connected into IFCBUILDING: