Before moving on to the software examples (how to ensure the principles of CCI, CCI-EE with them), let’s take a general look with the help of some examples of how the introduction of a unified classification system helps to design an asset-centric unique ID that considers the building whole lifecycle and both human and machine readable. If another unique ID has been previously used, it must be linked to the CCI-EE codes, which are not covered here. At the same time, those who are interested in how CCI-EE connects with existing BIM requirements (e.g. “General BIM requirements”) you can see an Estonian example of current BIM requirements mapped against CCI-EE (see, in Estonian only, BIM infosisu nõuded CCI-EE kontekstis (hooned, infra, TRAM). In general, it can be noted that any IT system can use its own unique ID value and we may not be able to redefine it in that software/application (take for example BMS or Building Management System, some security system solutions, room register, property register, etc. – all of them may have their own unique ID logic defined, some for example only in the form of numbers). Therefore, in the context of building information models or in the context of asset maintenance, we have to carry out mutual integration of information, where the unique ID of CCI-EE resulting from the building information model is linked to other, important information systems for the customer. Software default unique IDs (GUID, Element ID, Handle etc.) are not human or machine readable, in addition, different software packages do use different unique IDs, and when transferring similar information, we have to do multiple different integrations (extra work).

The adoption of a unique ID across information systems becomes critical if we want to move to model-based maintenance, where, among other things, optimal information exchange transfers must be defined (EIR or Exchange Information Requirements as stipulated by the EN ISO 19650 series). At the same time, it is important to talk about a single, unique ID concept (human and machine readable) at any stage of the construction life cycle, where it is necessary to make summaries or extracts from the quantities/volumes (either from the building information model or related documentation), which are then used for budget compilations or connected to other information databases. Based on its unique code, CCI-EE enables automatic connections with other sub-tables of CCI-EE, e.g., certain construction aids/resources or construction activities are connected to certain construction components. CCI-EE provides an opportunity to talk about quantities both on a more general level (e.g., in the context of CCI core tables, international dimension) and also in a more detailed presentation, which already includes CCI-EE application tables, where in addition to the general level code, the type/subtype context is also introduced. Please note that the CCI-EE application tables (types/subtypes) are a supplement to the CCI-EE additions (tables), which we also briefly discuss here.

Classification usually means defining some specific properties, using them in the context of digital / physical assets. So, before moving on to a specific example, it is worth noting the list of properties that come into play when applying CCI-EE. These are the characteristics through which we classify and identify a building element, space, building or building complex. The names of these properties are derived from the CCI-EE <RI> table, and it is very important that when naming the properties, the alphanumeric part given in the table <RI> (2 letters + 3 numbers) always remains correct. In this example, we limit ourselves to so-called green table classifiers and supplement them with properties related to type / unique ID / reference identifier. In addition, CCI-EE yellow/red table classifiers and their associated types/unique ID may be included in the model. At the same time, the information related to the yellow/red tables can also come into play outside of the models, in some other information system, where the information exported from the model and with CCI-EE characteristics is linked to the information in another information system, where CCI-EE is also used (e.g. unit cost table that simplifies budgeting, additional resources based on the construction component the need for inclusion, etc.). Below is a list of CCI-EE properties/parameters that must be implemented in building information models for successful implementation of CCI-EE (to the extent of the green tables). These same characteristics with such names must also be used in the software templates.

Parameter name	Description of the parameter (additional information, including the connection to IFC / ETIM or specific EN / ISO standard, can be seen in CCI EE <RI> table)
AC125_cciCScode	class code of built space from CCI-EE table <CS> (three-letter code)
AC130_cciCSterm	description of a selected built space from CCI-EE table <CS> (written text)
AC135_cciCCcode	class code of construction complex from CCI-EE table <CC> (one-letter code)
AC140_cciCCterm	description of a selected construction complex from CCI-EE table <CC> (written text)
AC145_cciCEcode	class code of construction entity from CCI-EE table <CE> (two-letter code)
AC150_cciCEterm	description of a selected construction entity from CCI-EE table <CE> (written text)
AC155_cciCFcode	class code of functional system from CCI-EE table <CF> (one-letter code)
AC160_cciCFterm	description of a selected functional system from CCI-EE table <CF> (written text)
AC165_cciCTcode	class code of technical system from CCI-EE table <CT> (two-letter code)
AC170_cciCTterm	description of a selected technical system from CCI-EE table <CT> (written text)
AC175_cciCOcode	class code of construction component from CCI-EE table <CO> (three-letter code)
AC180_cciCOterm	description of a selected construction component from CCI-EE table <CO> (written text)
AT800_TypeNumber	a type ID value of a classified construction element, construction entity, construction complex, built space, etc. (two-level number, usually based on CCI-EE application table)
AT825_TypeTerm	description for the selected type ID of construction element, construction entity, construction complex, built space, etc. (written text, usually based on CCI-EE application table)
AT850_TypeDesignation	combined value of type number and type term (description) as given in CCI-EE guidelines
AJ125_IDNumber	a unique ID of a classified construction element, construction entity, construction complex, built space, etc. according to reference designation schema (unique ID of a window which is related to a certain wall element – not a unique ID of a window in a whole building; unique ID can be also based on a room level, but it is always connected to a type first and then its uniqueness aspect)
AR200_ReferenceDesignation	construction element / built space / construction entity / construction complex, etc. combined value of a class code, type number (AT800_TypeNumber) and ID number (AJ125_IDNumber)
AM945_MultiLevelRD	construction element / built space / construction entity / construction complex, etc. sub-component and/or accompanying element (may not be always filled in)
AR225_ReferenceDesignationSet	reference designation code combinations of construction element / built space / construction entity, etc. always given for higher relations only (may also include yellow/red tables, see CCI-EE guidelines)

In addition to the above, other information needs may also be included, but again using the CCI-EE property codes/names from <RI> table. Some examples can also be found in software templates, but a more comprehensive table can be found in the previously cited article (In Estonian only, BIM infosisu nõuded CCI-EE kontekstis (hooned, infra, TRAM). When including information content, it is worth considering whether its presence is necessary/important in the building information model or whether it is reasonable to include this information in another information system (information content resulting from specifications, accompanying a specific CCI-EE component type/subtype, etc.). Based on this, the scope of the information content in the included, sample templates have also been kept to a minimum. Of course, the context of the level of information need, as well as exchange information requirements are important parts to consider before starting to use any available templates.

For example, in the Autodesk Revit template, a property called AJ300_IfcClassificationReference has been added, by filling it in, we ensure the correct transfer of the general classification (green tables) to the structure of the IFC file (see example in the next chapter). At the same time, such a property is not needed in the example of Autodesk Civil 3D, because there the general classifier is transferred from another data structure (not with the parameter given by us).

Following the CCI-EE logic, in addition to the classification of components, the construction resources associated with them can also be defined, or the stage of the project, etc. There are separate properties to describe this, which can be found in the CCI-EE <RI> table. By default, they are not included in all the provided templates presented here, as these properties can also be filled in externally (outside from the modelling package) based on the unique CCI-EE codes (reference designation set values). Below is an example of the properties that describe yellow/red tables.

• AC245_cciPAcode: <PA>EAG (pre-design process, project administration, sketching)
• AC205_cciRAcode: <RA>ABA (developers, designers, planner)
• AC265_cciPPcode: <PP>### (not yet defined)

Note. The creation of reference designations and reference designation sets can be based on different templates. For example, in addition to the fixed value, you may also want to include a reference to the table from which it comes (however, this is defined by the name of the selected property anyway). In other words, in addition to the EAG value (note the property name from the previous example) coming from the <PA> table, you may want to include the table name code: <PA>EAG. However, it should be noted that this changes the automatic creation of the reference designator, so a way to correct that, must be also developed. Therefore, it is worth considering how the selected information presentation method will be used in the subsequent information transmission / on the platform to which it will be transferred. Again, the exchange information requirements / guidelines are helpful here, by which we ensure that information transfers are defined in a same manner.

Now that we have opened up the more general nature of unique ID and highlighted the features of CCI-EE that enable to define the unique ID, let’s look through software examples how it can be used in certain situations. First, in a more general view, where we do use specific software, but where it is important to follow how the properties are fulfilled. Therefore, we will not go into the specifics of the software in the first part, and the principles presented must be independently transferred to any other software that a particular user prefers. However, in the more technical part (which follows the more general examples), we will take a closer look at how the developed software templates are structured and how to implement the classification system in specific software.