IFC Modularisation: current status and request for feedback

[ReD_CoDE]

I shared this link at first comments, have you read it?

IFC Modularisation: current status and request for feedback

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

IFC just holds Data/Information, it holds many things, especially rules and formulas

@jwouellette We all agree with the modularity you offer, some say it be based on disciplines which is a good idea, some say based on work package, etc

Even I thought a little bit diffrent (I think just Context is not a good term in my way as “where”):

https://github.com/IfcXtreme/ODClass

These days my concerns lie around automation and control and how to automate the majority of workflows

And I think bSI, if develops anything based on UML 2.0 or SysML 2.0, will be able to add formulas and ruels and many invaluable things to IFD/IFC/IDM/MVD etc

[Helland]

Thanks for trying to move the discussion back to the topic. In my opinion, it would also be appropriate to moderate and delete the most off topic comments.

And to the topic: You try to add more context, but if I get what you are saying correctly, you are basically stating two criterias:

1. It should be possible for any application to be able to display everything in an IFC file.
2. An application should be allowed to specialize on their own domain. For example architecture. So they shouldn’t be required to manipulate anything else.

I think this describes the situation we already have. So your first question “how would it be different from what there is today?” is something I think you should answer. I see nothing more to discuss unless you don’t provide more criterias and/or problems to be solved.

The presentation in the first post here describes at least two more problems:

• difficult to maintain / harmonize for new releases
• certification based on use-cases does not scale

But these are just claims without further description or context, so I don’t know what problem we are actually trying to solve here.

And next, I will just repeat myself and say that with the technology we’re using today (STEP files), there is no way an application can display objects that it doesn’t know about. If an architect application stumble upon an IFCOUTLET, but it doesn’t know what that is, there is no way to display this.

So you will probably have to restructure IFC to use composition instead of inheritance. But I expect you don’t want to do a grand restructuring of the existing IFC schema, and also guess you don’t want to totally switch technology? If you want that, this becomes a much broader discussion, with many other concerns to bring in than just modularization. (this is the kind of discussion Ehsan is trying to start, but that quickly gets off topic because it has so many other concerns)

Because of your first criteria (that it should be possible for an application do display everything in the IFC file it receives), you have only 1 option as far as I can see: To continue with one monolithic schema that contains the full IFC specification. But have clear boundaries in the certification, so that an architectural application can be certified for doing architectural stuff, without having to know more about roads than how to display them. (it is enough to know that IfcRoad is an IfcProduct, and thus the geometry follows the Body Geometry concept)

[DrShawnOKeeffe]

Agreed! This is exactly the same situation in hand at the moment.

“1. It should be possible for any application to be able to display everything in an IFC file.”

This goes against the IFC mission to date, was never intended, and is technically not possible, hence, we have Model Views, Not the so-called “ifc files”. Model views work well for both practical implementation in daily practice, and for certification. Why do we need to “see everything.” What does this even mean?

A Coordination View or Reference View for Road, Rial, etc. would be suffice and could be imported into Arch based design applications if needed. These tolls could get certified for the Model Views as they do now using ISO 10303 part 21, or even other parts e.g. 28, 26, etc.

Overlaps of data in two different domains, if required, can be define in a specific model view as is the case now, e.g. the WSie Venne Diagram I shared which use Plumbing, Architectural, HVAC, etc. This is perfect for the exchange of non-editable plumbing systems, suffice for drawings, coordination, simulations, and capturing, verifying, and validating FM data from that phased of the project life cycle. Short hand formula for such file, lets say using schema 2X3 tc1, would be: WSie = CV + COBie + IfcPort

In fact, the exact same method could/should be used for water systems within an Infrastructure Domain. That software which is used to author such a model view, could easily be certified for import and export of said file. Short hand formula for such file, lets say using schema IFC5, could be: Infrastructure Water Systems information exchange (IWSie = RV + (Similar Reqs as COBie but it would be technically something else) + IfcPort, where IfcPort defines the distribution/Rel connections so the flow of infrastructure water can be managed, simulated. This file could also be imported into Arch based tools to analyse the connection to facilities, etc, where this Arch app, e.g. Graphisoft Archicad could easily get certified for the import of such a model view. Many of these application are already designed for there API to handle such geometry. Those which are not, already have a problem in this regard and modularisation as defined in this scope would not solve those technical rendering, serialisation, etc. issues. I can envisage cases where it would actual be worse. Conforming to the new approach, said modularisation, would actually make software compliance much worse, and in many cases the problem will actually not ever be solved, e.g. Graphisoft Archicad uses the IFC2X3 tc1 CV 2.0 MVD for its so-called “General Translator”, with seems like an add-hoc way to do such a modularization approach…but its technically wrong now, and presumably in the future where one could easily see such a vendor trying to conform with modularisation by expanding their currency existing default “IFC Exporter”, which is no more than the CV 2.0 MVD, which can easily been check/sought in the STPE Physical File header.

“2. An application should be allowed to specialize on their own domain. For example architecture. So they shouldn’t be required to manipulate anything else.”

This is the way it is now, as mentioned above. A problem here, which cannot be controlled, if folks forcing application to do things they were not built for, e.g. road and rail in Revit. Such applications already struggle to comply with exist MVDs, much less domain specific outside the scope of enabling the extraction of 2D drawings from 3D models using cut plane algorithms, etc. While 3rd party apps, e.g. COBie Extension, can be developed and tested for compliance, such solutions are are suboptimal versus other applications were the API can actually handle this type of information without the need fro external databases, GUIs, etc.

I guess my point in general is that, to bring such modularization into practical use, i.e. by engineers designing etc., it would likely cause more problems than solutions, due to already existing software limitations. I would hate to see another 30 years go by and we do nothing more than replace the light-table, again!

[Helland]

@DrShawnOKeeffe

“1. It should be possible for any application to be able to display everything in an IFC file.”

This goes against the IFC mission to date, was never intended, and is technically not possible, hence, we have Model Views, Not the so-called “ifc files”. Model views work well for both practical implementation in daily practice, and for certification. Why do we need to “see everything.” What does this even mean?

Hmm, I disagree. In IFC, the geometric representation of a product is decoupled from the product itself. It is very easy to make a viewer that can display everything, and this is one of the strengths of IFC. All products uses the same Body Geometry concept for their geometric representation, so it is very easy to create a viewer that can display everything. The only thing I’m pointing out, is that you need to know about the type. The application can’t display an IfcRoad or an IfcOutlet unless it knows that they are subclasses of IfcProduct.

But the Body Geometry of a product can be made by many different geometrical classes. Advanced modeling applications may use advanced geometry (IfcAdvancedBrep for example), while others may not even be capable of displaying this and would thus prefer getting the geometry as Tesselated geometry for example. Maybe this is what you talk about when you say that it isn’t technically possible to display everything? But I think this is a completely different discussion.

[DrShawnOKeeffe]

I meant the full IFC “data model”. Not a geometry related statement by me.

It is not feasible to serialize an IFC-SPF with a representation of the full data model. This was neither the original intention of IFC in practical use, right?

I think we are on the same page!

[Helland]

Hmm, I also think we are on the same page. But I don’t understand what I and/or Jwouellette have said, that goes against the IFC mission. We’ve not said that the full project (infrastructure+architecture+analysis+electro+hvac+…) should be serialized into one single IFC file. But what we’ve said, is that it should be possible for an application to display the geometry from any other domains.

His example was that an architect application may get an IFC file with infrastructure (roads and site geometry) (again, not a file with “everything”, just “something” that is not within the scope of the receiving (architect) application). It should be possible to display the geometry of these roads and the site (aka. “everything” in that file), although the program doesn’t manipulate or use the information on this infrastructure for anything other than just displaying the geometry as a scenery around the building.

And with that criteria, I don’t see any room for modularizing the schema.

(In my first post, I actually explained that it should probably be made even easier to make a “project” consisting of multiple different IFC files that are related to each other, or are allowed to have relations to objects form another file.)

[ReD_CoDE]

I read all the comments and I think:

For me IFC is a combination of three things:

1. Geometry/Topology Elements
2. Data Elements --> bSDD (IFD)
3. Information Elements (Anything that structure and represents information, like Documents, …) "Modularity happens here"

And I think first of all we should decouple these three

With this view we will have some 2D/3D geometries that just represent geometry and Data and Information which are decoupled (Data and Information Elements which are so close to the idea IDM Toolkit suggests as well) can “mounnted on” 2D/3D geometries based on “Use Cases” etc

What I dislike in the approach IDM Toolkit follows and I think is mistake is that IDM Toolkit puts MVD before IDM (and part of IDM) but I put IDM before MVD and just see MVDs (Micro-MVDs) as results of IDM Elements processes

[Helland]

I don’t get the difference between Data Elements and Information Elements. Data and information are synonymous words. You need to be more specific and also explain your words better. I also don’t know what you mean with Documents.

And I don’t understand what you really mean with decoupling geometry from data. This is already decoupled, so you need to explain what kind of decoupling you are talking about.

And you use too many abbreviations that I don’t know about. I don’t know what IDM Toolkit is, and neither does Google. So please explain more if you want me to listen to your ideas.

[stefkeB]

If an application understands the higher level of the IFC scheme we can assume it knows about products, property sets, quantity sets, classification references, material resources. In addition, when importing IFC, the application will at least understand static BREP geometry and can (optionally) support the full set of STEP geometry (which from my experience no application really does - but I can be wrong).

Having abstract entities with Attributes and PropertySets is something that most applications might be able to represent, even though their internal data model is probably different from the IFC scheme.

This would allow read-only visualisation of models (e.g. the Bridge model that you would load/link from an Architectural design application), up to viewing properties, but no need to manipulate. Similarly, when you develop a Bridge engineering software, there is not need to support the full set of building classes, but when a building model is referenced, you are sure that it is positioned correctly and the entities are shown with their attached properties (even though you can not make modifications).

So for me, the modularisation is more about having a shared understanding by using abstraction instead of simply cutting the scheme in separate subschemas. In reality we probably have to do both (and are already doing that in the current scheme).

[ReD_CoDE]

Data Elements are like LEGO pieces that are ready for putting them together
If you putted them together then they are not Data, they become blocks/packages/elements as Information Elements (Molecularity then happens here)

A word only is a Data, but when you put it in a sentence it becomes part of Information because now has a “specific as well as structured meaning”

[Helland]

But you are still just describing the situation we already have today, and you don’t mention any problems with it. So what do you think is the problem that should be solved by modularization?

That is the problem with this discussion so far: There is no clear understanding of what problems we want to solve. And it makes no sense to talk about a lot of “solutions” if we don’t have a clear understanding of the problem.

[ReD_CoDE]

The main issue of IFC is that it really wants this happen, but is more flexible through its relationships that doesn’t let it be “explicit”

Through Information Elements bSI can provide this important goal

[DrShawnOKeeffe]

I guess the main points/issues with Modularization are:

1. MVD - Is IDM/MVD going to be kept in place? (My advice based on experience is, Yes.)

2. Certification - If above is No, then how do we proceed with certification for authoring applications? (To the best of my knowledge, the issue with this is the length of time it take to certify, Not the certification itself nor functionality post certification.)

3. And least of all Shared Domains Outside the Scope of Buildings - I do not see this as a problem. The current data model can support this. Actually by using 1 & 2 above. Can it not? (What are the limitations imposed by ISO 10303 STEP Parts and EXPRESS data model language that prevent IFC5 use and certification from being as we already have?)

I do not fully see the Need for the so-called “Modularization.”
(Can someone provide a clear Technical Example for th need of this Modularization? (Especially one that mar rents all the negative side effects of such a drastic change.)

[DrShawnOKeeffe]

@Helland

Hmm, I also think we are on the same page. But I don’t understand what I and/or Jwouellette have said, that goes against the IFC mission. We’ve not said that the full project (infrastructure+architecture+analysis+electro+hvac+…) should be serialized into one single IFC file. But what we’ve said, is that it should be possible for an application to display the geometry from any other domains.

Indeed, we are on the same page. I’m glad this is clear now so others know exactly what we are speaking about in relation to “everything.” For those less versed in model views etc may get the wrong impression. Maybe we can simply say display all geometry. Thanks for the clarification. Appreciate it.

[ReD_CoDE]

I again strongly say we need to focus on SysML because it gives a lot of great features to build structured structures for IFD and IFC

But even we insist on STEP, in 2017 version it gives us the ability to build “decoupled” objects and files that will open new doors to work on IFD and IFC improvements

[DrShawnOKeeffe]

…[quote=“ReD_CoDE, post:41, topic:2054”]
SysML because it gives a lot of great features to build structured structures for IFD and IFC

But even we insist on STEP
[/quote].,…

According to the ISO 16739, technically you can use whatever you want to represent IFC data…
Some MVDs are NOT to be delivered using STEP because to do so would actually have no purpose, i.e. that model view data is needed in other formats to be consumed by other machines, etc.

Or did you mean SysML as an alternative to EXPRESS as a modelling language?

[ReD_CoDE]

Let me explain the current issue and why we all have waited for further improvements

Dion asked a question a couple of weeks ago and many couldn’t understand what he says:

Creating federated IFC models

I am looking for ways to distribute a series of IFC models federated together into a “single file”. The most straightforward way of doing this, I think, is to put all the IFC files into a single .ifczip. I did not see any official documentation that disallowed this, but viewers don’t seem to support multiple IFC files stored this way (tested with XBim and BIMCollab). Another approach is by using references and anchors in the latest STEP standard, but again, no viewer supports this. This seems …

“Current” IFC dosn’t let we have federated files and (even I want have federated schema)

And why SySML? Because IFC just holds data and geometry, but with SySML as modeling language can be more advanced and flexible and can hold many great things like formulas, rules, etc that will cause the next generation of IFC

If IFC today is 3, with SySML becomes 7

[Helland]

I’ve probably not understood SysML correctly. But it is a dialect of UML. So it is a standard for how to model a system with diagrams. You can draw a SysML diagram on a whiteboard. And that diagram can define a data structure in which you can store building information and processes. But you cannot send SysML between applications. SysML isn’t a file format?

So I don’t see what that has with IFC to do? It could be a replacement for EXPRESS-G (the visualization of an EXPRESS schema), but not much more than that?

There is nothing stopping you from modeling any data (and also data structures for forumlas and rules) with EXPRESS.

I’m not saying that I like EXPRESS. But I just don’t understand what you will use SysML for.

[DrShawnOKeeffe]

“Or did you mean SysML as an alternative to EXPRESS as a modelling language?”

Dear Eshan,
Again you are not answering peoples questions?
If you would like to have a conversation/s with us, then we suggest you participate accordingly, versus the randomness in which you speak. At first I thought is may be google translator issues, but I’m sure now this is not the case.

If you want to warrant your claims, you must provide working examples, and not gibberish based on assumptions.

When you write to us, please also tell us clearly how it is linked to the context of the overall forum post, in this case “Modularisation.”

Kind Regards

[DrShawnOKeeffe]

@Helland

SysML isn’t a file format?

Indeed, you are correct from my understanding here. Simply an alternative to presumably EXPRESS/EXPRESS-G…This does not seem to have substance here in this conversation, unless further clarified.

What does SysML offer in relation to the topic at hand, i.e. better handling multiple domain models, etc.? …little to nothing it seems…