BIM Model Data – what information do I have in my model?

While working with the BIM models you definitely must have encountered some of those with the weirdest possible properties and started to ask yourself: why is it even here? Who created it and for what reason? I’ve sometimes asked myself these questions too. Afterwards, it struck me that while we’re creating more and more data in our design, it is equally important to understand where the data comes from and where it belongs.

At first, I wanted to cover the topic of data validation. A little bit of introduction has been made by Ignacy here and I wanted to go deeper into data-related model checks. Nonetheless, before I can show you what and how to validate, you have to understand what data hides in our BIM models. A different set of properties is important in the design software, and the whole others outside of it (in IFC). What is more, some important data hides inside the models, while other is outside of it! Are you interested in what I mean? Keep on reading this article!

The following article is included in the Data Management in BIM series. In case it’s the first post you came across, I encourage you to read the introduction "What is data? Introduction to Data Management in BIM". I describe there the basic concepts and at the bottom you will find table of content. All that to make sure you can get the most out of the series. Have a good read.

Table of Contents

Model data is not your whole data!

Model data is a subject strictly interconnected to the whole BIM methodology and processes. To understand all the tables below, you have to first know what data is and what data is used in a BIM model. Luckily, I’ve already covered it in the article about the basics of BIM technology, in the entry about ISO 19650 and lastly in the series about data in BIM.

This graphic from ISO 19650 (and its great guidance by UK BIM Framework) and is the shortest summary of what data we collect in construction projects:

Graphics from ISO 19650-1 that depicts different data gathered during any project life cycle.

Commenting on the graphics above – from a BIM model data perspective, projects include:

  1. Structured data inside the BIM model (properties)
  2. Structured data outside and connected to the BIM model (schedules, some requirements and product data)
  3. Lots of both structured and unstructured data, outside and unconnected to the BIM model (emails, excel spreadsheets, contracts, documents)

This entry covers the first two since that data is the one we validate in our BIM validation software.

Model data: proprietary and IFC

In each model, there are at least two places to store the data – one in the design software (let’s call it proprietary data) and the other in IFC – an open format used in the construction process among others to federate the models and perform interdisciplinary checks.

Proprietary models tend to have a lot of properties for multiple reasons:

  • many are necessary to the design,
  • built-in properties and logic behind the software,
  • different add-ons that enhance the model with their own properties.
    That shouldn’t bother you as long as the model runs smoothly.

IFC models, on the other hand, should be clean of unnecessary data. They ought to contain only properties that are going to be used later in the project. The project’s Exchange Information Requirments (EIR) provides the list of such parameters. It all boils down to how the project will use the models. There are many possibilities ranging from the most complex model data usage to almost no data, for example:

  1. If the model is used actively on-site by workers – the highest number of properties
  2. If the model is used by the contractor in the office – the amount depends on the tasks performed
  3. If only as a basis to create drawings, then we need very few IFC properties.

Here you can read how to make the IFC model clean depending on the aim of the IFC usage.

Amount of proprietary data vs amount of IFC data in a model.
As you see in the graphics above, IFC data is a part of model data. It is also called MVD (model view definition). The dance is to map the data from proprietary models to IFC and to include in export only the data required by the project. If there are too many properties, those will come as the first issue after checking 😉

What data is in the model?

Many designers, while producing their beautiful models, don’t care about the data. Though they still create it and oftentimes this is high-quality data. By choosing the correct object category, material, capacity and dimensions, designers are already creating data in their models. This is the easiest data to create because it comes by itself within the design software (though there are of course mistakes. Lately, I’ve seen a mark on the wall designed as a “slab” category). I call these collections objects basic data and design data.

Enforcing correctness on other properties is much harder. I call them project management data – important for coordination and building process, but not much for the designers. This is the place where data carelessness takes the biggest toll. One of the reasons is the manual process of data entry. The designer has to write a value in the cell and it does not come by an action performed with the design tool.

Below, I classified the data by way of their creation, usage and destination. This is going to help us understand the next topic I want to cover – data validation.

Object basic data (class, name)

These are standard information about any object in the model. Some of them come with the design (category, name), while the others are voluntarily filled out by the designers (Mark, Number). Even though properties, such as “name” always exist, it doesn’t mean the quality of such data is always high. To maintain consistency throughout the whole model, designers have to create and follow project standards and naming conventions.
Property Name Description Example value
Name Name of the object. Often derived from the type name or profile name. Concrete-Round-Column 300mm
Category/Class What building element it is Column
Mark/Number/ID Additional numbering of the object C-01
Description Additional information about the object Placeholder STR
GUID Unique identifier for object instances. Available after export to IFC. 2IMP_i0eL4sO4GQO1ccL

Table showing example basic element properties.

Design data (material, profile)

They are the result of modelling using correct objects’ attributes and calculations. This refers both to the bearing load of a concrete slab as well as fresh air volume for the ventilation duct. If the design is correct, these data are also correct. Though, if the data here is incorrect it can have serious consequences for the project (too weak construction, insufficient ventilation, etc.).
Property Name Description Example value
Material Type of material and its class Concrete C40/50
Dimensions Width, height, length, radius, etc. 300mm
Profile/thickness Specific to the type of the element IPE300
Ventilation flow, rebar thickness, voltage, etc. Physical properties and calculation fields. Different for different branches 24000 m3/h, 25mm, 400V
Ratings Fire rating, Sound Transmission Class EI60, STC33

Table showing example design properties.

Project management

Those are so-called User Defined Properties (Attributes) that are not directly connected to the design outcome. Many of them exist to help with design management (eg. LOIN), calculations (classification code) or quality control and scheduling (control area, responsibility). Each of those parameters has its own role defined by the Building Owner in the EIR document.
Property Name Description Example value
Responsibility Who is responsible for mounting this object on-site K360
Control Area Where in the building this element exists 11.0401
Classification Code Code depends on a used classification ++215011=360.001:01-SQZ310%SQZ001
MMI / LOIN / LOD Maturity/ level of development of the element MMI200 / LOD350

Table showing example project management properties.

What data is outside the model?

Elaborating a bit more on point no. 2 from the first chapter list: not all model data has to be inside your design. What does it mean?

External databases connected to the model.

Their usage is steadily growing. Projects’ stakeholders do realize that BIM models are not the best place to manage their growing amount of data. They use external relational databases to store high amounts of data connected with the objects inside the model. This method has multiple advantages, I already discussed them three years ago in this entry.

Such external data can also be treated as model data because it can be easily queried using unique model identifiers (such as GUID, classification code or other). What’s more, all those different data sources can be combined using business intelligence software, such as Power BI.

External data

All the data that you’d better not have in the models, yet they are still important for the running or closing out of a project. This can be, for example, the data that is neither used for the design nor for the construction process but is still crucial before or after that phase. It entails early planning data or facility management. Also, BIM 4D and 5D can fall into that category since it is much easier to use third-party software to enhance the model than to load even more properties manually.

Property Name Description Example value
ID Unique identifier to connect database and model objects 21983
Work Schedule date Time when the element should be mounted on-site 2023-Week 41
Product information Metadata about the used product: supplier, manufacturer, etc. Manufacturer: Kone
Cost information How much does the material cost? $2480
Required equipment Early planning data - what equipment is required in each room 1 patient bed, 2 chairs, 1 reading lamp, etc.
Room requirements What are the requirements for that room specified by the building owner Permanent workstation for 2 people

Table showing example data that can be stored outside the BIM model.

Summary

So far you have learned the different aspects of data in models. You know that some of the data come by just modelling using correct tools, while the others require an effort of creating them manually. You have also learned that BIM data exists also outside of BIM models. Having that knowledge you should better answer the question from the beginning: why is this data even here? This is the first step for data validation.

Did you like that post ? Share it with others !

We spend a lot of time and effort creating all of our articles and guides. It would be great if you could take a moment to share this post !

Share:

Comments:

Subscribe
Notify of
guest
0 Comments
Oldest
Newest
Inline Feedbacks
View all comments

Author:

Download BIM CASE STUDIES:

After reading this guide you will learn:

  • How BIM is used on the biggest projects in Norway
  • What were the challenges for the design team and how were they solved
  • What were the challenges on the construction site and what was our approach to them

Newest articles: