4. Interoperability of data
Interoperability is defined as the ability to access and process data from multiple sources without losing meaning and subsequently integrate the data in question for mapping, visualisation, and other forms of representation and analysis. In this report, two topics are selected, namely:
- Machine-readable EPD and LCA data that are essential for the digital communication of LCA and EPD results.
- A common classification system of buildings that support comparability across countries in the building element level. When the result is reported with a high granularity level, a classification that includes building element types, such reported LCA results are then also applicable for digital supervision.
Machine readable EPD and LCA data adopted to BIM
The transfer of any construction object information in the construction process needs standardised machine-readable structures and formats to ensure an efficient and secure flow of information. In the future, with the new Construction product regulation (CPR), we will likely handle this with standardised data templates in the form of jointly agreed and documented properties that are relevant to a product or any construction system. Data templates will likely be used for the declaration of technical performance, as well as the suggested mandatory EPD related to the forthcoming CPR. A data template may cover any property related to a construction object. The data template approach is designed to be used in Building Information Modelling (BIM).
It is likely that, besides the context of other essential requirements and the future Declaration of Performance or Declaration of Conformity, the data template approach will be used for additional (non-regulated) properties asked for by the market as a basis for digital communication. To complement the regulated essential requirements with a more extended list of properties, several initiatives are now running to establish common properties for individual products based on data templates in parallel with regulatory initiatives and nationally established PDT organisations. We will also see the same development with such system data templates (SDT) to handle common properties for construction objects.
The goal with this part of the project is to establish a common definition based on JSON to communicate any data template or sheet based in it. The same format will be reused to create a stand-alone file for a data sheet and the basis for a standardised API. Furthermore, the new ISO 23387 will include an XML based format for communication on data templates; in the future, there will be a need for a uniform mapping between the TD JSON developed here and the XML defined in the new ISO 23387.
European level
Our recommendation for a common digital format for any construction object for digital communication is that it shall be based on the data template approach (ISO 23386, ISO 23387, and ISO 12006-3), which is the new approach that includes the concept of a data dictionary and links property-based information to any construction object. A data template can be used to define a common set of requirements, form the basis for generic properties for a construction object, which will be replaced with the actual (specific) properties when it is in the context 'as built'. This so-called data template is developed to communicate information for any kind of construction objects and designed to be used in BIM.
Our recommendation for a common digital format for any construction object for digital communication is that it shall be based on the data template approach (ISO 23386, ISO 23387, and ISO 12006-3), which is the new approach that includes the concept of a data dictionary and links property-based information to any construction object. A data template can be used to define a common set of requirements, form the basis for generic properties for a construction object, which will be replaced with the actual (specific) properties when it is in the context 'as built'. This so-called data template is developed to communicate information for any kind of construction objects and designed to be used in BIM.
In the implementation of these data template standards, there is currently an urgent need for a common file format to support communication and interconnectivity between different domains. To support this development is a common JSON specification, developed based on ISO 12006-3 and the future updated ISO 23387. This so-called DT JSON will then be implemented to handle properties for any specific product group and its so-called product data template. The data template can also be defined for any other kind of construction object and referred to as a system data template (SDT). It is also possible to establish a horizontal set of properties that is information used across products, construction objects, or systems based on the same data template approach.
This DT JSON will then be implemented for EPD and LCA following ISO 22057, and then ready to be implemented by the program operators that publish EPDs and the tools that developed these EPDs. It is likely that this is part of the same technical solution that will be launched for Digital Product Passports. Concerning environmental information for products based on EPD and LCA results, it will be made machine-readable based on the standard ISO 22057. To be in line with the product category rules for construction products (EN 15804) and buildings (EN 15978), it is required that the ILCD nomenclature must be followed. ISO 22057 is designed to follow EN 15804 and the ILCD nomenclature is demanded.
We observe that different regulations already have adopted ISO 22057 when digital EPD/LCA information is asked for. The PDT format ISO 22057 is suggested in the EU Taxonomy delegated act as a basis for the digital logbook to be established for a building, in order to collect and report EPD-based information on request. ISO 22057 is also the suggested format for EPDs or Digital Product Passports for construction products, according to the ongoing CPR Acquis process. One of the benefits of using ISO 22057 is that it is part of the BIM standards already applied, and the PDT-defined properties are connected to a common data dictionary that also includes a library of classes, relations, and units. The PDT approach can be used as logical models for any construction data software from 3D object libraries (CAD), product data catalogues (PIM), and to any building information model (BIM) tools.
National level
On a national level, additional indicators may be introduced and added to the EPD or climate declaration, such as the indicator GWP-GHG, and this indicator is already defined in the PDT for ISO 22057.
On a national level, additional indicators may be introduced and added to the EPD or climate declaration, such as the indicator GWP-GHG, and this indicator is already defined in the PDT for ISO 22057.
GWP-GHG is a modular GWP indicator that makes the LCA result comparable module by module and is used in the Finnish and Swedish LCA databases. GWP-GHG is asked for in Sweden when, for example, a limit value is suggested for the construction stage, module A1-5. In the programme operators EPD International and EPD Norway, it is mandatory to report GWP-GHG for construction products. The indicator GWP-GHG includes all green-house gases except the uptake and emission of biogenic carbon in the product itself and its packaging material. These uptakes and emissions are always zero over the life cycle. GWP-GHG is a supplementary indicator to GWPtotal. GWPtotal as the GWP indicator restricts the comparison between individual modules. If only a whole life cycle (A to C) is reported, the result will be the same for GWP-GHG and GWPtotal. See the section 'Selecting GWP indicators' concerning more information about GWP indicators.
What is a data template?
A recognised way to support innovation and cost-effective solutions is to start with performance-based constructions. In the same way, authorities can contribute to innovative thinking and material-neutral solutions by setting performance-based requirements in laws and regulations for construction. Today, the construction industry, to a great extent, has performance-based requirements in European building legislation. To achieve performance-based construction, there must be a common system for managing properties at different levels from the construction work to parts of buildings, building elements, components, and products.
In the digital world, a building consists of several different construction objects. Regardless of which construction object it is, its properties must meet the prescribed performance that can be defined using a data template. These requirements can then be matched against a generic or specific solution or product selection. A data template is a set of defined properties for a given type of construction object. A data template, when it has been filled with a generic or specific solution, is referred to as a data sheet.
The problem we generally see with digitisation today is a broken digital flow of information between different actors during a building's life cycle. When it comes to reporting product properties for objects, the challenge seen today is different competing systems dealing with product information, with different ways of defining properties, and varying quality and documentation (see Figure 7 below). The systems exist today mainly because nowadays, material suppliers need to report product properties in different ways to all these different commercial systems dealing with product information, which is extremely resource-intensive and counteracts coordination.
Figure 7 The same property of a window is named and defined differently, depending on the system used, where the concept of data templates would handle these with a common defined property (figure source: Cobuilder).
With the data template setup, the construction material supplier produces their product information once – one data drop – and it can then be used for all other systems or directly to the customers. It is only the material supplier that can guarantee product performance and not any external organisation/system that collects distributed construction product data, but does not put them to the market. With the digital data template setup, updates can also be made automatically by linking the systems that retrieve the product properties of the suppliers to the original source. Normally, one then chooses to save the version that applies at the time of delivery to the building information model representing 'as built'. By setting up a common set of properties for a construction object based on a data template approach, communication is facilitated between the different sources that publish them and those who will use and interpret these properties.
Different types of data templates
The data template concept is described in a number of standards (ISO 23386, ISO 23387, and ISO 12006-3) that define how data templates should be constructed. These standards are generic in terms of the type of information to be handled. The data templates can be vertical, i.e. adapted to a certain type of building components or products and their properties. A data template can also be created for a set of common properties that are valid for all types of structural objects, which then constitutes a horizontal data template. An example of this is the data template for an Environmental Product Declaration (EPD), which looks the same regardless of the product or the object for which it is used.
A data template with filled quantities/values for the properties becomes a digital product data sheet. A digital product sheet can theoretically consist of properties from one or more data templates. When searching for product data digitally through a web service (API), a selection of properties from different data templates can be used to get exactly the information one may be looking for. As with all information delivery specifications, the properties can be divided for different so-called purposes. A purpose can be information asked for in the characteristics of a structural design or when ordering the product in the construction phase.
Construction Products Regulation shows the way
EU legislation also sees a need for digitalisation linked to construction products and their properties. Within the framework of the Construction Products Regulation (CPR), work is underway with market players called the CPR Acquis process. The aim is partly to develop a new generation of Technical Declarations of Performance (DoP), and partly to develop the forms for a new mandatory Environmental Product Declaration (EPD) based on the product-specific rules for EPDs of construction products based on EN 15804.
Sustainability of construction works – Miljödeklarationer – Product-specific rules.
Figure 8 The conceptual structure of digitalised construction product information as part of the CPR Acquis process for future implementation in the forthcoming construction product regulation (figure source, presentation by Oscar Nieto, November 2023).
In the CPR Acquis process, the horizontal data template for an EPD, according to ISO 22057,
Sustainability of construction works – Data templates for the use of EPDs for BIM Building Products.
Figure 9 Digitised properties for construction products will be used to support different legislative requirements (figure source, Construction Product Europe).
Thus, it is concluded that within the framework of the current construction product legislation (CPR) and the development that takes place through the Acquis process, a new generation of declarations of performance will be developed based on product data templates. The data template approach will support not only CPR but also other legislation (see Figure 9).
Data templates and data dictionaries
An interesting consequence of developing data templates is that altogether, each individual PDT creates and builds up a subset to a data dictionary, with properties needed for a certain product type (or in general, any construction object). Altogether, these individual properties from all data templates will form the basis of a common European data dictionary. This is where all legally required properties and the standards that define them will be stored. There is a project ongoing dealing with how such databases and other dictionaries could be interconnected.
The work is done by Tecnalia, UNE and Cobuildet. https://cobuilder.com/en/eu-approach-for-the-digital-product-passport-of-the-construction-industry/
However, the market need for product information is greater than what is contained in the regulated declaration of performance and known as essential requirements. This means that industry associations (or their equivalent) must produce data templates that include more characteristics that are used for different purposes, such as what is required to order a product or what should be included in the dispatch advice (delivery note). These characteristics will likely include national additions. It must therefore be possible to manage them nationally, and a long-term management organisation must therefore also be in place. Currently, Norway is a frontrunner, and two bodies exists (PDT Norway, Cobuilder) that define PDT with national additions. A process initiated by a Smart Built Environment project in Sweden is running, where one of the goals are to establish the foundation of a Swedish organisation type ‘PDT Sweden’. In Denmark, Molio is working on establishing data templates for construction elements, but there are no ongoing initiatives for construction products. No data template approach is identified for Finland. In the long run, to maximise the availability of the definitions, a global dictionary, like the buildingSMART Data Dictionary, bSDD, should be used as the central node in a global interconnection between different national data dictionaries.
Data template market values
Examples of market values and benefits generated by the described information structure with standardised data templates and data sheets for product types are given below.
- A common information structure for many different markets and systems:
Data templates and their digital data sheets based on harmonised and European product standards can be used by manufacturers, wholesalers, retailers, and customers in a wide range of markets within Europe and probably a variety of other international markets (as they are based on international standards). The approach is by the potential one-data-drop possibility. The PDT approach will save costs for the material producer, and at the same time, support information that is efficiently communicated throughout the value chain from contractors to property owners and their asset management. - Early access to decision information in different phases of, for example, a construction project
In the early design stage, data templates can be used to describe the ‘recipe’ for different construction objects, which can then be inherited down to enterprise product types later in the process. This would likely support an improved design process (see the Danish/Molio example given above). Standardised properties can be compared for products from different suppliers, both from a technical perspective and from an environmental and climate impact perspective. This makes it easier to make choices and calculations, for example, when quantifying for purchasing and the climate impact. - Traceable information and data throughout a lifecycle.
With standardised data sheets and traceable identities (man and machine) for product types and items, information and data can be included, for example, when a building is handed over. Building objects in BIM models can be linked to product building objects, and in this way, information and data can be available for decisions and updates throughout the life cycle, for example, for maintenance, repairs, reconstruction. As well as at the end of the life cycle, information and data are also available for circular decisions and activities, even for trade transactions in circular value networks.
A common file format
In the implementation of the data template standards, there is currently an urgent need for a common file format to support communication and interconnectivity between different domains. To support this development is a common JSON specification developed based on ISO 12006-3 and the future updated ISO 23387. This so-called DT JSON will then be implemented to handle properties for any specific product group and its so-called product data template. Data templates can also be defined for any other kind of construction object and then referred to as system data templates (SDT). It is also possible to establish a horizontal set of properties that is information used across products, construction objects, or systems based on the same data template approach. More information on this common DT JSON can be found here:
The implementation provides well-defined JSON schemas for all the necessary entities from the standards, some additional common “implementation specific” entities, and some useful “default instances” (e.g. a standard set of relationship types).
Figure 10 The basic relation between the (construction) object that is called xtdSubject in ISO 12006-3 that is the source of which the property information is linked to.
The standard ISO 23387 provides the rule that apply to a data template established within a data dictionary based on ISO 12006-3:2007. Objects, collections, and relationships are the basic entities of the model in ISO 12006-3:2007. A data template is a superset of this model (since ISO 23387 add entities above ISO 12006-2), providing the concepts and relations needed to describe information about construction objects. It should be noticed that the standard ISO 12006-3 uses other names than ISO 23387, and that there is an update of this later standard (hence, the mapping given in Table 8 will be outdated very soon). A mapping between those current standards for some entities are given in Table 8. Please note that the entities GroupOfProperties and SetOfProperties have similar names but different definitions. The same goes for xtdObject and Object, and it will be elaborated and explained in the forthcoming update of ISO 23387. This updated standard will include a XML-based format for communication on data templates, so in the future, there will be a uniform mapping between the DT JSON developed here and the XML defined in the new ISO 23387.
ISO 23387 names | ISO 12006-3 names |
Data template | xtdBag |
Reference document | xtdExternalDocument |
Construction object | xtdSubject |
Group of properties | xtdNest |
Generic property | xtdProperty |
Specific property | xtdProperty |
Quantity | xtdMeasureWithUnit |
Unit | xtdUnit |
Enumerated type value | xtdValue |
Table 8 Naming relations between ISO 23387 and ISO 12006-3.
This DT JSON will then be implemented for EPDs and LCAs in order to follow ISO 22057, and then ready to be implemented by the program operators that publish EPDs and the tools that developed these EPDs. It is likely that this is part of the same technical solution that will be launched for digital product passports. Concerning environmental information for products based on EPD and LCA results, it will be made machine-readable based on the standard ISO 22057. To be in line with the product category rules for construction products (EN 15804) and buildings (EN 15978), it is required that the ILCD nomenclature must be followed. ISO 22057 is designed to follow EN 15804 and the ILCD nomenclature is demanded. More information on this common DT JSON implemented for ISO 22057 can be found here:
Use of a common classification system in the context of building LCA
Classification in the climate declaration will be used for:
- reporting the GWP result
- defining the inventory scope
- supervision/auditing
A building classification system that is based on a common recognised standard is lacking in the current Product Category Rule (PCR) standard for buildings (EN 15978), as well as in its forthcoming update. The building declaration system Level(s) includes a list of building parts (“shell”, “core” and “external”; see Table 3), but this list is only used to describe the scope of the inventory, and not as part of a mandatory common reporting of the environmental indicator result.
Having such a common building classification system in place would greatly benefit the use and comparison of the LCA results between different climate declarations independent of its national origin. Moreover, for thorough and digital authority supervision to be possible, a common method for sufficient classification details is needed, detailed at a suitable level.
European level
Our recommendation for a common classification system for the climate declaration of a building is that it should be based on the IEC/ISO 81346 series of standards. This classification subdivision is used when the climate impact based on the LCA calculations is reported, in combination with information on the information module (from A to D). This approach will guarantee that the climate declaration divided into major building parts can be compared regardless of the country origin. It will contribute to a European common basis of granularity for reporting that will support benchmarking at both building and element levels, see Table 8 and Annex 3. IEC/ISO 81346 is already used in classification systems in Denmark, Sweden, and Eastland as counties related to this report.
Our recommendation for a common classification system for the climate declaration of a building is that it should be based on the IEC/ISO 81346 series of standards. This classification subdivision is used when the climate impact based on the LCA calculations is reported, in combination with information on the information module (from A to D). This approach will guarantee that the climate declaration divided into major building parts can be compared regardless of the country origin. It will contribute to a European common basis of granularity for reporting that will support benchmarking at both building and element levels, see Table 8 and Annex 3. IEC/ISO 81346 is already used in classification systems in Denmark, Sweden, and Eastland as counties related to this report.
National level
The classes of generic building elements defined in IEC/ISO 81346 need to be complemented by more specific types of elements if used as a basis for supervision, e.g. wall constructions using different materials and components. Such granularity is not part of IEC/ISO 81346 and therefore needs to be defined nationally.
The classes of generic building elements defined in IEC/ISO 81346 need to be complemented by more specific types of elements if used as a basis for supervision, e.g. wall constructions using different materials and components. Such granularity is not part of IEC/ISO 81346 and therefore needs to be defined nationally.
To support supervision, the LCA result must, in addition to the overall result divided into building parts, typically be reported per building element type based on a predefined and commonly agreed unit (m, m2, m3 pcs). This will allow comparisons in respect to an expected value for the building type assessed. This approach makes it possible to create a key performance indicator for each building element type, which can be used for comparisons between buildings and suitable for supervision.
Moreover, if needed and relevant on a national level, the classes in IEC/ISO 81346 can be translated to and complemented by any national classification systems. Therefore, the building digital logbook must accept different classification systems to be used, since a national system exists that also will be used in parallel in the future.
In the long run, it is recommended that instead of different national classification systems, a free-to-use European classification system based on IEC/ISO 81346 should be established. It should be noticed that a further development is then needed, since the current IEC/ISO 81346 series do not include a granularity for a ‘construction element type’, where the materials used in a construction element are typically accounted for. Such granularity is essential and there is a need for digitalised cost-effective supervision, since the amount of construction product data that is part of the integrated life-cycle GWP supervision may cover several tens of thousands of data rows.
Parts 2 and 12 of the international standard series IEC/ISO 81346 include classes of building elements: functional systems, technical systems, and components, but not building element types (as described above). These classes can be used for classifying “construction elements”, as defined in ISO 12006-2, which is the basic classification standard for the built environment. A classification system based on IEC/ISO 81346 is currently used in Sweden and Norway (CoClass), Denmark (CCS), and the Baltic countries, Poland and Czechia (CCI).
Classification and LCA
The scope of the building LCA and the building elements included is greatly helped by using a classification system. The LCA result is reported per information module, but is often combined with a further granularity by dividing the result attributed to different building elements. Such reporting supports the interpretation of the result. When different technical solutions are evaluated in the design process, it is common practice to compare the climate impact, production cost, and other factors.
When evaluating the LCA result for a building, the most straightforward approach is to compare the result for an individual building element with the expected value. For this, a clear description of the building element type is needed. A type has a specified set of properties and property values found in all occurrences of that type.
As an example, in the context of LCA, a type can be a floor construction that fulfils a certain sound insulation class, showing its major material composition, such as made of CLT and casted concrete on the top. The expected LCA result for a wooden floor system is different than a solid concrete floor that fulfils the same sound insulation class. LCA information on this level can be used to improve the construction. Compared to the LCA in the design process, the digital LCA information that is created for the “as built” background LCA calculation are, at this stage, found of verifiable certificates from the digital trade, namely dispatched advices.
A document, delivery note, sent to a customer that states the description, type, and quantity of goods that have been sent to them.
Note that the number of digital items for the LCA calculation that is based on dispatched advices will increase from a couple of thousands of rows to about 20–40 thousand. If the LCA data is structured combining the building element type and their impact, the regulators can use this information in their supervision. If value limits are introduced in the future, it is important that the authorities can guarantee the law enforcement. Such digitalisation support is currently not on the market, and time is needed to establish such a system.
In order to create comparability on the building element level for supervision (surveillance/auditing) a common predefined reference unit per building element is needed. In practice, the impact in a climate declaration is given for the total amount of respective building elements. So, as supplement information, the amount in m, m2, m3, etc. for respective building elements need to be reported. This makes it possible to create a key performance indicator for each building element type to be used for comparison and suitable for supervision. Such digitalisation support is currently not on the market, and time is needed to establish such a system.
The climate impact for the building must therefore be reported per building element type, based on its reference unit. The key performance indicator per building element type can then be calculated per reference unit. The reference unit is a default and commonly agreed unit given per m3, except for the following building elements (typically according to IFCBuilingElement):
- Windows, doors, curtain walls, and shading devices per m2
- Chimney per pcs.
To summarise, it seems important that a common classification system is established to support a common knowledge database based on cooperation between countries.
Standardised building classification
The basic standard for the classification of the built environment is EN ISO 12006‑2:2020 Building construction – Organization of information about construction works – Part 2: Framework for classification. This standard shows that the built environment can be classified using a series of tables: spaces, construction complexes (e.g. a housing area), construction entities (e.g. a house), and construction elements (e.g. a roof or a window). An element can consist of other elements, thus forming a system.
Most or all of these tables can be found in national classification systems, e.g. Talo 2000 (Finland), TFM (Norway), SfB (old Swedish system, still used in, e.g. Denmark and the Netherlands), BSAB 96 (Sweden), Omniclass (USA), and Uniclass (GB). These systems are basically “enumerative”, sorting objects needed for construction in more or less similar ways: systems, sub-systems, and components.
There is also an international series of standard containing tables that can be used as an application of EN ISO 12006-2, namely IEC/ISO 81346. Part 2 of this series contains tables for spaces and “objects” (i.e. “components”); Part 12 contains tables for functional systems and technical systems; Part 10 contains tables for construction complexes and construction entities. All the classes are based on the function of the object.
Part 1 of IEC/ISO 81346 describes a method for identifying individual objects, and for showing four aspects of the object: its function, how it is assembled, where it is located, and what type it is. This method is unique and has been used in the industry—particularly within the field of electrical power—for many years. Classification based on IEC/ISO 81346 has a number of local adaptions: in Sweden and Norway (CoClass), Denmark (CCS), and the Baltic countries, Poland and Czechia (CCI). The use is still fairly small but growing.
For a classification system to be useful, it must have a clear purpose. The Talo system has its primary use for cost calculations. The Swedish BSAB system was developed for technical specifications and is used in the so-called AMA publications for describing technical and other requirements, including the material, on the finished result. The same can be said for SfB, TFM, Omniclass, and Uniclass.
As mentioned, the IEC/ISO 81346 tables have a very different purpose, namely to classify and identify functional objects throughout their entire life cycle. As soon as the need for an object is established, it can be given a class and a unique identity: a reference designation (RD). This constant RD will then be supplemented by other properties, based on the current need. These properties can include material, production method, size and weight, type and model, all the way down to the actual product or article used to realise the object. This article may be identified by its GTIN or by some other method.
The generic classes in IEC/ISO 81346, e.g. a wall construction, can be supplemented with constructive types, e.g. a wall with a concrete core and plaster board wall covering. In national applications, the 81346 classes and types can be “translated” into the national system.
CAD modelling softwares all have their own method of describing objects. When exported to the standardised IFC format, the software translates its internal object to the IFC equivalent, so that, e.g. a “Beam” becomes an “ifcBeam”. Apart from this basic classification, the IFC object carries many properties exported from the CAD software or added afterwards in a IFC editing tool.
Some of these properties—collected in an “ifcPropertySet”—can contain supplementary classification and identification. This way, a complete reference designation, according to IEC/ISO, can be added to each object of interest. It is noteworthy that there may be more than one classification system, and that those systems are often more precise than the IFC elements used.
The unique RD of each object can be used as a common “key” when storing additional data describing the object in other data formats. The different data sources share the same information model of the construction entity. This way, geometrical data from the CAD model can be combined with database sources, together forming a complete description of each object: its size, location, material, environmental impact, cost and so on, possibly to the extent of forming a “digital twin”.
To summarise, all classification systems for the built environment have their strength and weaknesses, based on their purpose. The only system designed for the life-cycle stable classification and identification of digital objects is IEC/ISO 81346. Other systems have different roles in specific phases of the construction and asset management process.
Suggested building parts and elements to be used
The draft version of EN 15978 that gives the LCA-based calculation contains an example list of building parts and elements. As an example, this is, in the table below, translated into equivalent CoClass classes or types. The letters in the CoClass are based on the common structure from IEC/ISO 81346. Refer to ‘Annex 3: Building part from prEN 15978 mapped with Nordic classifications systems’ for an extended mapping of the classification systems.
Building parts | Building element and processes | CoClass class/numbered type 1 letter = Functional system 2 letters = Constructive system 3 letters = Component | ||
Pre-construction works | Facilitating works | Temporary/Enabling works | ||
Specialist groundworks | ||||
Work to existing building | Demolition and alterations | |||
Substructure | Foundations and piles | A20 | Foundation | |
Basement walls | B31 | Cellar wall system | ||
Retaining walls | B32 | Retaining wall system | ||
Waterproofing | FSG10 | Water proofing | ||
Ground floor construction | C10 | Bottom slab system | ||
Super-structure | Frame | Columns | ULD | Column |
Beams | ULE | Beam | ||
Shear walls | BD | Wall structure | ||
Upper floors | C20 | Mid slab system | ||
Balconies | C41 | Balcony slab system | ||
Roof | Roof structure | D | Roof system | |
Weatherproofing | FSG10 RQA | Water proofing Insulation | ||
Stairs and ramps | AF AG | Stair construction Ramp construction | ||
Fabric | External envelope | External walls | B10 | Exterior wall system |
Windows | QQA | Window | ||
External doors | QQC | Door | ||
Shading devices | RQD | Screen | ||
Internal walls | Internal walls – load bearing | B20 | Interior wall system | |
Internal walls – non-loadbearing | B20 | Interior wall system | ||
Internal doors | QQC | Door | ||
Finishes | External finishes | Cladding | NCB | Wall covering |
Coatings | FSZ | Coating | ||
Internal finishes | Wall finishes | FSZ | Coating | |
Raised floors | AQ | Floor construction | ||
Floor finishes | NCC | Flooring | ||
Ceiling finishes | NCE | Roofing | ||
Building services | Water systems | Hot water distribution | F22 | Tap hot water system |
Cold water distribution | F21 | Tap cold water system | ||
Water treatment systems | KC | Cleaning system | ||
Rainwater systems | G24 | Roof water runoff system | ||
Sewage systems | G11 | Wastewater system | ||
Lighting | Internal lighting | Q11 | General lighting system for building space | |
External lighting | Q12 | General lighting system for outdoors space | ||
Electricity generation and distribution | K | Electrical system | ||
Renewable generation systems | K.HG31 | Electrical system > Solar electric supply system | ||
Heating systems | H20 | Heating system | ||
Cooling systems | H10 | Cooling system | ||
Ventilation systems | J | Ventilation system | ||
Conveying systems | N | Transportation system | ||
Telecoms and data systems | M | Information and communication system | ||
Fire protection systems | P10 | Fire safety system | ||
Communication and security installations | P30 | Personal safety system | ||
Table 9 Building part outlined in prEN 15978 and its mapping to CoClass that is an example of a classification based on IEC/ISO 81346.
Establishing constructive types of building elements
In order to be useful, classification systems need to have a clear purpose and a consistent principle for sorting objects into classes. For the built environment, ISO 12006-2 stipulates that the classes of construction elements should be defined by function, form or position, where “form” typically means “technical solution”. Examples:
- Function: delimiting a space, providing fresh air, letting in daylight.
- Form: solid, truss construction, aggregated.
- Position: interior, exterior, above, below.
Most of the current systems, e.g. BSAB 96, TFM, and Uniclass, use a combination of the three to define the classes of systems and components. As mentioned, the classes in IEC/ISO 81346 are primarily based on the function of the object. However, in the components table, about half of the 700 classes also show a technical solution.
In CoClass, the classes in IEC/ISO 81346 are supplemented by a large number of types. No distinct difference between a class and a type can be defined. A type simply has at least one additional.