Interoperability, openBIM and Data Exchange

Introduction and Context

Building Information Modelling (BIM) is often described as a digital representation of a built asset, but its value depends on more than the existence of a three-dimensional model. A project may involve architectural, structural, mechanical, electrical, civil, estimating, scheduling, procurement, commissioning and facilities-management systems. Each system stores information according to its own data structures, naming conventions and business processes. If these systems cannot exchange information reliably, BIM becomes a collection of isolated models rather than a coordinated information environment.

Interoperability is the ability of different software applications, organisations and processes to exchange information and use the exchanged information correctly. It includes both technical exchange and semantic understanding. A file may open successfully in another application but still be practically unusable if object types, properties, relationships, units or classifications have been misunderstood.

OpenBIM is an approach to collaborative information management based on open, vendor-neutral standards and documented processes. It does not mean that proprietary software is prohibited. Rather, it means that project information should be capable of being exchanged, checked and retained without being permanently dependent on one software vendor.

This chapter examines native formats, open formats, IFC, BCF and COBie; explains data loss and information mapping; introduces schema validation, APIs and classification systems; and considers how BIM information can be integrated with construction and asset-management platforms.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Distinguish native, proprietary, neutral and open BIM formats.
2. Explain the purpose and structure of IFC, BCF and COBie.
3. Analyse why information is lost or distorted during exchange.
4. Apply principles of mapping, classification, schema validation and model checking.
5. Compare file-based exchange with API-based integration.
6. Recommend an appropriate exchange strategy for a construction project.
7. Evaluate governance, security, contractual and practical implications of interoperability.

1. Native and Open Information Formats

Native formats

A native format is the internal or preferred format of a particular software application. It generally preserves the greatest amount of information that the application can create, including parametric relationships, design history, constraints, families, styles, proprietary metadata and links to internal databases.

Native formats are valuable during authoring. For example, an architectural team may need to retain editable walls, hosted components and design parameters. However, native files can create dependency on a particular application and version. A receiving organisation may lack the software, licence, plug-ins or expertise required to open and interpret them. A native file may also change between software versions, making long-term access difficult.

Proprietary exchange formats

Some formats are controlled by a vendor but are designed for exchange between products. They may be efficient and widely supported, yet their specifications, licensing conditions or implementation details can limit independent use. Their practical success depends on the quality and consistency of import and export tools.

Neutral and open formats

A neutral format is designed to represent information independently of one authoring application. An open format has a publicly available specification or governance arrangement that permits broad implementation. Neutral and open do not necessarily mean that every application supports every feature. An open standard still requires careful implementation, testing and project governance.

A robust project normally uses native formats for authoring, open formats for coordination and structured databases or schedules for selected information deliverables. The choice should be based on information requirements rather than on the assumption that one format can perform every function.

2. Interoperability as a Technical and Organisational Problem

Interoperability has at least four dimensions:

• Syntactic interoperability: systems can read the structure of an exchanged file or message.
• Semantic interoperability: systems interpret terms and values with the same meaning.
• Process interoperability: information arrives at the correct stage, in the correct form, for a defined business process.
• Organisational interoperability: participants agree on responsibilities, approvals, security and information ownership.

For example, two systems may both accept a property called “fire rating”. Syntactic interoperability exists if the property is imported. Semantic interoperability exists only if both systems understand whether the value means a wall assembly rating, a door rating, a required performance or an observed test result. Process interoperability requires the value to be available at the stage when approval or procurement depends on it.

Interoperability therefore cannot be solved solely by purchasing a converter. It requires an information exchange requirement, agreed data definitions, appropriate software, testing procedures and accountable people.

3. IFC: The Open Model Exchange Standard

Purpose and scope

Industry Foundation Classes (IFC) is an open data schema for representing information about buildings and infrastructure. It is developed and maintained through buildingSMART International and is published as an international standard, ISO 16739. IFC is intended to support exchange across software applications and project disciplines.

IFC is not simply a file extension. It is a schema describing entities, attributes, relationships, property sets, quantities, geometry, materials, actors, tasks, resources and other concepts. An IFC file may be encoded in several ways, including the commonly used STEP physical file format. The quality of an exchange depends on both the schema version and the exporting and importing applications.

Conceptual structure

IFC represents a project through interconnected objects rather than an unstructured collection of lines. Examples include:

