Simplebim Base Model

Authors: Jiri Hietanen, Maria Lennox, Sakari Lehtinen

Executive Summary

The purpose of this whitepaper is to define the theoretical foundation of the Simplebim Base Model, so it can be understood, debated, improved and adopted.

The Simplebim Base Model was born out of nearly 30 years of practical experience with BIM data exchange. The main premise is to abandon the goal of getting model authors to deliver exactly what model users need, in favor of thinking about how to get the maximum value from models that model authors can realistically deliver.

Without software ideas like the Simplebim Base Model are not worth much. However, our Simplebim application, which we have now developed for 17 years, already implements this idea. The solution we propose in this white paper has been tested and used in projects for the last 15 years. What is new is the formalization of the idea and its explicit implementation and distribution as ready-made dataflows in the Simplebim application.

In short, the Simplebim Base Model allows us to get the most out of any model. This is done by first finding all useful information no matter how it is encoded in the model, making this information understandable by standardizing properties and values, and finally organizing the result from the viewpoint of the model user. This provides a solid and reliable foundation for any use of the model data, be it further enrichment in Simplebim, use in any IFC enabled downstream application or in data analysis.

Introduction

In an optimal solution for BIM data exchange designers concentrate on their main task of creating great designs using tools and processes that come naturally to them. At the same time downstream users get reliable data that is structured according to their individual needs. The whole process is realized with a minimum amount of bureaucracy, cost and delays.

The current practice is far cry from this lofty goal, but with the Simplebim Base Model it becomes reality.

Why do we need the Simplebim Base Model?

The Goal

When BIM started to be seriously introduced in the mid-1990s the overall goal was to make data about buildings machine readable. The big idea was to start using machine readable models instead of human readable drawings and documents, because machine readable data can be exchanged and processed more efficiently and more reliably. This goal remains unchanged.

The Problem

After 30 years of concentrated international effort the envisioned benefits of BIM have not yet materialized on a large scale. Sure, everybody is talking about BIM, but it is still a specialist topic with only sporadic success.

The current mainstream approach relies on BIM requirements, legal mandates, agreements, model checking and issue management, which originates from the definition of ‘machine readable’ from 30 years ago. The whole approach is based on the idea that model authors deliver models that explicitly contain all the information needed by model users and are correctly structured based on needs of various downstream use-cases.

This approach sets strict requirements not only for data but also data structures, and has created a heavy, slow, fragile and expensive process requiring even new professions, like BIM coordinators. The absence of success has even led to truly absurd situations where we are expected to celebrate new specifications and legal BIM mandates instead of benefits to our industry.

The Solution

The solution is to be realistic about what we can expect from humans and to bridge the ‘semantic gap’ between humans and computers using better processes and smarter software that exists today but was not feasible 30 years ago.

The first component of the solution is to expect models that contain information model authors need in their own work and are responsible for. This information is captured and organized based on the needs of the model authors. These models still have certain requirements, but they don’t have to be flawless. They can contain spelling mistakes, incorrect labels and use different modeling styles that are a natural outcome of using different applications, company guidelines, templates, libraries and modeling practices.

The second component is to use the Simplebim Base Model to transform these models to contain the information needed by different downstream use-cases organized according to the needs of those use-cases.

The Simplebim Base Model solution has many benefits compared to the current mainstream approach.

The solution is easier, because it requires less agreements and set less requirements for the original models. This means less bureaucracy and easier modeling. It becomes easier to agree what must be done and easier to deliver what has been agreed.

The solution is faster because the process is faster to set up, and once the process is in use, modeling is faster. Because of the radically decreased complexity there are far fewer iterations and delays during the data exchange.

The solution is less expensive because time is money, but also because the process requires less highly paid experts for delivering the desired value.

The solution is more reliable because the original models contain information we can trust.  This is because model authors understand and themselves use the information in the models they deliver. Subsequent transformations are automated to produce a consistent result for downstream uses.

The solution is scalable because much of the heavy lifting is automated and far more people are skilled enough to participate. The results are also usable for a larger audience even beyond project boundaries and support a multitude of use cases.

The solution produces better designs, because the selection of designers can happen based on design skills, not technical skills such as being able to produce models that comply with complicated technical requirements.

The solution is open, because the Simplebim Base Model becomes part of the model (IFC) and is available to any downstream application. Such open, fit-for-purpose models enable all downstream applications to produce better results.

What is the Simplebim Base Model?

Not a Strict Standard

The Simplebim Base Model is not a strict or fixed standard. Instead, it is a framework for data standardization that can be adjusted and expanded by users for different purposes. It does however provide ‘best guesses’ that we have developed already for two decades. These are used as default values and they already enable a lot of use cases, but they should not limit the users. One thing we have learned the hard way is that, even though theoretically possible, it does not make sense to force the world to use one strict standard. The main goal is not ideology or academic correctness, but that data exchange works and produces value.

The Definition

