Fact-checked by Grok 2 weeks ago

Industry Foundation Classes

The Industry Foundation Classes (IFC) is an open, that provides a standardized, schema for describing and exchanging data about the , including buildings, civil infrastructure, and related processes such as , , and . Developed to enable vendor-neutral in (BIM), IFC codifies the identity, semantics, attributes (e.g., materials and thermal properties), and relationships of physical components, analytical models, cost breakdowns, and workflows. It is published as ISO 16739-1:2024 by the (ISO) and maintained by buildingSMART International. The development of IFC originated in the early 1990s as an effort to create a neutral data exchange format for the , , and (AEC) industry, building on the STEP () standard and EXPRESS modeling language. In August 1994, twelve U.S. companies initiated the project, leading to the formation of the International Alliance for Interoperability (IAI) in September 1995, which coordinated global development with software vendors as primary stakeholders. The first release, IFC 1.0, was issued in January 1997 with a limited scope focused on basic architectural elements, followed by IFC 1.5.1 in July 1998, which gained initial support. By April 1999, IFC 2.0 expanded to include building services and cost estimation capabilities. Subsequent versions marked significant evolution: IFC 2x in October 2000 provided stability and opened the standard for free use, initiating ISO's Publicly Available Specification (PAS) process; IFC 2x2 in May 2003 added 2D geometry and facility management support; and IFC 2x3 in February 2006 became a key stability release, coinciding with IAI's rebranding to buildingSMART International. IFC 4, released in 2013 as ISO 16739-1, emphasized quality and broader applicability, with addenda in 2015 and 2016. The current official version is IFC 4.3.2.0 (commonly called IFC 4.3), published in 2024, which refines support for infrastructure and advanced BIM exchanges while maintaining backward compatibility. IFC data can be encoded in formats like STEP, XML, or JSON, and is supplemented by model view definitions (MVDs) and information delivery manuals (IDMs) to tailor exchanges for specific use cases. Ongoing development toward IFC 5 aims to further enhance semantic precision and integration with emerging technologies like digital twins.

Overview

Definition and Scope

The Industry Foundation Classes (IFC) is an open, for the exchange and sharing of (BIM) data, defined as a standardized, digital description of the , including buildings and civil . Developed by buildingSMART International, IFC is formalized under ISO 16739-1:2024, ensuring a neutral framework for data interoperability across diverse software applications and stakeholders. The scope of IFC encompasses the architectural, engineering, and construction (AEC) sectors, as well as facility management (FM) and civil infrastructure projects, capturing the full lifecycle of built assets from design through operations and maintenance. It includes representations of physical components, manufactured products, systems, and abstract concepts such as performance metrics and costing, with explicit support for geometric aspects (e.g., locations and connections), semantic details (e.g., identity, attributes like material and color, and object types), and relational elements (e.g., ownership and process relationships). This comprehensive coverage enables the modeling of diverse assets, including buildings, bridges, and other infrastructure, while integrating both spatial and non-spatial data. Unlike proprietary formats tied to specific vendors, IFC emphasizes vendor-neutral and platform-independent representation, promoting seamless without reliance on any single software . This open nature facilitates broad adoption in the industry, ensuring remains accessible and usable across tools and workflows.

Purpose and Benefits

The Industry Foundation Classes (IFC) standard serves as a neutral, open data schema designed to facilitate seamless data exchange between diverse (BIM) software applications in the , , , and facilities (AEC/FM) sectors. By providing a common platform for representing building and infrastructure data, IFC minimizes translation errors, rework, and information silos that often arise from proprietary formats, thereby streamlining project workflows from initial design through ongoing operations. This enables stakeholders to share accurate, consistent geometric and semantic information without loss of fidelity, supporting efficient decision-making across multidisciplinary teams. Key benefits of IFC adoption include enhanced collaboration throughout the building lifecycle, encompassing planning, design, construction, operation, and eventual demolition. Standardized data reuse allows project data to transition smoothly between phases, reducing coordination challenges and enabling updates among architects, engineers, contractors, and managers. For instance, in mandated public projects, IFC has been shown to improve design quality by up to 45% and deliver cost savings of 10-20% through reduced inefficiencies and faster project delivery. These advantages extend to facilities , where IFC supports ongoing asset by preserving essential attributes for long-term use. IFC plays a pivotal role in advancing openBIM principles by promoting vendor-neutral data accessibility, which prevents proprietary lock-in and ensures that project information remains usable indefinitely, regardless of software changes. As an ISO-standardized format (ISO 16739), it fosters a collaborative where data can be freely exchanged and extended, ultimately lowering barriers to and enhancing the of projects.

History and Development

Origins in the AEC Industry

The Industry Foundation Classes (IFC) emerged as a critical response to the fragmentation in data exchange within the , , and construction () industry during the mid-1990s, where proprietary (CAD) systems from various vendors hindered seamless collaboration across project teams. In 1994, leading software companies, including , initiated the formation of the International Alliance for Interoperability (IAI) to address these challenges by developing a vendor-neutral standard specifically tailored for the sector. This began as a collaborative effort among approximately 12 U.S.-based firms, evolving into a formal by 1995, with the primary goal of enabling efficient sharing of building information models (BIM) without dependence on specific software platforms. The initial development of IFC drew inspiration from the STEP () standards, which were originally designed for product data exchange in industries, but adapted to meet the unique requirements of building lifecycle in . Unlike STEP's broader, slower-evolving framework, IFC focused on creating lightweight, extensible product data models that captured essential geometric, spatial, and semantic information for buildings, such as architectural elements and structural components. This evolution incorporated STEP's EXPRESS modeling language for defining schemas while prioritizing AEC-specific needs like HVAC systems and construction processes, ensuring the standard could support both design and workflows from the outset. Early collaborations within the IAI involved a diverse group of AEC stakeholders, including software developers, architects, engineers, and end-users, who worked together to define a neutral, open that facilitated exchange across disparate tools. These efforts culminated in the release of the first IFC version (IFC 1.0) in January 1997, which provided a foundational for architectural , though initially limited in scope to basic building elements. This milestone marked the beginning of IFC as a platform-independent BIM standard, setting the stage for broader industry adoption.

