IFC as a universal data exchange format
The Industry Foundation Classes IFC are clearly gaining momentum as a standard. On the one hand, IFC5 is being planned and can soon be expected as the first preliminary version. At the same time, new working groups have recently been formed that are attempting to develop the openBIM idea into new areas with the help of the IFC standard.
Thus the association called buildingSmart recently set up a working group to expand IFC for "Site, Landscape, and Urban Planning". Their goal is to plan all outdoor spaces in the overarching IFC standard to insert.
But how sensible is such a project anyway? Do we really need such an extended standard?
Possibility is already there in the substructure
What is to be described with the new working groups can technically already be mapped in IFC today. Users can currently define objects in IFC that are not contained in the catalogue as so-called IFC proxies. These are given individual property characteristics, so-called IFC property sets. The problem is that the semantically transparent and thus reliable exchange of data between different partners is no longer possible due to the properties that are assigned at will.
The fact that the new IFC working groups are being formed has to do with a shortcoming of the standard: IFC is currently still very building-centric, writes buildingSMART self-critically in the announcement of the landscape working group. Explicit semantics for the description of outdoor facilities are missing. Neither trees nor outdoor furniture, paths and their surfaces, water pipes and sewage systems could be represented with the available elements. Nor could the structure of the landscape or objects within it, such as bodies of water and lakes.
IFC working groups everywhere
Analogously, this criticism can also be applied to the other areas on which working groups have met in recent months. These include those for traffic routes, bridges, tunnels, railway lines and airports. If these groups agree on binding results, the IFC standard would make it possible to describe considerably more of the built and designed environment, and infrastructure enable.
Industries are also starting to get involved. One example is the precast industry. It formed the IFC Precast working group and is working on the modelling of built-in parts. As a long-term goal, it would be possible to uniquely identify each precast part. And this would be possible from the planning stage through production by machines that use IFC-dates for control purposes, right up to assembly. This would provide traceability - not just over the building life cycle, but over the extended component life cycle.
With the extension to IFC5, buildingSMART is pursuing another important goal: to create more standardised workflows. The reason for this is that the increasing spread of BIM means that an ever greater number of users from more and more trades and sectors are using the BIM method. In order to ensure that data exchange continues to work in the future, the requirements profile for the description standard must be expanded, argues the association.
Only: how relevant is such an extension really, especially with regard to BIM and CAFM? And the question must also be asked: Who benefits from the extensions if the current IFC4 standard - for example in Germany - is only used in rudimentary form?
The crux: who cares?
I admit that the question is wrongly posed. Undeniably, a standard is always to be welcomed and fundamentally relevant. It helps to make content bindingly available for different users. The question is therefore how implementation can be improved in this country. Fundamental things can certainly be found:
For example, most BIM models include data for infrastructural CAFM to be found. In the case of technical facilities, however, the possibilities of IFC almost always remain unused. And this is despite the fact that there are sufficient possibilities within the IFC "domain layer" to model here as well.
BIM models I have today show the gaping holes: planners often use the higher-level IFC entities instead of using the concrete subtypes. In electrical/air-conditioning engineering, everything is blanketly described as a IFCFlowTerminal reported, even if it is a simple lamp or a radiator. Or entities that do not make sense are chosen. Thus it happens that in the area of fire protection the SHEV dampers are often designated as IFCWindow and thus be shown as a window.
Or the generic path via a IfcBuildingElementProxy so that, for example, lifts are then no longer considered as IfcTransportElement of the type ELEVATOR can be seen.
For CAFM and BIM, the extensions of IFC and the amendment with IFC5 are good and desirable progress. But for the extensions to bear fruit, their possibilities must be used consistently. Specialist planners will rarely voluntarily click their way through the depths of the nomenclature. There should be a complete translation matrix in the company that assigns each component type to the corresponding IFC entity.
Demand enemy differentiation actively
The necessary fine differentiation must be actively demanded - be it by the client, be it by the later user and operator, be it by partners who are dependent on clear information in the course of the BIM process.
You also have to be careful with planning software. Unfortunately, they only prefer general entities by default. Only by parameterising the corresponding BIM authoring tools such as Revit or Allplan are reasonable IFC exports generated.
BIM manager as gatekeeper
The BIM manager is responsible for ensuring that the information from IFC is correctly stored in the BIM model. He has to monitor that the planned nomenclature of the project is adhered to and actively demand it in case of non-compliance.
Nevertheless, the coming extensions will contribute to IFC finding its way into even more sectors as a universal data format. This will make openBIM's goal of acting as a central database and central exchange format more likely. And this is likely to be accompanied by an increasing disciplining of all those involved. Everyone would benefit, whether with regard to trades and collaboration or with regard to the internationalisation of projects.
With that, I can only advise: Let's all play along. Then the standard is already available today with IFC4 and also in the future as IFC5 for BIM like CAFM very useful.
We are sorry that you did not like this post so much.
How can we improve that?