• project, site, building and storey spatial structure;
• walls, slabs, doors, windows, beams and distribution elements;
• systems such as air-conditioning or electrical networks;
• materials, quantities and property sets;
• relationships such as containment, aggregation, assignment and connection;
• geometric representations and coordinate information.

An object’s geometry is only one part of its identity. Its type, location, containment, material, classification, properties and relationships may be equally important for analysis and construction.

IFC versions and implementation

IFC2x3 remains widely encountered in industry because of its extensive software support. IFC4 introduced broader capabilities and improvements, while IFC4.3 extends the schema for infrastructure domains such as roads, railways, bridges and waterways. A project should specify the required IFC version and supported model view or exchange scope rather than merely stating “IFC required”.

Applications do not necessarily implement every entity and property in an IFC release. Consequently, an IFC export can be schema-conformant while still failing a project need. A practical exchange requirement should specify:

1. the IFC version;
2. the required disciplines and object types;
3. geometric and non-geometric information;
4. classification and property requirements;
5. coordinate and unit conventions;
6. validation and acceptance criteria.

Strengths and limitations

IFC supports vendor-neutral coordination, archival access and multidisciplinary model exchange. It can preserve relationships and properties that simple geometry formats cannot. However, it is not a perfect replacement for native authoring. Parametric constraints, feature histories, application-specific behaviour, rendering settings and some specialist calculations may not transfer. Importing an IFC model and then editing it as though it were native content can be unreliable.

IFC is therefore best understood as an information exchange model. It should be tested for the intended use—coordination, quantity review, code analysis, fabrication, construction planning or handover—rather than judged by whether the receiving application displays a visually similar model.

4. BCF: Issue and Coordination Exchange

BIM Collaboration Format (BCF) is an open format for communicating model-based issues. It is designed to exchange coordination information without requiring the entire model to be transferred each time an issue is created or updated.

A BCF issue commonly includes:

• a globally unique issue identifier;
• title, description and status;
• author, assignee and relevant dates;
• priority, type and stage;
• references to model components;
• a camera viewpoint;
• snapshots or other visual context;
• comments and a history of updates.

BCF can be exchanged through files or managed through a BCF web service. In a file-based workflow, a BCF package contains structured issue data and associated viewpoints or images. In an API workflow, systems can create, retrieve and update issues directly.

BCF does not usually contain the full geometry of the building. It refers to objects in models through identifiers and provides enough context for people to locate and discuss a problem. The stability of those identifiers is essential. If an exporter generates new identifiers every time a model is issued, previous issue references may no longer locate the intended element.

BCF is particularly useful for clash management, design review, construction queries, safety observations and commissioning defects. It separates the communication of an issue from the authoring system in which the model was created.

5. COBie and Structured Handover Information

Construction-Operations Building information exchange (COBie) is a structured approach to delivering information about maintainable assets. It is associated with handover and facilities management rather than with detailed geometric coordination. COBie information may be represented in spreadsheets or other structured forms, depending on the project implementation.

Typical COBie concepts include facilities, floors, spaces, zones, types, components, systems, attributes, documents, contacts and jobs. A component is an individual maintainable asset, such as a specific pump. A type describes a category or manufacturer model, such as a pump model used in several locations. The distinction reduces repetition and supports asset-register creation.

COBie is not merely a spreadsheet template to be completed at the end of construction. It is most effective when information requirements are defined early and populated progressively. For example, equipment data can begin with a required type and performance specification, gain manufacturer information during procurement, and receive serial numbers, installation dates and warranty documents during construction and commissioning.

COBie’s principal benefit is a clear focus on operational information. Its limitations include inconsistent spreadsheet implementations, incomplete data, ambiguous property definitions and weak links to changing model identifiers. A project should define which fields are mandatory, who supplies them, when they are approved and how they will be validated before import into a facilities-management system.

6. Information Loss, Transformation and Fidelity

Data exchange rarely involves only a simple copy. It usually involves transformation between schemas, object models, units, classifications and levels of detail. Information may be lost, altered or duplicated at several points.

Common causes of data loss

