The Evolution of IFC: The path to IFC5

The spanish version of this article is available in this link. 

Evolution of IFC up to version 4

IFC has come a long way since its initial conception. Developed by buildingSMART International [6], formerly known as the International Alliance for Interoperability (IAI), IFC has become the de facto standard for data exchange in Building Information Modeling.

The legacy of STEP in IFC [1] [2]

In its early stages, IFC was based on the STEP format (Standard for the Exchange of Product Model Data), an international standard for the representation and exchange of product model data. STEP provided advanced modeling techniques that allowed for efficient data exchange and optimized storage in files. This choice was strategic, as STEP was suitable for the file-based data exchange needs prevalent at the time.

However, the use of these advanced techniques also resulted in a complex schema. The monolithic structure and dependence on STEP-specific technologies made the IFC schema difficult to implement and expand. Furthermore, this led to large file sizes and limited scalability, which affected the adoption and effectiveness of IFC in larger and more complex projects.

IFC versions up to IFC4

The evolution of IFC has been gradual but constant:

• IFC1.0 (1997): The first version, which laid the foundation for the schema and used STEP as its technological base.
• IFC2x (2000-2003): Introduced significant improvements in the stability and coverage of the schema, but maintained the dependence on STEP.
• IFC2x3 (2006): Widely adopted, this version became a major milestone, although it still inherited the limitations of the STEP-based approach. [3]
• IFC4 (2013): The current version, which includes improvements in geometric representation and support for new domains, but still retains much of its STEP legacy. [4]

IFC4, with its subversions 4.3 [5] and upcoming 4.4 [6], represents the current state of the art in BIM data exchange. However, despite its advancements, the industry has begun to recognize the inherent limitations due to its continued dependence on STEP. The complexity of the schema, the difficulties in implementation, and the restrictions on interoperability have highlighted the need for a fundamental evolution in the IFC approach.

buildingSMART's Technical Roadmap

In 2020, buildingSMART International, under the leadership of Léon van Berlo [7], presented a new technical roadmap [8] that would set the course not only for the immediate development of IFC, but also for its long-term future. This roadmap recognizes the need for a significant transformation in the way IFC addresses data representation and exchange.

One of the key decisions was to move towards a language-independent schema, freeing IFC from its dependence on STEP. This would allow IFC to be represented in multiple formats, such as XML, JSON, RDF, and even binary formats like HDF5. By adopting a more format-agnostic approach, IFC could be more adaptable and accessible to a wider range of users and software applications.

The vision presented in this roadmap is not limited to incremental improvements, but rather contemplates a fundamental reimagining of IFC. It recognizes that the current and future challenges of the industry require a more flexible, scalable, and adaptable approach than the current STEP-based structure can offer.

Complexity and Extensibility

One of the main challenges facing IFC4 is its increasing complexity, partly due to its STEP heritage. The monolithic structure and advanced modeling techniques used make the schema difficult to manage and extend. This complexity affects not only software developers implementing IFC, but also end-users who must navigate an increasingly intricate system.

The dependence on STEP-specific technologies has limited IFC's ability to adapt to new needs without compromising its integrity. Incorporating new concepts or relationships often requires significant changes, which can lead to incompatibilities between versions and difficulties in adopting new features.

Collaboration and distributed authorship

Another important challenge is the growing need for real-time collaboration and distributed authorship in construction projects. IFC4, while excellent for file-based data exchange, was not designed with these capabilities in mind. The rigid and monolithic structure inherited from STEP hinders distributed collaboration and integration into more dynamic and connected environments.

This limitation becomes especially evident in large and complex projects, where coordination between different disciplines and real-time change management are crucial. The lack of flexibility in the current schema hinders efficiency and can lead to errors in the design and construction process.

These challenges and limitations have been the catalyst for fundamentally rethinking the structure and objectives of IFC, giving rise to the first conceptualizations of what would become IFC5.

From COINS to ECS: early conceptualization of IFC5

