IFCs - even more important now?

We all know about IFCs. But why are they so important from an interoperability, communication and longevity point of view? And how can we as an industry ensure that we are benefitting from their true value? Here we explore more…

IFC (Industry Foundation Class) can be defined as a common standard for data exchange. In many ways, IFC is an enabling technology, facilitating effective collaboration and communication on a project, as well as providing longevity and protection. In an industry where there can be many different software packages and products being used on a single project, IFC allows a rich data exchange that can be easily shared between teams and is able to be opened and viewed using any application, regardless of the original proprietary software.

As well as aiding effective coordination between project teams and partners, IFC is also just as important from a longevity perspective. When it comes to the more complex and large-scale construction and civil engineering projects, such as Hinkley Point C in Somerset, they can take years to deliver, from the initial design, engineering and concept design phase through to on-site construction, handover and operation. Given the speed at which technology is advancing, it is critically important that trusted, immutable data is still accessible to any party who is starting work on the latter stages of such mega projects, perhaps five or more years after the initial construction models were issued.

It's all about futureproofing the file and its data. Imagine you have a model file from version 1.1 of a software, but you are now on version 4.3 of the same software package. Can you still open the original file? We only need to look at the transition from floppy discs (remember those?!) and CDs to memory sticks to the cloud to see how storing and transferring data has changed in just a couple of decades.

That said, while the principal value of IFCs sounds great, it isn’t without its challenges. In many ways, organisations on a project shouldn’t need to talk about IFC; it should just happen smoothly in the background as the default exchange process. Just like if you were to take a photo on your smartphone and wished to share it with a friend; you don’t have to think about reformatting it in order to send it via text, or WhatsApp, or Facebook Messenger. Similarly, if you were to send a photo from an iPhone to a Samsung (for example) - two devices with different operating systems – you don’t have to do a conversion process, it just happens.

We should be at the same point when it comes to sharing BIM model files, automatically sending and transferring all data as an IFC. After all, interoperability and communication are essential. However, as an industry we are not yet quite at this point, with all software vendors on different journeys and at different stages when it comes to IFC data exchange.

While most software products will enable you to exchange and convert data via IFC, the rules and scope of the schema mean there are limits as to what can be exchanged ‘out of the box’, so to speak. There are various nuances within the IFC schema and, as a result, it is always best to test the exchange process to ensure the data required does move across successfully - for example, if wishing to share custom components from Tekla Structures. There is always the flexibility to add additional fields to the IFC schema to resolve these potential issues, so long as exchange parties agree on these definitions. Understandably, when the primary purpose and value of IFCs is communication, coordination and data exchange, the potential for data loss is a concern.

However, another obstacle facing the true and total use of IFCs on an industry-wide scale is the age-old hesitation and concerns around data ownership and data security. Some people simply do not want to share their models and its data with third parties – a mindset that will take some work and time to change.

At Trimble, we’ve always promoted taking an open platform approach to BIM, understanding the importance of software and data interoperability. A great example of this in action is Quadri, our cloud-based platform for civil infrastructure projects. Quadri allows design teams to collaborate in near real time, enabling multiple people, stakeholders and disciplines to work on the project together, all using different modelling platforms. By avoiding vendor lock in, project teams can share and exploit data in different software and technologies, enabling them to get more out of the data and gain better insights, in turn leading to greater project outcomes.

Trimble’s commitment to open data workflows also extends to our membership of buildingSMART International, where we are part of the Strategic Advisory Council. We meet regularly to develop and execute on the core mission and values of the buildingSMART International community, jointly working towards a truly connected construction industry. Working with other members, we’re proud to help shape the future of the industry by providing critical guidance, feedback and input in developing the standards and solutions for the built asset industry. A great example of this is Trimble’s support for the development and implementation of the IFC4.3 schema, covering infrastructures and civils.

We know that in the construction industry and its marketplace, people will always use different software solutions for different things – and that’s okay. What’s important is that this doesn’t have a detrimental impact on communication and coordination. Moving forwards and as we progress, it’s clear that greater adoption is still needed from across the industry if IFCs are to be used to their truest potential, ensuring effective interoperability and full data exchange across the lifecycle of an asset.

Find out more about real-time BIM collaboration: watch how Trimble has helped BYLOR deliver nuclear quality at Hinkley Point C.