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:
Commenting on the graphics above – from a BIM model data perspective, projects include:
- Structured data inside the BIM model (properties)
- Structured data outside and connected to the BIM model (schedules, some requirements and product data)
- 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:
- If the model is used actively on-site by workers – the highest number of properties
- If the model is used by the contractor in the office – the amount depends on the tasks performed
- 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.
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)
| 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)
| 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
| 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.
Check out the series about Data Management in BIM:
