🗞️Digital Quality Management for IFC Projects
by Tobias Schmidt, TUV SUD
Last updated
by Tobias Schmidt, TUV SUD
Last updated
© 2024 Autodesk Inc.
About the Author:
Tobias Schmidt is a renowned expert and BIM Director at TÜV SÜD. TÜV SÜD provides BIM Consul- ting and Advisory via a global network of experts who combine technical building know-how, busi- ness and process consulting expertise, and technology experience. BIM Consulting and Advisory by TÜV SÜD helps you to define the best feasible and profitable BIM strategies to implement proper Exchange Information Requirement (EIR) and BIM Execution Plan (BEP) as well as to optimise CAPEX and OPEX of your building.
The use of IFC is particularly interesting for those appointing parties – or building owners - who want to rely on a universal project implementation of BIM. The universal tactic of an IFC application can be triggered through various project strategies: a short-term project approval is incapacitating the appointing party to formulate an individual BIM strategy, or the technical procurement has identified the best project feasibility and the highest project attractiveness when different software solutions are implemented, or the Project Information Manager has defined an information model to rely on a generally recognized standard.
For both appointing and appointed parties in a BIM project, IFC as a data medium has the potential to streamline the entire information management process: information models that have already been created from a software application can also be used by other systems without investing a lot of manual effort in duplicating, repairing or completing information models. This quality measure, in turn, is achieved when the overall project strategy and the entire Information Management are adapted to fully support IFC as a deliverable and the matter of open BIM as a project work culture.
TUV SUD has recognized, that “I want IFC” from the appointing party and that a click on “Export to IFC” on authoring and coordination level from appointed parties, such as technical consultants and contractors, is not a sufficient quality measure to achieve a very best IFC. Looking into the Information Management described in ISO 19650, it turns out that IFC is not just a data format. IFC means a well-structured, aligned, and synchronized work culture among all stakeholders, across all trades, and along the entire project or asset lifecycle.
The successful IFC use is guaranteed if the building owner, as the appointing party, and all the appointed parties jointly set up solid information management in BIM projects that supports IFC quality:
- Clearly define overall IFC requirements at the start of the project: because the IFC standard has now grown to a large „data ecosystem“ with many options and different characteristics, appointing parties shall develop and integrate Exchange Information Requirements to define which use cases for the project and for the building documentation, using IFC, should be realized; the Model View Definitions developed by BuildingSmart (see „BuildingSmart MVD Database“) gives an insight into which project topics IFC can optimally support; Model View Definitions are part of every solid IFC project ‘ Exchange Information Requirements, because these MVDs log for appointed parties which elements from the various trades and specialist models are really required; MVDs create a very lean, clearly structured information requirement and avoid the need to transfer, manage and update all (and thus also unnecessary) information from all the involved trade models; both appointing and appointed parties benefit equally from an objective IFC model through defined MVDs, because less information in better quality strengthens everyone involved in the project
- Set up the IFC modelling in a jointly coordinated manner: for a well-coordinated, aligned information Model authoring, coordination, and handover via IFC, the BIM Execution Plan (BEP) and the Master Information Delivery Plan (MIDP) play an essential role; by means of the BEP and MIDP, the appointed parties take on the organizational and procedural BIM topics of the Exchange Information Requirements and document on a technical level, among other aspects, how all trades and planning participants create a jointly coordinated ‘federatable’ IFC model and work with it; BEP and MIDP also promote the coordination of all those involved in the planning before the model is created with regard to specific settings and processes (e.g. BIM coordination) in order to ensure that every trade and every party contributes to receiving a quality-optimized IFC export for the best possible overall IFC model; here are particularly important:
• Jointly agreed on project settings and modelling approaches in the respective native formats, which have a direct effect on the IFC trade or technical model quality by means of which the MVDs are implemented
• decide about export settings that are coordinated with one another so that each IFC trade model can be optimally integrated into the overall model in a time-saving manner and with the best possible data completeness (e.g. for collision checks, quantity and cost calculations, AsBuilt BIM documentation, etc.)
Common Information Management, instead of “mutually assigning errors”: during project processing, IFC “lives” primarily through joint creation, coordination and use of an IFC-based information model; it is important that all trades work together on the “common denominator” of IFC, both at the technical level and at the overall project level, so that the various appointed parties and involved specialists support each other to achieve the goals of an optimal IFC project; For appointed and appointing parties, when using BIM, the focus is on feasibility, quality in added value and implementation, as well as better productivity and the highest possible data completeness. ISO 19650 speaks about
• cyclical, defined information model submission from the appointed parties to the appointing party, for the purpose of appointing party acceptance
• yclical availability checks of reference information and of shared resources; generating information; complete quality assurance checks; review information (models) and approve for sharing
With these three ‘IFC best practices’, appointing parties and appointed parties can create the foundation for a solid, joint IFC application in projects. It is important that basic parameters such as IFC version (IFC 2.3, IFC 4.X), the Model View Definitions and the dedicated Use Cases including the relevant joint BIM model export settings are coordinated among all trades and project phases, so that the best possible IFC at both the technical layer and the overall project workflow level is enabled.
From the experience of the BIM team at TUV SUD, having audited and consulted on IFC projects across the globe, a total of three checking categories for the best possible IFC quality and “IFC Quality Essentials” can be derived. If these are observed jointly in the project, important - but of course, not all - aspects for a real open BIM culture are properly been implemented:
A project-specific, uniform model structure across all trades is important because, especially when using IFC, this item is the basis for all trade models to be coordinated with one another, e.g. for the creation of federated models as a basement to perform cross-trade use cases, such as quantity take-offs, clash detection etc.
Only If the model structure, including the naming of the parameters (IFC PSets), of all technical models involved in the project is uniform and consistent in accordance with ISO 16739 and BuildingSmart nomenclature, the federated models can be created with as little data loss as possible.
Risk values in this area have the effect that the IFC models cannot be used for automated design reviews and for technical applications, e.g. fire protection, calculations of pipe and sewage networks, energy calculations etc.
Here are some IFC checking best practices from TUV SUD to ensure your IFC models are set up for a project-specific, uniform model structure across all trades:
• Identical Common Project Basepoint: each discipline model should have the same global positioning. This is reflected by the model‘s Longitude, Latitude, Bottom
elevation and rotation to True North; a common project base point the very first quality item and most essential towards the coordination and ‘checkability’ of a discipline model
• There shall be only one – and not several – IFCsite instance in each project; if a project is defined by more than one IFCsite instance, it cannot be guaranteed that the trade models are coordinated by one physical measurement point
• Ensure that there are only unique GUIDs in all the trade models and that there is no doubled GUID in one of the IFC models, which would indicate doubled elements, ending e.g. in false quantity take-offs and in unclear responsibilities e.g. towards clash cleaning
• When it comes to geometric integrity, check that there are no 2D objects integrated (or left) in the IFC models, as 2D elements do not accurately represent the geometry of the individual elements, and also 2D elements are not exhibited during the clash detection
• Check the Grid Lines: Each discipline model should contain grid lines; trade models that are not standardized by a single grid system cannot guarantee cohesion
• No ProxyElements as components should be specified and found as IfcBuildingElementProxy; please consider a proper IfcEntity instead, to enable that further use cases, such as fire concepts, pipe/duct calculations and cost counting can be properly executed.
Harmonized modelling guidelines across all project IFC models are important, as this area is the foundation for proper engineering reviews that require a homogenous IFC setup to be passed on to manufacturing and engineering.
Risk values in the area of the modelling guidelines arise when the respective trade models of a project are structured differently, which leads to inconsistent, incoherent IFCs, so that continued use of the IFC models, e.g. for the construction phase and for operation, is unsuccessful.
With the following few checks, it is easy to create a cross-trade common IFC quality on modelling level:
• Reasonable offset to host storey: check that all components are created within a reasonable offset to its host storey, which you can easily check when specifying and code checking with a project-relevant setting
• Validate that all hosted components have a geometry: components thatthe are decomposed by other components must have a geometrical representation
• Check that host component may not have geometry: components that decompose into other components may not have a geometrical representation
• Storey heights within limits (customized assets per each project) are also a criteria to check for proper Model Integrity, as checking distances between intermediate slabs (= storey height) is recommended to see whether slabs, selected by using the IFC Entities classification, indicate that the project is really modelled floor- wise; a very relevant general VDC item
• Check the Sum of Material Layer Thicknesses (Total Component Thickness); this check ensures that the sum of the material layer thicknesses is equal to the total component thickness; if the total material layer thickness of components is not equal to the geometrical thickness of the components, there may be problems in original modeling of the components, or in exporting of the component.
• Avoid bulky and too-detailed models: check that the geometrical representation is not too detailed, to ensure that the project does not include components with overly detailed geometry which is indicated by a too much detailed LoD (Level of Development) which results in a very slow authoring or coordination affecting in weak project productivity; you can set a maximum number of polygones suitable for your project and then let Model Checks run through each component to detect too many Polygons per Object Component
• Check that the Material of Decomposed Components is defined (only) on the component level to indicate decomposed components (assemblies); that is important to extract correct quantity take-offs and correct material definitions
• Analyse that MEP components within the IFC model/s are connected to at least one other MEP component and that any MEP component is part of a system; this rule checks if all MEP components are connected to at least one other MEP component, which indicates that there are no undetermined or non-connected items, which would effect on Quantity Takeoffs and indicate that there are elements in the IFC models that are not (yet) part of a well-coordinated functional system
• Architectural model should have spaces: check that the architectural model/s contain/s space components and that every ‘space’ has a unique identifier; that avoids doubled or overlayed spaces which, in turn, would affect false spatial quantities and incorrect room books later
• Openings in Complex Walls should be related to the wall, not to one element; openings in an IFC modell that do not completely cut through a multilayer wall run the risk of creating uncoordinated openings
Uniform and well-structured information requirements are the basis for reliable information transfer between trades and to further life cycle phases, e.g. for BIM- based tenders, maintenance optimization or Design for Maintainability, Schedule Management, etc.
Quality errors occur the risk that uncoordinated, missed, or non-aligned information leads to misinterpretations, duplications, and incorrect information, especially for BIM use cases that involve several disciplines and that are relevant for numerous life cycle phases, such as Design-to-Construction use cases or those ones for Construction-to-Operation.
To get a basement of IFC quality in the area of Information requirements, start a check for the following items and extend the checklist by project-specific additional validations:
• Correct PSets: check that each element of the IFC trade model/s is defined with its correct PSet and that – initially - no individual property nomenclatures or property contents are added or overwritten; PSets as defined in the original BuildingSmart IFC documentation ensure that BIM projects start smoothy and well-coordinated, to avoid some trade models are initially developed by BuildingSmart PSets, while other might already contain unique property structures or contents, which would then disable general information exchange and information processing on federated model level; as a help, check if components contain default ProperySets starting with „Pset_“ and take a closer look to all those items missing “Pset_” at the start
• Enable that each component is be defined by an IfcEntity, as that is important to properly work with the IFC Classifications according to ISO 16739 later on; in terms of IFC, layers and classification are not properties but actually ‘entities’; any entity is associated to other entities like IfcBoiler, IfcBuilding or IfcSpace through those important relationships
• Check that each component is be defined by an IfcType, as wrong or undefined types disable most of the BIM use cases
• Ensure that every component has a property “IFCAsset”; elements that are not defined by IFC Asset ID parameter/s are not identifiable to the Facilities Management
• Validate that each component is classified according to the IFC Type classification of BuildingSmart
• On the attribute level, ensure that each component has a name, a Type, and Material information, which adds usability of the IFC Project Information Models through clear human and machine-readable information, which is important to automate workflows e.g. with other programs or with Model Checkers
• Cross-check the Exchange Information Requirements and the BIM Execution Plan of the project with the applied generic IFC properties so that every required IFC property is present and also properly filled, e.g.
- AcousticRating
- FlammabilityRating
- ThermalTransmittance
- LoadBearing
- FragilityRating
- FireRating
- etc.
• For accurate Quantity Takeoffs, check that the relevant IFC QuantitySets are present in every trade model and every relevant element, and also that the content is of the QuantitySets is accurately defined by the authoring tool (and not by human hand!); as an example, to extract proper Quantity Takeoff for walls right form the model, the following setup shall be checked: Pset_WallCommon. LoadBearing = TRUE and Pset_WallCommon.IsExternal = TRUE; also, check for the following consistencies:
- Consistent Component Properties
- Component Thickness Must Be Consistent
- Component Profiles Must Be Consistent
- Door and Window Dimensions Must Be Consistent
- Door and Window Top Elevation Must Be Consistent
- Wall Height Must Be Consistent
- Column Length Must Be Consistent
- Component Elevation Must Be Consistent
- etc.
• Check that all project-relevant Pset_BuildingStoreyCommon properties are onboard: as a basic Virtual Design & Construction (VDC) measure, every IFC model shall be developed storey-wise, to drive both design analytics and documentation use cases forward; take into account that several building attributes of Pset_BuildingStoreyCommon are handled directly at the IfcBuildingStorey instance; examples of important Pset_BuildingStoreyCommon properties are:
- EntranceLevel
- AboveGround
- GrossAreaPlanned
- NetAreaPlanned
- SprinklerProtection
- SprinklerProtectionAutomatic
- Pset_BuildingStorey BaseQuantities
- NominalHeight
- GrossFloorArea
- NetFloorArea
- GrossVolume
- NetVolume
• Enable all relevant IFC models contain Compartmentation: checks that the components have property Compartmentation; missing Properties indicate …
