Model View Definition (MVD)

A Model View Definition (MVD) is a focused subset of the IFC schema, designed to streamline data exchange for particular purposes or processes by tailoring the data scope to meet the recipient’s specific needs [14,15]. Often referred to as an IFC-filtered view, it allows users to extract specific segments of model information that address particular needs [16,17]. Instead of exporting the entire model, users can choose a preconfigured IFC export, such as the Energy Analysis MVD, for tasks like energy analysis. This targeted export includes only the essential information needed for the specific purpose. The concept of MVD provides three core capabilities. First, it involves selecting a subset of the IFC schema relevant to a specific objective [18]. Secondly, it enables additional constraints on the selected subset, enhancing its applicability and relevance. Lastly, MVDs involve defining the expected level of software implementation needed to support the chosen subset of the schema [14].

Users frequently encounter confusion since an IFC dataset is fundamentally built upon an MVD. This confusion arises from the inability to seamlessly interchange datasets constructed from different MVDs. The interoperability between various MVDs cannot be guaranteed, hindering seamless collaboration between diverse software applications. Each MVD necessitates separate implementation as a distinct feature within software tools, which can limit the scalability and versatility of this approach. Moreover, the monolithic structure of IFC means that consensus must be reached across all stakeholders before a new version of IFC can be introduced, which can impede swift progress [19].

4.1.   Existing MVDs

Software tools can implement MVDs and need to approach buildingSMART for certification. Listed below are the most common MVDs. A complete list of MVDs can be found on the buildingSMART website.

4.1.1.     Coordination View CV 2.0

Coordination View Version 2.0 (CV V2.0) in based on IFC Schema 2x3. It is developed for coordination of models between architectural, structural, and mechanical disciplines and is the most implemented MVD in the construction industry.  In this view, the elements are represented by specifying the boundaries of spaces they occupy, meaning they are represented by extruded areas. Hence, it represents both linear and planar elements as volumetric objects.

It is designed to show basic information about building parts, like their location and borders, for coordination purposes. This method does not focus on how the parts are connected, so no connection details are included. The parts are shown touching at their ends without overlapping. Models in this view do not contain any information about the mechanical properties of materials, except for their names [20].

4.1.2.      Structural Analysis View

Structural Analysis View based on IFC 2x3 TC1 has been developed to represent the information related to structural engineering, such as loads and load conditions, boundary conditions, constraints, materials, and connections between the elements [21]. In this view, elements are depicted as simple lines for linear elements and simple areas for planar elements. The cross-section and thickness information specify their dimensions. Elements are represented by interconnected nodes: linear elements use two nodes, while planar elements use more than two nodes [20].

4.1.3.      IFC4 Precast

IFC4Precast is based on IFC4 ADD2 TC1 Schema and is developed for the precast industry to enable information sharing between the CAD, MES and ERP/PPS Systems for automated production of precast building components [22].

4.1.4.      Design Transfer View

Design Transfer View is based on IFC4 ADD2 TC1 Schema. It is a successor of IFC 2x3 Coordination View CV 2.0 and supports interconnected elements and insertion point alignment for structural elements [23]. The documentation for this MVD is still in draft stage.

4.1.5.      Reference View

Reference View is based on IFC4 ADD2 TC1 Schema and is a subset of IFC4 Design Transfer View. It is developed to be used for reference workflow in which a model is imported as a read-only file. This View ensures intellectual property rights of the originator as it cannot be modified [23].

4.1.6.      Space Boundary Add on View (SBAV)

Space Boundaries are needed to support different tasks like energy calculation, lightning calculation, indoor navigation, quantity take-off and facility management.  Therefore, Space Boundary Add on View is developed on IFC 2x3 TC1 Schema to attach space boundaries to building elements [24].

4.1.7.      Basic FM Handover View

This view covers all the data exchange needed for the design, build, and operate stages, including architectural design and construction details for facility management, mechanical, electrical, and plumbing design and construction details for facility management, inventories from surveys or previous facility management handovers to facility management [25].

This view is based on the Coordination View, already used by most major AEC CAD vendors. It can be divided into three sub-views:

• Architectural BIM model information to CAFM (Computer Aided Facility Management) model information

• MEP (Mechanical, Electrical, Plumbing) model information to technical CAFM model information

• Model information from existing inventory databases (a subset of CAFM) to CAFM model information

4.1.8.      COBie

Construction Operations Building Information Exchange (COBie) defines when, how, and what data needs to be captured for FM purposes. COBie is not listed as official MVD in buildingSMART as it is based on a US standard rather than an international standard. However, it is still based on IFC Schema and has almost all the elements available in the coordination view except the geometric data. COBie is an MVD for the exchange of data to support facility management by owners and operators and is typically delivered as a spreadsheet. It defines a list of maintainable types and objects. However, an understanding of this definition also requires an understanding of the IFC classes defined in the specification [26].

A COBie UK 2012 workbook consists of 20 worksheets, including an instruction worksheet. Each worksheet is defined to contain a specific type of information. The structure of the worksheets is predefined, with fixed column locations. The types and formats of data that can be used are specified in the “Picklist” worksheet. The data between the worksheets is connected using colour coding [27].

The process of capturing and checking the data at defined stages is known as “data drops.” Data drops involve generating COBie files at different developmental stages of a project to track, control, and create an efficient facility management data deliverable during the handover stage. This process includes extracting COBie data at predefined stages and checking it against set benchmarks and requirements documents. Different authors and organisations describe the stages of data drops in various ways. For example, East [28] identified the data drop stages as as-planned, as-designed, as-constructed, as-occupied, as-built, and as-maintained (six stages). Meanwhile, East and Carrasquillo-Mangual [27] mentioned only four stages for data drops, defining them as design development deliverables (35% design), construction document design deliverables (100%), beneficial occupancy construction deliverables, and as-built construction deliverables.

Challenges with COBie

Various Studies have been done around COBie which have highlighted the following challenges.

• Data Capture is based on manual data entry and is prone to errors and duplication. It lacks automation in generating specific attributes for different building elements and consistency checks, which creates significant additional effort and potential for data mismatches between the BIM model and COBie sheet [29–32].

• COBie faces challenges with data consistency due to errors from post-export modifications, unaddressed semantic relationships, and inadequate verification tools that mainly check format and simple links rather than the logical correctness of data dependencies, adding significant verification burdens for BIM modelers [31,33].

• Current COBie practices inadequately address how data evolves throughout a project, leading to significant changes in data values, relationships, and entries between phases, and the existing data drop process lacks mechanisms for meaningful tracking and analysis of these changes. Hence, it lacks visualisations and query capabilities.

• There is a lack of understanding about the real usefulness of the COBie datasheet, how they benefit FM handover, and its usefulness beyond FM [34,35].