IFC as a universal data exchange format

IFC as a universal data exchange format
IMS team-Marcel-Kunzmann-
Contribution recorded by: Marcel Kunzmann

Marcel is a technology consultant and ideas giver for our software. He investigates the technically feasible and tests upcoming techniques, for example AR and IoT. After work, he swings on the bike - his analogue equalization to digital peak performance.

The Industry Foundation Classes IFC are picking up speed as standard. For one, IFC5 is in planning and soon to be expected as the first pre-release version. At the same time, new working groups have recently found themselves trying to establish the openBIM idea in new areas with the help of the IFC standard.

For example, the buildingSMART association recently called for a working group to expand IFC's "Site, Landscape, and Urban Planning." Your goal is to have all the outer surfaces in the overarching IFC standard insert.

But how useful is such a project anyway? Do we really need such an extended standard?

And how does he fit into BIM and CAFM meaningful?

Possibility is already there in the substructure

What is to be described with the new working groups, can already be technically reflected in IFC today. In IFC, users can currently define objects that are not in the catalog as so-called IFC proxies. These receive individual characteristic features, so-called IFC property sets, The problem: Due to the properties assigned to Gusto, the semantically transparent and therefore reliable data exchange between different partners is no longer possible.

Thus, the fact that the new IFC working groups are formed has to do with a deficiency of the standard: IFC is currently still very building-centric, writes buildingSMART self-critically in the announcement of the Landscape working group. An explicit semantics for the description of outdoor facilities is missing. Neither trees nor outdoor furniture, paths and their coverings, water pipes and sewage system could be represented with the available elements. And also not the structure of the landscape or objects in it, such as bodies of water and lakes.

IFC working groups everywhere

Analogously, this criticism can also be applied to the other areas to which working groups have come together in recent months. These include those for traffic routes, bridges, tunnels, railways or airports. If these groups agree on binding results, the IFC standard would make it possible to describe a much more well-built and designed environment and infrastructure.

Even industries are starting to get involved. An example is the precast industry. It formed the working group IFC Precast and works on the modeling of built-in components. As a long-term goal, it would be possible to uniquely identify each finished part. From planning to production through machines that use IFC data for control, to assembly. This would provide traceability - not just across the building lifecycle, but across the extended part lifecycle.

With the extension to IFC5 buildingSMART pursues another important goal: to create more standardized workflows. Reason is that the increasing use of BIM, an increasing number of users from more and more trades and areas uses the BIM method. In order to continue the data exchange in the future, the requirement profile of the description standard must be extended, the association argues.

Only: how relevant is such an extension really, especially with regard to BIM and CAFM? And to ask is also: Who used the extensions, even if the current IFC4 standard - for example, in Germany - is used only rudimentary?

The Crux: Who cares?

I admit, the question is wrong. Indisputably, a standard is always welcome and fundamentally relevant. It helps to keep content binding for different users. It is therefore necessary to ask how the implementation in this country can be improved. Basic is definitely to find:

For example, data for infrastructural CAFM can be found in most BIM models. In the case of technical systems, however, the possibilities of IFC almost always remain unused. And that, although within the IFC "Domain Layer" there are sufficient possibilities to model here as well.

BIM models that I have today show the gaping gaps: Planners often use the parent IFC entities instead of using the specific subtypes. In the electrical / air conditioning everything is flat rate as IFCFlowTerminal even if it is a simple lamp or a radiator. Or, meaningful entities are not chosen. Thus it happens that in the field of fire protection, the SHEV flaps are often called IFCWindow and thus be shown as a window.

Or it will be the generic way over IfcBuildingElementProxy so that, for example, elevators then not more than IfcTransportElement of the type ELEVATOR can be seen.

For CAFM and BIM, the additions to IFC and the IFC5 amendment are a good and desirable advance. But for the extensions to bear fruit, their options must be used consistently. Specialist planners will seldom voluntarily click through the depths of nomenclature. Flaning, there should be a complete translation matrix in the enterprise that assigns each component type to the corresponding IFC entity.

Demand enemy differentiation actively

The necessary differentiation of the enemy must be actively demanded - be it from the client, be it from the later user and operator, or from partners who rely on clear information in the course of the BIM process.

You also have to be careful with planning software. By default, it also prefers only generic entities. Only by parameterizing the corresponding BIM authoring tools such as Revit or Allplan are reasonable IFC exports generated.

BIM manager as gatekeeper

The fact that the information from IFC is stored correctly in the BIM model is the responsibility of the BIM manager. He has to supervise that the planned nomenclature of the project is respected and to actively demand it if disregarded.

After all: The upcoming expansions will contribute to the IFC as a universal data format finds its way into even more industries. Thus, the goal of openBIM to act as a central database and central exchange format, more likely. And this should be accompanied by an increasing discipline of all involved. Anyone would benefit, whether with regard to trades and collaboration or with a view to the internationalization of projects.

I can only advise: Let's all play with. Then the standard is already today with IFC4 and also as IFC5 for BIM like CAFM very useful.

Best regards

signature KUN IFC as a universal data exchange format »IMSWARE.de

Your feedback?

average 4.4 / 5. Number of votes: 7

Be the first to rate :-)

Great. Thank you very much!

Maybe you want to follow us on ...


How can we improve that?

All with just one software CAFM at ALNO AG in Pfullendorf
Christmas: Electric, but maintenance-free!