The next generation of open BIM standards
Robust, open formats can be the foundation of our industry's digital transformation. What do we need from the next generation of standards?
Welcome back to A Bicycle for Design! After a long summer hiatus, we are back to discuss tech, architectural and engineering design and how the world is changing.
Today, I will summarize a short talk I contributed to the BuildingSMART Standards Committee Technical Executive on June 30, 2022. You can watch the original presentation on Youtube.
As the construction industry digitizes, we are slowing shifting from file-based data transfer to platform- and object-based data management. In this post, I will put forward a general defintion a Building Information Model, and lay out some principles for the design of a next-generation data transfer model (e.g. IFC 5?) that will support platform or object-based workflows instead of file-based ones. These observations are based on my work as a structural engineer, my involvement in developing and deploying Speckle Systems within Arup over the past three years, and my work leading the design and development of Oasys' GSA Structural Analysis and Design software.
If you are in Montreal next week, I would love to meet up! I will be speaking at a panel on digitization of infrastructure projects at the Grand Forum des Infrastructures on Tuesday afternoon, and will be attending the BuildingSMART International Standards Summit from Tuesday to Friday. I hope to see you there!
What is a Building Information Model?
The clearest and most useful definition of a Building Information Model that I know of was given by Walter Richard Dolezal in Success Factors for Digital Mock-ups (DMU) in complex Aerospace Product Design:
A DMU is a digital 3D representation of a product together with its product structures and attributes
(A Digital Mock-up is a term from the aerospace industry with many parallels to a Building Information Model.)
In BIM-friendly terms, this mean that
A Building Information Model consists of:
3D Geometry
Attributes
Structures (plural!!)
There is no primary ordering or hierarchy
I struggled for a long time to understand the natural way to order or organize a set of elements defined in space. Do you sort them by their coordinates? Z, then X, then Y? Is there a 'correct' hierarchy that the data should always fit into?
Dolezal's definition of a DMU / BIM is quite clear: there are multiple possible hierarchies of data, none of which are 'better' than others. Each one helps to accomplish a different task: design, constrution, procurement, maintenance, sales, etc...
This leads to two principles:
The standard should allow multiple organizations of a single data set: If BIM is truly about collaboration, and since different tasks require different organizations, each team should be able to maintain their own hierarchy of data (either manually, or automatically).
The organization of the data should be independent of its definition: The objects that we are representing--be they bridges, buildings, retaining walls, etc...--do not know or care about any hierarchy. They simple exist in space and the laws of physics determine how they function. For a standard to be widely useful, it should be able to describe, for example, a retaining wall as either part of massive highway project or a building built into a slot. After all, a retaining wall is still a retaining wall, no matter what kind of project it is part of.
Don’t Mix Definition and Organization
When discussing hierarchies of data, there are two different types of hierarchy that are often discussed together, leading to great confusion: the defintion hierarchy and the organization hierarchy.
A definition hierarchy has is-a relationships. For example, the a beagle is a dog, a particular kind of dog. A gypsum partition is a particular kind of wall.
An organization hierachy consists of has-a relationships. For example, a building has a floor, or a plumping system has a pipe.
Definition Hierarchies should be as shallow as possible: Complex, formal taxonomies are useful for studying systems, but for accomplishing work, a simple (and often informal) vernacular is sufficient. We don't need to agree on the hierarchy of words, we just need to agree on what the words mean.
The data structure should not impose a specific hierarchy of organization: Since different users of the data need it organized in different ways, imposing a single organizational hierarchy will exclude all users for whom it is not fit for purpose and reduce the value of adopting the standard.
The data format should be able to describe things outside of a hierarchy: If multiple ways of organizing data are possible, it should also be possible to not organize the data. As we transition away from file-based data transfer to server-based data transfer, we need a standard that is able to share data about a single object, regardless of how different users have organized it.
Simplify the Scope
Keep the Geometry Simple
Geometry must be expressive (powerful) and unambiguous: A number of standards and open-source libraries exist for representing geometry (WKT, OpenNURBS, Open Cascade, etc...) that are well known and well supported.
Start with a Clean Snapshot
The data structure should exclude any mechanism for tracking revision history: the industry dominant version control system for software code, git, has demonstrated that there is no need to include version control within the data. Based on crypographic principles, a distributed version control system that wraps around the data can provide a robust and shared record of changes.
The data structure should allow differences between two versions of a data set to be automatically detected: For data to be productively managed in such a version control system, it much be easy to compute the difference between two versions of a model. This allows us to build tools to show what has changed between two models, and also allows model updates to be transmited as compact statements of changes. For example, if someone changes a wall colour in the full model of a massive hospital, we want to both know that this is all they changed and we want to be able to share the change with the whole team without re-uploading a multi-gigabyte model!
Analytics Models are not BIM
A BIM data standard should not introduce any complexity for the purposes of accommodating analytical models: Analytical models mean models that represent some behaviour of a structure. This could be a structural model that show how the building deforms under load; an energy model that shows how much energy is required to operate it over its lifetime; a lighting model that shows how much natural light each room will have; a pedestrian circulation model that shows how crowds will circulate in the space; etc... These models are different from Building Information Models a number of key ways:
Analysis models represent behaviour, not existence: a BIM shows what is where
The interconnections between elements (the hierarchy) is fundamental to the analysis model: while a BIM can have multiple hierarchies, an analysis model behaviour is driven by the interconnections.
Analysis models are often built on simplified geometries: instead of a one-to-one correspondance to the physical world, there are decisions taken to simplify the elements so that the analysis can focus on the behaviour of interest.
Given the differences in both the purpose and the nature of interconnections between BIM and Analysis models, adding the ability to represent analysis models into the core BIM standard will result in a massive increase in complexity.
One the other hand, a family of distinct standards could all describe geometry similarly and could also agree on some basic metadata attribute names.
Standardize to Scale
A scalable standard needs to be simple and strict. The standard should make decisions, not provide choices: Though standards are often criticized for taking too long to be agreed, it is best to speed up the standards process by simplifying scope, not by adding multiple ways to express the same thing just to keep everybody happy. For a standard to really drive interoperability, it should be as clear and unambigous as possible.
To give one example: there are many different ways of expressing an arc (a segment of a circle) in different 3D geometry standards, and my team has spent weeks debugging arc translations. If the standard only has one way to express an arc, then everyone who interacts with the standard needs to worry about one translation at the maximum.
What next?
In summary, here are the principles that a next-generation standard should meet:
The standard should allow multiple organizations of a single data set
The data structure should not impose a specific hierarchy of organization
The data format should be able to describe things outside of a hierarchy
Geometry must be expressive (powerful) and unambiguous
The data structure should exclude any mechanism for tracking revision history
The data structure should allow differences between two versions of a data set to be automatically detected
A BIM data standard should not introduce any complexity for the purposes of accommodating analytical models
A scalable standard needs to be simple and strict. The standard should make decisions, not provide choices
What do you think? I would love to hear your thoughts, either in the comments here on Substack, over on Twitter, or (even better!) face to face if you’ll be in Montreal this week!