Evolution of Versions

The development of the Industry Foundation Classes (IFC) began with the release of IFC 1.0 in January 1997 by the International Alliance for Interoperability (IAI), focusing on a limited scope that primarily covered basic building elements such as walls, doors, and structural components to enable initial data exchange in the architecture, engineering, and construction () sector. This foundational version established the schema's structure using the STEP () technology base, providing a neutral format for sharing geometric and semantic information without proprietary dependencies. IFC 1.5.1, released in July 1998, expanded on the with initial support, while IFC 2.0 in April 1999 introduced broader coverage including building services and cost estimation. Subsequent enhancements arrived with IFC 2x in November 2000, which introduced a more stable model with extensions and improved geometric representations, including better support for swept solids and constraints to address limitations in earlier prototypes. Further refinements in IFC 2x2 (May 2003) and addenda expanded coverage to building services, , and 2D elements, enhancing overall expressiveness for practical implementations. A pivotal milestone occurred with IFC 2x3 in February 2006, which refined the schema for quality and interoperability without major scope expansions, leading to its adoption as an ISO Publicly Available Specification (PAS) under and formalizing it as in subsequent updates. This version, along with its technical corrigendum in July 2007, aligned IFC with geospatial standards and improved documentation, marking the transition from IAI governance to in 2005, which introduced certification programs to ensure software compliance and broader adoption. The release of IFC4 in March 2013 represented a comprehensive upgrade, integrating advanced property sets for parametric object definition, full boundary representation (BREP) geometry for precise 3D modeling, and support for modern BIM workflows like resource management and quantity takeoff, while achieving full ISO standardization as ISO 16739-1. Addenda such as IFC4 Add1 (July 2015) and Add2 (July 2016) further enhanced documentation, added tessellated geometry, and ensured downward compatibility, culminating in IFC4 Add2 TC1 for certified model views. Extending IFC4's framework, IFC 4.3 emerged in phases starting with IFC 4.1 (preparing ), IFC 4.2 (adding bridge elements like IfcBridge), and reaching finalization as IFC 4.3.2.0 in 2024, with ISO approval in April 2024 under ISO 16739-1:2024 to support domains including roads, railways, ports, and bridges through new entities for alignments, geotechnics, and spatial structures. These updates have cumulatively increased IFC's expressiveness, incorporating capabilities via extensible property sets and alignments with contemporary BIM practices for seamless across building and projects.

Standards and Specifications

IFC Schema Overview

The Industry Foundation Classes (IFC) schema is defined using the EXPRESS data specification language, as outlined in ISO 10303-11, which enables the formal description of an object-oriented data model for building and infrastructure information. This schema functions as a hierarchical and extensible class library, encompassing over 1,300 entities along with their associated types, providing a comprehensive framework for representing building elements, relationships, and attributes. The modeling approach emphasizes reusability and modularity, allowing for the definition of complex constructions through interconnected classes that capture both geometric and semantic data. The schema's structure is organized into four conceptual layers to promote and facilitate extensibility. The Domain layer occupies the uppermost level, providing specialized extensions tailored to specific industry sectors, such as or . Below it lies the layer, with entities enabling cross-domain interactions across disciplines. The layer includes the schema containing the most general entities, such as IfcRoot, that introduce essential features like globally unique identifiers and owner history information. At the base is the Resource layer, offering foundational, shared concepts such as representations, units, and measures that are independent of global identification. This layered ensures that base-layer definitions remain abstract and reusable, while upper layers can incorporate domain-specific refinements without altering the foundational model. Inheritance principles form the backbone of the schema's object-oriented design, with every deriving ultimately from IfcRoot to inherit common attributes and behaviors, thereby enforcing across the model. For instance, subtypes like IfcObject or IfcRelationship extend IfcRoot to add specialized properties while maintaining compatibility with the parent class. Extensibility is further supported through mechanisms such as property sets (prefixed with Pset_) and quantity sets (prefixed with Qto_), which allow users to attach custom attributes or metrics to without modifying the base , preserving in exchanges. This design has matured through successive IFC versions, culminating in the robust IFC4.3 release.

Model View Definitions (MVDs)

Model View Definitions (MVDs) are formal subsets of the Industry Foundation Classes (IFC) schema designed to address specific exchange requirements within the architecture, , and (AEC) industry. By limiting the scope of the full IFC to essential entities, properties, and relationships, MVDs ensure consistent data interoperability for targeted workflows, such as clash detection or , without the overhead of unnecessary elements. For instance, the Coordination View 2.0 restricts data to geometric representations and basic spatial information suitable for multidisciplinary coordination and clash detection in BIM tools. Similarly, the Structural Analysis View focuses on analytical models, including load cases and finite element representations, tailored for integration with finite element analysis (FEA) software. The development of MVDs is overseen by buildingSMART International, which maintains a rigorous process involving domain experts, semantic reviews, and public consultations to align with industry needs. Once approved, MVDs are documented in the mvdXML format, an XML-based schema that precisely defines concepts, rules, and requirements for implementation. Validation is facilitated by tools such as , which generates documentation and checks compliance against the MVD specifications. This structured approach allows software vendors to certify their IFC implementations for particular MVDs, promoting reliable data exchange. Examples of official MVDs include the Reference View, which supports comprehensive data exchange for general model viewing and reference purposes, and the Quantity Takeoff View, which emphasizes quantifiable elements like volumes and areas for cost estimation processes. As of November 2025, buildingSMART has standardized 8 official MVDs across IFC versions, with 47 MVDs developed in total, including drafts and industry-specific extensions like IFC4precast for modeling.

