buildingSMART Technical Roadmap

 Technical Roadmap

 

The digitalisation of our industry is accelerating. The demand and use of openBIM solutions and standards are increasing.
buildingSMART used to primarily focus on data exchange within the building domain. It is now pushed to widen the scope. More and more users, developers and modellers from outside the building domain want to use openBIM standards in their processes and tools. With new concepts like smart buildings, smart cities and digital twins just around the corner, there is an increased expectation for future-proof standards and solutions. This increased request for dealing with high data volume, low latency in exchange, modern frameworks for Artificial Intelligence and Machine Learning have quite a disconnect to the current file-based information silos.

The industry is moving towards more and more connectivity between domains. To facilitate this, buildingSMART needs to create scalable interoperability for data standards, tools and the underlying technologies.

The current standards and solutions operate in a limited environment. The threshold to use openBIM standards is high for people that are new to the community. This is often due to the use of underlying technologies that are not mainstream (anymore), the use of bespoke tools in the management process, and the creation of solutions that are not designed to work in modern, more generic development environments.

Creating a future technical roadmap is difficult today because the technology base of many standards and solutions is not scalable enough. The current technical roadmap is focussed on moving solutions and standards towards a generic, scalable base that lowers the threshold for users, modellers, developers and implementers from both inside and outside of the community to quickly and reliably use the standards and solutions.

The main goal of the short term is to move from bespoke solutions and technology to technologies and solutions that are scalable, widely adopted and work in a broad range of tools.

View a 30 minute webinar giving a full overview of the important content of the Technical Roadmap below.

Buildingsmart Technology roadmap summary challenges

Why a roadmap?

The digitalisation of our industry is accelerating. The demand and use of openBIM solutions and standards are increasing.

buildingSMART standards used to primarily focus on file-based data exchange within the building domain. It is now pushed to widen the scope. More and more users, developers and modellers from outside the building domain want to use openBIM standards in their processes and tools. With new concepts like smart buildings, smart cities and digital twins just around the corner, there is an increased expectation for future-proof standards and solutions. This increased request for dealing with filtering high data volumes, low latency in exchange, modern frameworks for Artificial Intelligence and Machine Learning have quite a disconnect to the current file-based information silos.

The industry is moving towards more and more connectivity between domains. There is a need for ‘next generation’ standards and solutions. To facilitate this, buildingSMART needs to create scalable interoperability for data standards, tools and the underlying technologies.

Download the roadmap

Get the PDF by filling out this form:

Industry Foundation Classes

IFC

Next generation IFCs

While the current structure of IFC is focussed on creating a standard for file-based exchange, new ways of working with a connected Common Data Environment (CDE), application of Digital Twins, connections to (streams of) sensor information, micro services, and future Smart cities, are demanding new requirements to IFC.

Changing the objective to optimizing IFC to ‘be used in a transactional environment’, instead of ‘optimizing file-based exchanges’ is a big change.

Become predictable and consistent

The geometry kernel is too big to fully implement. There are many specific entities that increase the efficiency of storage, but only have a few use-cases. Redundant geometry entities need to be cleaned up to lower the needed resources to implement IFCs reliable.

Remove circular references and dependencies

IFC is seen as an isolated container with all that is needed inside. This results in a situation where the whole file needs to be analysed, with multiple dependencies, before the result of a single object can be derived. Circular references make it hard to maintain in a CDE.

Language independent

The use of advanced STEP modelling structures have little or no comparable equivalents in broadly used languages. The many different options that are available provide a wide range of options for software vendors to build implementations. The schema needs to be language independent, stricter and eliminate ambiguity.

Simplified and consistent

Many of the advanced structures in IFC have been proven to be too complex for software vendors to implement. The time that vendors need to implement IFC is too long, and for vendors that have lower commercial interest in supporting IFC the threshold becomes too high. This results in half-baked implementations that cause problems for end-users.

10 principles of IFCs

To make changes on IFCs, the "10 principles of IFC" have been developed. These principles express what IFC should be, and are used as a guiding principle for decision making of future versions.

Learn more about the technical details of the next generation IFC in this video:

Information Delivery Specification

Your contract, your validation mechanism, your quality assurance

Introducing a new standard: IDS
Machine readable Information Delivery Specification

An Information Delivery Specification is a computer interpretable document that defines the Exchange Requirements. This can be a combination of  IFC, Domain Extensions, and additional classifications and properties (either stored in bSDD or somewhere else). This is the standard to use to define your Level of Information Needs. It brings validation of IFC to the client, the modeler and the Software Tools that perform (automated) analyses. It holds the ability to create localized and use-case specific requirements for your project. The IDS is the missing link for predictable and reliable data exchange workflows.

Predictable & Valid IFC exchange

An IDS will:

  • be able to define instance level requirements;
  • be able to link to bSDD concepts, properties and domains;
  • be able to specify properties and specific classifications;
  • be machine readable to be able to load into authoring tools to facilitate both users and software tools to generate, validate and correct mapping of internal data to the desired output;
  • be computer interpretable to allow automatic validation of IFC against the requirements;
  • be based on industry standard technologies to work with generic parsers;
  • be extendable.

Contact technical@buildingsmart.org if you want to participate in the development of the Information Delivery Specification standard.

See how an IDS would work in a future IFC workflow:

And more!

IFC Modularisation, bSDD, Deployment tools, BCF, APIs, etc...

buildingSMART Data Dictionary

The buildingSMART Data Dictionary (bSDD) is a service from buildingSMART to provide standardized access to additional classifications, property sets and more.  Although the bSDD is already up and running, there are challenges on the technical side, and on the usability. The 'Next Generation bSDD'  will have attributed to properties to allow the use of Product Data Templates.

This video shows how bSDD interacts with IFC:

 

Access to & communicating about data

Building an open API strategy

buildingSMART has a family of standards and solutions. Besides IFC and bSDD, standards like the openCDE API and the BIM Collaboration Format (BCF) unlock value in any collaborative workflow.

This video shows the relation between multiple standards, and the shared core they have in common.

 

Quality Assurance and Quality Checking

The buildingSMART deployment process needs to be transparent, traceable and reliable. It needs to facilitate the broad group of stakeholders, while keeping high quality assurance. The Technical Roadmap describes the different content streams and how to keep them harmonized and in sync using Continues Integration tools and the GitHub platform.

This video explains the deployment strategy for buildingSMART Standards and Solutions:

In 2 minutes

You have reached the end of the page. Hopefully all content was clear. Fill out this form to download the full Technical Roadmap as PDF: