Checking IFC with MVD Rules in Infrastructure: A Case Study ^†

Building information modelling (BIM) is getting increasingly used in practice as a method of consistent and continuous usage of digital information in the design, construction, and operation of buildings [1]. During recent years, the infrastructure sector of the architecture, engineering, and construction (AEC) domain has been introduced to the previously established workflows, processes, and data models to focus on the building sector [2,3]. This contribution showcases a typical workflow as applied to a bridge model, i.e., the quality checking and quality assurance (QA/QC) of digital information delivered during the design phase. We present the QA/QC process, report lessons learned, and conclude with an outlook.

A very important aspect of any information flow is ensuring received data’s compliance with predefined requirements (see Figure 1). In the world of BIM, the Exchange Information Requirements (EIRs) lists all necessary information to be delivered at handover, i.e., every element with its attributes, attribute types, as well as constraints to values in attributes. The information author produces a BIM execution plan (BEP) which details the EIR as applied to the project considering the software solutions employed. The model is submitted in an agreed format, e.g., a vendor-neutral non-proprietary data in an Industry Foundation Classes (IFC) format [4]. Checking rules shall be derived from the BEP and encoded using the open data format mvdXML. The rules are used for automatic model checking of the delivered data from the BIM modelling process. Identified issues shall be reported back to the modeler using the BIM collaboration format (BCF) data format.

We showcase the QA/QC process on a bridge model from Sweden. The requirements were defined before the design commenced and shared with the design firm. For example, the EIR requires the length of an edge beam Längd (kantbalk) to be provided for the asset management system used by the agency. The BEP foresees this information to be provided within an IFC dataset, attached with a property set to an IfcBeam element. The property set is named ePset_BaTManKantbalkOccurence and the property K35: Längd (kantbalk).

The corresponding checking rule in the mvdXML is presented in Figure 2. It checks that the type of the property’s value is a length measure next to the correct naming of the property set and the property. The model submitted to the stakeholder is checked against the requirement with the following result. Out of 15 beams in the delivered dataset, 13 pass and 2 fail the described check, since they do not have the specific property set attached.

The example and the checking rules are prepared in the current official IFC4 version of the standard [4]. The scope of this version is building related with limited support for the infrastructure domain. Thus, many modelling decisions in BEP are suboptimal, which can frequently and knowingly involve misusing an established concept or an IFC entity. The spatial container for the whole bridge is chosen to be IfcBuilding and showcases a work-around for the lack of better alternatives, whereas the railing of the bridge modelled as an IfcRailing, for example, demonstrates good practice. Additionally, many elements are modelled using the placeholder entity IfcBuildingElementProxy and classified using less than ideal concepts, e.g., properties for objects defined in this project.

The IFC standard was expanded over the course of the past few years to provide better support for infrastructure specifics [3]. The authors call for its fast adoption in the industry to ensure semantically rich exchanges with little-to-none work-arounds needed. This can provide a sound basis for QA/QC in the infrastructure domain of the AEC industry.