IFC Modularisation: current status and request for feedback

Developers Next-Gen IFC (aka IFC5)
#96

Interesting! :slight_smile:

Hi Thomas…always great to hear what you have to say on these matters.

Can you please provide 5 examples?

Can you please elaborate on “very basic IFC subsets, which are still broad enough to cover dynamic exchange requirements” ?

Should not MVDs be very concise and explicit for verification and validation purposes? (I guess more the validation part, since verification is simply check the format of the data and has no way of knowing if the information exchanged is what was required in the contract.)

If it’s basic and broad, how will one know if the requirements has been met? and How would one contract such broad and basic exchanges? Pretty vague in my opinion. I would not want to be the receiver of such model views…especially if I’m the owner, e.g. how do I know I’m getting what I paid for?

#97

Hi @DrShawnOKeeffe - always good to discuss with you.

Actually your answer goes to the heart of the necessary clarification! What do we understand about “verification and validation and (also) certification process”. Here (in my view) different people understand the same word very differently. Depending on the context in which it is used.

Here my understanding:

MVD is a software development topic, it is to defined the IFC subset and to implement it in software (as IFC interfaces today, maybe as openAPI in future), and the quality assurance of the implementation. Validation (as part of a certification ot software QA process) is to ensure, that sender and receiver of the information (according to the IFC subset) have the same understanding and that there is no data loss or misinterpretation. But an MVD is not concerned with the completeness of the content of the information.

Validation of the information exchanges is a user topic, it is to ensure that the creator of the submitted model has provided all necessary information for what he was contracted. So it is connected to the use case (or exchange requirement) for which the information exchange is required.

Of cause, the underlying MVD is the boundary in which a successful information exchange can be performed (in a way the eye of the needle). But the same MVD can enable multiple exchange requirements. So to answer your question - it is the formal (and computer readable) exchange requirement (based on a MVD) that has to be referenced in a contract. I would phrase it like this in a contract:

  • the party “A” is requested to deliver a BIM model according to the exchange requirement “abc”. The format of the delivery is “ifc mvd 1”.

This would separate the requirments on the content (the exchange requirement) from the requirement on the format by which it is delivered.

2 Likes
#98

Thanks for you explanations…Just a thought…

Me and others use a concrete cylinder as an example, i.e. the cylinder is the MVD and the contents (concrete) is what was to be exchange…BUT…

How do we know if the concrete is good? We test it to assure it was created per the specification/standard, and so we know we can consistently pour it on site.

In your case Thomas, I do not see the testing of the Concrete to be possible. “?” At least not in a standardised way. That is what we want right?

#99

I’m happy you clarified this

I’m not sure I understood your view about this or not?

In my view (to be challenged) we should not move away from MVD, but put MVD back head on feet. Meaning decouple it from the exchange requirements and restrict it to max 5? very basic IFC subsets, which are still broad enough to cover dynamic exchange requirements (ako LOIN).

Maybe I’m wrong but current IDM Toolkit/Configurator follows this view which I think is good

In my approach we will have just the whole model, based on the highest LoD(s), because everything happens inside the software, and everything is automatic as well as “programmable”

#100

[quote=“TLiebich, post:97, topic:2054”]
"Validation of the information exchanges is a user topic, it is to ensure that the creator of the submitted model has provided all necessary information for what he was contracted. So it is connected to the use case (or exchange requirement) for which the information exchange is required".

@TLiebich
Is this not the current problem?

Currently there are not many Validation methods, nor Automatic Verification tools.

The IDM/MVD should include this explicitly with an objectively tested and approved standardised method, right?

Also, I think this is incomplete for practical use. It does not specify the verified MVD, so folks can actually use it…e.g. It passed the verification tool testing with NO errors so we know machines/programs will read it. And, the Validation method that specifies how the user shall assure the information in the, e.g. IFC-SPF (could be different format, which should be specified too if that’s the case), is in fact what was contracted. We cannot leave this open to subjectivity. I believe the big issue we all are facing is the need to reduce/remove Subjectivity by creating 100% Objective methods where ever possible. It is 100% possible to do this with most design and construction deliverables, and where that information cannot be mapping to the IFC data model, the IDM simply says so and where does that warranted information lye.

