buildingSMART Forums

IFC Modularisation: current status and request for feedback

Hi all,

There have been some efforts going on to modularise IFC (again).
It is crucial for IFC to become modulair for future maintainability and for interoperability between multiple domains.
The following presentation shows slides that present the current consensus and direction for IFC5. It also has some questions that still need to be resolved.

20191126 modulair IFC

Feel free to provide us feedback and help on this journey. Make your posts constructive and please work towards finding a solution/consensus for the whole industry/community. It would be nice to focus on answering the questions, but other ideas are of course also welcome.
Direct feedback is also welcome on


The slides leave me wondering what a ‘module’ is: it is certainly not just the outcome from a Room or a Project, and it cant just be a Domain, because every Domain uses (or may need to use) entities from other Domains. (Except structural analysis !).

My view of the IFC schema is threefold:
1: Spatial/conceptual, including Ifc Site, Zone, Building-Storey/region and Space/location
2: Physical, including Ifc Building/facility, System, Type and Component
3: Process, including Ifc Project, Work-Package, Task-Type and Task.
Very few of the specializations of these core 12 entities are totally domain specific.
In “Ports and waterways” we need it all! So
Perhaps we should stop using MVD to specify software import/export and only use it to specify requirements. We stop trying to define domains and just certify on which Resources are supported. Does application X read CSG? Constraints and parametrics? NURBS? Document, Library and Classification ?


Could not agree more with @nn1 - the built environment is a very interrelated field. A better approach would be to stop using MVD for importing and exporting. Instead, the MVD should state requirements: does this IFC dataset in X format contain data about Y that I’m interested in?

This also opens up possibilities for BIM authoring tools that focus on aspects of the IFC schema. You can have a 3D modeling program that has no concept of documents, classifications, structural analysis, etc, but is simply really good at modeling and exporting out shape representations. This shape representation represents a tiny IFC dataset, incomplete by itself, but can be “linked” into another BIM program that is specialised in purely assigning attributes, classes, and classifications. This can then be linked into another BIM program that specialises in document association… another that specialises in materials for lighting simulation …

and so on.

I believe this is how IFC should be “modularised”. Concepts such as “documents” or “shape representations”, or “advanced breps” should be the modules, which they almost already are, and certification should enforce authoring programs to roundtrip an IFC file without mangling the data.

Currently, since MVDs are inherently monolithic (i.e. they include a large portion of the spec), this means that BIM programs must be expert at all of the BIM concepts, which is completely unrealistic. No program should be able to do it all. The practical result is what we have today - where every single IFC program has data loss in one form or another.


I think sooner or latter the industry will realize that needs something more advanced and it would be modeling and simulation-based systems engineering (M&SBSE)

So, why you don’t recreate IFC based on it? It even has some similarities with ISO 19650 but is more advanced than what ISO 19650 suggests

Take a look at this presentation (2015):

Would this not enable overloaded information exchanges? (for both file based and webbed transactions)

E.g. If I want to write an ISO Schematron checker based on MVD/Requirements as you suggest, then the verification cannot be Explicit. Hence, then Validation may not be explicitly possible, because other items (attributes etc.) are in the exchange.

How will we certify software if we cannot test which MVD they conform to?

Currently this is straight forward using IDM/MVD, IFC in some format e.g. ISO 10303-21, 28, RDF, etc., and ISO Schematron based tools can be developed for automatic verification.

I think I agree with nn1 and Moult.

I don’t see how the schema can practically be modularized. I think most programs would need to know about the full schema (all modules) anyway, because they will get files with lots of different modules.

And I’m particularly sceptical to introduce versioning per module. What will then happen with files that uses multiple modules? For example an electro circuit that controls an HVAC valve or a road traffic light? There will have to be some kind of “global” versioning system to ensure that the different modules are compatible with each other.

From the application perspective, I just don’t see how this could work well in practice. But I think I would need more concrete examples to be able to know what we really are talking about here, so this is mostly based on fear of the unknown.

Btw: The ISO 10303-21 standard (step text format) also describes conformance 2 type, where objects are written like this:


instead of this:


This allows programs to deal with objects even if it doesn’t know about the concrete subtype. Any IFC viewer could thus visualize the product (since it knows about IfcProduct), but doesn’t necessarily have to know about IfcOutlet, because that could be part of an unknown module. I think this could be useful (but also very verbose and give much bigger files).

What I’m basically saying, is that the ISO 10303 does already touch these topics, and already supports modularization. So if we are still going to use the STEP/EXPRESS architecture, we should look at the standard and see what more it has to offer in this direction.

I think there is another kind of modularization that would much more benefit applications, and that is if the IFC models itself were more modular and could be split across multiple files. One step in that direction would be to use GUID references in relation objects instead of entity ids.

The convention today is to have separate files for each domain: one architect file, one electro file, one ventilation file etc. All of them repeates (duplicates) for example the spatial structure. And there is no way to enrich another model (for example specify material layers in building elements, needed for various simulations, without reexporting the whole architecture model).


For “Merging” - Do we not have IFC Based Information Exchanges that already show how to “explicitly” merge and test MVD files? E.g. WSie, HVACie, etc. where - WSie = COBie + IfcPort + 2x3tc1CV 2.0 MVD (or IFC4 RV)

Much effort (people, money, time) has been put in to such Information Exchanges to pave the way for better lean information exchange, verification, and validation…Do we just throw this away now under this new “consensus”?

IFC5 can easily use the same methodology to share information via similar exchange method…Can it not?

1 Like

I like what you and Dion @Moult suggest if still bSI insists on STEP/EXPRESS or XMI (XML)

And I think I suggested before both decoupling and also the structure ISO 10303-21 standard provides

Personally these days I think SysML can solve the majority of issues

There’s a long time I’ve found a “missing part” in OpenBIM process that caused this issues but I’ve waited to see what will do some people who work on IDM Toolkit projects and even COBie

I have something that will change the game some have started

I am not quite sure what the objective of this proposal is. Why is it crucial that IFC becomes modular? I thought that did not go so well and now we have MVDs. I would agree with other comments from @nn1, @Moult, @DrShawnOKeeffe, @Helland here. In the end, any facility requires most building elements. For whatever comes on top, an MVD kind of provides the tool to specify any additions. MVDs delivered by IFC Bridge demonstrate this e.g. the Bridge Reference View inherits from Reference View and just adds the Bridge specific elements, same for Bridge Alignment Reference View (additionally to the bridge specific elements alignment and linear placement concepts are added). Of course, it would be nice to be able to assemble MVDs not just inherit but to achieve this, does it make sense to start with an entirely different approach? Why not just modify MVDs so that they could be put together according to requirements?


1 Like

What does it mean “put together?”

IFC is Object-Oriented based, so we didn’t put together objects before?

You know and we know too, IFC with the existing approach is just waste of time and money, even IDM elements improve current issues a little bit and are some steps closer to what Systems Engineering (SE) suggests

IFC inherently has some modularity when is about “objects” but what some have started to think about that even comes from my insights is to build “blocks/packages” --> IDM Elements?

MVD is good “if we see it just as an archive file,” otherwise MVD definition has a BIG issue/mistake, personally DISLIKE MVD be JUST A SUBSET OF IFC --> I shared the missing part

I don’t know why some of you insist on things that the majority have realized are “ineffective and inefficient”

Let me explain: You want MVD as an “input file for other software/solution”

I put other software/solution before MVD and just see MVD as an archive file that is not just a subset of IFC, is a subset of IFC after processing

IFD+IFC (Input) --> IDM (Processing/Modeling/Management) --> MVD (Output/Archive)

This approach will drop many software/solutions you invested your time and money on them :wink:

The Water Systems information exchange Venne Diagram I’ve posted shows so-called “putting together”. This is the proper way to exchange information via IFC to assure explicit exchange for specific purposes without duplication of data. The key is your physical schema ability within your authoring application and knowing how to automatically verify the resulting exchange, no matter it’s format.

I would like to suggest one think objectively about this, with the focus of solving real problems today with today’s applications/tools.

I completely understand your approach

But I think the majority of today’s tools are/were good for BIM Level 2, BIM Level 3 is about data/information management/exchange/control, in general “automation and control” and most of the solutions will disappear soon because are “against/obstacles” of automation and control

I suggest Systems Engineering (SE) because is an emerging solution and will bring efficiency to the industry

The majority of things happen automatically inside the Systems Engineering (SE) applications

BIM levels? Don’t think these have a place here. :slight_smile:

As for today’s tools for info exchange, management, control, automation, etc, NO they are NOT suffice hence the want to “Modularize” vs “just do it right” and build on what exists. Hence the need to leverage off current MVDs not yet adopted and tested by vendors. Remove MVD and verification and validation methods start all over again.

Too change as proposed, will bring us back to the 90’s in relation to IFC adoption, certification, etc. To move forward with MVD and implement what exists like BAMie, etc. will bring us steps forward, and these steps can happen now with existing tool to solve problems today! I’m working on a book now for IFC based exchanges using current tools. WSie, HVACie, etc.

If I want to capture FM data from design tools as I do now to integrate into CMMS directly, are we saying that changing to Modularization will change how one does this?

Or more simply, if I’m a vendor who spent year on certification for CV MVD, this is all of a sudden redundant?

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

Wow. I’m done here. Please be constructive. Very large accusations and assumptions on behalf of yourself in relation to professionals here and the bSI organization. Good luck on your mission. Best wishes.