IFC Standards Explained: Data Exchange for CAFM and BIM Projects [Pset]

Today I'm trying to explain what the IFC standard means and how it makes data exchange between BIM models and CAFM systems openly interoperable. It's about data formats, property sets, and what workflows are typically needed, and how to plan a robust IFC-based integration strategy. Practical examples and recommended tools like Revit, Archicad, Solibri, IfcOpenShell, or BIMcollab show concrete implementation steps for CAFM and BIM projects.

IFC Fundamentals and Relevance for CAFM and BIM

The IFC standard is an open, internationally recognized data model that enables interoperability of BIM and FM systems across disciplines. It defines classes, properties, and relationships so that models from Revit, Archicad, or other authoring tools can be seamlessly processed in CAFM platforms such as Planon, RIB FM, or FM:Systems. With IFC4, the semantics for facility management have become firmly established, and FM-specific property sets have been expanded. In practice, this means: structured data instead of fleeting exports, clear assignment of components to asset categories, and a more stable data chain over the entire lifecycle of a building. More information can be found on the BuildingSmart pages about IFC Standards.

Openness creates standardization, but also effort. Implementation requires clear governance, consistent naming conventions, and a robust mapping approach between BIM objects and CAFM assets. Not all CAFM systems support IFC4x3 to the same extent; export and import processes falter when object IDs are missing, fields are incomplete, or semantics remain inconsistent. Those who save here will pay double later in the form of rework, commissioning errors, and delayed operations. In practice, it's best to react with early validation and defined versioning.

Practical example from the field: In a medium-sized new hospital construction, the BIM team exports the model from Revit as IFC 4 and imports it into the CAFM system. The central challenge lies in mapping IfcSpace, IfcBuildingStorey, and technical systems to the CAFM room and asset categories. With a predefined mapping table, rooms, doors, and technical trades are reliably assigned; subsequent validation steps in BIMcollab or IfcOpenShell prevent later conflicts during operation.

Data quality is not a bonus item, but the core of interoperability. Necessary measures include unique object IDs, complete property sets (PsetSpaceCommon, PsetDoorCommon, Pset_WallCommon) and versioning that tracks changes to the model. Validation tools such as IfcOpenShell, Solibri, and BIMcollab should be an integral part of the workflow, not optional. Clear role distribution and approval processes prevent faulty IFC files from entering the operational phase and having to be expensively corrected there.

• Incomplete Property Sets: Perform an audit before export and use clear FM templates.
• Incorrect Object Assignments: Maintain the mapping table and check it regularly.
• Versioning Problems: Define the project basis (e.g., IFC4x3) and consistently work with the same version.
• Large Models and Performance: Filter the export, control the level of detail, and export only relevant rooms.

The next step is a targeted pilot: Select a building area, export the BIM model as IFC 4, validate object IDs and property sets, create the mapping, and test the import into your CAFM or IWMS system – only then can operations be reliably connected.

Structures of the IFC Model: Entities, Property Sets, and Data Flow

In IFC Model geometry and semantics work closely together, but they follow clear principles: a stable hierarchy defines where a component is located, while separate property sets carry the operational attributes. This separation allows BIM models to be visualized efficiently while consistently managing FM information. Those who want to implement interoperability in a practical way must understand the difference between structure (Who, Where, What) and attributes (How, Which properties) and specifically connect both cleanly.

Core Structures in the IFC Model

The model hierarchy starts with IfcProject and rises through IfcSite and IfcBuilding to IfcBuildingStorey. At the end are IfcElements as carriers of components or equipment. This sequence maps the building structure, which guides geometry, location, and usage context. Typical examples are IfcWall, IfcDoor or IfcSpace, which are anchored as objects in the hierarchy. See How-to-Anchor: The structure enables reliable location queries, component assignment, and subsequent maintenance processes. IFC standard provides the specifications for the concrete use of these classes.

• IfcProject – Root of the model, organizational framework
• IfcSite – Geographical location and reference point
• IfcBuilding – Main building object
• IfcBuildingStorey – Floor structure
• IfcElement Component or equipment as a carrier of geometry

On the semantics side, the family of Property Sets comes into play. IfcPropertySet bundles grouped attributes that are relevant for FM. Typical FM sets are PsetSpaceCommon, PsetDoorCommon and Pset_WallCommon. These sets are linked to the building components via relationships such as IfcRelDefinesByProperties with the building components. This way, a door component receives status data, serial numbers, or manufacturer information in addition to geometry – without burdening the geometry.

The connection between geometry and semantics is established through three central mechanisms: firstly, geometry via IfcProductRepresentation, secondly, semantics through Property Sets, and thirdly, placement and location via IfcObjectPlacement or IfcLocalPlacement. In practice, this means that exports from BIM tools deliver both the geometry and the attribute bundles, while CAFM systems adopt these bundles via mapping interfaces into asset categories.

