What is OpenBIM and why are architecture, engineering, and construction firms increasingly specifying open data standards particularly IFC over proprietary BIM file formats for model exchange and project delivery?
OpenBIM is a universal approach to Building Information Modelling that uses open, vendor-neutral data standards principally the Industry Foundation Classes (IFC) format developed by buildingSMART International to enable any BIM software platform to exchange model data with any other platform without requiring both parties to use the same proprietary software. AEC firms are moving toward OpenBIM because the alternative a project ecosystem where all disciplines must use the same proprietary BIM platform to exchange data creates software lock-in that restricts team composition, inflates software licensing costs, and makes long-term asset data inaccessible to facility managers who don't use the same platform the design team used, while IFC and related open standards allow any compliant platform to read, write, and use the model data regardless of which software produced it.
Introduction
BIM's promise has always been about data: a shared, intelligent model of the building that every project participant architect, structural engineer, MEP engineer, contractor, facilities manager can access, update, and use for their specific workflows across the project lifecycle.
The practical reality of BIM data exchange in most project teams has been more constrained. The dominant BIM authoring platforms Autodesk Revit, Bentley OpenBuildings, Graphisoft ArchiCAD, Nemetschek Allplan each store model data in proprietary formats that other platforms can read imperfectly or not at all. An architect working in Revit who needs to exchange a model with a structural engineer working in Tekla Structures, or a building owner who wants to use their Revit-based BIM model in an FM platform that doesn't support Revit's native format, encounters the fundamental limitation of proprietary data formats: the information in the model is only fully accessible to users of the platform that created it.
OpenBIM addresses this limitation through open, internationally standardized data formats that any compliant BIM platform can implement so that the model data created in any BIM authoring tool can be used by any other compliant tool without information loss, without proprietary translation, and without requiring every project participant to license the same software.
What OpenBIM Covers
OpenBIM is a philosophy and a set of standards rather than a single technology. The core standards that implement OpenBIM in practice are developed and maintained by buildingSMART International, the non-profit organization whose members include most of the major BIM software vendors and hundreds of government agencies, owners, and professional organizations worldwide.
Industry Foundation Classes (IFC)
IFC is the foundational data schema of OpenBIM a standardized, vendor-neutral format for representing BIM data that defines how building elements (walls, columns, beams, ducts, pipes, equipment) and their relationships, properties, and attributes are encoded in a file that any IFC-compliant software can read.
IFC is an ISO standard (ISO 16739) and is supported at varying levels of completeness by all major BIM authoring platforms. An IFC export from Revit contains the same structural data as the native Revit model in a format that Tekla, ArchiCAD, Allplan, and dozens of other platforms can import and use for their own workflows.
The current released version is IFC4, with IFC4.3 extending the schema to cover infrastructure roads, bridges, rail, ports, and waterways in addition to buildings. IFC2x3 remains the most widely supported version in practice, because software IFC implementations take time to update and because older projects continue to use older schema versions.
BIM Collaboration Format (BCF)
BCF is an open file format for communicating model-based issues clash detection results, design review comments, coordination questions between BIM platforms. Where IFC exchanges geometry and data, BCF exchanges issues: a BCF file identifies a location in the model, a viewpoint, and a comment or question, allowing issue tracking to happen across platforms without requiring all parties to use the same coordination software.
BCF is particularly valuable in coordination workflows where the BIM manager uses one clash detection platform and the discipline teams use different authoring platforms: BCF issues generated in Navisworks can be assigned to and resolved in Revit, ArchiCAD, or Tekla without the assignee needing access to the originating platform.
Information Delivery Specification (IDS)
IDS is a newer buildingSMART standard that allows project teams to define exactly what information must be present in an IFC model for specific purposes what properties, classifications, and attributes must be populated for a model to meet the project's BIM requirements. An IDS file is a machine-readable specification of information requirements that IFC-compliant tools can use to check model compliance automatically, rather than relying on manual review of model properties.
IDS closes a gap that IFC alone doesn't address: IFC defines how to represent information, but not what information a specific project requires. IDS defines what's required; IFC provides the format to contain it.
Why OpenBIM Matters for AEC Project Delivery
Reason 1 - Software-Agnostic Team Composition
Proprietary BIM exchange requires discipline teams to use compatible software versions, which in practice often means all teams using Revit, because the project's BIM manager uses Revit and the coordination workflow is Revit-centric. This software homogeneity constrains which firms can participate in a project: a structural engineering firm that uses Tekla Structures for its steel detailing workflow, or a facade specialist that uses Rhino with a Grasshopper-driven parametric design workflow, can't participate in a Revit-native project without either licensing Revit or accepting the information loss that comes from format translation.
OpenBIM-specified projects define model exchange in IFC rather than in native format, allowing each discipline to use the software best suited to their workflow. The structural engineer uses Tekla; the architect uses ArchiCAD; the MEP engineer uses Revit and all exchange in IFC, which any platform in the team can consume.
BIM coordination services that are platform-agnostic working in IFC exchange rather than requiring all discipline models to be in Revit give project teams the software flexibility to staff the best-qualified firm for each discipline scope rather than the best-qualified firm that happens to use the platform the BIM manager standardized on.
Reason 2 - Long-Term Asset Data Accessibility
The useful life of a building's BIM data extends far beyond the project delivery period. Facility managers need the BIM model for maintenance planning, renovation design, space management, and capital planning across decades of building operation. If the model is stored in a proprietary format, its accessibility depends on the facility manager either maintaining a software license for the platform that created it or accepting the information degradation that comes from translating it to a format they can use.
An IFC-based BIM handover produces an asset model in an open, ISO-standardized format that remains readable regardless of which software vendor's market position changes, which platform discontinues a feature, or which licensing model evolves over the building's 50-year life. The investment in BIM data is protected by the openness of the format rather than by the continued viability of a specific software vendor.
Reason 3 - Reduced Integration Cost for FM and Digital Twin Platforms
Facility management platforms, IoT sensor management systems, and digital twin environments are not BIM authoring tools. They don't need to read native Revit or ArchiCAD files they need the building element data, the spatial relationships, and the asset attributes that the BIM model contains, in a format their data processing pipelines can consume. IFC, as an open standard with published schemas and open-source parsing libraries, is significantly cheaper to integrate into FM and digital twin platforms than proprietary BIM formats that require licensed APIs and version-specific translation.
Building owners who specify IFC-based BIM handover reduce the integration cost of connecting the BIM model to their operational technology the FM system, the asset management database, the energy management platform because the open format provides a stable, well-documented interface that doesn't depend on proprietary software agreements.
Reason 4 - Government BIM Mandate Compliance
Government BIM mandates in the UK (BS EN ISO 19650), in Finland, Norway, and Singapore, and in emerging mandates in US federal infrastructure programs increasingly specify OpenBIM standards IFC model delivery, BCF issue tracking, and COBie data handover rather than proprietary platform requirements. AEC firms working in mandated environments need IFC competency as a compliance requirement, not just as a workflow preference.
The UK's Government Soft Landings framework and the ISO 19650 standard both specify information management in terms of information requirements and data formats rather than software platforms, which in practice means IFC is the mandated exchange format for public sector projects in an increasing number of jurisdictions.
Where OpenBIM Implementation Fails in Practice
IFC Export Quality Varies by Platform and Configuration
IFC is a standard for what can be represented; it isn't a guarantee of what will be represented when a specific platform exports to IFC. Every BIM authoring platform's IFC export has configuration settings that determine which element properties, which classification systems, and which geometric representations are included in the export. Default IFC export settings typically produce outputs that are geometrically complete but property-incomplete the walls and columns are there, but the material specifications, fire ratings, and cost data aren't, because the default export didn't include those property sets.
Specifying IFC exchange in a project's BIM Execution Plan without specifying the required IFC property sets, the IFC schema version, and the validation requirements produces IFC files that meet the format requirement but don't contain the information the receiving party needs to use them.
LOD Loss in IFC Translation
IFC translation from native BIM formats isn't lossless. Connection geometry that's native to Tekla Structures may not translate completely into IFC in a form that Revit can consume and display correctly. Parametric properties that drive schedule data in the native authoring environment may not export as queryable IFC properties. The "level of information" in the IFC file may be lower than the level of information in the native model, even when the geometric representation is complete.
Understanding what information survives IFC translation and specifying IFC export requirements that capture the specific information the receiving platform needs requires explicit testing of the exchange between the specific platforms and versions used on the project, rather than assuming IFC export produces a complete representation of the native model.
BCF Workflow Adoption
BCF's value in coordination is realized only when the full team uses BCF-compliant tools for issue tracking which requires both the issue originator (typically the BIM manager or coordination team) and the issue assignee (the discipline model author) to use BCF-enabled software and to follow a BCF-based workflow rather than a parallel email or spreadsheet-based issue tracking process. Projects where the coordination team uses BCF but the discipline teams track issues in email produce BCF records that are incomplete as a coordination audit trail.
OpenBIM Standards Status in 2026
IFC4.3 is the current released schema for infrastructure projects, covering alignment-based elements for roads, railways, bridges, ports, and waterways. Software support for IFC4.3 is still developing several major infrastructure design platforms have partial IFC4.3 support, with full implementation timelines into 2026 and 2027.
IDS (Information Delivery Specification) is in active deployment on major public sector projects in the UK and Scandinavia, with buildingSMART-certified IDS validation tools available in several BIM authoring platforms. IDS-based BIM requirements are beginning to appear in government employer's information requirements (EIRs) as a replacement for narrative information requirement specifications.
IfcOpenShell - the open-source Python library for reading and writing IFC files has become a standard tool in AEC technology workflows, enabling developers to process IFC data without proprietary API dependencies and making IFC integration into custom FM, digital twin, and workflow automation tools significantly more accessible than it was five years ago.
Scan-to-BIM and BIM modeling services that deliver IFC-compliant model outputs with specified property sets, validated against project information requirements, and tested for compatibility with the receiving platform produce BIM data that functions as intended in the open exchange workflows that government mandates and owner FM requirements increasingly specify.
Frequently Asked Questions
Q: Is IFC the same as OpenBIM?
A: IFC is the primary data standard that enables OpenBIM the file format through which BIM model data is exchanged between platforms in a vendor-neutral way. OpenBIM is the broader philosophy and set of practices that includes IFC for model exchange, BCF for issue communication, IDS for information requirement specification, and bSDD (buildingSMART Data Dictionary) for classification and property standardization. IFC is the most widely implemented component, but OpenBIM as a complete approach includes the full suite of buildingSMART standards working together.
Q: Does using IFC mean giving up native BIM authoring software?
A: No. OpenBIM doesn't require teams to abandon native BIM authoring platforms it requires them to exchange model data in IFC rather than in native format. Each discipline continues to author in whatever platform best suits their workflow (Revit, Tekla, ArchiCAD, Civil 3D, etc.), and the exchange between disciplines happens in IFC. The native model remains the authoring environment; IFC is the exchange format.
Q: How do I specify IFC requirements in a BIM Execution Plan?
A: IFC requirements in a BIM Execution Plan should specify: the IFC schema version (IFC2x3 or IFC4 confirm which version the receiving platform supports), the IFC property sets required for each element category (which IfcPropertySet entries must be populated for walls, columns, MEP elements, etc.), the IFC export configuration settings for each authoring platform in the project, the IFC validation tool and pass criteria (using a validator like Solibri or IfcOpenShell-based tools), and the exchange frequency and naming convention for IFC model files. Vague IFC specifications produce IFC files that meet the format requirement but not the information requirement.
Q: What is COBie and how does it relate to IFC?
A: COBie (Construction Operations Building Information Exchange) is a data format for building asset data equipment lists, component data, maintenance schedules, and warranty information that facility managers need at handover. COBie data is a subset of the information that a complete IFC model contains: it extracts the asset management-relevant properties from the BIM model into a spreadsheet format that FM systems can consume. An IFC model with correctly populated equipment and component properties can generate a COBie spreadsheet automatically; a COBie delivery requirement without an underlying IFC model with the required properties typically produces a manually assembled spreadsheet that doesn't stay current with the design.
Q: Which countries have mandated OpenBIM or IFC delivery?
A: The UK requires IFC-compliant BIM delivery on public sector projects under ISO 19650. Finland's Senate Properties mandates IFC delivery on all public building projects. Norway mandates IFC on public sector construction. Singapore's BCA mandates BIM submission in IFC format for building permit applications above defined project values. Germany, France, and several other EU member states have OpenBIM requirements in development or pilot deployment. In the United States, federal infrastructure programs funded under the Infrastructure Investment and Jobs Act are increasingly including IFC requirements in BIM specifications.
Conclusion
OpenBIM and IFC represent the AEC industry's answer to a data ownership problem that proprietary BIM formats create: when the model data that defines a building is stored in a format only one vendor's software can fully read, the building owner's access to that data is contingent on maintaining a software relationship with that vendor. Open standards make the data independent of the software that created it readable, processable, and integrable into whatever platform the owner, the FM team, or the digital twin environment needs to use it in.
The implementation challenges IFC export quality, LOD translation loss, BCF workflow adoption are real and addressable with explicit specification and platform testing. The direction of travel is clearly toward open standards: government mandates, owner FM requirements, and the increasing sophistication of the AEC technology ecosystem all push toward IFC as the common language of BIM data exchange. Firms that build IFC competency now in export quality, in information requirement specification, and in IFC-based coordination workflows are building the capability that mandated and owner-driven OpenBIM requirements will increasingly require.
Top comments (0)