The issue of interoperability is becoming more apparent as we begin to use more pieces of software, but how we integrate information has always sparked commentary and divided opinion. Here Stefan Mordue explores the ‘guidelines’ or ‘rules’ that determine what BIM information is exchanged.
BIM is more than just ‘technology’, but perhaps it is the development in the transfer of digital information that is providing the impetus missing in previous construction industry initiatives, such as the responses to the Latham and Egan reports. To achieve BIM’s full potential we require a robust mechanism to exchange the ever increasing levels of digital data, regardless of what software package or BIM platform is used.
Essentially speaking, IFC provides the ‘guidelines’ or ‘rules’ to determine what information is exchanged. Although it may include geometry, it is not limited to this; it presents tangible building components such as walls and doors and also enables the linking of alphanumeric information (properties, quantities, classification, etc.) to building objects and maintaining these relationships.
What is information exchange?
IFC is an industry-wide open and neutral data format that is fast becoming the de-facto standard for rich data exchange. It was first developed by an industry consortium formed by Autodesk in 1994 and known as the Industry Alliance for Interoperability. To assist the development of a non-proprietary standard it was renamed the International Alliance for Interoperability in 1997 and reconstituted as a not-for-profit alliance. It promotes IFC as a neutral product model supporting the building lifecycle and opens up membership to all interested parties.
Model View definition
Since 1996 there have been six principal schema releases, IFC1.5.1, IFC2.0, IFC2x, IFC2x2, IFC 2x3 and IFC4. (Formally known as IFC 2x4). BuildingSMART recommends that at this moment in time, IFC 2x3 is the best choice to implement as it has the broadest coverage of support of all published IFC releases. However now IFC4 is registered with ISO as an official International Standard, ISO 16739:2013 it is hoped that software vendor implementation will increase.
For further information on currently certified software and the software certification scheme, see the buildingSMART website 
.
In order to satisfy the many information exchange requirements of the ‘AEC Industry’, a Model View Definition (MVD) defines a section or ‘subset’ of the IFC schema for particular uses. For example, the COBie spreadsheet is a mapping of the FM Basic Handover MDV, which includes operational information. Other MDVs for 2x3 include the ‘Coordination View’ and the ‘Structural Analysis View’.
Combined data
At NBS we are passionate about information. Information needs to be authored ‘once’, and in the ‘right place’ but with BIM we now have the added benefit that we can ‘report it many times’. With the development of our NBS Plug-ins, BIM objects are becoming placeholders, connecting to a wider and richer source of information, and providing this with relevant guidance at the point in time it is required.
Since data is coming from a variety of sources, we need to be able to report and collate it in one central depository. Working alongside Professor Steve Lockley at the BIM Academy, the NBS Software development team have been generating a set of components that read and write to and from IFC. Currently in beta format, they have the ability to link key property sets together between the geometric model and the specification, producing an IFC file that contains the combined information.
Exchange Schema
As the saying goes, ‘it takes two to tango’, and is worth noting that as a schema, IFC itself cannot provide interoperability, rather it relies on the software packages interfacing with it. The schema often sparks debate and criticism in that it sometimes ‘drops data’ or loses geometry, but is this due the IFC standard or how it is being implemented? Further limitations currently exist around IFC’s ability to contain parametric information and manipulate the size of an object, however IFC4 and subsequently future releases look to address this.
Today, most modern BIM authoring platforms support import and/ or export of IFC model data, with buildingSMART issuing official certification to applications that comply with consistent procedures. This flow of information is critical for collaboration and interoperability, as it allows use between different authoring and downstream applications, e.g. facilities management, structural modelling and analysis applications.
With the 2016 Level 2 BIM deadline date fast approaching, the construction industry is getting to grips with the Open Standard data format set by the Government, the Construction Operations Building information exchange (COBie) data schema. COBie allows information about buildings to be organized, documented and shared in a standardized way. In association with the Open BIM network, NBS wanted to test whether the buildingSMART IFC file format was capable of supporting the creation of COBie datasets. We did this by running a trial with the help of a number of Tier 1 contractors. The free IFC/ COBie Report 2012 is available to download from theNBS.com. As a follow on to this trial, the OPEN BIM Network (which merged with buildingSMART UK to form a User Group) in partnership with the BIM Academy, defined a further series of COBie field trials 
using live models provided by Gatwick Airport Ltd.
Best of Breed
Open BIM is more than just “IFC”, it is a commitment to open standards and engagement. It allows both small and large platform software vendor’s to participate and compete on system independent, “best of breed” solutions. Any vendor with similar strategies can participate, even competing products and so the attraction of Open BIM is that consultants can join workflow without giving up their BIM tool which they are familiar where they may have otherwise been essentially excluded from a project. In the past interdisciplinary collaboration have taken advantage of “Xrefing” each other’s 2D drawings with coordination being managed by manual update changes. Clearly, complex 3D elements need a more robust level of co-ordination and so Open BIM uses a reference model concept. Using this approach is perhaps as much about a new mindset than anything else as it requires a strict regime of classifying elements correctly in order that information can be filtered and exchanged. It is unlikely that the receiving party will require the full BIM so by appropriately classifying elements using IFC classification headings, only the relevant elements and information are sent to the other party.
Open Exchange
The proprietary data format that is particular to a BIM software vendor can be quickly, reliably and efficiently updated and adapted to suit a changing market. However, the conundrum here is that in the long term they will prove to be expensive to maintain and support if they do not support a shared approach to data exchange, the very ethos of BIM. I am sure we have read the analogy of Betamax versus VHS to BIM software formats over and over again. VHS, the eventual winner, gained a dominance in the market that for almost 20 years, but the format received little development. And we really do not want that for the construction industry.
Open exchange standards are not new and started to emerge as early as the late 1970s following agreements between the leading CAD vendors and users. In the mid-1980s the Standard for Exchange of Product (STEP) model was developed as it was considered at that time that none of the existing formats, on their own, could support the needs of an open standard across multiple industries. However, STEP was considered too slow and unresponsive to meet upcoming market need in the construction industry and so motivation started to develop for a separate standard for the architecture, engineering and construction (AEC) and facilities management (FM) industries.
Does IFC really deserve the criticism it receives or is it simply misunderstood? Answers on a postcard, please.