Data exchange often follows a pragmatic pattern: export in IFC 4 format, subsequent assignment of objects to CAFM assets using a mapping table, then import into the CAFM system. The consistency of object IDs, the completeness of Property Sets, and clear room assignment become the central test criteria. A cleanly set up mapping workflow significantly reduces rework during operation.

Practical example: In a medium-sized office complex, planners export Revit models as IFC 4. The door IfcDoor receives fields such as Door Type, Fire Rating, and Serial Number via Pset_DoorCommon. In the CAFM system, this door object is linked to the asset entry via mapping, and the room location is assigned from IfcSpace. This allows maintenance plans to be automatically applied to doors and the building's inventory to be cleanly accessed in operations management.

Key message: IFC separates geometry from semantics, but interoperability critically depends on consistent property sets and a defensive mapping approach.

Workflows: Exporting and Importing from BIM to CAFM with IFC

The workflow from BIM to CAFM begins with a clean IFC export from the BIM authoring tool. In practice, this delivers IFC4 the most stable, FM-specific property sets, but the added value only unfolds when model content is cleanly organized. Without clear Object IDs, complete Space Properties and consistent room assignments, interoperability when importing into CAFM significantly decreases. Consistent governance over naming conventions and version statuses prevents data chaos later on.

Practical Workflow

The practical workflow follows a clear sequence: Before exporting, clarify structure and semantics in the BIM model, export as IFC 4 with relevant FM Psets, create a mapping table, and check the assignment before importing into the CAFM system. Use validation tools to ensure IFC compliance and semantic consistency. This significantly reduces error sources and speeds up operational handover.

• Preparation in the BIM model: Harmonize naming conventions, check that rooms exist and room assignments are consistent.
• IFC export settings: Export as IFC 4, activate FM-relevant property sets and keep the geometry manageable so that semantics remain visible.
• Create mapping table: Mapping of IFC objects to CAFM assets, focusing on room IDs, serial numbers, and manufacturer fields.
• Import into CAFM system: Ensure that ObjectIDs and room assignments are consistently transferred during import.
• Validation: Use tools such as Solibri, IfcOpenShell, or BIMcollab to check IFC compliance and assignments.
• Iterations and release: Pilot run, corrections, release before operational handover.

Example: In a medium-sized office complex, the BIM model was exported from Revit as IFC 4. Upon import into the CAFM system, there was initially a gap in room assignments and 30 incorrect object IDs. Through a targeted mapping table and post-validation, the import was completed without errors, allowing maintenance to start seamlessly.

A central trade-off is the balance between level of detail and import stability. More property sets mean richer FM data, but they increase export file size and validation effort. In practice, the core Psets like PsetSpaceCommon, PsetDoorCommon and object-specific fields like condition, manufacturer, serial number are often sufficient – the rest is fed into the CAFM asset model. This saves time and resources without compromising interoperability.

Governance around IFC files is often neglected: Without clear release processes, version control, and tracking protocols, costly rework arises during operation. Define who exports, who validates, and who approves, then maintain data lifecycle integrity.

Next step: Start a pilot phase with a clear mapping strategy, limit the scope, and integrate validation into every export-import cycle before scaling to larger projects.

Data Quality and Governance in IFC-Based Data Exchange

Governance and Data quality are not a theoretical claim in IFC-based data exchange, but an operational foundation. Without clear ownership structures, defined fields, and robust version control, the process drifts apart: Global IDs become obsolete, objects lose assignment continuity, and CAFM asset categories no longer align. This leads to rework, faulty exports, and costly delays in operations.

• Ownership and responsibility roles: Data Owner, Data Steward; clear RACI distribution and defined release paths.
• Naming Conventions and ID Standards: standardized room names, object identifiers, a consistent GlobalId strategy, and version controls.
• Central Mapping Table: mapping of IFC objects to CAFM assets, with status, responsible persons, and change history.
• Validation Tools and Approvals: automated checks before import; use of IfcOpenShell, Solibri, and BIMcollab for quality assurance.
• Approval and Versioning Processes: defined change logs, approval workflows, and clear distinctions between planned and built states.
• Pilot Project Planning: limited scope, clear success criteria, learning loops, and iterative improvements.

Example: In a 12-story office building, the BIM model from Revit exports IFC 4; Pset_SpaceCommon provides central space data such as area and usage. The assignment of rooms to CAFM assets is done in a mapping table, otherwise inconsistent assignments or duplicate assets are threatened. The subsequent pilot project showed that validation before import and a cleanly maintained mapping significantly reduced the error rate and made operational handover activities more reliable.