The Simplebim Base Model has a definition, or schema, that defines ‘what it is’. How it is created, i.e. how to create a ‘Simplebim Base Model Enriched Model’, is not part of that definition. Leaving this open makes it possible to use different approaches and techniques that evolve and improve over time. Leaving also open how an ‘Simplebim Base Model Enriched Model’ is used makes it possible to use the result in new and innovative ways. The definition of the Simplebim Base Model itself stays stable, which provides a calm and reliable structure over time.

Simple Data Structures

One big table contains all data for all objects. Rows are objects. Properties are columns.

In the Simplebim Base Model all design disciplines use the same flat data structures for all objects. This is a radical simplification from the dedicated complex and hierarchical data structures used by design applications (see appendix A). This complexity is needed for supporting efficient design work, but it is not needed by downstream use-cases and thus it is not needed and causes many problems in data exchange. For example, the object class of an object most often reflects the modeling tool used by the model author, but for model users it is just a property among others. Sometimes it is useful, sometimes neutral and sometimes it is confusing and has negative value. What the downstream users need is reliable information in the simplest possible data structures.

Properties with Meaning

The Simplebim Base Model at its core is simply a list of properties and property values. Each property has a clearly defined meaning. Property values are understandable and obvious to model users.

Groups of Objects

Even though the result of the Simplebim Base Model can be expressed as simple properties, i.e. a table of data, where each row represents an object and each column a property, object groups play a central role in creating the Simplebim Base Model. Groups are the mechanism used for restructuring the original data to fit the needs of the model user. Groups are something everybody understands and knows how to use without any technical jargon.

How is the Simplebim Base Model Created?

01 - Find

The first step is to find all useful information no matter where it is in the original model and to standardize where it can be found. Any properties, relationships and geometry can be used for this. The result is the 01 -series of properties that contain original information that is copied into standard properties. For example, different models may use different properties for the same information and there may be properties with the same name in different property sets in a model. This makes finding information challenging, but with the Simplebim Base Model the same original information can always be found in the same place in all objects, in all models and for all disciplines.

Our current ‘best guess’ for 01 -properties is listed in Appendix B. However, the idea is that this list can also be extended as needed.

02 - Understand

The second step is to make the values of the standardized properties understandable. The original properties may contain domain specific abbreviations, project specific values and technical terms that are only understood by domain or BIM experts. The Simplebim Base Model makes an interpretation of the original 01 -properties and creates new properties where both the property and its values are standardized, and the property values are understandable. The original 01 material property may for example call the same material by different names or use abbreviations, but in the 02- property each distinct material has only one name.

In our ‘best guess’ for 02 –properties we have currently concluded that there are only two universal properties; building part and material. And even for these properties the values are not universal. In our Finnish version of the Simplebim Base Model we have many more properties but after testing them internationally we realized that there is a lot of variation. Instead of trying to force everybody into the same mold the 02 -properties must be extendable and experience will tell which, if any, additional properties are truly universally applicable. But the properties do not have to be universal to be useful to you, they just must be well defined and used consistently.

03 – Organize

The third step is to organize the information in the model based on the needs of the use-case at hand. The 01 and 02 properties provide a flat data structure without any grouping or hierarchies; they serve as raw material for creating any grouping or hierarchy that is needed. The basic method for the 03 properties is to create ‘data keys’ where several properties are chained together for creating combined values that meet the needs of the downstream users. The main idea is that the model author does not have to know anything about how the data must be organized for downstream uses. Instead, they simply provide the raw material and the model users each organize the model using this raw material.

Validate

From the original model we should only use data that we choose to trust. But even so, humans make mistakes and software has bugs. For validation the 02 -properties are crucial. To begin with, we only have 02 -properties that we really need and those properties have values that we, as the users of the data, understand. This gives us the ability to focus on what is important and to see if the data is correct. We see what values exist in the model and can view objects by value. For example, if the building part value is ‘external wall’ we can very easily see visually if that property value is correct. This also takes into account our individual understanding of what ‘external wall’ means, which can differ between use cases, like quantity take-off and energy analysis.

The core point is that once we have confidence in the 02 -properties we can also have confidence in the 03 -data key properties and everything else we later build on this information.

Enrich

The reason for creating the 03 -properties is targeted selection of objects, although in some broad cases 02 or even 01 properties can be directly used as selections. These selections are used as ‘targets’ in enrichment, which means deriving new information from existing information or adding new information from external sources.

The basic structure of enrichment is ‘target à action’, where the target is a selection of objects and the action is some operation that we perform on those objects. The target could be for example rooms and walls, and the action to create new wall surface objects based on the wall-room relationship. In this example creating these derived objects is only reliable if both the room and wall ‘targets’ are correct.

Automated and repeatable

Even though the definition of the Simplebim Base Model does not specify how it is created, it is important that the creation is automated. This means that adding the 01, 02 and 03 properties is automated using rules, and the process is not ‘GUID based’.

The second important characteristic of creating the Simplebim Base Model is that it is deterministic, meaning that the result with the same model is the same every time. This is different from using AI, which is probabilistic and where every run can produce a different result.

How is the Simplebim Base Model Used?

No Original Information is Lost