"

  • the party “A” is requested to deliver a BIM model according to the exchange requirement “abc”. The format of the delivery is “ifc mvd 1”.

Here is a real example from a contract where I know this process/method I’m speaking of works. I can literally let files go out the door knowing the machine will read them first time, and the information within them are correct and validated by the person who actually created that information. This latter part is most important, but we can revisit it once Modularisation as spoken of here can assure these other issues are sorted first.

"ALL COBie data in every COBie file generated must be verified, which means the data must be in the correct format as per the COBie standard specification. 100% error free (Zero Errors – See Table 1) COBie QC Reports for Design, Construction, and Handover, as per the COBie standard specification and as required by the EIR and AIR, shall be submitted to assure the Employer this is in fact the case with each and every COBie deliverable specified.

COBie MVD example…
“ALL COBie files, drawings, and models shall be validated. For example, the information on the drawings, in-particular the drawing schedules (e.g. door schedules, valve schedules), must match the COBie data output. The COBie Design data output must be derived from the BIM model. Participants shall not copy and paste schedules on to drawing. ALL drawing schedules must be generated parametrically from the BIM model parameters in the design software. In short, the data in the drawing schedules must come from within the model elements’ parameters in the design software to assure that the needed COBie data in the COBie files are in fact generated by the Revit® COBie Extension.”

"NO XLSX formatted COBie files shall be filled in by hand in Excel unless approved by Contractor’s Project Information Manager.

A field validation check of the AIM and its COBie counterpart deliverable shall be conducted prior to handover, i.e. the Participant is required to check that serial numbers, warranty dates, etc. of the components, as per the AIR, installed on site match the AIM and COBie data handed over.

NOTE: For help with COBie QC see: http://www.lulu.com/shop/e-william-east-and-alfred-c-bogen/construction-operation-building-information-exchange-cobie-quality-control/paperback/product-22947013.html

The COBie QC for Design and Construction Handover appears as follows (as per NBIMS US V3 Section 4.2 COBie Version 2.4)"

"COBie QC for Design:

For the COBie Design Rule, the Participants must satisfy ALL COBie requirements by ensuring the following fields are populated as per the EIR and the associated Employer’s AIR – Contacts, Facility, Floor, Space, Zone, Type, Component, System, and Attribute. Document is optional, and Spare, Resource, and Job are N/A.

COBie QC for Construction:

For the COBie Construction Rule, the Participants must satisfy ALL COBie requirements by ensuring the following fields are populated as per the EIR and the associated Employer’s AIR – Contacts, Facility, Floor, Space, Zone, Type, Component, System, Spare, Resource, Job, Document, and Attribute."

"Handover – Tests on Completion - Contacts, Facility, Floor, Space, Zone, Type, Component, System, Spare, Resource, Job, Document, and Attribute.

NB: Participants’ attention is drawn to note that the following shall be included as ‘Tests on Completion”

a. COBie – XLSX for Design - 100% QC with zero errors

b. COBie – XLSX with Construction - 100% QC with zero errors

c. Field Validation Checklist demonstrating data provided matches to field installation

d. Model IFC2x3 CV2.0 MVD file and native (Revit) formatted models with matching As-Built Drawings as PDF demonstrating model matches COBie data and record drawings."

"COBie Handover Inclusions and Exclusions:

COBie scope inclusions shall be as set out in COBie Standard https://www.nationalbimstandard.org - Chapter 4.2 NBIMS US V3 pg. 219-220; exclusions for COBie, Chapter 4.2 NBIMS US V3 COBie Annex A pg. 71, and the COBie Responsibility Matrix.

See Appendix 9 below for pgs 219-220 of NBIMS V3.