The disadvantage is the additional effort at the beginning; a too strict governance can slow down initial projects. Plausible solution: phased implementation with a lean basic version in the first step and successive expansion of controls in the operational phase. Automate field completion and checks, use templates for naming and mapping, and conduct short, test-driven iterations.

Next step: Start a defined pilot with KPIs such as pre-import validation rate, error rate, and throughput times to enable data-driven decisions on the IFC integration strategy.

Practical Guide: Step-by-Step Implementation in a Typical FM Project

The starting point of a practical IFC-supported integration project is an honest assessment: Which BIM and CAFM data exist, where are fields missing, and how should data exchange function in everyday life. In practice, this means first defining a clear goal of which asset categories should be stored in CAFM and which IFC property sets are necessary for this. Without this, one relies on diffusion instead of interoperability. Refer to the IFC standard documentation goal "IFC standard" and the importance of open standards in construction.

Kickoff and assessment set the framework: Collect the existing BIM models (examples: Revit, Archicad) and the existing CAFM data. Clarify roles (BIM Manager, FM Manager, Data Responsible) and define approval levels. Determine which data is relevant for the first pilot project so that exchange in routine operations really works.

1. Kickoff and Inventory of BIM and CAFM Data
2. Define IFC Export Strategy: IFC 4, necessary fields, Pset_SpaceCommon, and other FM-specific sets
3. Create Mapping Table: Assign IFC objects to CAFM assets, including IDs and status
4. Test Import, Prepare Validation: Object IDs, Property Sets, Room Assignments
5. Plan Pilot Import and Operational Handover: Roles, KPIs, Operational Approvals
6. Governance and Documentation: Versioning, Change Management, Audit Trail

A realistic mapping strategy is crucial. In practice, a mapping table with two core columns is needed: IFC Object ID and CAFM Asset Category. Add fields for status, responsible persons, and approval date. Plan time for departmental reviews so that later adjustments are not interpreted as failures.

Example: In a medium-sized office building, a pilot was implemented with an IWMS system. Revit provided IFC 4 files from the BIM model; initial room assignments showed discrepancies, delaying the import. Through a clear mapping table and targeted validation, the coverage of asset categories could be quickly brought to 90% and maintenance workflows rolled out after the first inspection.

Practical trade-offs: more fields in property sets increase mapping effort and potentially increase error sources. Too early, comprehensive data depth prolongs the project without immediate benefit. Better: expand iteratively, test in pilot projects, and stabilize governance steps early on.

Takeaway: The path to smooth IFC integration leads through a lean, controlled pilot with measurable goals, clear responsibilities, and a defensive stance towards data depth at the beginning of the project.

Tools, Case Studies, and Tips for Getting Started

In practice, IFC interoperability works through a lean tool ecosystem, clear responsibilities, and consistent validation. Tool selection alone does not solve the data exchange problem – it only creates potential that is only utilized with governance.

Tool Ecosystem and Roles of the Tools

• Autodesk Revit: IFC 4 export with robust support for typical FM property sets; combine it with a mapping table to consistently assign fields to CAFM classes.
• Graphisoft Archicad: Strong IFC export and validation, well-suited when architects use Archicad; check room assignment consistency before import.
• IfcOpenShell: Open-source toolkit for script-based checks, bulk exports, and custom validations; ideal for tailored quality checks outside of commercial tools.
• Solibri: Quality and consistency check of the IFC file, including clash checks with model components; useful as a gate before CAFM import.
• BIMcollab: Issue tracking around IFC exports, supports approvals and central documentation of deviations.
• The best cleaning is the one you don't see – but you feel. (Planon, FM:Systems, Archibus): IFC integration interfaces, usually configuration needed to match object categories with the asset database.

Practical Case Study: A medium-sized office building (approx. 8,000 m2) is modeled in Revit. The IFC export is done as IFC 4, after which a mapping table is created to assign objects to CAFM assets. During the import into CAFM, room assignment errors initially occur, but by correcting the Pset_SpaceCommon assignments and re-validating, the import runs smoothly.

Tips for Getting Started

1. Define Pilot Project: Choose a manageable object with a clear data basis and a concrete objective.
2. Create Mapping Table: Define mappings of IFC object to CAFM asset; document versions and assumptions.
3. Validation before import: Use tools like Solibri, IfcOpenShell, or BIMcollab to check Object IDs, room names, and Psets.
4. Documentation of decisions: Note down naming conventions, mapping logic, and approvals so that operations can understand.
5. Iterative approach: Start small, expand step by step to make later modifications easier to integrate.

Core rule: Without clean object IDs and complete property sets, data exchange fails – invest early in governance instead of retroactive corrections.