The path towards IFC5, seeking to overcome the limitations of previous versions, did not arise in a vacuum. Within the Netherlands, there was a precursor to this global effort called COINS. This Dutch standard, although eventually superseded, aimed to address the complexities of digital information exchange in construction projects. COINS sought to bridge the gap between various stakeholders using different software and data formats, recognizing the critical need for interoperability within the industry. Although COINS eventually gave way to newer standards, its core objective was summarized as: facilitating the seamless exchange of construction data, laying important groundwork for future developments, including the conceptualization of IFC5. The limitations encountered by COINS, such as its restricted adoption and the emergence of more advanced international standards, likely shaped the future development trajectory of IFC5. The subsequent exploration of the Entity Component System (ECS), which we will detail in the following sections, as a potential solution for IFC5 reflects a continuation of these efforts, albeit on a broader and more globally focused scale.

The potential of the Entity Component System (ECS) [9]

The search for a solution to the challenges presented by IFC4 led developers to explore new data modeling paradigms. One of the most promising proposals was the adoption of the Entity Component System (ECS), a design pattern originating from the video game industry.

The ECS proposes a fundamentally different data structure:

• Entities: Unique identifiers that represent objects in the model.
• Components: Sets of data that describe specific aspects of an entity.
• Systems: Logic that operates on entities with specific components.

This structure offers several potential advantages for IFC5:

• Flexibility: Allows adding or modifying components without altering the fundamental structure of the object.
• Granularity: Facilitates access and manipulation of specific data without needing to process the entire object.
• Efficiency: Improves performance in operations that only require certain types of data.
• Distributed collaboration: Allows different disciplines to contribute specific data to the same object without conflicts.

First Proposals and Experiments

The first explorations of ECS for IFC5 focused on how this structure could address the limitations of IFC4:

• Handling type-occurrence relationships: A system of "ID prefixing" was proposed to maintain the relationship between types and occurrences of objects, allowing property inheritance and specific overrides.
• Simplified geometry: The use of triangular meshes was considered as the main geometric representation, with additional metadata to preserve semantic information.
• Flexible serialization: Formats like JSON were explored to represent the ECS structure, seeking a balance between human readability and computational efficiency.
• Composition and inheritance: Mechanisms were investigated to allow the composition of complex objects and the inheritance of properties, while maintaining the flexibility of ECS.

These initial experiments demonstrated the potential of ECS to address many of the challenges of IFC4, but also revealed new complexities and areas that required further research.

The shift towards Universal Scene Description (USD) [10]

As the development of IFC5 progressed, the buildingSMART community began to pay attention to another emerging technology: Universal Scene Description (USD).

Background of USD and its role in the construction industry

USD (Universal Scene Description), originally developed by a major animation studio (Pixar), is a file format designed for collaborative 3D workflows, especially in computer graphics and visual effects. Its growing popularity in the construction industry stems from its simplicity, efficiency in handling complex 3D data, and ability to support collaborative workflows. Unlike traditional formats like IFC, which are rooted in older technologies and can be complex to manage, USD offers a flatter and more accessible structure that is better suited to modern data processing and analysis.

Several leading technology companies and institutions are playing significant roles in integrating USD into the construction industry. Three major technology corporations have formed an alliance with the goal of promoting USD as a standard for data exchange and collaboration. Two prominent construction software vendors, who are key members of buildingSMART, have also joined this alliance. This suggests a potential shift in the industry towards USD, although buildingSMART has not officially committed to integrating USD into future versions of IFC. This shift is driven by the desire for more efficient data management and potentially influenced by the strategic interests of major software vendors, who see USD as a way to unify data and potentially streamline their ecosystems.

USD offers several features that align with the goals of IFC5:

• Data composition: USD allows combining data from multiple sources in a non-destructive manner, facilitating collaboration.
• Hierarchical structure: It uses a system of "prims" (primitives) organized in a tree structure, similar to the object hierarchy in IFC.
• Extensible schemas: Provides mechanisms to define and extend data schemas flexibly.
• Optimized performance: Designed to handle massive and complex datasets.

