CCI example: Autodesk Civil 3D
In this section we carry out a basic classification on the example of a bridge, where we classify one component but also define it’s relation to technical system and functional system.
However, you can find a more complete picture in the downloadable Autodesk Civil 3D file, where all similar components are classified. To reuse those sample attributes you can use the same Civil 3D file. 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 Civil 3D sample model used in this example (version 2024):
Download the IFC 4×3 exported from Autodesk Civil 3D sample model:
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.
Classification of a component
After importing CCI-EE related attributes into the active project, those are displayed under the Extended Data pane of the Properties dialog. At the same time, it must be emphasized that with later addition, the corresponding attribute groups must be included in the objects through the Add Property Sets dialog. The template includes two attribute groups: (1) A001_AdminEntity (used only at construction entity / complex / built space level) and (2) A010_AdminElement (used to classify most components).
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 – 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. 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.
Note. The format of refefrence designation set(s) (in here also noted as UniqueID) should be viewed based on the exchange information requirements.
With this, we have presented an example of classification logic based on Autodesk Civil 3D. 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.