- Watch out
- What it costs
- Experienced readers
- Remember
- In BIMpedia
Everyone makes mistakes in a model. What matters is who finds them. When you find a missing fire rating at your desk, it takes two minutes to fix. When the fire engineer finds it during a review, it takes a meeting, a re-issue and a week. ISO 19650 puts the check before share for exactly this reason: it belongs to the team that produced the work.
The architect shares the model on Friday. On Tuesday the coordinator's IDS check fails 7 of 10 requirements. The model is rejected, the clash tests wait a week, and the structural engineer has worked against a version that's now withdrawn.
On Thursday afternoon the architect runs the project's IDS file against the export. Six walls on level 1 have no classification (a level copied from an old template) and three doors have no fire rating. Fixed in an hour. The shared model passes, with a note: "IDS 10/10, no proxies, coordinates checked."
Check against the project's own rules
- 1Prepare in work in progressMandatory
The task team finishes the model it is responsible for.
Output: A model file named to the project convention
Gate: Self-check done: name, coordinates, purged views and links - 2Check the information
Run the agreed checks: requirements (IDS), naming, clashes inside the discipline.
Output: A short check report
Gate: Every failure is fixed or listed as an agreed exception - 3Share for coordinationMandatory
Move the file to the shared area with a status code that says what it may be used for.
Output: The model in the shared area, with a status code
Gate: The status code matches the purpose (e.g. coordination only) - 4Review and authorise
The lead appointed party reviews the federated set against the plan.
Output: Review comments, or an approval
Gate: Approved by the person named in the BEP - 5Publish and record
Approved information moves to published, and the previous issue to the archive.
Output: A published revision and an updated register
Gate: Register and transmittal updated
A gate is the question a reviewer asks before the next step may start. If the answer is no, the model goes back one step.
The checklist is not yours to invent. Use:
- the IDS file or LOIN the client issued,
- the naming rules from the information standard,
- the agreed coordinates (one or two control points),
- a quick look at classes and storeys after export.
IDS (Information Delivery Specification) is a buildingSMART format for requirements: "every door must have Pset_DoorCommon.FireRating", "every space must have a name". A checker reads the IDS and the IFC and reports which elements pass or fail each requirement.
Read the result by cause
A long list of failures looks frightening. Sort it by level, type and requirement and it usually collapses into a few causes:
| Pattern | Likely cause |
|---|---|
| All failures on one level | A copied level or an old template |
| All failures on one type | The type is missing the property |
| Every element fails one requirement | An export setting or a misspelt property name |
| A few scattered elements | Genuine gaps: fix them one by one |
Open the IDS Checker on the sample. The BIMpedia Clinic is checked against its ten requirements.
- How many requirements fail?
- Group the failures by cause: which are probably one cause each, and which are scattered gaps?
- What would you write in the note when sharing, if you fixed everything but the manufacturer?
Key takeaways
- Self-checking is the 'check' in ISO 19650's WIP to shared step: it belongs to the team that produced the work.
- Use the project's own requirements (an IDS file or the LOIN) as the checklist, not your own guess.
- Look at failures by cause, not one by one: one wrong export setting can fail a thousand elements.
- Record what you checked with each issue, so the reviewer can trust it.
Your notes
Related tool
Check an IFC model against an IDS file and see which elements fail, and why.
Open IDS Checker →