Quality Assurance Matrix that shall be followed is detailed in Appendix 10"

I see a few issues I would fix in there, but overall, this person did very well with the knowledge they have. The files created for a Water Treatment Facility in Ireland using this method in the contact, was very successful. The files were read first time by the CMMS, and even IBM in Ireland said they were the best files they have seen to date. To be clearer on what they meant exactly, is that the files were the best in relation to Verification, not Validation - IBM could not possibly know if the information in the files were suffice to what was actually contracted.

I would also like to suggest that we be very clear about Verification vs Validation and one can see this clarity in ISO 9001… e.g. for this MVD in particular it looks like this for Design…"Verification: data in the correct format, e.g. ISO Date and Time used in title blocks etc.

Validation: Data = Drawings (Rule of Thumb), e.g. scheduled items volts on the drawings match that same data in the corresponding COBie file."

Of course in the contract it should even be more specific…I guess at that level specificity it should be given as Thomas says, by the User…e.g. in a BIM Implementation/Execution Plan saying how they will assure the deliverable are correct so they can actually get paid. At the end of the day all of this is about 2 things: 1. Assurance the Owner got what they paid for,…and on the other side that coin, 2. that folks get Paid. One should not be paid for a service that has no proof the service was done properly, hence, the Concrete Testing example. Surely we would not allow the concrete for the bridge to be poured if there was no field testing conducted, e.g. slump test, temperature, breaking of the cylinders, etc.

IDM/MVD should be no different than this, and any new technology brought to industry by bSI MUST adhere to these simple needs that the Construction industry has conformed, in the case of concrete 200 years of standardised testing.

It has been proven we can and should do the same with data using IDM/MVD. I mentioned this earlier in the posts above.

As for "This would separate the requirments on the content (the exchange requirement) from the requirement on the format by which it is delivered."

I’m not sure I agree with this in all cases of data/information exchange, especially where the format is critical for the success of the delivery as per the contract, e.g. the format must be only a certain type of formatted file, for a particular purpose, and to assure that file works it must be tested in the singular format.

Contracts and IDM/MVDs/Standards cannot be vague.

#101

Some countries have started Integrated Digital Delivery (IDD) projects nationally, so the way bSI and other standards were suggesting “someday” now is not “effective”

ISO and bSI just provide “bases” but countries and experts/leaders for sure won’t limit solutions to what ISO and bSI suggest

What you all are talking about “again” was good for BIM Level 2 projects, today “few” work on BIM Level 3, and “real” Integrated Digital Systems --> GIS+BIM+PLM

bSI has started to cover GIS+BIM and somewhat PLM when they work on PDT as part of PDM systems

However, anything is “dependent” to “national” projects and strategies and solutions

#102

Hi, I really see it as a two stage approach:

  • MVD is the first (or base) stage - few, international, general purpose, focussing on the software capability to guarantee loss-free exchange
  • ER is the second (dynamic) stage - more local, project oriented, specific, focussing on the capability of the design team to delivery the right information

here an example what I would anticipate in terms of validations/testing (as there is a long debate on right color exchange on the forum). Assume one wants to state in a contracted delivery, that all traversal reinforcing bars should be delivered as red in a BIM delivery.

  • MVD for colors

    1. Ensure, that all software interprets the color definitions in IFC the same (see concept templates - like)
    2. Ensure, that there is precise implementation guidance (e.g. about the precedence of geometry color over material color)
    3. Have unit test cases comprising all possible variations of IFC color definitions to enable full software tests
    4. Have a certification programme that oversees the above = this shall guarantee that the software, the design team is using, is able to carry the correct color information from the native software over into the neutral exchange file - *.ifc.

  • ER for colors

    1. formally define, that each instance of IfcReinforcingBar classified as traversal shall have a color "red assigned (this should be part of the exchange requirement definitions)
    2. have a way to express this in a formal rule (today mvdXML [attention: name is misleading, as the rule checking part is actually checking against exchange requirements])
    3. have checking software that can read the formal rules and execute them - showing all traversal reinforcing bars, that are not red “non complying” = this shall guarantee that the design team has delivered the contracted information exchanges according to the contract, as a prerequisite, they shall use software, that passed the MVD certification as described above.