The Simplebim Base Model does not remove any information that is found in the original model. Instead, it adds the Simplebim Base Model information on top of the original information. In the Simplebim application it is technically possible to remove (trim) original information, but this is always a separate decision from adding the Simplebim Base Model.

Model Management

When the Simplebim Base Model is added to the original model this creates a new model, the ‘Simplebim Base Model Enriched Model’. It does not create a version of the original model. If you think about this in the context of a CDE the original model is versioned based on the versions the model author publishes to the CDE. The Simplebim Base Model Enriched Model is a separate model in the CDE and has its own versions that may be synchronized with the versions of the original model.

Base Model First Then Merge

When creating combined/merged/federated models the Simplebim Base Model should first be applied to each model before merging the models.

Merged models amplify the benefits of the Simplebim Base Model. The constituent models originate from different design disciplines, applications and modelers. Once the Simplebim Base Model is added to all models, browsing, understanding and using the information in the merged model becomes very easy compared with a merged model created from the original models.

Conclusion

Now that you are familiar with the idea and definition of the Simplebim Base Model you can have your own informed opinion about it. The theory may be a bit heavy, but the idea is simple; getting the maximum value from models that model authors can realistically deliver. For this end, the Simplebim Base Model improves both the models and the process that is used for creating them.

We are convinced that the approach presented in this paper, paired with its implementation in the Simplebim application and dataflows, is the solution for finally getting real benefits from BIM data exchange. It does not solve everything, but it will provide a major leap in how our industry is exchanging machine-readable data for increasing productivity and improving quality.

Appendix A: Complex data structures in original models

Object Class

The object class is intended to tell what an object represents, but often only tells which tool was used for creating the object and it can even depend on the export settings. It varies how well this information can be trusted and when it can be trusted, the object class is seldom the ‘target’ that is needed for actions.

Object Properties

The properties attached to an object either in the model schema or using extension mechanisms like property or quantity sets. Some properties may have an elevated meaning like predefined types, but the problem is that lists of allowed values always fall short of reality and even if the values were useful, they are not populated correctly.

Classifications

Hierarchical classification systems structure model objects from a chosen viewpoint. The problem is that there is no universally useful classification system because there is no common viewpoint. It then follows that classifications used by model authors are not useful to model users and on the other hand, model authors do not have the skills or motivation to use classification systems of model users.

Systems

Systems group objects from a functional viewpoint, like HVAC systems. The issue with systems is that the system breakdown is often too detailed for downstream use and the naming of systems is often understandable only to model authors.

Zones

Zones are essentially groups of rooms. The issue with zones in data exchange is that zones are usually defined by model users for their own purposes, not by model authors.

Groups

Groups are groups of objects for any purpose. The issue with groups in data exchange is that groups used by model authors are often not useful to model users and on the other hand, model authors don’t have the skills or motivation to create the groups model users need.

Type Objects and Type Properties

A type object defines properties that have the same value for all objects of the same type. Type objects are a powerful concept for model authors because they make modelling more efficient and help in keeping models consistent. The issue with type objects in data exchange is that model authors type objects differently from model users and thus exchanging type objects is not useful. However, exchanging or treating the type properties as instance properties is useful.

Containment / Model Tree

The containment (sometimes called model tree) defines a hierarchical structure of the model objects, where one object can belong only to one branch of the tree. The tree has spatial containers (like sites, buildings, building storeys) and elements (like walls, doors and windows). It may also have assemblies, which are elements that contain other elements. The issue with containment in data exchange is that there may be disagreement about which objects belong to which branch, for example if a floor slab belongs to the building storey above or below it. There is also no universal agreement about assemblies, because model authors need detailed breakdowns into parts, whereas model users typically work on a less detailed level.

3D and 2D Geometry

In addition to the visual appearance geometry can contain a lot of implicit information. The geometry itself has measurements, like dimensions, areas and volumes. The relationship of geometries has information, for example about which objects are inside another object, like which room a piece of furniture is located in.

Geometry Metadata

In addition to the resolved geometry the definition of geometry may carry information, such as profile names.

Location and Proximity

The location of objects has information, for example the elevation relative to the building storey containing the object. The proximity of objects carries information, for example a wall bounding a room tells us that some kind of surface treatment is needed for the part of the wall that is adjacent to the room.

Materials

Objects may have material information that is not captured as properties but as dedicated material objects, for example material lists or material layer sets.

Color and Transparency

In addition to visual information the color and transparency of objects can contain information. For example, a transparent wall could be understood to be a window.

Appendix B: Simplebim Base Model Properties

The following table lists the Simplebim Base Model properties that are the same for all objects. Not all objects have all properties, but none of the properties are bound to an object class, let alone a subtype of an object class. With this simple data structure, it becomes possible to capture all model data in one table, which is the optimal format for data analysis. The same simple structure is also easy to understand and superior especially when working with combined/merged/federated models.

The tables below list the Simplebim Base Model standard properties. They represent the status of the Simplebim Base Model on 21.9.2026 and follow the structure of the (then current) dataflows that ship with Simplebim version 12.0. The various Dataflow Kit -packages (version 1.0) contain dataflows that, when run, produce the Simplebim Base Model standard properties listed under them.