CCI example: Autodesk Revit

by Raido Puust

Note. Autodesk Revit classification examples are presented in a way where all attributes are first defined in the Instance way. In certain situations, some attributes are also needed in the Type representation and will be addressed in later sections (e.g., transferring type-related attributes to the COBie information exchange format). Note that certain categories always assume an Instance attribute (eg Room, Project Information), so Instance is also the first choice in the examples here. At the same time, it is possible to include attributes in both the Instance and Type sections using the given Shared Parameters file, but it should be noted that some attributes are strictly Instance in nature, i.e. they present some ID value and therefore cannot belong to the Type section. Instance/Type based definition can be very software specific and may not be a topic at all in other software (e.g. Autodesk Civil 3D).

Contents

Building example
Bridge example

Building example

Below, we will carry out a basic classification exercise on the example of a building, where we will select one component, one technical system (with the functional system reference) and also the built space and construction entity.

However, you can find a more complete picture in the downloadable Autodesk Revit file, where all similar components are classified, additional tables, etc. are included. The sample Revit file as well as the Shared Parameters file can be used to reuse attributes. In addition, the CCI-EE/R (CCI-EE types table) is in use, which lists the types/subtypes used in the classification.

Note. The types/subtypes of the CCI-EE/R table must be based on a uniform set of rules, e.g. a distinct function that the element performs or some other distinct aspect. Types/subtypes can always be specified with product-specific attributes (additional attributes), so CCI-EE table types/subtypes must not be viewed in the context of product/manufacturer or overly specific attributes. However, in some cases, the distinguishing type/subtype can be the context of the material if such a distinction is very fundamental (e.g. environmental aspect). The CCI-EE types table presented here is cross-client, i.e. if you look at the type tables on the example of one specific client, it is obvious that they do not need to expand all CCI basic classifiers into types/subtypes, but to limit themselves only to the parts that are important to them.

Download the Autodesk Revit sample model used in this example (version 2024):

AA-Single-dwelling-house_CIA-DD-2024.05.0.1.rvt

Download the IFC 4×3 exported from Autodesk Revit 2024:

AA-Single-dwelling-house_CIA-DD-2024.05.0.1.ifc

Note. The example file can be extended if additional component types/elements are included. At the moment, the main components of the architectural part are in focus.

Building: Classification of a construction component (window)

After CCI-EE classification-related attributes are included in the active project, those are displayed in the Properties > Identity Data section. Autodesk Revit is limited in that we can use built-in sections like Identity Data, IFC Parameters, etc. While other attributes, which also come from the CIA-DD table, are gathered in the Data section. The display of attributes can be set based on the category of the object (e.g., it does not make sense to show an attribute related to a component or technical system for rooms, or it does not make sense to show a classifier characterizing a building for a component, because it is moved to the Project Information dialog).

In the given examples, it is assumed that the composition of the attributes is specified in the exchange information requirements. In current examples, it is assumed that the attributes that show the relation to the system/subsystem, are also filled in. Some attributes are filled in individually, but with reference designation(s) and a unique ID, different values are combined into a single value (this can be automated, which will be discussed in further examples).

Using the example of a window as a component, we will therefore go through the attributes shown in the previous image, which also stipulates the rules for fulfilling these attributes.

AC175_ComponentClassCode – window key class code (from CCI-EE <CO> table). No additions (numbers/letters) are allowed. In this example: QQA
AC180_ComponentClassName – concept supporting the key classifier as text (from CCI-EE <CO> table). In this example: Window

In essence, the basic level of classification is limited to those two parameters. It will be extended through the definition of reference designation system (RDS), which includes, among other things, the unique ID of the window, the window type, as well as the relation to a wall type/ID, and from there to the desired main level (functional system, construction entity, built space, construction complex).

AC176_ComponentTypeCode – window type code from the CCI-EE/R types table or on the example of the client’s own asset register (an example of the CCI-EE/R types table is used here)
AC181_ComponentTypeName – the name of the window type from the CCI-EE/R types table or on the example of the customer’s own property register (an example of the CCI-EE/R application table is used here)

AC177_ComponentID – returns the enumerated value (01 – 99) of a window of a specific type
AR340_RefDesignation – this attribute summarizes the component ID and type code separated by a %
AR320_MLevelRefDesignation – in this example it is empty because there is no other child component associated with the window (e.g. on a drop-down window we may want to refer to the window lock, window handle, etc.)
AR360_UniqueID – this field contains the reference identifier of this component (AR340_RefDesignation) and the reference identifiers located above it (hence the name – reference identifier group). For example, with the component, the reference code of the wall (as a technical system, as a functional system) comes here, and you can also put parts of the building and construction complex. In this example, it is written as:
B1010.AD5003.QQA02%QQA40

Note. Note that the reference designation set (RDS) can also be presented in “smaller bites”, for example without a construction entity/complex. For this, the characters “-” and “+” are applied. In addition, we may wish to refer to which built space something belongs. In that case the context of “host” (+) or “location” (++) must be distinguished. Several reference designation sets can also be combined as one property value, but in this case they should be separated with the “/” sign.
-B1010.AD5003.QQA02%QQA40/+<CS>BAA1001

Note. The format of refefrence designation set(s) (in here also noted as UniqueID) should be viewed based on the exchange information requirements.

Note. See also the previous chapter. <CS> is a negotiated value. It can be replaced, for example, by the letters described by ISO 81346-12, but with certain differences/modifications.

Building: Classification of a technical system (wall example)

Below we have selected a wall in which we have classified the window in the previous section. Let’s look at what attributes must be met (minimally) for the wall as a technical system.

AC165_SubsystemClassCode – the main classifier of the wall (in which all layers of the structure are included) (from the CCI-EE <CT> table). No other letters/numbers can be added to it. Noted here as: AD
AC170_SubsystemClassName – the concept supporting the main wall classifier as text (from the CCI-EE <CT> table). Noted here as: Wall construction

In essence, the basic level of classification is limited to this, and it is followed by its specification as reference designators, which includes, among other things, the unique ID of the wall, the type, as well as the relation to a functional system, construction entity, built space, construction complex.

AC166_SubsystemTypeCode – wall type code from the CCI-EE/R types table or using the example of the client’s own asset register (an example of the CCI-EE/R types table is used here)
AC171_SubsystemTypeName – the name of the wall type from the CCI-EE/R types table or on the example of the client’s own asset register (an example of the CCI-EE/R application table is used here)
AC177_ComponentID – returns the enumerated value (01 – 99) of a wall of a specific type
AR320_MLevelRefDesignation – in this example, it is unfilled, because there is no other subcomponent associated with the wall (e.g., we may want to refer to the load-bearing part of this wall with AD30, i.e. a separate structural layer, for example AD30.BD30 – BD30 then comes from the list of a separate type/subtype)
AR360_UniqueID – in this field, the ID of the wall is presented in the context of the upper levels. For example, in the case of a wall as a technical system, a functional system is added here, and in addition, parts of the construction entity and construction complex can also be included. In this example, written as:
B1010.AD5003 (includes functional system type/subtype B10 with the enumerated value 01)

Building: Classification of a construction space

Below we have selected a room in the building that has been classified according to the CCI-EE scheme. Let’s look at what attributes should be filled in (minimally) for a room as a built space. Since the room/space is an Instance type element in the Autodesk Revit concept, there cannot be two-way filling here.

AC125_BSpaceClassCode – the main classifier of the room (from the CCI-EE <CS> table). No other letters/numbers can be added to it. Noted here as: AAB
AC130_BSpaceClassName – the concept supporting the main classifier as text (from the CCI-EE <CS> table). Noted here as: Living space

In essence, the basic level of classification is limited to this, and it is followed by its specification as reference designators, which includes, among other things, the unique ID, the type, as well as the relation to the construction entity, construction complex.

AC126_BSpaceTypeCode – it presents the type code derived from the type table (the CCI-EE/R types table, which is separate from the general CCI-EE table and may be established by the project / client)
AC131_BSpaceTypeName – it presents the name of the type derived from the type table (the CCI-EE/R types table, which is separate from the general CCI-EE table and may be set by the project / client)
AC127_BSpaceID – it returns the enumerable room ID based on the room type (01-99)

Building: Classification of a construction entity

Using the example of Autodesk Revit, the classification related to the construction entity and the construction complex can be presented in the Project Information dialog (provided that the project contains only one construction entity, if there are several, it is necessary that the classification related to the construction entity is in the Identity Data section and available for elements, e.g., the volume surrounding some construction entity via an additional element). Project Information is Instance-based attribute, it can be filled in with Instance-based attribute only.

AC135_CoComplexClassCode – classification of the construction complex (from CCI-EE <CC> table). No other letters/numbers can be added to it. Noted here as: A
AC136_CoComplexTypeCode – construction complex type (from CCI-EE /R table). No other letters/numbers can be added to it. Noted here as: A11
AC137_CoComplexID – construction complex ID based on its type. Noted here as: A1101
AC140_CoComplexClassName – a term supporting the construction construction complex main class code (from CCI-EE <CC> table). In this example as: Residential complex
AC141_CoComplexTypeName – construction complex type name (from CCI-EE /R table). No other letters/numbers can be added to it. Noted here as: Single family housing area
AC145_CoEntityClassCode – classification of the construction entity, building (from CCI-EE <CE> table). No other letters/numbers can be added to it. Noted here as: AA
AC146_CoEntityTypeCode – construction entity type code (from CCI-EE /R table). No other letters/numbers can be added to it. Noted here as: AA11
AC147_CoEntityID – construction enitty ID based on its type. Noted here as: AA1101
AC150_CoEntityClassName – a term supporting the construction entity main class code (from CCI-EE <CE> table). In this example as: Single-dwelling house
AC151_CoEntityTypeName – a term supporting the construction entity type (from CCI-EE /R table). No other letters/numbers can be added to it. Noted here as: One-story single-family house

In essence, the basic level of classification is limited to this, and it is followed by its specification as reference designations, which includes, among other things, the unique ID of the building / building complex, type code.

With this, we have provided an example of classification logic based on Autodesk Revit. The components are different and thus the previously discussed principles must also be used in the classification of other objects. The software specifics and template structure are described in a later section.

Bridge example

Below, we will carry out a basic classification exercise using the example of a simple bridge (viaduct), where we select one component and a construction entity (the technical system as a subsystem and the built space are not presented in this example, however, you can look at the logic using the example of a building if such an element should be in the model!).

Download the Autodesk Revit sample model used in this example (version 2024):

RK-Bridge_CIA-DD-2024.05.0.1.rvt

Download the IFC 4×3 exported from Autodesk Revit 2024:

RK-Bridge_CIA-DD-2024.05.0.1.ifc

Note. The example file can be extended if additional component types/elements are included. At the moment, the main components of the structural parts are in focus.

Bridge: Classification of a construction component (beam)

Using the example of a window as a component, we will therefore go through the attributes shown in the previous image, which also stipulates the rules for fulfilling these attributes.

AC175_ComponentClassCode – beam key class code (from CCI-EE <CO> table). No additions (numbers/letters) are allowed. In this example: ULE
AC180_ComponentClassName – concept supporting the key classifier as text (from CCI-EE <CO> table). In this example: Beam

In essence, the basic level of classification is limited to those two parameters. It will be extended through the definition of reference designation system (RDS), which includes, among other things, the unique ID of the beam, the beam type and from there to the desired main level (functional system, technical system, construction entity, built space, construction complex).

AC176_ComponentTypeCode – beam type code from the CCI-EE/R types table or on the example of the client’s own asset register (an example of the CCI-EE/R types table is used here)
AC181_ComponentTypeName – the name of the beam type from the CCI-EE/R types table or on the example of the client’s own property register (an example of the CCI-EE/R application table is used here)

AC177_ComponentID – returns the enumerated value (01 – 99) of a beam of a specific type
AR340_RefDesignation – this attribute summarizes the component ID and type code separated by a %
AR320_MLevelRefDesignation – in this example it is empty because there is no other child component associated with the beam (e.g. mounting plate)
AR360_UniqueID – this field contains the reference identifier of this component (AR340_RefDesignation) and the reference identifiers located above it (hence the name – reference identifier group). For example, with the component, the reference code of the beam structure (as a technical system, as a functional system) comes here, and you can also put parts of the construction entity and construction complex. In this example, written as:
C5001.BC2001.ULE01%ULE12

Note. The format of refefrence designation set(s) (in here also noted as UniqueID) should be viewed based on the exchange information requirements.

Bridge: Classification of a construction entity

AC145_CoEntityClassCode – classification of the construction entity, bridge (from CCI-EE <CE> table). No other letters/numbers can be added to it. Noted here as: RK
AC150_CoEntityClassName – a term supporting the construction entity main class code (from CCI-EE <CE> table). In this example as: Bridge
AC135_CoComplexClassCode – classification of the construction complex (from CCI-EE <CC> table). No other letters/numbers can be added to it. Noted here as: R
AC140_CoComplexClassName – a term supporting the construction construction complex main class code (from CCI-EE <CC> table). In this example as: Traffic complex