logo

BIM Classification - Giving your models some Class

What role will classification play in lifecycle BIM? Is it important for AEC project collaboration? Is it important for Asset Information Management? Will it help bridge the gap between the two? Opinions around classification varies a lot. Having models with classification can have high value or can seem totally useless. The act of classifying can run smooth and almost automatic or can be a manual process seemingly without purpose.

The AECO industry needs a better understanding of the why, how, when and who of classification. Classification systems and processes also needs to be evolved into the new BIM world. After all - the promise of BIM is more data reuse and less data re-entry. We need to reuse the intelligence in our models and minimise manual tasks. As we will see classification systems can be a great way to bridge the gaps to existing processes and existing tools.

What you will learn

In this article we will cover what classification systems are, where they come from and where they are heading. In a lifecycle BIM context we will help point out where they provide value and where they may be redundant. We will have a special focus on classification as part of an openBIM workflow targeting handover between construction and operations.

What are classification (systems)

From wikipedia :

“Classification is a general process related to categorization, the process in which ideas and objects are recognized, differentiated, and understood.”

For the AECO industry a classification systems give the different parties a common understanding of what “something” in the AECO and FM domains is. This “something” to be categorised can be everything from complex properties and infrastructure (e.g hospitals, university campuses and motorways) to small items (like electrical components or furniture). In addition to describing what the “something” is, we often classify the use of “something” - a space for teaching or a component for airflow regulation.

Class systems are often hierarchical where the main classes are divided into subclasses some levels deep. This allows us to be very specific in the categorization and at the same time we can aggregate on the higher level classes when that make more sense.

A class (node in the class system) are often a combination of the class name (the human readable short name description) and the class value (the “code” that describes its place and level in the class hierarchy). In addition to those core items the class may be supported by a longer form description, synonyms and pointers/ references to other class values or class systems. This to help find and decide on the right value, understand its meaning or help translate between classification systems.

Why use classification systems

If classification is used consistently humans will have an easier way to find information. Machines will be able to understand the meaning of structured data. Classification is also important for standardization. It will help owners aggregate cost data and spot trends and outliers across the portfolio. It will help contractors bid on projects regardless of what consultant created the bid package.

Example use cases

A common use use of classification systems is to use standard categorization of building elements and products in specifications. Contractors will have a familiar structure in the specification and they are able to multiply quantities from the specification with their cost and price database.

For operations & maintenance (O&M) and handover is it common practice to name and tag systems and components using some kind of classification system. Classification system are also used to structure the contents of the handover of as-built and O&M documentation. This give familiarity and the possibility to have common view of the whole portfolio. Owners of portfolios also want to categorize their facilities and spaces by their use to get a common foundation for space management, cost budgeting, benchmarking etc.

In fact, for most processes where building data are created, shared and accumulated there are usually some kind of categorization needed to help both humans and machines communicate. To standardize and automate this categorization a classification system is used.

Example classification system

Let us have a look at a sample classification system to exemplify further. We have picked Uniclass 2015 as our sample system because:

The figure below show the core tables of uniclass 2015. The hierarchy/ graph show how the different tables relate to one another and how bigger complexes are divided into smaller components. To help understand the complexity and detail of the different tables we have added the number of classes to each node. As you will see there are more than 10.000 classes in total and the largest tables are the products and systems tables. Having many classification values may be a good thing as you can be more specific in the categorization, but it may also mean that it is more chance of classifying “wrong” or “differently”.

BIM Uniclass 2015 tables

What each of the tables are used for with samples are given in this great article by the NBS. The same link also have the seven main class tables available online as shown below. We recommend to take the time to use one of your projects or facilities as a case and try to classify the complex/ entity/ activities and sample spaces, systems and products to get a feel of the system in use. You will then also experience some of the challenges of classification.

BIM Ventilation system classification

Classification in IFC

Classification in IFC can be a bit confusing. There is already a lot of intelligence and categorization in IFC models by default. (The data model is called Industry Foundation Classes and describes a hierarchical structure of building elements, systems, types, properties etc).
The objects in the model are already classified as windows, doors, slabs, walls etc. In IFC the window may even be classified as being a skylight with a single panel, top hung with an aluminum frame (type enums). In addition there can be multiple standard and custom properties with values describing each window.

The reason for using classification systems in addition to these values can vary from owner to owner and contractor to contractor. It could be to standardize on one classification system across projects with and without the use of BIM. It could also be a way to to harmonise processes and to fill in the gaps where IFC do not have info needed in attributes or property sets.

The IFC data model have a specific concept called “Classification Association” that are used for adding references to external sources of information. The source of information can be a classification system or a dictionary server. The classification reference can point to an external source or the parts of the classification system that is in use can be embedded in the project data.

However in practice we most often see classification added to entities in alternative ways. Often as a result of how design tools work. E.g. class values are added as properties or classification values are used to name or describe entities (e.g. systems, types or layers). We also see many examples of BIM standards using properties instead of classification references.

Classification in COBie

Classification in COBie is a bit more straightforward
We have a separate article on COBie in case you want to read up on what COBie is and how it relates to IFC. COBie itself can be seen as a simplification of the IFC data model with a focus on data about the spaces and components that require management, operations and maintenance.

In COBie the classification values are put in a column/ property called category. If you use a spreadsheet to collect COBie data you would typically use a picklist for this column with class values as selection options.
In COBie it is mandatory to use a classification system but the owner can choose what classification system to use (the details of requirements and recommendations vary a little from country to country and edition to edition).

BIM Classification in COBie

In the table below we have listed the sheets where use of classification is recommended and also listed the omniclass tables (US) and uniclass 2015 tables (UK) that are recommended for each

COBie sheet Omniclass tableUniclass 2015 table
Contact34 Organisational RolesNA (PM Project Management)
Facility11 Construction entities by functionEn Entities
Space13 Spaces by functionSp Spaces
Type23 ProductsPr Products
System21 ElementsSs Systems

In traditional projects it is common to name and label documents and components using a combination of class values and unique numbers. In COBie documents are classified via their connection to the type (or system, space, facility or contact) objects.
Similarly components are classified indirectly by their type classification and also by their system (if they belong to one).

Please note that PAS 1192-4 (COBie for the UK) was released before uniclass 2015 was released. Therefore other tables from a previous version of uniclass is used in the example below taken from PAS 1192-4. You will also see that the previous version of uniclass was not covering all COBie objects and you often needed multiple tables. Comparing the images above and below show how the new version uniclass has harmonised much better with COBie (and IFC).

PAS 1192-4 COBie classification recommendations

Looking ahead

In this article we have covered the foundation of what classification systems are, where they come from and how they are implemented in openBIM and BIM standardization efforts. In later articles we will continue to investigate the topic and cover best practises, lessons learned and general advice for specific use cases related to lifecycle BIM. Watch this space if you are interested and use the comment section below if you have questions or opinions.

If you are interested in following us on this and related topics you should also sign up for our newsletter to get regular updates on lifecycle BIM and smart FM