1. Conceptual mismatch: one system represents a parametric family while another represents only an occurrence.
2. Unsupported entities: the exporter or importer does not implement a particular IFC class or property.
3. Geometry conversion: complex solids, sweeps, analytical surfaces or fabrication details are approximated.
4. Property mismatch: a source property has no agreed destination field.
5. Unit conversion: values are converted incorrectly or their units are not carried with them.
6. Identifier changes: object references are regenerated, breaking issue and asset links.
7. Classification differences: systems use different codes for the same object.
8. Version incompatibility: applications support different schema versions or exchange views.
9. Workflow filtering: an export intentionally excludes information not required for the selected use.
10. Manual re-entry: people copy data between systems and introduce omissions or transcription errors.

Data loss is not always unacceptable. An export for spatial coordination may not need design history or every manufacturer attribute. The important question is whether the loss affects the intended use. This is why exchange requirements should define information fidelity in relation to a purpose.

Mapping and transformation

Mapping establishes how a source concept corresponds to a destination concept. A mapping table may include the source field, destination field, transformation rule, unit, permitted values and responsible party.

Mapping can be one-to-one, many-to-one, one-to-many or conditional. A one-to-one mapping occurs when “serial number” maps directly to “serial number”. A many-to-one mapping may combine several source descriptions into one destination field, which can reduce detail. A one-to-many mapping may require a rule that separates a compound source value into multiple destination properties.

A mapping specification should record assumptions. If a source field called “manufacturer” contains both company and product name, it should not be silently mapped to a destination field that expects only the company. Ambiguity should be resolved through a controlled definition or reported as an exception.

7. Schema Validation and Quality Assurance

Validation checks whether information conforms to defined structural and business requirements. It should occur before and after exchange.

Schema validation

Schema validation tests whether a file follows the formal structure of its format. It may verify required elements, data types, relationships and permitted values. For IFC, a validator can identify invalid entities or malformed relationships. For XML or JSON-based APIs, validation may use a schema definition such as XSD or JSON Schema, although the exact method depends on the platform.

Schema validity does not guarantee usefulness. A file may be structurally valid but contain missing asset identifiers, incorrect classifications or implausible dimensions.

Content and rule validation

Content validation checks project-specific requirements, such as:

• every maintainable equipment item has an asset identifier;
• every door has a fire-performance value where required;
• every object is assigned to a valid storey;
• every space has an approved number;
• all coordinates fall within the agreed project system;
• units and decimal precision are appropriate;
• classification codes belong to the specified edition;
• equipment required for handover has warranty and maintenance data.

Rule-based validation may be expressed through model-checking tools, spreadsheets, databases or automated scripts. A good validation report identifies the object, property, rule, severity, responsible party and corrective action.

Validation workflow

A practical workflow is:

1. define the exchange purpose and acceptance criteria;
2. prepare the source model and remove avoidable ambiguity;
3. export using the agreed version and settings;
4. validate file structure and schema;
5. check geometry, coordinates and units;
6. check properties, classifications and identifiers;
7. open the exchange in the receiving platform;
8. compare selected objects and quantities against the source;
9. record defects and repeat the exchange after correction;
10. archive the accepted file, report and software settings.

Validation should be risk-based. A minor visual issue in a coordination model may be less serious than a wrong equipment identifier that prevents a maintenance record from being linked to the correct asset.

8. Classification Systems and Common Terminology

Classification systems organise construction information into controlled categories and codes. They support searching, procurement, cost planning, specification, model checking and asset management. Examples used internationally include Uniclass, OmniClass, MasterFormat and other national or client-specific systems. Their suitability depends on geography, sector, contractual requirements and the intended use.

Classification is not the same as naming. A name such as “AHU-01” identifies or labels an item, while a classification code places it within a defined system. Classification is also different from an IFC entity. An object may be an IFC fan or distribution element while separately receiving a classification code for mechanical equipment or an organisational asset category.

Projects should specify:

• the classification system and edition;
• the table or hierarchy to be used;
• whether codes apply to types, occurrences, spaces, systems or documents;
• how multiple classifications are handled;
• who owns and updates the classification mapping.

Cross-mapping between classifications is not always exact. Two systems may divide the construction domain at different levels. A crosswalk should therefore record equivalence, broader-than, narrower-than or no reliable correspondence rather than pretending that every code has a perfect match.

9. APIs and Platform Integration

