Towards a technology independent IFC

Intro

The Industry Foundation Classes are the flagship standard of buildingSMART. It is the most mature standard that has a long history and many implementations in software. IFC has always been defined using STEP technology. The STEP standard is very efficient and has a rich set of advanced modelling techniques to create efficient file-based data exchange. The definition of IFC has quite some STEP specific modelling techniques, and over time gathered some inconsistencies. To work towards a future-proof IFC these issues need to be resolved. This page explains the objectives and sets the boundaries. Please read this whole article before contributing. Instructions how you can help will be in the text; a link to add your feedback is on the bottom of this page.

IFC in Common Data Environments, Digital Twins and Smart Cities

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. The use of a CDE, or the use of IFC in a Digital Twin requires an object-based use of IFC data. The current IFC is optimized for file-based exchange. To facilitate current use-cases like working with connected CDEs, and new business concepts like Digital Twins and automated (micro)services, IFCs needs to become capable of transactional exchanges, allowing smaller discreet exchanges. Transforming IFC to be capable of being used in a transactional environment is a huge task, and a drastic shift from the file-based optimization modelling techniques that are used up until now. Transactional capable IFCs can still be exchanged as files but also accessed, maintained and exchanged using an ‘Application Programming Interface’ (API). Partial (transactional) file exchange, or exchange of ‘changes’ (sometimes called ‘deltas’) is an industry need already. CDEs and Digital Twins are strongly based on the connection of different systems using APIs. The standardisation of APIs is an activity buildingSMART should focus on in the coming years. Currently it is difficult to use IFCs through an API because the way it is structured. Exchanging partial files between systems is also difficult because of the complex structure of the files. The file-based exchange optimisation is hindering the object-based access and exchange of (partial) IFC. Changing the objective to optimizing IFC to ‘be used in a transactional environment’, instead of ‘optimizing file-based exchanges’ is a big cultural change. It means the tech community of buildingSMART needs to use other key performance indicators during the development of IFC than they have been used to for the last 15 years.

The future of the IFC schema

Currently, the data model of IFC is very closely related to the STEP modelling techniques. This makes it hard to represent IFC in different formats. The focus on optimization of file-based exchange has resulted in very advanced data modelling solutions. Using the STEP standard is the best choice to model the IFC schema when it is focused on file-based exchange. The use of very advanced methodologies that are available in STEP, provides the opportunity for small file sizes and efficient file storage. The consequence of using these highly advanced techniques is that the schema becomes very complex. This complexity has numerous negative side-effects:

• 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.
• The structure has many dependencies in it. The final representation of entities is depending on the attributes of others (for example positioning of objects). The whole file needs to be analysed, with multiple dependencies, before the result of a single object can be derived.
• The use of advanced data modelling structures like ‘linked lists’, and ‘selects’ have little or no comparable equivalents in broadly used languages like UML and linked data standard RDF. Trying to mimic the IFC data types in languages like XML and JSON creates bespoke solutions that cannot be used with out of the box libraries.
• The many advanced data modelling structures that are available provide a wide range of options for software vendors to build implementations. This creates different implementations in software that are not interoperable. The schema needs to be stricter and eliminate ambiguity.
• 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.

To guarantee a future proof IFC, the schema needs to:

1. become predictable and consistent (to become stricter and easier during implementation);
2. be based on methodologies that have an equivalent in multiple, modern computer interpretable languages like XML, RDF/OWL and JSON (see picture);
3. remove circular references and possibly add identifiers to entities that don’t have any now;
4. improve modularity to facilitate additional domains and extensions.

Separating the conceptual schema of IFC from the modelling language and file format, will force the opportunity to eliminate complex modelling heritage. From a more generic base, different serialisations to STEP, XML, RDF, JSON(-LD) and binary formats can be generated efficiently. This will also open the possibilities for data modellers from other domains to contribute to the development of IFC. This creates a broader community that is scalable for future challenges. The clean-up needs to be sensible and reasonable. It is of vital importance to involve important stakeholders like the software vendors and other implementors. Depending on how thorough the clean-up of the schema will be, it could also influence the long-standing discussion about round tripping IFC.

Please help!

This repository is the place to work on the mentioned challenges. Please suggest your improvements and fixes by starting an issue on: https://github.com/buildingSMART/NextGen-IFC/issues