IFC Modularisation: current status and request for feedback

Activities & Projects Next-Gen IFC (aka IFC5)
1

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 leon.vanberlo@buildingsmart.org

4 Likes
2

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 ?

3 Likes
3

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.

3 Likes
4

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): https://www.incose.org/docs/default-source/delaware-valley/mbse-overview-incose-30-july-2015.pdf

5

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.

7

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:

#13=(
  IFCROOT(‘2hMAnP$AmSdgDeydu23hwc’,$,’OutletName’,$),
  IFCOBJECTDEFINITION(),
  IFCOBJECT($),
  IFCPRODUCT(#14,#15),
  IFCELEMENT(‘tag’),
  IFCDISTRIBUTIONELEMENT(),
  IFCDISTRIBUTIONFLOWELEMENT(),
  IFCFLOWTERMINAL(),
  IFCOUTLET(.TELEPHONEOUTLET.)
);

instead of this:

#13=IFCOUTLET(‘2hMAnP$AmSdgDeydu23hwc’,$,’OutletName’,$,$,#14,#15,‘tag’,.TELEPHONEOUTLET.);

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).

3 Likes
8

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
9

10
10766×585 83.5 KB

10

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

11

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?

Indeed!

1 Like
12

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:

13

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.

14

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

15

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?

21

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.

3 Likes
22

Again, you’re an academic figure, so please read about modeling and simulation-based systems engineering (M&SBSE)

See some project related to it, for instance, from UC Berkeley and even MIT

23

Can you please show direct application and proof of what you are speaking about is related to the Modularisation issue in hand?

Please provide examples for us where same/similar problems were solved this way as you propose. (Best examples would be ones you have worked on first hand.)

We should keep this constructive and on the forum topic. Anything otherwise feel free to contact me directly.

3 Likes
24

Sorry, but I think the conversation is sort of spiraling out of control now. I would like to bring it back to LĂ©on’s original question about modularity. There are many reasons for such a discussion that could have a significant impact on expanding IFC use while lowering the threshold for implementation among many different kinds of software applications and remaining “compatible” with the larger IFC-based environment.

Maybe it helps to add some context. For example:

Say IFC5 includes all the new classes for infrastructure (bridges, tunnels, ports, harbors, roads, rail, utilities, and landscape), as well as enhancements to the existing building domain and additional “core” schema improvements.

If I’m an architect (building design), ideally I want a software tool that does architectural design really well, if not best in class. It may or may not include extensive structural, MEP, or landscape capabilities directly related to the building design, but I should be able to design all other aspects from an architectural point of view, from programming, space planning, element design, finishes, to FF&E, and info for handover/COBie. At the same time, I would reasonably NOT expect this same tool to be able to do road, bridge, tunnel, or rail design to the same level because it would be far too complex of an interface. However, if I receive an IFC file that has a site in which I am to place a building, it might have landscape, road, and even rail elements which the application should be able to import and display, but not necessarily manipulate (architects SHOULD leave that to the other domain experts).

In this case, IFC schema modularity would mean that the architect’s software would have the ability to support EXPORT of building architectural domain elements to varying levels of detail and types (and optionally the structural and MEP) but NOT site, landscape, rail, road, tunnel, etc. It might also have the ability to IMPORT any IFC file, but wouldn’t be expected to translate all IFC classes not directly related to the building domain to native software elements for further manipulation
 viewing yes, editing, no. For the software developer, this kind of modularity makes sense as it focuses the IFC support on the platform’s strength and capabilities and not require him/her to expand that functionality beyond the platform’s development plan.

Along a larger workflow, context, you might have a model viewer/checker that is able to read the entire file, aggregate files, do model element analysis, etc. But, it is not explicitly manipulating that data and re-exporting to a new IFC file.

At the end, you may have a comprehensive Digital Twin tool that does have the ability to IMPORT everything, as well as view it, and maybe manipulate the data, then exporting subsets of that model for various purposes (maybe even back to another architectural BIM platform for future additions/revisions). This may be related to a CDE, or a very powerful platform that has a great deal of modularity in its interface.

In my mind, and I think what we are trying to get at with this particular discussion, the question is WHAT does that “modularity” look like?

  • How would it be different from what there is today?
  • What falls within the “Core” vs. “Common” vs. “Module”?
  • What adjustments to the schema must be made to enable this?
  • Are there further restrictions that must be made to limit flexibility, but enable better compatibility by removing uncertainty?

I think Nick began a good retort, but I also think he uncovers one thing that concerns me, which is a blind spot people might have regarding practical, pragmatic tooling and workflows versus theoretical ideals when it comes to authoring all the different domain elements/systems. We can’t expect all the tools out there to suddenly expand their capabilities to include support for modeling/editing ALL elements in the built environment. In such a context, how can the schema support practical modularity?

5 Likes
25

Please don’t give up. Let’s refocus. We are trying to get somewhere


2 Likes
26

Ehsan
 watch it. Maybe lay off the forum for a while and let the conversation develop.

2 Likes