Data Formats and Exchange

File Formats

The primary format for serializing and exchanging Industry Foundation Classes (IFC) data is the STEP Physical File (SPF), which uses the .ifc file extension. This ASCII-based, human-readable format complies with ISO 10303-21 and enables full fidelity representation of the IFC schema, making it the recommended choice for file-based import and export due to its compactness and broad compatibility. Alternative serializations include ifcXML, an XML-based format with the .ifcXML extension that adheres to ISO 10303-28 and supports enhanced readability for partial model exchanges and web . ifcXML is particularly suited for scenarios involving XML frameworks, such as web services and browser-based applications, though it results in larger file sizes compared to . An emerging option is ifcJSON, a JSON-based aligned with the IFC4 and under development for IFC5, designed for lightweight and with geographic information systems (GIS) as part of ongoing updates as of 2025. As of November 2025, IFC5 remains in development, with its core project plan under review, promising enhanced semantic precision and format integrations like ifcJSON. IFC files in SPF format consist of a header , which specifies the version, preprocessing details, and such as file description, name, and authorization, followed by a data containing entity instances referenced by unique #ID identifiers. These sections encode the IFC entities, with optional annotations for additional context like comments or end markers.

Interoperability and Certification

buildingSMART International oversees the of software implementations to ensure conformance with Industry Foundation Classes (IFC) standards, particularly through Model View Definitions (MVDs). The program validates both IFC and functionalities across versions such as IFC2x3, IFC4, and IFC4.3, utilizing the b-Cert to automate testing against specified MVDs. This process generates scorecards that detail supported IFC entities, validity rates, and conformance levels, helping users assess reliability. The Technical Certification Report (TCR), derived from b-Cert evaluations, documents MVD conformance by verifying that exported or imported IFC files meet exchange requirements, including concept templates and property sets. Automated testing in this framework leverages the buildingSMART Data Dictionary (bSDD) to standardize terminology and enable rule-based validation of IFC data against domain-specific definitions. For instance, bSDD facilitates machine-readable checks for and classifications, reducing inconsistencies in multi-vendor workflows. To specify IFC usage in projects, the Information Delivery Manual () provides a standardized methodology for defining information requirements, processes, and deliverables throughout a building's lifecycle. IDM outlines exchange scenarios, ensuring that IFC data aligns with project needs, such as geometric accuracy and attribute completeness. Complementing IDM, the BIM Execution Plan (BEP) details practical implementation, including IFC version selection, MVD application, and measures tailored to the project's scope. These tools promote consistent data exchange by bridging high-level requirements with operational guidelines. Compliance checking relies on specialized tools like the buildingSMART IFC Validation , a free online platform that scans IFC files for schema adherence, geometric validity, and entity completeness. Similarly, Solibri Model Checker performs rule-based analyses on IFC models, identifying deviations from standards or project specifications. Studies on IFC reveal typical during ; for example, in exchanges between , , and MagiCAD, structural models lost all IfcBeam and IfcReinforcingBar entities (replaced by proxies), while MEP models exhibited up to 100% loss of specific flow terminals and associated properties, highlighting the need for certified tools to mitigate such issues. Overall, these mechanisms have improved exchange fidelity.

Core Architecture

Layered Structure

The Industry Foundation Classes (IFC) schema adopts a four-layered to facilitate , reusability, and progressive specialization in representing building information models. This design separates concerns into the Resource Layer for basic utilities, the Core Layer for foundational object management, the Layer for shared spatial and representational concepts, and the Domain Layer for discipline-specific extensions, with higher layers inheriting and building upon lower ones to ensure semantic consistency. The Resource Layer establishes the lowest level of abstraction, supplying generic, non-identifiable elements that underpin definitions in all superior layers. It encompasses dedicated to units, measures, and external data references, enabling uniform treatment of fundamental values without unique global identifiers. For example, the schema defines IfcUnit for enumerating and assigning measurement units, such as meters or kilograms, and various IfcMeasure types like IfcLengthMeasure for specific value representations. Similarly, the schema includes IfcLibraryReference, which allows linking to external libraries through URI-based locations and optional identification keys, supporting integration of supplementary data sources. Building directly on the Resource Layer, the Core Layer introduces the essential for IFC entities, mandating globally unique identifiers and owner history for all objects to enable tracking and relationships. It comprises the IfcKernel schema, which defines IfcRoot as the abstract supertype for all persistent entities, and IfcObject as a subtype representing individual object occurrences with attributes for naming and . Complementary entities include IfcTypeObject for reusable type definitions that parameterize occurrences, and IfcPropertySet from the associated IfcPropertyResource schema for grouping and assigning to objects or types. This layer provides the structural backbone for basic , , and property attachment across the entire IFC model. The Layer extends the Layer to promote data exchange across disciplines, emphasizing standardized representations for and that apply broadly to products and processes. It includes the IfcRepresentationResource , featuring IfcGeometricRepresentation to link geometric items—such as curves, surfaces, or solids—to objects, and the IfcTopologyResource with IfcTopologyRepresentation for modeling and adjacency without full geometric detail. These components support the spatial description of elements in a vendor-neutral way, crucial for model , , and in multi-disciplinary workflows. At the apex, the Domain Layer tailors the Interoperability Layer to address requirements of specific industry sectors, introducing specialized entities that inherit from shared concepts for targeted applications. In the building domain, entities like IfcWall from the IfcSharedBldgElements schema represent vertical construction elements with attributes for load-bearing and material layering. In the structural domain, IfcBeam models linear members designed for bending resistance, incorporating parameters for cross-sections and spans. This layer enables precise, sector-focused modeling while maintaining compatibility with the underlying .