The interest in USD led to a rethinking of the direction of IFC5, exploring how USD concepts could be integrated or inspire future development.

Exploring new serialization approaches

In parallel with the interest in USD, the exploration of more efficient and flexible serialization formats for IFC5 has continued. Some of the research areas include:

• USD JSON: A representation of USD in JSON format, seeking to combine the flexibility of USD with the familiarity and ease of use of JSON.
• Optimized binary formats: Research into formats that can efficiently handle large volumes of geometric and semantic data.
• Incremental serialization: Development of methods to transmit and update only the changes in a model, instead of the entire dataset.
• Integration with existing standards: Exploration of how IFC5 could more easily interoperate with formats like glTF for geometry or BCF for communication.

These explorations seek not only to improve the technical efficiency of IFC, but also to facilitate its adoption in a broader technological ecosystem.

Geometric and semantic representation

One of the biggest challenges in the development of IFC5 is finding the right balance between the simplicity of geometric representation and the richness of semantic information. The focus on triangular meshes as the main geometric representation offers advantages in terms of performance and compatibility, but raises questions about how to preserve design intent and parametric information.

Simplification of geometric definition in IFC5

The adoption of USD features in IFC5 has opened the door to simplifying geometric definition. One of the key advantages of USD is its ability to handle composition, allowing object instances to inherit data from a "typical" element. This means that the geometry of a repeated object does not need to be redefined multiple times, but can be inherited from a single source.

This composition is achieved by moving the idea of instance inheritance to a more fundamental level within the serialization system or library. Instead of treating it as another component, it becomes an inherent behavior of the system, allowing for a more efficient representation of repeated geometries.

Furthermore, USD introduces a schema language that defines entities and their associated components, ensuring that only relevant components are applied to a specific entity. For example, materials would not be applied to property sets, preventing illogical data associations.

Simplification also involves migrating from the current procedural and complex geometric definitions in IFC to an approach focused on triangular meshes, a fundamental geometric representation in USD. This eliminates deep dependencies and intricate Boolean operations that make analyzing and modifying geometry in IFC complicated.

Although meshes would be the primary representation, there is the possibility of overlaying additional semantic information on them. This would allow representing concepts such as extrusions, cutting planes, and voids in a more simplified and generalized manner.

This simplified approach to geometric definition, along with USD's composition capabilities, addresses the concern about repetitive geometric definitions. By defining a typical element and allowing instances to inherit its geometric properties, IFC5 could reduce redundancy and improve efficiency in handling complex models.

However, when simplifying geometry, it is essential to ensure that important aspects of design intent are not sacrificed. The ability to represent parametric and semantic details remains essential for many applications, so IFC5 will need to find ways to maintain this information, possibly through additional metadata or semantic layers on top of the basic meshes.

Standardization and software implementation

The transition from a STEP-based approach to a language-independent one presents significant challenges for standardization and software implementation. Developers will need to adapt their tools and workflows to work with these new data structures.

Key opportunities include:

• Development of reference tools and libraries: Facilitating the implementation of IFC5 in software through resources and detailed documentation.
• Certification and testing programs: Ensuring interoperability between different implementations through quality and conformance standards.
• Collaboration with the industry: Working closely with developers and end-users to identify challenges and needs, ensuring that IFC5 is practical and useful.

Looking ahead, IFC5 has the potential to transform how information is managed in the Architecture, Engineering, and Construction industry. However, it is crucial to recognize that this transformation must be rooted in a deep understanding and effective utilization of semantic information. Some key perspectives and expectations, considering the vital role of semantics, include:

• Deeper integration with other disciplines while preserving semantic richness: IFC5 should facilitate seamless integration with fields such as geospatial, facility management, and urban planning, but this integration should not come at the expense of semantic richness. The challenge lies in developing mapping mechanisms that allow the exchange of meaningful semantic information between different domains, ensuring data consistency and interoperability. For example, when integrating with geospatial data, IFC5 should not only exchange geometric representations of buildings, but also convey semantic information about their function, occupancy, and other relevant properties.
• Improved support for digital twins with semantic interoperability: The more flexible and efficient structure of IFC5 can make it more suitable for real-time digital twin applications. However, the success of digital twins depends on the ability to access, analyze, and visualize not only the geometry, but also the semantic information associated with building components. This requires IFC5 to provide robust mechanisms for representing and querying semantic relationships, classifications, and properties, ensuring that digital twins can leverage the full richness of building information.
• Facilitating artificial intelligence and machine learning through semantic data structures: A more granular and semantically rich data structure in IFC5 can enable advanced analysis and optimization using artificial intelligence and machine learning. AI algorithms rely on structured and semantically labeled data to identify patterns, generate insights, and make predictions. Therefore, IFC5 should prioritize the development of a data model that facilitates semantic labeling and structuring, making it readily usable by AI applications for tasks such as automated compliance checking, performance analysis, and predictive maintenance.
• Increased industry adoption driven by semantic clarity and usability: If IFC5 achieves its goals of simplicity and flexibility, it could see wider adoption in the industry, even in areas where IFC4 has faced challenges. However, simplicity should not equate to a reduction in semantic information. IFC5 must strike a balance between ease of implementation and semantic richness, ensuring that the data model remains sufficiently comprehensive and expressive to meet the diverse needs of the AEC industry. This involves developing clear and intuitive ways to represent semantic information, making it accessible and usable by a wider range of stakeholders.
• Continuous evolution guided by the changing semantic needs of the industry: IFC5 is likely to evolve to adapt to the changing needs of the industry and technological advancements. This evolution should include a focus on incorporating new types of semantic information and adapting existing data structures to accommodate emerging technologies and use cases. For example, as the industry moves towards a more data-driven approach, IFC5 might need to incorporate semantic information related to sensor data, building performance, and user behavior, ensuring that the standard remains relevant and valuable in the future.

In conclusion, while the proposed expectations for IFC5 are promising, they must be viewed through the lens of semantic information. We should highlight the importance of semantic data in achieving IFC's goals and supporting the industry's move towards a more data-driven and automated future. The success of IFC5 will depend on its ability to not only simplify and streamline certain aspects, but also maintain and enhance the semantic richness of the data model, enabling a truly comprehensive and insightful representation of building information.

The development of IFC5 represents a crucial moment in the evolution of information exchange standards in the AEC industry. By addressing the limitations of previous versions and exploring new paradigms such as ECS and USD concepts, IFC5 promises to offer a more flexible, efficient, and adaptable standard to the future needs of the industry. The transition from a dependence on STEP to a language-independent schema constitutes a significant step that will broaden the accessibility and usability of IFC, allowing a wider range of software applications to interact with the standard, thus fostering greater interoperability and collaboration across the industry.

However, it is essential to recognize that the global adoption of IFC4.x, and the path towards IFC5 is not without significant challenges. The implementation of new paradigms and technologies will require a concerted effort from software developers, industry professionals, and standardization bodies. The recent successes achieved with IFC 4.3 and the promising advances anticipated in IFC 4.4, especially in areas such as tunnels and geotechnical aspects, demonstrate the vitality and continued relevance of the 4.x series, a solid foundation that must be protected and valued.

The transition to IFC5 should be understood as a natural evolution rather than a disruptive revolution, where maintaining the balance between innovation and stability is fundamental. Organizations that are currently investing in IFC4.x implementations should feel confident that their efforts will not be in vain, as these implementations will form the basis upon which the future of IFC will be built. Continued collaboration and feedback from all stakeholders will remain crucial to ensure that IFC5 meets its objectives without causing unnecessary disruptions to existing workflows.