File exchange is useful for controlled submissions, snapshots and archival records. Application programming interfaces (APIs) support more continuous integration between systems. An API defines how one application requests or sends data to another. Modern APIs commonly use web protocols and structured payloads such as JSON, but implementation details vary.

Typical construction-platform integrations include:

• synchronising document metadata between a common data environment and a document-management system;
• creating BCF issues from a model-checking application;
• sending approved equipment data to an asset-management platform;
• linking procurement records to model objects;
• retrieving schedule or cost information for dashboards;
• connecting field-reporting applications with defects and work orders.

An API integration should specify authentication, authorisation, data ownership, identifiers, error handling, rate limits, versioning and audit logs. Integration is not simply a technical connection. It creates a dependency between business processes and must be governed accordingly.

A useful architectural principle is to avoid using a single application as an unexamined master copy of all information. Instead, each information domain should have an identified source of truth. For example, the design application may own geometry during design, the procurement system may own purchase status, and the facilities-management system may own operational work orders. Shared identifiers and controlled synchronisation rules connect these domains.

10. Integration with Construction Platforms

Construction platforms commonly combine document control, model viewing, workflows, RFIs, submittals, field observations, cost information and schedule data. Interoperability enables model objects to become connected to these processes.

A practical integration pattern is:

1. authoring teams create discipline models in native applications;
2. models are published to a common data environment;
3. IFC or another agreed open model is used for federated coordination;
4. model-checking software creates BCF issues;
5. approved information is linked to submittals, RFIs, schedules and procurement records;
6. verified equipment data is transferred to the handover or facilities-management system;
7. operational feedback is associated with the relevant asset identifiers.

The model should not be treated as a substitute for every project database. Some construction information—such as commercial approvals, contractual correspondence or inspection records—may be better managed in specialised systems. Integration should preserve traceability without forcing unsuitable data into the geometric model.

Applied Case: Illustrative Hospital Extension

Background

A contractor is delivering a hospital extension involving architecture, structure, mechanical services, electrical services and specialist medical equipment. The client requires a coordinated model, issue tracking during construction and a verified asset register for operations.

Problem

The design consultants use different authoring platforms. Early IFC exports show missing space information, inconsistent equipment names and unreliable references between coordination issues and model objects. The facilities-management team receives a spreadsheet containing equipment, but several serial-number fields are blank and classification codes do not match the client’s asset system.

Analysis

The project team identifies three separate information problems. First, the model exchange has a semantic problem: similar objects are represented with different categories and property names. Second, the coordination workflow has an identifier problem: object identifiers change between exports, so BCF viewpoints refer to obsolete objects. Third, the handover workflow has a governance problem: the equipment data requirements were not assigned to suppliers at procurement and commissioning stages.

Approach and solution

The team establishes an exchange information requirement containing the IFC version, coordinate system, required object classes, property sets, classification edition and validation rules. A mapping register defines how equipment tags, manufacturer fields, model numbers and warranty information are transferred.

The team also adopts a project-wide asset identifier that is created when equipment is approved for procurement. The identifier is retained through delivery, installation, commissioning and handover. BCF is used for coordination issues, and issue references are checked against each published model. A validation process checks spatial containment, equipment properties, classifications, identifier uniqueness and required documents.

COBie-style handover information is populated progressively. The mechanical subcontractor supplies type data at submittal stage, serial numbers after delivery, installation locations after placement and maintenance information after commissioning. The client’s facilities-management team participates in testing rather than waiting until project closeout.

Outcome

The second coordinated exchange contains fewer unresolved object-reference failures. Model geometry remains imperfect for some specialist equipment, but the project accepts the limitation because the required operational attributes and location references are available. The asset register can be imported after validation, and BCF issues remain traceable across model revisions.

Learning points

• Interoperability requirements must be defined before modelling is substantially complete.
• Stable identifiers are essential for linking models, issues and assets.
• Open formats support exchange but do not remove the need for mapping and testing.
• Handover information should be created progressively by the parties who possess it.
• A visually correct model can still contain operationally unusable data.

11. Governance, Contracts, Ethics and Security

Interoperability creates questions of responsibility and control. Contracts should state who produces, checks, approves and maintains each information deliverable. They should identify the required format, version, exchange purpose, acceptance tests and treatment of defects.

Information governance should address:

• access permissions and role-based authorisation;
• protection of sensitive building and infrastructure information;
• audit trails for changes and approvals;
• retention and archival formats;
• intellectual-property rights and licence conditions;
• responsibility for incorrect or incomplete data;
• cybersecurity of APIs and connected platforms;
• segregation of information about critical facilities.

Ethically, practitioners should not claim that an exchange is complete merely because a file opens. They should disclose known limitations, conversions and omissions. Automated mapping and artificial-intelligence tools may assist classification, property extraction or anomaly detection, but their outputs require human review. Training data, privacy, bias, explainability and accountability are relevant when AI processes project or operational information.

12. Contemporary Developments and Best Practice

Current openBIM practice is moving beyond periodic file transfer toward connected information services. IFC remains important for model exchange, while BCF supports issue workflows and structured handover approaches support asset information. Information Delivery Specification (IDS), developed within the buildingSMART ecosystem, provides a machine-readable way to describe information requirements for IFC-based exchanges. It can help specify required entities, properties, classifications and value restrictions, although implementation and tool support must still be checked.

Digital twins, common data environments, automated checking and connected asset platforms increase the value of consistent identifiers and controlled semantics. These developments also increase the consequences of poor data quality. A wrong asset location in a design review is inconvenient; the same error in a live maintenance system may affect safety, cost and service continuity.

Recommended practice is to:

1. begin with use cases and information requirements, not file formats alone;
2. choose the simplest exchange that preserves the required meaning;
3. document schemas, versions, units, coordinate systems and classifications;
4. maintain stable identifiers across model and platform revisions;
5. use native formats for authoring and open formats for agreed exchanges;
6. validate both structure and business content;
7. test exchanges with representative objects before full production;
8. maintain mapping registers and exception logs;
9. assign data ownership and approval responsibilities;
10. involve construction and operations personnel early;
11. protect APIs, credentials and sensitive asset information;
12. archive accepted files together with validation reports and settings.

Chapter Summary

Interoperability enables BIM information to move between software, organisations and project stages without losing the meaning required for decision-making. Native formats preserve authoring behaviour but can create vendor dependency. OpenBIM uses documented, vendor-neutral standards and processes to support collaboration.

IFC provides an open model schema for objects, properties, relationships and geometry. BCF communicates model-based issues and viewpoints without transferring complete model geometry. COBie and related structured handover approaches focus on maintainable asset information. Each format has a purpose and limitations.

Data loss results from unsupported concepts, property mismatches, identifier changes, unit errors, classification differences and intentional filtering. Mapping registers, stable identifiers, schema validation and business-rule checking reduce these risks. Classification systems provide controlled categories but are not substitutes for names, identifiers or IFC entities.

File exchange remains important, while APIs support more continuous integration between common data environments, construction platforms, procurement systems and facilities-management applications. Successful interoperability depends equally on technical standards and governance: clear requirements, ownership, security, testing, contractual responsibilities and honest reporting of limitations.

Key Terms

Interoperability: The ability of systems and organisations to exchange and correctly use information.

OpenBIM: Collaborative BIM based on open standards and vendor-neutral processes.

Native format: The primary authoring format of a particular software application.

Proprietary format: A format controlled or strongly associated with a vendor.

IFC: Industry Foundation Classes, an open schema for exchanging building and infrastructure information.

ISO 16739: The international standard associated with the IFC data schema.

BCF: BIM Collaboration Format for exchanging model-based issues and viewpoints.

COBie: A structured approach for delivering maintainable asset information.

Schema: A formal definition of permitted data structures, entities, properties and relationships.

Mapping: The defined correspondence between concepts or fields in different systems.

Semantic interoperability: The ability of systems to interpret exchanged information with the same meaning.

Identifier: A value used to distinguish and reference an object, issue or asset.

Classification system: A controlled hierarchy or coding system for organising construction information.

API: Application programming interface used for controlled software-to-software communication.

Validation: Checking information against structural, technical or project-specific requirements.

Common data environment: An agreed digital environment for managing project information and workflows.

Property set: A grouped collection of properties associated with an object or entity.

Data fidelity: The degree to which exchanged information retains required characteristics and meaning.

Information requirement: A defined statement of information needed for a project use, decision or deliverable.

Review Questions

Short Answer Questions