Fundamental Entities and Relationships

The Industry Foundation Classes (IFC) schema establishes a foundational to represent building in a structured, extensible manner. At the apex is IfcRoot, an abstract supertype from which all non-resource inherit, either directly or indirectly, providing core attributes such as a globally (GUID), optional ownership history, name, and . This forms the basis for three primary specialization branches: IfcObjectDefinition, which generalizes definable items including tangible elements like walls, conceptual items like grids, and processes; IfcRelationship, which objectifies connections between ; and IfcPropertyDefinition, which handles characteristics assignable to objects. IfcObjectDefinition further subtypes into IfcObject for individual occurrences, IfcTypeObject for shared type definitions, and IfcContext for project or library scopes, enabling hierarchical modeling of building components. Relationships in IFC are formalized through IfcRelationship, an abstract entity that encapsulates various connection types to maintain model integrity without embedding references directly in object definitions. Key subtypes include IfcRelConnectsElements for spatial adjacency and connectivity between elements, such as linking a to an adjacent , and others for (e.g., part-whole hierarchies), , , and . These relationships ensure that the model supports both physical and logical linkages, allowing for dynamic queries and validations across the building lifecycle. The property system in IFC allows for flexible attachment of attributes to objects via IfcPropertyDefinition, an abstract supertype that generalizes both property sets and individual properties. Properties are linked to IfcObjectDefinition instances through the objectified relationship IfcRelDefinesByProperties, which supports an N-to-M association where a single property set can apply to multiple objects, and multiple sets can attach to one object. For example, IfcPropertySingleValue, a subtype, defines a single attribute with a nominal value and optional unit, such as specifying material strength with a value in megapascals (e.g., NominalValue as IfcPressureMeasure with Unit as ). This mechanism decouples properties from core entity definitions, promoting reusability and extensibility while adhering to the schema's resource layer conventions for shared utilities. IFC employs both forward and inverse attributes to establish bidirectional links, enhancing navigability without redundancy. Forward attributes are explicitly declared within an entity's schema definition, such as a GUID in IfcRoot, while inverse attributes are derived from relationship instances pointing back to the entity. A representative example is the interaction between an IfcDoor and IfcOpeningElement: the IfcDoor participates in an IfcRelFillsElement relationship as the relating element (forward from the door's perspective via its FillsVoids inverse), which inversely references the IfcOpeningElement as the filled void; conversely, the IfcOpeningElement's HasFillings inverse points back to the IfcRelFillsElement, closing the bidirectional loop. Similarly, the host IfcWall uses an IfcRelVoidsElement relationship, where its HasOpenings inverse links to the IfcOpeningElement, ensuring comprehensive spatial and compositional traceability. These mechanisms, residing primarily in the kernel and extension layers, facilitate robust querying and integrity checks in IFC models.

Key Class Categories

The Industry Foundation Classes (IFC) organize its entities into key categories that facilitate the modeling of built assets, construction activities, supporting elements, and project frameworks in the architecture, engineering, and construction (AEC) industry. These categories—products, processes, resources, and contexts—provide a structured way to represent physical components, temporal workflows, consumable inputs, and overarching setups, enabling interoperable data exchange across software tools. Products form the core of IFC modeling for physical and spatial elements within built environments. The abstract entity IfcProduct serves as the supertype for all objects that have a defined position in space and can be represented geometrically, encompassing both tangible items like manufactured components and intangible ones such as annotations or grids. Key subclasses include IfcBuildingElement, which models structural and non-structural building components such as walls (IfcWall), doors (IfcDoor), and slabs (IfcSlab), allowing for detailed representation of their material properties, shapes, and placements. Another important subtype is IfcSpatialElement, used for defining zones and rooms (IfcSpace) that bound physical elements, supporting spatial decomposition and environmental analysis like lighting or thermal simulations. Processes capture the temporal and sequential aspects of construction and facility management activities. The abstract IfcProcess entity represents individual activities or events that occur over time, transforming inputs into outputs and establishing dependencies with other processes through nesting or sequencing relationships. Subclasses like IfcTask model specific work items, such as or , while IfcWorkSchedule aggregates tasks into structured plans for sequencing phases, including durations, constraints, and assignments to resources. Resources address the consumables, labor, and actors involved in project execution. IfcResource, an abstract supertype, defines the usage of items in processes, capturing costs, schedules, and impacts without requiring direct instantiation, and can link to explicitly modeled objects like products or materials. Subclasses include IfcMaterialResource for tracking material quantities and properties, and IfcLaborResource for crew-based efforts, often detailed by skill sets in descriptions. Complementing this, IfcActor represents organizations, persons, or roles (e.g., contractors or owners) that provide or consume resources, enabling assignment to processes via relationships. Contexts establish the foundational setups for projects, including geometric and organizational frameworks. IfcProject acts as the single root entity for an IFC data set, defining the overall context with attributes for units, phases, and representation contexts to ensure consistent data interpretation across the model. IfcSite models the land area for , incorporating via , , and , as well as geometric representations like footprints or 3D solids for site boundaries. IfcGeometricRepresentationContext specifies coordinate systems and precision for shape representations, including world coordinate axes and direction to align models with real-world orientations. These categories interconnect through relationship entities, such as assignments and decompositions, to form cohesive models.

Adoption and Applications

Software Implementations

Several major authoring tools in the (BIM) ecosystem provide native or add-in-based support for Industry Foundation Classes (IFC), enabling the creation, , and of IFC-compliant models to facilitate data exchange across disciplines. offers built-in IFC and capabilities, certified for IFC2x3 Coordination View 2.0 and IFC4 Reference View 1.2, with updates supporting IFC 4.3 for infrastructure elements starting from Revit 2022. includes native IFC support for versions 2x3 and 4, with IFC 4.3 and added in 29 to enhance in building workflows. Trimble , focused on , supports IFC2x3 and IFC4 for elements like beams, columns, and slabs, allowing structural models to integrate with broader BIM environments. Viewer and validator tools play a crucial role in reviewing and quality-checking IFC models without full authoring capabilities. Solibri Model Viewer provides free access to IFC files, supporting full import and interaction with IFC 2x3 models and partial support for IFC4, including clash detection and rule-based . BIMcollab, now under Trimble, enables viewing, combining multiple IFC files, and issue management, with support for IFC2x3 and IFC4 formats to federate models from various sources. These tools ensure certified reliability in IFC handling, as verified through buildingSMART's certification program. Open-source solutions and plugins address integration challenges for non-native applications, extending IFC capabilities through parsing, manipulation, and custom development. IfcOpenShell, an LGPL-licensed library, offers comprehensive reading, writing, and modification of IFC files across schemas like 2x3 and 4, with bindings for scripting and compatibility via wrappers for automated workflows. For applications like Rhino, the VisualARQ plugin enables IFC 2x3 and 4 import/export, assigning IFC properties to geometry to bridge parametric modeling with BIM standards. These implementations mitigate gaps by providing flexible APIs and add-ons for diverse software ecosystems.

Industry Use Cases

In design and coordination phases of , , and (AEC) projects, Industry Foundation Classes (IFC) enable clash detection by allowing interdisciplinary models to be exchanged and analyzed for geometric conflicts, particularly using the Coordination View Model View Definition (MVD). This facilitates early identification and resolution of interferences, such as between structural elements and mechanical systems, reducing rework costs in complex environments. For instance, in the expansion of in , IFC models were used to perform comprehensive clash detection on MEP systems against architectural and structural components, resulting in a fully coordinated LOD 400 model that saved approximately $7 million in change orders over six months. In and fabrication, IFC supports quantity takeoff and by providing standardized data exchange for material quantities and component specifications, streamlining off-site workflows. This is evident in Nordic initiatives, where IFC files integrate design data from multiple disciplines to generate accurate bills of quantities and fabrication drawings for prefabricated elements like wood frames and . A representative example is the work of builder Jadarhus, which imports IFC reference geometry into modeling software for prefabricated residential units, enabling precise integration of external and designs while identifying fabrication issues early to minimize on-site adjustments. For , IFC facilitates asset handover through as-built models that preserve detailed geometric and semantic , supporting operational for and space optimization. In , where BIM mandates require IFC-based submissions for projects over 5,000 square meters via the CORENET X platform, IFC serves as a "digital spine" for lifecycle , enabling seamless transition to operations and with technologies under the Integrated Digital Delivery framework. This approach ensures for ongoing management, such as real-time asset tracking in public buildings. Infrastructure applications leverage IFC 4.3 extensions for modeling linear assets like bridges and roads, enhancing data exchange in projects across . The standard introduces entities for alignments, terrains, and structural elements, allowing coordinated modeling of rail corridors with adjacent roadways and bridges. In the buildingSMART IFC Rail project, European stakeholders have applied IFC 4.3 to validate BIM models for railway infrastructure, supporting deliverables and reducing information loss in multi-party collaborations, as seen in pilot implementations for cross-border rail alignments.

Challenges and Future Directions

Current Limitations

The Industry Foundation Classes (IFC) , while comprehensive, suffers from significant complexity due to its expansive size and intricate structure, which has grown from approximately 650 entities in IFC 2x3 to over 1,300 in IFC 4.3. This monolithic design, inherited from the STEP standard, results in large file sizes and challenges in scalability, particularly for complex projects involving advanced modeling techniques. Consequently, software vendors often resort to partial implementations, supporting only subsets of the schema, which leads to issues such as semantic mapping errors and data loss during exchanges—for instance, advanced geometric representations like B-Rep solids or parametric surfaces may not be fully preserved when transferring models between tools like Revit and . Backward compatibility remains a persistent challenge in IFC usage, as evolving versions introduce structural changes that disrupt seamless upgrades. For example, migrating from IFC2x3 to IFC4.3 requires specialized converters like IfcPatch to handle entity renamings, attribute modifications, and deprecated features, often resulting in incomplete translations or manual interventions to maintain . This version dependency exacerbates issues in legacy projects, where older IFC files may lose spatial connectivity or relational data when imported into newer software environments without adequate mapping support. Semantic gaps in IFC limit its applicability beyond core architecture, engineering, and construction (AEC) domains, particularly in areas like sustainability analysis and AI-driven simulations. The schema's environmental impact parameters, such as those in Pset_EnvironmentalImpactIndicators, inadequately cover key life cycle assessment (LCA) indicators from standards like EN 15804, omitting metrics for freshwater eutrophication (EP-freshwater) or abiotic depletion potential for fossil resources (ADPF), which hinders automated integration of environmental product declarations (EPDs) into BIM workflows. Similarly, for AI applications, IFC lacks robust support for dynamic simulation data, such as real-time behavioral modeling in robotics or predictive analytics, necessitating non-standard extensions like IFC Rail that are not yet fully integrated, leading to fragmented data representation in interdisciplinary analyses. Adoption of IFC faces substantial hurdles, including a steep stemming from the need to master the EXPRESS language and domain-specific semantics for effective and . Vendor compliance is inconsistent, with major tools providing varying levels of IFC support that create a cycle of reduced market acceptance and failures. In emerging markets, these issues are amplified by limited access to , high costs, and lower prioritization of open standards amid reliance on , further slowing widespread uptake despite efforts by organizations like buildingSMART.

Developments Towards IFC 5

The development of IFC 5 represents a significant evolution in the , driven by buildingSMART International's Technical Roadmap published in April 2020, which outlines modernization efforts to address emerging needs in workflows. A core focus is modularization, where the schema is restructured into independent modules to facilitate easier maintenance, incremental updates, and domain-specific adoption; for instance, a separate module allows targeted extensions without affecting the entire . This approach, inspired by entity-component systems, enables flexible structures with entities, components, and systems, promoting and alignment with modern software architectures. Normalization efforts in IFC 5 aim to streamline the object hierarchy by enforcing mandatory element types, eliminating redundancies, and adopting a single model, potentially reducing the by over 100 entities to simplify implementation and reduce complexity. This refactoring also enhances language independence by transitioning from the EXPRESS to a UML-based definition, decoupling the standard from STEP dependencies and supporting multiple formats such as XML, , RDF, and HDF5. Such changes enable better non-English localizations through improved translation frameworks and automated quality controls in the buildingSMART , broadening global accessibility. Key enhancements in IFC 5 include native JSON support as a primary serialization format, replacing the more rigid STEP Physical File Format (SPFF) to accelerate integration and reduce development time from months to days for software teams. The standard also integrates provisions for AI and machine learning to enable semantic enrichment, such as automated data analysis and optimization in digital twins, by providing structured, small-scale data suitable for cloud-based processing and real-time collaboration. Additionally, expanded primitives for civil engineering, building on elements like IfcAlignment, address infrastructure modeling needs with simplified geometry representations using triangular meshes and semantic overlays. These features target a release post-2025; as of November 2025, development is ongoing, with the IFC 5 Core Project Plan reviewed by the Standards Committee in August 2025 and further updates in October 2025, enhancing interoperability for advanced use cases. buildingSMART's strategy for IFC 5 emphasizes phased development, beginning with the core module that defines domain-neutral concepts like object identity and spatial structure, followed by stakeholder-driven extensions through biweekly taskforce meetings and GitHub-based collaboration. This collaborative process, involving input from industry experts and alignment with ISO/TC 59/SC 13, ensures with IFC 4.x while positioning the standard for ISO 16739 series updates, ultimately aiming to sustain IFC's relevance for decades in openBIM ecosystems. The expected impacts include improved software , support for and transactional exchanges, and unlocked potential for AI-driven innovations in , , and .

References

  1. [1]
    Industry Foundation Classes (IFC) - buildingSMART Technical
    IFC, or “Industry Foundation Classes”, is a standardized, digital description of the built environment, including buildings and civil infrastructure.IFC Formats · IFC Specifications database · IFC Release teams · MVD Database
  2. [2]
    https://www.iso.org/standard/84123.html
  3. [3]
    [PDF] The IFC Standard - A Review Of History, Development, And ...
    May 29, 2012 · SUMMARY: IFC (Industry Foundation Classes) is an open and standardized data model intended to enable interoperability between building ...
  4. [4]
    Industry Foundation Classes (IFC), Clear Text Family
    IFC (Industry Foundation Classes) is an openly documented standard for the exchange of data about a building or facility and its construction or maintenance, ...Identification and description · Sustainability factors · Quality and functionality factors
  5. [5]
    Industry Foundation Classes (IFC) - buildingSMART International
    The latest official version of IFC is 4.3.2.0. This version is commonly referred to as IFC 4.3 and is also published by ISO as a final ISO 16739-1 standard.Latest Version · Ifc Validation And... · Frequently Asked Questions
  6. [6]
    The importance of Industry Foundation Classes in Building ...
    Learn how adopting the IFC standard and Building Information Modelling (BIM) will produce significant time and cost saving benefits.
  7. [7]
    [PDF] Global IFC Mandates - buildingSMART International
    Mandating IFC ensures data is open and available, and directives enable interoperable working methods. The benefits of mandating IFC are clear: it provides ...
  8. [8]
    The Evolution of IFC: The path to IFC5 - buildingSMART Spain
    Dec 3, 2024 · This article explores the fascinating journey of IFC towards its fifth iteration, IFC5, a development that promises to revolutionize the way we conceive and ...
  9. [9]
    IFC Release Notes - buildingSMART Technical
    IFC Release Notes. The following notes indicate the significant milestones and developments (revisions, additions, redactions) of the IFC schema release.Missing: history | Show results with:history
  10. [10]
    BCLP-049-BuildingSMART International and IFC - LinkedIn
    Apr 17, 2024 · Transition to buildingSMART International (2005-Present):. Rebranding (2005):. · IAI is renamed buildingSMART to address concerns about the ...Missing: governance | Show results with:governance
  11. [11]
    Body Brep Geometry
    4.8.2.9.6 Body Brep Geometry. The Body Brep Geometry is the representation of the 3D shape of a product by faceted boundary representation models.
  12. [12]
    IFC 4.3 Formally Approved and Published as an ISO Standard
    Apr 2, 2024 · IFC 4.3 is an ISO standard for digitalizing construction, extending to horizontal assets like roads and railways, and is expected to be widely ...
  13. [13]
    Introduction - IFC 4.3.2 Documentation - buildingSMART International
    The classes in the ISO 10303-11 EXPRESS schema distribution of this international standard are typically reflected in program code and directly influence ...Conventions · Model View Definitions · Architecture
  14. [14]
    Model View Definitions (MVD) - buildingSMART Technical
    MVDs are a way to deal with an IFC specification that is not specific enough. They are not neutral exports or mere technical profiles.Mvds Can -- And Frequently... · Examples Of Real-World Mvd... · How To Define Information...
  15. [15]
    Demystifying IFC Model View Definitions (MVDs) - LinkedIn
    Jul 31, 2025 · IFC Coordination View 2.0 Used for: Multidisciplinary clash detection Details: One of the earliest and most widely used MVDs based on IFC2x3.
  16. [16]
    IFC (Structural Analysis View) - Developers - buildingSMART Forums
    Apr 1, 2019 · Hello Experts, I made a model of simple framed structure using ETABS. After exporting it into the IFC file (Structural Analysis view), ...
  17. [17]
    MVD Database - buildingSMART Technical
    Compilation of Model View Defintions (MVDs), including official buildingSMART International standard MVDs and others throughout the industry.
  18. [18]
    The curious case of the MVD - buildingSMART International
    The harmonization of entities between different extensions is discussed until there is one single harmonized IFC, and then sliced up in the almost 20 MVDs.
  19. [19]
    IFC Formats - buildingSMART Technical
    IFC may be encoded in various electronic formats, each having benefits and tradeoffs of software support, scalability, and readability.
  20. [20]
    https://www.iso.org/standard/63141.html
  21. [21]
    https://www.iso.org/standard/40646.html
  22. [22]
    [PDF] ifcXML - buildingSMART Technical
    The IAI IFC schema, the SPF format and ifcXML formats are a particular implementation of the ISO-10303 standards and reference can be made to these documents as.
  23. [23]
    buildingsmart-community/ifcJSON: Repository containing ... - GitHub
    This repository contains the specification for ifcJSON-4 - version in sync with IFC EXPRESS Schema. What JSON is used throughout the world for exchanging and ...Missing: serialization 2024
  24. [24]
    [PDF] Implementation Guide for Header Data - buildingSMART International
    Aug 5, 2008 · The IFC header, taken from ISO10303-21, includes fields like FILE_DESCRIPTION, FILE_NAME, and FILE_SCHEMA, and is part of the IFC exchange file.Missing: origins | Show results with:origins
  25. [25]
    Software Certification Program - buildingSMART International
    At the moment the IFC import and IFC export software certification are available for all official versions of IFC (i.e. IFC 2x3, IFC 4 and IFC 4.3).Get Your Software Certified... · 'scorecards' Explained · Trusted By Leading Software...
  26. [26]
    [PDF] MVD policy for IFC 4.x - buildingSMART International
    This. 'conformance level' can for example define if IFC data can be used as a reference inside the software, or that is should be mapped to internal objects.
  27. [27]
    Information Delivery Manual (IDM) - buildingSMART Technical
    The main purpose of an information delivery manual is to make sure that the relevant data are communicate in such a way they can be interpreted by the software ...What Is It? · How Is It Used? · GuidesMissing: BEP | Show results with:BEP
  28. [28]
    [PDF] BIM Project Execution Plan Guide - BIM Forum
    Teams sometimes abbreviate BIM Execution Plans as either BEP or BxP in industry ... The current standards that most BIM software applications can use are IFC.
  29. [29]
    IFC Validation Service - buildingSMART International
    The IFC Validation Service is a free, online platform for validating IFC files, developed by buildingSMART – with the help of software vendors and bSI projects.
  30. [30]
    Solibri Office - The core product for model checking and collaboration
    Solibri Office imports building models from all major BIM software using the standardized IFC interface. It identifies potential problems early.Pricing · Product Tour · Contact sales · Integration partnersMissing: metrics loss
  31. [31]
    https://doi.org/10.3846/jcem.2018.6132
  32. [32]
    Introduction - IFC4.3.2.0 Documentation - buildingSMART International
    The classes in the ISO 10303-11 EXPRESS schema distribution of this international standard are typically reflected in program code and directly influence ...Conventions · Model View Definitions · Architecture
  33. [33]
    IfcMeasureResource
    The IfcMeasureResource schema specifies units and defined measure types that may be assigned to quantities. NOTE The fundamental unit types used in this schema ...
  34. [34]
    8.6.3.10 IfcLibraryReference - IFC 4.3.2 Documentation
    Jul 16, 2024 · An IfcLibraryReference is a reference into a library of information by Location (provided as a URI). It also provides an optional inherited ...
  35. [35]
    IfcRoot in IFC4 - buildingSMART International
    IfcRoot is the most abstract and root class for all entity definitions that roots in the kernel or in subsequent layers of the IFC specification. It is ...
  36. [36]
    5.1 IfcKernel - IFC 4.3.2 Documentation
    Jan 5, 2023 · There are six fundamental entity types in the IFC model, which are all derived from IfcObject. products - are physical object (manufactured, ...
  37. [37]
    6.1 IfcSharedBldgElements - IFC 4.3.2 Documentation
    Jul 15, 2023 · The shared building elements (IfcSharedBldgElements) define the subtypes of IfcBuiltElement, which is defined in the IfcProductExtension. Those ...
  38. [38]
    6.1.3.41 IfcWall - IFC 4.3.2 Documentation
    Jul 16, 2024 · IfcWall with IfcMaterialLayerSetUsage is used for all occurrences of walls, that have a non-changing thickness along the wall path and where the ...
  39. [39]
    6.1.3.1 IfcBeam - IFC 4.3.2 Documentation
    Jul 16, 2024 · An IfcBeam is typically a horizontal, or nearly horizontal, structural member that is capable of withstanding load primarily by resisting bending.
  40. [40]
    https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcObjectDefinition.htm
  41. [41]
    5.1.3.38 IfcRelDefinesByProperties - IFC 4.3.2 Documentation
    ### Summary: How IfcRelDefinesByProperties Attaches Properties to Objects
  42. [42]
    8.16.3.12 IfcPropertySingleValue - IFC 4.3.2 Documentation
    ### Summary of IfcPropertySingleValue (IFC 4.3.2)
  43. [43]
    5.1.3.13 IfcPropertyDefinition - IFC 4.3.2 Documentation
    ### Summary of IfcPropertyDefinition
  44. [44]
    6.1.3.16 IfcDoor - IFC 4.3.2 Documentation
    IFC4-CHANGE The inverse attribute datatype has been changed from the supertype IfcRelDecomposes to subtype IfcRelAggregates. Decomposes, SET [0:1] OF ...
  45. [45]
    5.4.3.40 IfcOpeningElement - IFC 4.3.2 Documentation
    The opening element stands for opening, recess or chase, all reflecting voids. It represents a void within any element that has physical manifestation.
  46. [46]
    5.1.3.10 IfcProduct - IFC4.3.2.0 Documentation
    ### Summary of IfcProduct
  47. [47]
    5.1.3.9 IfcProcess - IFC4.3.2.0 Documentation
    ### Summary of IfcProcess
  48. [48]
    5.1.3.43 IfcResource - IFC4.3.2.0 Documentation
    ### Summary of IfcResource
  49. [49]
    5.1.3.11 IfcProject - IFC4.3.2.0 Documentation
    ### Summary of IfcProject Definition and Role in Project Setups
  50. [50]
    5.4.3.63 IfcSite - IFC4.3.2.0 Documentation
    ### Summary of IfcSite Definition and Role for Geometric Contexts
  51. [51]
    8.18.3.4 IfcGeometricRepresentationContext - IFC4.3.2.0 Documentation
    ### Summary of IfcGeometricRepresentationContext for Coordinate Systems
  52. [52]
    4 Fundamental concepts and assumptions - IFC4.3.2.0 Documentation
    ### Summary of Fundamental IFC Concepts
  53. [53]
    LOD 400 MEP Clash-Free Modeling at International Airport | Oman
    The client needed a clash-free coordinated model in Revit and clash detection reports in Navisworks for a completely new airport project in Oman.
  54. [54]
    Case Study: Jadarhus - Vertex BD Software
    Jan 1, 2014 · Norwegian house builder Jadarhus is happy with Vertex BD's new IFC format, importing IFC reference geometry into the Vertex model. It makes any ...
  55. [55]
    [PDF] Global openBIM Mandates - buildingSMART International
    It supports the construction of data assets, data infrastructure, and digital twin cities in smart cities. • It guides and promotes data sharing in BIM ...
  56. [56]
    IFC Rail Project Phase 2 - buildingSMART International
    The focus of this phase is to implement and validate the Candidate Standard IFC 4.3 and bring it to the status of a Final Standard.
  57. [57]
    Applying IFC 4.3 for Rail Project - buildingSMART International
    The aIFC4Rail project aims to make IFC 4.3 available in software for rail projects, enabling required data import/export and formalizing requirements.Project Overview · Project Organization And... · Prioritized Business Cases
  58. [58]
    https://doi.org/10.3390/buildings15162927
  59. [59]
    IFC Backwards compatibility - Developers - buildingSMART Forums
    May 29, 2019 · Attached document shows a previous work to deal with compatibility issues between IFC2x3 and IFC4.
  60. [60]
    (PDF) Barriers to the adoption of Building Information Modelling in ...
    Despite its enormous potential, BIM is not widely used in developing countries such as Ghana and there are a number of barriers that inhibit its usage [18].
  61. [61]
    [PDF] Future of the Industry Foundation Classes: towards IFC 5
    That means the upcoming IFC 4.3 version and IFC 5 will have the same semantic scope. This way the IFC 5 release can focus on technological agreements and is ...Missing: relational | Show results with:relational
  62. [62]
    IFC 5 Core Project Plan is now out for review by the Standards ...
    The IFC 5 Core project establishes the foundation of a new, modular version of the Industry Foundation Classes (IFC) standard.
  63. [63]
    Clarifying the Role of IFC STEP (SPF) in IFC5 and Its Relationship ...
    Apr 2, 2025 · The primary format for IFC 5 will not be SPFF. Currently is looks to become JSON, but that is not a final decision yet.Missing: AI ML integration civil engineering
  64. [64]
    IFC4 vs IFC5: What the Upcoming Standard Means for Your Roadmap
    Aug 6, 2025 · While IFC4 is well-established, IFC5 introduces a fresh approach to data structure and sharing. IFC4 vs IFC5: Key Feature Comparison. Here's how ...<|control11|><|separator|>
  65. [65]
    IFC 5: A new hope for interoperability - BIM me UP!
    Oct 26, 2025 · Cloud and AI compatible: The small-scale data structure provides an ideal basis for cloud workflows, machine learning and automated quality ...
  66. [66]
    IFC and ISO: Four Tracks for Strategic Collaborations
    with industry engagement at the forefront ...