Ultimately, the success of IFC5 will depend not only on its technical merits, but also on its ability to build upon the achievements of IFC4.x, maintaining the trust of the industry and ensuring continuity in the development of the digital construction infrastructure. With a careful and collaborative approach, IFC5 has the potential to lay the foundation for a more integrated, efficient, and innovative AEC industry in the coming decades, without compromising the progress and investments made to date. This balance between innovation and stability will be essential to ensure a successful transition to the next generation of information exchange standards in construction.

[1] International Organization for Standardization, "ISO 10303-21:2016 Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure", ISO, [online]. Available in: https://www.iso.org/standard/63141.html. [Accessed: 2016]

[2] International Organization for Standardization, "ISO 10303: STEP Standards", ISO, Geneva, Switzerland, 2016.

[3] buildingSMART International, "IFC2x3 TC1 Documentation", buildingSMART Standards, [online].Available in: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/. [Accessed: 2024]

[4] buildingSMART International, "IFC4 Add2 TC1 Documentation", buildingSMART Standards, [online]. Available in: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/. [Accessed: 2024]

[5] buildingSMART International, "IFC4.3 Documentation", buildingSMART Standards, [online]. Available in: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/. [Accessed: 2024]

[6] buildingSMART International, "IFC 4.4 - dev: Potential extension of 4.3. Adding additional functionality. Currently in planning phase", buildingSMART Technical, [En línea]. Available in: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/. [Accessed: 2024]

[7] L. van Berlo et al., "BIM Quickscan: Benchmark of BIM Performance in the Netherlands", en Proc. CIB W78 2012: 29th International Conference, 2012. [online].Available in: https://itc.scix.net/pdfs/w78-2012-Paper-30.pdf

[8] buildingSMART International, "Technical Roadmap", buildingSMART, [online]. Available in: https://www.buildingsmart.org/standards/technical-roadmap/. [Accessed: 2020]

[9] buildingSMART International, "Entity Component System (ECS) for IFC", buildingSMART Technical, [online]. Available in: https://technical.buildingsmart.org/projects/ecs-for-ifc/. [Accessed: 2023]

[10] Pixar Animation Studios, "USD Technical Introduction", OpenUSD, [online]. Available in: https://openusd.org/release/intro.html. [Accessed: 2024]

[11] Pixar Animation Studios, "Universal Scene Description Documentation", OpenUSD, [online]. Available in: https://openusd.org/release/index.html. [Accedido: 2024]

[12] buildingSMART International, "IFC5 Documentation", buildingSMART Technical, [online]. Available in: https://ifc5.technical.buildingsmart.org/. [Accedido: 2024]

[13] buildingSMART International, "IFC5-development", GitHub Repository, [online]. Available in: https://github.com/buildingSMART/IFC5-development. [Accessed: 2024]

[14] buildingSMART International, "IFC Overview", buildingSMART Technical, [online]. Available in: https://technical.buildingsmart.org/standards/ifc/. [Accessed: 2023]

[15] buildingSMART International, "Industry Foundation Classes (IFC) - Implementers Forum", buildingSMART, [online]. Available in: https://www.buildingsmart.org/resources/ifc-if/. [Accessed: 2024]

[16] buildingSMART International, "IFC Schema Specifications", buildingSMART Technical, [[online]. Available in: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/. [Accedido: 2024]

[17] buildingSMART International, "mvdXML Documentation", buildingSMART Technical, [[online]. Available inn: https://technical.buildingsmart.org/standards/mvd/mvdxml/. [Accedido: 2024]

[18] buildingSMART International, "What We Do", buildingSMART, [[online]. Available in: https://www.buildingSMART.org/about/what-we-do/. [Accessed: 2022]

[19] International Organization for Standardization, "ISO 19650-1:2018 Organization and digitization of information about buildings and civil engineering works", ISO, [online]. Available in: https://www.iso.org/standard/68078.html. [Accessed: 2018]