1 Like
#103

Exactly. First level is that the concept of a brep (the idea of that kind of geometric representation i.e. in terms of mvdxml concept templates) gets harmonized between software products. Second is that I as an end user can say that e.g. I want only brep on roofs and either brep or extrusion on walls. The same principle works on any other concepts. First software products need to agree on how a property is written into SPF then as an end user I can say that I want Pset_WallCommon.FireRating on my Partitioning walls.

@DrShawnOKeeffe you are talking about this second level. The points you bring up are very important if data exchange is supposed to be meaningful. One thing that mvdxml should be able to do with ERs (my view) is to be able to pull the data from the authoring system. The authoring system should be able to deliver that kind of data if it is certified according to the official MVD that was used to configure the ERs. This way we could move away from exclusively Excel and PDF (not replacing as there is still a need for legal documents) based ERs and into the digital realm.

2 Likes
#104

Thanks guys! So what effects does Modularisation have on these two issues?

#105

Let me explain this in a way all can understand:

Let’s accept that IFC was/is GOOD ENOUGH for BIM, indeed OpenBIM!

Now, bSI properly has started to cover GIS and somewhat PLM (which was/is in its plans and deadlines)

So, today’s question is that: "IFD/IFC architecture/structure would be GOOD ENOUGH to cover all these huge areas?"

For instance in IFC4 bSI has worked with some Building Performance projects and has improved IFC schema in some areas like a huge improvement in MEP and also a huge improvement in LoD, but still IFC4 is GOOD ENOUGH in Building Performance area? What about GIS? What about PLM?

#106

Also, my suggestion that comes from Systems Engineering (SE) is redesign IFD/IFC architecture based on:

System --> Element --> Part

#107

Any news Leon?

1 Like
#108

Blogpost will be in today’s newsletter.

2 Likes
#109

Thanks Leon! :slight_smile:

Please provide the link here to the newsletter once posted.
I’ve signed up for bSI Newsletters but want to assure I get it.

Cheers!

#110
1 Like
#111

