Article #3 of 8 from AEC Magazine’s IFC Special Report
Emma Hooper, Associate Director and Head of R&D at Bond Bryan Digital, provides a useful overview of the IFC data model specification
Over the course of a facility’s life, information is created and goes on a journey in which it is constantly exchanged by people using technology.
From the initial idea to construct a building to the deletion of this asset from a map following its demolition, a building creates a trail of information that follows it from cradle to grave.
This trail is invisible. Some call it a ‘golden thread’. I prefer to call it an ‘information layer’, which forms part of an information management ecosystem. But whatever you call it, this trail is currently fragmented and, quite frankly, a mess.
The purpose of information management is to view information as an asset in its own right. To get the full value from information, it must be rationalised and joined up – both processes entirely separate from software.
Two layers at work
The information management ecosystem is made up of two layers. First, there’s the management layer, which includes recurring cycles of information management activities, based on appointments. This is covered by ISO 19650.
Second, there’s the information layer, where the complexity of the different facets of information are broken down, structured, ordered and joined up, in order to provide a base data language for the activities in the management layer outlined above and for the technology to plug into.
The information layer is complex. There is no escaping that. Try describing one component in a facility: its type, performance, materials, location, name and all the other data related to it, plus the data about the data. And that’s just one component.
Now, multiply this to cover tens of thousands or millions of components and how they all connect to one another. The task is utterly mind-blowing in its complexity! So, the only way we can produce connected, machine-interpretable data is to use data models as part of the information layer.
What is a data model, anyway?
Essentially, a data model is a way of structuring and joining up data. It creates order and enables complex connections to be made. A data model is not a BIM model in the traditional sense, and it doesn’t have to contain geometry.
But we also need a standardised data model to provide a single data language throughout, otherwise we quickly encounter interoperability issues. Do we have something already? We do! It’s called Industry Foundation Classes, or IFC.
IFC is an off-the-shelf data model specification. It is managed by buildingSMART International (see buildingSMART article) and is an international standard, ISO 16739.
IFC provides a data framework for most of the parts of the AEC industry, allowing information to be connected. For example, a boiler might be connected to a pipe and associated with a particular system, along with the space and building in which it is located, a construction programme, commissioning certificates, performance properties, a cost plan, classification and so on. In fact, I could go on and on. What’s important is that there is nothing in the industry, besides IFC, that can accomplish so much in terms of connecting information across so many domains.
IFC is a digital representation of a built asset for a computer to understand.
Why do we need IFC?
Each proprietary software application has its own data model running in the background. These are typically packaged up in custom file formats for exchange purposes.
But these data models are bespoke and often poorly created, with the sole objective of serving the software. Therefore, when we exchange data between software packages, we run into interoperability issues, because these packages speak different languages. If software packages can read and write to a standard data model, they only have to create the mapping once, rather than a point-to-point solution for every permutation of software exchange.
It’s also not just delivery and the exchange of design information where IFC can play a part. Going back to the information management ecosystem, IFC is at the heart of the information layer as the standardised data model. Therefore, it can be used to provide data foundations to underpin ISO 19650 activities. IFC can be used to structure exchange information requirements, deliver them and assure the delivered data against the original requirements and store data during and after the project (see Gen Zero project article).
Because the data model is so big, it has to be broken down to exchange information. This is all done using filtered parts of the IFC schema called model view definitions. This approach is being redeveloped by buildingSMART to make it more flexible using information delivery specifications, or IDS.
The more we digitise, the more data models organisations will create. If we don’t have a standardised starting point for these, they will be structured in completely different ways and, as a result, sharing information between them will be as difficult as it is now between authoring software, just on a much bigger scale. Technology will not provide a magic solution!
IFC basics
The IFC standard is free and can be accessed via the buildingSMART website. There are currently two official versions:
- IFC2x3 TC1 (IFC2x3) – this is aligned to ISO 16739:2005.
- IFC4 ADD2 TC1 (IFC4) – this is aligned to ISO 16739-1:2018.
IFC2x3 is the predominant version used in the UK. However IFC4 implementation within software has recently accelerated and, together with the proposed release of IFC4.3 in 2022/2023, we need as an industry to start the transition to IFC 4.3 in the next year (see IFC 4.3 article).
Communication of the data model is carried out using a schema. This provides a data modelling language to represent a data model often in a graphical way, enabling a viewer to see what the data model contains and work out which parts are connected.
IFC can be visualised using several schemas. Currently, the principal one is EXPRESS-G, but the plan is to move to UML (unified modelling language) in IFC5.
On top of this, when transferring data from a data model, you need an exchange format to transport it. IFC typically uses the STEP physical format (SPF) which is text-based. (Because it has the ‘.ifc’ file extension, this has led to the misconception that IFC is just a file format.) Being text-based means that model files can be opened using a standard text editor such as Notepad.
Other exchange formats include XML and JSON and there are others in development. These include RDF/XML,Turtle and JSONLD, where the emphasis is less on exchanging files and more on exchanging the data.
IFC data model composition
In simple terms, IFC is made up of three parts: entities, attributes and relationships.
Entities are the main classes and, in the data model, act like nodes. In other words, it’s the entities that get connected. Most entities can be considered as objects – not just physicalbased objects such as walls and boilers, but also objects such as geometry, processes, properties, materials and so on. This means there is potential to perform cost schedules, resource planning and construction using IFC.
A particularly important entity is IfcBuildingElementProxy, which can be used where there is no appropriate entity. This acts like a template entity, identifying all the appropriate attributes and relationships. There is also the ability here to define the object further (see section below on predefined types).
Attributes define entities further by including basic data such as ‘name’, ‘description’ and ‘globalID’. Attributes also allow connections to be made to other entities by acting like hooks.
Relationships connect entities via attributes, and in the IFC schema, are objects themselves. It is the relationships that are key and will become even more important as we move into a more connected future.
Watch Emma Hooper’s NXT BLD 2022 talk on Information Models and the future of IFC. Register here
Predefined types, properties & external references
There are a few more terms with which users need to familiarise themselves.
For example, one important attribute is the predefined type. This allows an entity to be described further; for example, for IfcSanitaryTerminalType, predefined types include TOILETPAN, SINK, WASHHANDBASIN and so on. These are listed in capitals, just as they are on the predefined pick-list.
The USERDEFINED predefined type should be used only where there is no appropriate predefined type.
USERDEFINED still needs to be entered at the predefined type, but the entity can be defined further by using the ElementType or ObjectType attribute.
IFC also enables properties to be associated with objects. Before the association can take place, the property has to be assigned to a property set. A property set is a container of properties that have something in common; within the IFC schema, property sets are characterised using the ‘Pset_’ prefix.
Custom properties can also be added using custom property sets, but it is first important to check that the properties don’t already exist in industry dictionaries or lexicons.
Finally, let’s look at external references. IFC recognises that not all information will be captured within IFC models, so it also has the ability to associate externally referenced sources of information to IFC objects. The three external references are:
- Classification, which allows classification systems such as Uniclass to be associated to objects.
- Libraries, which allow data from external databases to be associated to objects (for example, product data manufacturers).
- Documents, which allow documents to be associated with objects (for example, a commissioning certificate can be associated with a boiler).
In summary, I would not claim that IFC is perfect – but as an industry, we need to team up and help to support, improve and evolve IFC across an ever-changing digital landscape. Those working in the digital information space need to know the basics. But the majority of people shouldn’t even know it’s there, because it operates seamlessly in the background. In fact, I’d go as far as to say that the more I understand IFC, the more I come to think of it as one of the greatest achievements in digital construction.
IFC’s benefits
- Free, off-the-shelf and ready to be used for almost any purpose, IFC brings big benefits. These include its ability to:
- Provide the data framework for information management activities • Enable repeatable processes and software configurations during delivery
- Deliver longevity and sustainability of data
- Side-step intellectual property issues and vendor lock-in
- Support more complex querying, via relationships, providing better insight for decision making
- Provide easier connection to external data sets via standardisation, for complex use cases like smart cities
- Accelerate advancements like machine learning
Click here for more information about buildingSmart UK & Ireland.
This article is part of AEC Magazine’s
IFC Special Report – Enabling interoperability in the AEC industry.
To read the other articles in this report click on the links below.
Industry convergence
From sustainability to new business models, and from wellness to emerging technologies, IFC can be a force for good, driving the AEC industry to new levels of achievement
Inside buildingSMART
What is buildingSMART and what can it offer industry practitioners?
IFC for Infrastructure
Perhaps the most significant update to the IFC standard is the inclusion of extensions for infrastructure entities in IFC 4.3
Native OpenBIM, and the rise of open source in AEC
OpenBIM can deliver on the promise of a digital world for the built environment where information and data are truly valued
IFC at Hinkley Point C
By Tim Davies, digital engineering manager, BYLOR JV – Hinkley Point C
Tackling the Gen Zero Project
The UK Department for Education’s Gen Zero project showcases how IFC can be used as the underlying data standard for a large, complex project, from start to finish
buildingSMART certification
By Phil Read, program lead at bSUKI and managing director, Man and Machine