1. What is the difference between a native format and an open format?
2. What type of information is primarily exchanged using BCF?
3. Why is IFC more than a three-dimensional geometry format?
4. State two causes of data loss during BIM exchange.
5. What is the purpose of a classification system?

Long Answer Questions

1. Explain the technical and organisational dimensions of interoperability in a construction project.
2. Compare the purposes, strengths and limitations of IFC, BCF and COBie.
3. Describe a complete validation workflow for an IFC-based coordination exchange.
4. Explain how mapping and stable identifiers support integration between BIM and facilities-management systems.
5. Discuss the governance, contractual and cybersecurity issues associated with API-based construction-platform integration.

Analytical / Application Questions

1. A structural model imports successfully into a coordination platform, but several objects have incorrect material properties and cannot be linked to procurement records. Diagnose the likely interoperability problems and propose a corrective workflow.
2. Develop an exchange strategy for a university building requiring design coordination, construction issue management and facilities-management handover. Identify suitable formats, validation checks and responsible parties.
3. A client requests “an IFC model and a complete COBie spreadsheet” at project closeout but has provided no property definitions, classification system or asset-identification rules. Critically evaluate the request and recommend what should be agreed before production begins.

Multiple Choice Questions with Answers

Question 1

Which statement best describes semantic interoperability?

A. A file can be opened by a receiving application.

B. Two systems interpret exchanged information with the same meaning.

C. A model contains only three-dimensional geometry.

D. A project uses the latest software version.

Correct Answer: B. Two systems interpret exchanged information with the same meaning.

Question 2

What is the principal purpose of IFC?

A. To provide a vendor-neutral schema for exchanging building and infrastructure information.

B. To replace all native authoring functions.

C. To manage only construction contracts.

D. To store only photographic site records.

Correct Answer: A. To provide a vendor-neutral schema for exchanging building and infrastructure information.

Question 3

What does BCF primarily exchange?

A. Complete parametric authoring histories.

B. Manufacturer invoices and payment certificates.

C. Model-based issues, viewpoints and coordination discussions.

D. Only facility energy-consumption data.

Correct Answer: C. Model-based issues, viewpoints and coordination discussions.

Question 4

Which deliverable is most closely associated with structured operational asset information?

A. BCF

B. COBie

C. A rendering file

D. A clash screenshot without metadata

Correct Answer: B. COBie

Question 5

A model file passes formal schema validation but contains no asset identifiers for maintainable equipment. What does this demonstrate?

A. Schema validity always guarantees project usefulness.

B. Geometry validation is unnecessary.

C. Business-content validation is also required.

D. The model must be converted to a native format.

Correct Answer: C. Business-content validation is also required.

Question 6

Why are stable object identifiers important in BCF workflows?

A. They increase rendering quality.

B. They allow issues to continue referring to the intended model objects across revisions.

C. They eliminate the need for model coordination.

D. They automatically create construction schedules.

Correct Answer: B. They allow issues to continue referring to the intended model objects across revisions.

Question 7

Which statement correctly distinguishes classification from naming?

A. Classification provides controlled categorisation, while naming labels or identifies an item.

B. Classification and naming are always identical.

C. Naming is only used for geometry, whereas classification is only used for drawings.

D. Classification removes the need for unique identifiers.

Correct Answer: A. Classification provides controlled categorisation, while naming labels or identifies an item.

Question 8

Which factor should be specified in an IFC exchange requirement?

A. Only the colour scheme of the model.

B. The IFC version, intended use, required properties and coordinate conventions.

C. The personal preferences of every modeller.

D. Only the software brand used by the architect.

Correct Answer: B. The IFC version, intended use, required properties and coordinate conventions.

Question 9

What is a major advantage of an API over a manually exchanged spreadsheet?

A. An API can support controlled, repeatable communication between systems.

B. An API guarantees that all exchanged data is correct without validation.

C. An API eliminates access control requirements.

D. An API can represent every native modelling operation.

Correct Answer: A. An API can support controlled, repeatable communication between systems.

Question 10

Which practice best supports reliable facilities-management handover?

A. Collecting all equipment data for the first time after practical completion.

B. Allowing each subcontractor to invent independent asset identifiers.

C. Populating required information progressively and validating it before import.

D. Prioritising visual rendering over asset properties.

Correct Answer: C. Populating required information progressively and validating it before import.