Digital Twins & BIM

What is IFC and why does it matter for building data exchange?

Specify each IFC exchange by purpose, check it with IDS and test it early with the software that will receive it.

Conceptual interoperability scene with building elements exchanged consistently across different workstations.
On this page
  1. What the schema covers
  2. Narrowing a very large standard
  3. Say what each exchange is for
  4. Test with the system that will receive it
  5. Practical application
  6. Openness has to be written into appointments
  7. Sources

IFC, short for Industry Foundation Classes, is the open data schema for exchanging building information modelling (BIM) information between software applications. It is maintained by buildingSMART International, which describes it as vendor-neutral, and is published as an ISO standard. The current edition, ISO 16739-1:2024, replaced the 2018 edition and extended coverage to infrastructure such as bridges, roads, railways and ports; buildingSMART's repository identifies that ISO edition with its IFC 4.3.2.0 release.

Its importance follows from how buildings are made and run. A building's information is produced in many applications, from architectural, structural and building services design to cost, scheduling and facilities management, and it passes between many organisations over decades. A published, open schema allows that information to be exchanged and read without depending on any one vendor's file format.

An IFC file, however, is not proof of interoperability. What counts is whether the right information, for a defined purpose, arrives intact in the receiving system.

What the schema covers

ISO's abstract describes IFC as an open international standard for BIM information exchanged and shared among the software used by participants in construction and facility management, with definitions covering buildings and infrastructure over their life cycle. It includes a data schema, property and quantity set definitions, and an exchange file format. Its scope runs from project structure, physical and spatial components and analysis items through processes, resources, controls, actors and context, across life-cycle phases up to operation and maintenance, and for disciplines including building services and facility management.

Narrowing a very large standard

Because IFC is so broad, no single exchange uses all of it, and two mechanisms exist to narrow it down.

Model view definitions (MVDs) define which subset of IFC a software application implements for a particular type of exchange. ISO's abstract notes that conforming software must identify the MVD it conforms to when applying for certification.

The Information Delivery Specification (IDS) is a buildingSMART standard for specifying information requirements and checking IFC models against them. An IDS file contains machine-readable specifications, such as "all air terminals must have a maintenance identifier and a classification code", each with an applicability part and a requirements part. Model authors can check their work before delivery, and receivers can check what arrives.

For an owner, IDS turns "provide IFC" into "provide IFC that passes these checks", which is far easier to accept or reject.

Say what each exchange is for

Coordination between designers, quantity take-off and operational asset information each need different content, so "IFC" alone is never a sufficient requirement. Each exchange should state the IFC version and, where relevant, the MVD; the objects, identifiers, classifications and properties required; the units and permitted values; how documents are referenced; and how compliance will be checked, ideally with an IDS file issued alongside the requirements.

Test with the system that will receive it

Representative objects should be exported early in the project and imported into the receiving application itself (the CAFM, CMMS or data platform) rather than checked in a model viewer. The test checks identifiers, properties, units, relationships and document links, and geometry where it matters, and any known limitations and agreed workarounds are recorded.

IFC supports transfer, not synchronisation. Once information has been exchanged, a separate process must decide which system is authoritative and how updates flow.

Practical application

Openness has to be written into appointments

An open standard helps only when the required exchanges, the validation method and the responsibilities are written into appointments. Write them in, then prove them with a trial exchange into the systems that will actually receive the data.

Sources

This article connects to our work on Digital twin.

Related articles

Related service

Digital twin

We can discuss how this subject fits the project brief.

Contact Pagin Consulting