[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".
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.