Thanks Leon.
Can you please explicitly define “dynamic exchange information requirements”? (Preferably without pointing me in another direction :slight_smile:

#112

Hi Leon, some positive movements ahead, however, I think it would be hard or even near impossible in the near future you control conditions based on MVD certificates, even if you limit them to 20.

I see a great movement when I see Dynamic exchange information requirements and I think the industry will use it more and more (MVDs can be structured or unstructured soon because you’re going to cover BIM Level3 and most importantly “Smart Cities” which inherently are “Dynamic”)

So, I think Modularization will help you control the quality of the IFC schema and its implementation and certification better, “if” your modules be based on:

  1. “Disciplines Modules” like: Architecture (ARC), Structure (STR), MEP (MEP), …
  2. and also based on some “Core Modules” like: Geometry, Material, Resource, …, “Product”
#113

Is not the real problem that the IfcRoad, IfcRail, etc. were all developed differently? and therefore not actually Aligned?

Wouldn’t it be better to fix this major issue, and then STANDARDISE the needed MVDs as ISO Standards versus availability and responsibility solely on bSI?

#114

@ReD_CoDE That modularization of the schema already exists.

@DrShawnOKeeffe While they may have been developed by different teams of people, they should still adhere to the same semantics and general hierarchical constructs.

The problem lies in how the numerous extensions have:

  1. created a number of new classes (objects/products, spatial, etc.) and
  2. further complicated the existing “shared” concept layers/domains.

As an example, ponder the following questions:

  1. If the IFC Bridge and IFC Rail have created new structural elements (or permutations of structural elements), shouldn’t the existing “building/architecture” and “structural” domains be reconsidered and have more classes moved into the “common” or “interoperability” layer and then those existing domains, as well as the new “bridge”, “rail”, “road”, and etc., being further specialized, containing fewer classes, so as to avoid duplication/overlapping? If so, then what do those look like?

  2. With the explosion of more applications used across a wide variety of hardware platforms and operating systems (including mobile/web-based), how can we look at the refactoring or (re)modularization of geometry in the schema to better support consistent, reliable results in the variety of implementations across a growing number of workflows? For example, should we have a basic, common BREP geometry “module”, and an advanced CSG/parametric “module”, where either (or both) can be specified for use in an MVD?

This then impacts implementations by doing the following:

  • Application developers can decide which process/functional domains they want to support (architectural, structural, infrastructure, etc.) for internal data modeling and export (importing applications would assume to support representation of ALL domain classes fro viewing);

  • Application developers would also decide if they were to support the import/export of BREP and/or CSG/parametric geometries associated with those domains;

  • Software certification would be based on unit testing an entire domain, or combination of domains, based on their pursuant workflows (building design vs. railway design vs. underground utility design vs. structural analysis vs. mobile device viewing app vs. …). So an example might be Vectorworks Architect certifying on full EXPORT of the architectural/building and site/landscape domains, including CSG/parametric and BREP geometries, but only certify for BREP IMPORT of MEP/building services, while BIMTrack would certify on IMPORT of all domains using BREP geometry but SOLIBRI might certify on IMPORT of all domains and ALL geometric representations;

  • When application developers certify across the entire range of a domain or module, then MVD creators can have confidence that the applications will support any new MVDs very quickly and not require a ton of time and resources to create support for the new MVD, which varies from previous MVDs.

  • MVD developers could then better address software functionality and supported workflows by making decisions on more precise or more flexible scopes of included concepts. As an example, a more “general” Design Transfer View, where CSG and parametrics are ALWAYS included and BREPs are optional where advanced geometry cannot be created, can be specified versus a stricter Architecture to Structural DTV where CSG must be used and BREPs are forbidden. (a rough, example, I know, but I hope you get the point);

  • MVD developers can also create more MVDs outside of having certifications for every single MVD, especially at the international level, and can be more fluid/flexible in creating MVDs for specific market needs without significantly impacting the needs of all other markets.

  • Potentially, MVDs can become more fluid and be developed on an “as needed” basis, where BIM authoring software gives end users interfaces to create a new, job/process/application-specific MVDs “on-the-fly”, relying on the public information of the receiving application(s) to be able to accurately consume the new model. And, MVDs could be pull as much as push, so the MVD concept might originate as a request from an application (Revit users asks Tekla user for all structural steel columns and ONLY structural steel columns, using CSG or BREP, but no parametrics to use for referencing).

1 Like
#115

I think the missing part is “I TALK ABOUT SYSTEMS”

Current IFC has developed based on which ontology? Yes you explained it on Wikipedia

I talk about this hierarchical tree:
https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/inheritance-general-usage.htm

This hierarchical design maybe was good for “just BIM” but won’t handle a huge area as GIS+BIM+SomewhatPLM

Even STEP/EXPRESS (ISO 10303-239) today suggests some parts of the idea I shared:

Based on RDLs and SysML Modeling

So, I suggest to break this long and deep hierarchical tree and build it as “specific packages as Modules”

(I think Control+Product+Process extensions are not good choices for schema architecture, instead Systems --> Elements --> Parts are

In Systems Engineering “Control+Product+Process” are “Elements and Parts”

And I think current IFC with SE view has this architecture: Just Element --> Part
The missing part is dividing schema based on “SYSTEMS”)

Yes, here all “Modules” are decoupled “on paper” but IFC schema as a whole does support this structure?

image
image560×600 42.9 KB

This is why I suggest:

Decoupling the whole schema on modules as systems/disciplines and core modules

Then you can build:

Concept Usage + Module Usage matrixes and Concept Usage + Entity Usage matrixes

Also please see these two as well: