Check and Validation of Building Information Models in Detailed Design Phase: A Check Flow to Pave the Way for BIM Based Renovation and Construction Processes

Abstract

Model checking of building information models is gaining interest for academic and industrial fields. However, several limitations can be identified in the practical application of model checking processes. One of the main limitations is the unavailability of detailed guidelines describing how these checks should be developed. The research presented in this paper focuses on the development of a check flow that can be applied to any type of building project answering to three main questions, namely what to check, when to perform the check, and who should perform the check. During the research a complete guide for checking activity has been developed identifying the subjects responsible for each specific check during the process. The proposed check list has been tested using a practical case study where the checks have been applied to a real model using commercially available checking tools. The results of the process have determined the need to streamline the proposed flow through a risk management analysis that allowed the definition of two other flows, optimized for achieving prefixed purposes. The research has been developed focusing on a specific phase of the construction process that is the detailed design authorization. Nevertheless, the results can be extended at different phases providing a good support both to clients and public administrations during the validation and authorization phase, and to the designers during the development of the project as an iterative checking process. The results presented in this work can pave the way for the integration of structured and standardized checking processes improving the overall quality of the construction process. This work has been developed and intersected with the activities of the H2020 BIM4EEB project considering the need to pave the way for the creation of quality models to facilitate the development of BIM based renovation processes.

1. Introduction

As known, the release of authorizations from municipalities is based on the satisfaction of minimum requirements defined by the law, regulations, and standards, etc. In addition, detailed projects must also comply with a series of indications and minimum contents, defined by the client and/or by local regulations (for example, in the Italian context, the code of public contracts requires plans of the various floors on a scale of not less than 1:100, cross-sections and longitudinal sections on a scale of not less than 1:100 with measurements of the net heights of the individual floors, the thickness of the floors, and the total height of the building, etc.). In public works the compliance with these additional requirements is mandatory according to regulations in force, while, in private works, it is recommended in order to optimize the quality of the process. In this scenario, considering the BIM model as the centralized digital entity on which the entire process is based and from which the traditional 2D and 3D views are extracted, the model must also guarantee the compliance with specific standards and quality requirements. Hence the need to check the BIM models quality. However, it is difficult to find detailed guidelines about checking methods that can be used to control building information models. An analysis of the scientific literature highlighted the availability of documents containing general indications about checking methods, but none of them goes into details providing detailed technical prescriptions. Consequently, the appointing party, usually an “unaware actor” in the process [1] and unprepared for the use of advanced information tools, may be in difficulties by the need to perform a complete analysis of such a large and multifaceted digital model, forcing the appointing party itself to turn to third parties to carry out the activity or, in the case of private works, to completely renounce performing the analysis applying purely random model validation. This procedure, however, collides with one of the essential prerogatives of the BIM methodology, that is the full involvement of the appointing party in the process, who can no longer play a formal role within it, but has the task of being an active participant, both in the definition of the information needs and requirements and in the final assessment of their actual satisfaction [2,3,4].

It is crucial to meet the needs of the public and private appointing parties, providing a comprehensive (but not exhaustive) guideline to check and validate building information models supporting the completion of the detailed design phase in the construction process. Therefore, this research developed a check flow that can be applied to any type of building project, containing the list of checks deemed essential during detailed design phase for the validation of a BIM model by public and private appointing parties and for the definition of e-permit processes by the competent administrations. Since the check process is an iterative operation within the different design phases, the checks carried out by the design teams involved in the modeling process have also been included in the flow; therefore, the check flow can also be used as a support for the designers, who can use it to verify the quality of the BIM models according to clients and/or regulation requirements. Within this scenario, the model checking activity takes the form of a cycle, which begins with the checks by the designers, namely those who start the process, and ends with the contradictory check of the client, then start up again in the next design phase in the same way. It is worth mentioning that designers remain responsible for the quality of the BIM model delivered. Even if the customer has approved and validated the models, full responsibility lies with the design team, namely who made the mistake and not who didn’t detected it [5].

In a broader sense, the purpose of this publication is to support the evolution of clients skills in the context of BIM model checking, paving the way for the development of autonomous (or semi-autonomous) checking and e-permit processes. The guideline developed in this research can support the creation of the necessary conditions to complete an ideal BIM process in all its phases, considering the active collaboration between the involved stakeholders (especially the client) with a consequent increase in the overall quality of the resulting construction.

The work presented here focuses on the Italian context considering the national regulations. Nevertheless, the principles here defined can be extended to other countries considering and integrating the specific requirements expressed in the national and/or local regulations. In fact, this research has been developed and intersected with the activities of the H2020 BIM4EEB project (BIM based fast toolkit for Efficient rEnovation in Buildings) considering the need to pave the way for the creation of quality models to facilitate the development of BIM based renovation processes. BIM4EEB is a European Horizon2020 project that aims at supporting environmental, economic, and social sustainability for buildings’ renovation works using an innovative BIM based toolkit, based on ontologies and linked data. The focus of the project is to develop a BIM based toolkit to be adopted in the renovation of residential buildings to make the flow of information more efficient, impacting on renovation time, average renovation cost, net primary energy use for a common residential apartment and working days required for a deep energy audit and simultaneously improving the conditions, quality and comfort for inhabitants.

The rest of the paper is organized as follows. Section 2 presents an overview of the main sector regulations to be respected in order to obtain the necessary authorizations to carry out the building and lists the main aspects of the project to be checked in public works, in order to ensure its high quality. Section 3 goes into detail about the BIM process by extending what has been said about project check also to building information models, introducing the concept of model checking. Section 4 proposes a methodology for checking information models, specifying what is important to verify and who should carry out the checks. On the basis of the considerations made in the previous section, Section 5 proposes, in a tabular format, a different check flow for each of the three responsible parties identified for carrying out the checks. Section 6 shows the application of the proposed check flow to a case study of a real project in progress while, in Section 7, the results of this application are explained, and the limits of the check flow are analyzed. Section 8 proposes a resolution of the problems identified through an optimization process of the check flow based on risk management principles. Finally, Section 9 and Section 10 conclude the discussion of the topic and highlights the advantages and disadvantages of adopting the proposed method.

2. E-Permit and Projects Check

The interventions of urbanistic and building transformation of the territory are subordinated to the release by competent administrations of specific authorizations, which must ascertain the quality of the detailed project delivered, as well as the respect of the sector regulations in force, including regulations about [6]: urban planning, seismic, safety, fire prevention, health and hygiene, energy efficiency and landscape. Each application must be accompanied by appropriate administrative documents, drawings and declarations issued by competent authorities (e.g., fire brigade, ASL, etc.) and by qualified technicians who asseverate, with signature, the compliance of the project with regulations in force. In Italy, the law that regulates the procedures for issuing these documents is the so-called “Testo Unico dell’ Edilizia” (D.P.R. n.380/2001) which, depending on the entity of the transformation, admits the existence of different authorization processes. The check flow developed in this publication will refer to the most complete of them, namely the building permit, so that it can be easily scalable in case of minor interventions.

In order to ascertain the quality of the process, the activity of projects check assumes fundamental importance. In the context of public procurement, this activity is made mandatory for each project phase according to the Legislative Decree 50/2016 [7], regardless of the economic value and type of the work, and must be carried out before entrusting the works to the contractor. In private contracts, however, the projects check remains an activity at the discretion of the appointing party since, to date, there is no regulation prescribing its execution. Nevertheless, project check represents a guarantee for the private client who intends to reduce the risks of variations and delays during the execution of the works. In parallel, the Italian Ministerial Decree 560/2017 (“BIM Decree”) has defined the modalities and timing for the gradual mandatory introduction of the BIM methodology in Italian public procurements, “in the design, construction and management phases of the works and related checks” [8]. Therefore, with this decree, the legislator has extended (within the time limits established in the document) what is reported in the Italian code of public contracts regarding the projects check also to works carried out with the BIM methodology, for which the model represents the main source of information. The importance of the information model is underlined by the same decree in art.7, which specifies that, from the mandatory introduction of BIM, “the contractual prevalence of the information content is defined by the information model” [8] and not by the paper documentation. In particular, in accordance with art.56, designs check must be carried out for each project phase against all the documentation produced, with reference to general aspects such as:

• Reliability: check of the coherence of the project hypotheses at the basis of the environmental, cartographic, architectural, structural, plant engineering and safety technical elaborations.
• Completeness and adequacy: check of the existence of all the documents required for the level of the project to be examined.
• Legibility, coherence, and traceability: check of the coherence of information between the various elaborates.
• Compatibility: check of the correspondence of the design solutions to the requirements expressed by the client in the design guidelines document or in the design documents produced in the previous phase.

It is precisely the underlying generality of these provisions that has provided the incentive for developing a list of checks with a greater level of detail than just mentioned, accompanied by practical examples, as the authors believe it is essential to define with greater technical precision the series of actions that the verifier must perform, in which order they must be performed, with the aim of making the check operations less and less interpretative and subjective and, at the same time, reduce the possibility of errors in the assessment.

3. Model Checking

In the exclusive context of a BIM-based project, the model checking process allows to check the models in order to ensure their correct validation by the designers and, ultimately, by the client. Generally, it is divided into three main consequential check phases [5,9,10,11]: BIM validation, which aims to ascertain the quality level and internal consistency of the model in order to ensure the extraction of reliable results in subsequent analysis; clash detection, namely the control of physical interference (collisions) between elements; code checking, namely the check of compliance of the model to the reference standards.

In Italy, model checking is regulated by UNI 11337-5:2017 (national annex of the ISO 19650 series) through the coordination levels and verification levels. In particular, coordination occurs through three main operations [12]:

• Analysis and control of geometric interferences (clash detection).
• Analysis and control of information inconsistencies (code checking).
• Resolution of detected conflicts.

Depending on the object of coordination, the standard distinguishes three hierarchical coordination levels [12]: LC1 is the control of the data and information contained within a single information model, charged to the author of the specific model; LC2 is the coordination of data and information between several information models and, therefore, between two or more different disciplines; LC3 is the control and resolution of interferences and inconsistencies between data generated by information models and data (digital and non-digital) not derived from BIM-authoring applications. Verification levels, on the other hand, although they can be confused with coordination levels, mainly concern procedural rather than disciplinary aspects [13]. Among these, it is important to mention the verification level V3, the only one charged to the client (who may eventually avail itself of the support of an independent third party), whose task is to perform the following check operations [12]:

• Interferences and inconsistencies check.
• Check of the achievement of the required levels of detail.
• Check of the application of the specific standards and technical rules of reference.
• Check of the comprehensiveness of the information content produced in relation to the requirements expressed in the Exchange Information Requirements (EIR).

Even in this case, the basic generality that characterizes the provisions just reported has highlighted the need to develop a more detailed and in-depth list of checks to help the client. It is important to underline that V3 corresponds to the phase of the process in which the client performs, at the end of checks, the validation of designs and models [13].

To support the verifier, model checking software are available on the market and able to analyze in an automatic way the quality of BIM models through the use of rules preset by the user, with which to examine both single disciplinary models and a combination of the same within a single federated model, consisting of entities that can also have origin from different modeling programs (e.g., Revit, Allplan, Tekla, Rhyno, etc.) [14], provided that they are properly exported in the same open format (e.g., IFC [15]). The functioning of these rules is guaranteed by the use of information objects, which have associated to them all the necessary data for their automatic identification within the model. This possibility opens the way to an important change of mentality. If in a traditional process, in fact, any control can only be performed on a sample basis, in a BIM-based process the possibility of automatic or semi-automatic implementation of the checks allows much more extensive analysis [16]. In this regard, it should be considered that “in standard design processes, just the 5–10% of the project informative content is systematically checked. Model checking leads to an automated validation of 40–60% of the design, by following specific checks rather than sample checks” [9]. The possibility of creating and reusing, within the model checking software, a database of tested and reliable rules makes it possible to add the characteristic of repetitiveness and objectivity to the checks to be carried out, thus guaranteeing the standardization of the process, with a consequent reduction of the margin of error and shortening of the time necessary to complete the check process [16,17]. In order to fully exploit the potential of a model checking software, it is necessary that the project and the relative three-dimensional models are entirely realized with a BIM-based approach and that they contain, therefore, all the information required in the specific design stage.

The world of model checking has been and still is an object of interest in the scientific literature. In 2020, Sydora et al. [18] developed a domain-specific language for representing building interior design rules and applying them to a BIM model. With the same logic, in 2019, Nawari [19] developed a Generalized Adaptive Framework (GAF) for IFC neutral data standard that enables automating the code compliance checking processes by transforming the written code regulations and rules into a computable model. A new model for the computable representation of building codes was also proposed by İlal S.M. in 2017 [20], by Park S. et al. [21] and by Lee H. et al. [22]; in particular, the latter described an approach to translate the written content of the Korean Building Act into a computer-executable format for the purpose of evaluating building permit requirements. With reference to building permits, Narayanaswamy et al. [23] developed a prototype to automate municipal bylaw and wall framing code compliance checking for residential building and demonstrated its benefits compared to manual checking; Kim et al. [24], instead, developed a prototypical system for an e-submission process based on the IFC data model, performing code checking, submission, pre-checking, and automated rule-making. Many authors [25,26] have instead addressed the issue of the BIM data validation against the requirements of the Model View Definition (MVD), a subset of the IFC schema. The application of model checking analysis to specific sectors of the construction industry was examined in depth by Soliman-Junior et al. [27] in the field of healthcare design and by Ciribini et al. [28] with regard to residential construction, in both cases involving the use of Solibri Model Checker for validation; Acampa et al. [29] and Häußler at al. [30] investigated the complexity of infrastructure sector validation, while Jiang et al. [31] that of the field of green construction; with regard to timber building, Kincelova et al. [32] concentrated their studies on the automated check of fire safety regulations, while Ventura et al. [11] took care of the translation into a parametric rule-set of the Italian construction health and safety normative text (D.Lgs. 81/2008) with the aim to propose a guideline for the modeling, management, and validation of BIM models in the field of construction health and safety. Another issue addressed by the authors concerns the enrichment of BIM models with all the missing information needed to start the model checking analysis, for example a semantic enrichment using artificial intelligence (AI) [33]; in other cases, checking the completeness of the model with model checking software is necessary to carry out more specific analyses, such as structural analysis [34]. Finally, studies on clash detection have been carried out to develop systems to solve spatial coordination problems during collaboration in the CDE [35] or for the automated identification and resolution of steel rebar clashes and congestion in RC members [36].

An analysis of the scientific literature shows that recent studies in the field of model checking have focused on a wide range of topics, from the translation of building regulations into automatable languages to the application of new automatic analysis systems to the most varied sectors of the building and infrastructure industry. What has been highlighted, however, is the lack of systematic guidelines such as the one proposed in this publication that can provide the basic tools necessary to understand which checks to perform in order to validate a final BIM model, the first requirement necessary to effectively organize a model checking process and support the practical application of this activity.

4. Methodology

The methodology at the basis of the research, i.e., the development and application of a check flow of the BIM model in the detailed design phase, requires some basic assumptions that allow framing of the object, the subject and the timing of the checks. In fact, the application of the method requires a clear and concise process at the base, lightened of futile elements and carried out as the phase proceeds by well-defined actors. For this purpose, three questions were posed to draw up the check flow: (1) What to check? (2) When to perform the check? (3) Who should do the check?

4.1. What to Check?

Checks that constitute the flow have been identified starting from a careful analysis of the scientific literature, interviews with industry professionals, online research and analysis of BIM models related to real projects in progress. In addition, all checks have been analyzed with reference to an ideal use of the BIM methodology, for which the information model, in accordance with current regulations on public procurement (but with the possibility of application also for private contracts), has contractual prevalence over paper documents and it is not a mere element accompanying the latter. Consequently, the importance attributed to the BIM model by the contract signed between the parties, makes it necessary to include within it all the project data, because, precisely from it, the necessary information will be drawn during the subsequent phases of the work. For this reason, a well-executed BIM model contains an immense geometric and informative content, and the complete check of each of its parts would involve an excessive consumption of resources. Therefore, in order for the checks to be exhaustive but at the same time convenient in terms of time and costs necessary to perform them, the check flow must include only:

(1)

All the checks are necessary for the quality control of a BIM model during the detailed design phase, necessary both to facilitate the validation of the project itself by the client, and for the release of the authorizations by the competent administrations. To such purpose, the checks can vary from time to time on the basis of the requests made for the specific order by the client and the administrations respectively.

(2)

All the important checks of the model that can be carried out starting from a detailed design phase (as the elements to be checked must already exist) are only relevant for subsequent phases, which should be carried out immediately in order to avoid the real risk of postponing the resolution of errors to phases that are so advanced as to make their resolution too costly or even impossible.

Taking into account these two primary aspects, everything else has been left out, namely everything that is superfluous or irrelevant for the above-mentioned purposes. For example, in the representation of a furnishing element, it is not so much the element itself that is important, but rather its size, which is necessary to evaluate the interference of the relative use spaces with the paths of accessibility within each room. Consequently, the checks regarding furnishing elements contained in the flow will be pertinent solely to the latter aspect, leaving aside any other type of analysis (this is true for any phase of the design, and even more so for the detailed design phase).

4.2. Who Should Check and When?

The check flow has been designed with reference to the controls to be carried out at the final milestone of the phase, coinciding with the delivery of the detailed project with 100% progress, necessary both for the validation of the project itself by the client, and for the release of the authorizations by the competent administrations. However, it is emphasized that, in order to obtain effective results, it is necessary to apply the check flow also in other moments of the detailed design phase and not only at its conclusion. In this case, since the checks will concern a BIM model in progress, it will be necessary to exclude some of them from the flow, in order to take into account the natural incompleteness of the model at the time of this intermediate check (for example, the checks concerning the production of designs required by the competent administrations will not be able to be carried out, in all probability, on a model that is only 60% complete). It should be highlighted that the greater is the number of control phases that are carried out, the greater is the burden in terms of time and costs to be borne, while guaranteeing, as the number of verifications increases, a higher quality of the design process. Consequently, the number of model checking analyses to be carried out during the design process depends strictly on the resources available for the project, as well as on the agreements signed between the parties involved in the process.

On the basis of the above and with reference to the coordination levels and verification levels of the UNI 11337-5, three subjects have been identified as being responsible for the check of the BIM model:

• MOD (modelers, designers side): these are the subjects responsible for the realization of the single disciplinary models (BIM specialist) [37] and who have the initial task of performing, as far as possible, an initial quality control of the BIM model in native format, using the functionalities existing within the BIM-authoring software used [5], in order to easily solve many basic problems and avoid, at least in the initial phases, the check of the file in open format. In the next phase, on the other hand, they will have to proceed to export their file in open format (e.g., IFC) and apply the required checks to it [5]. In both cases, any problems encountered must be corrected by them directly within the original file in native format. After making the necessary corrections to the model, the modelers must re-run the cycle of checks until no more errors are found and produce a report containing the results of the checks, which must be handed over to the coordinator who will make the appropriate evaluations. It is possible, depending on the company organization, that it is not the modelers who carry out these control operations on the open format files, but a figure within the design team who has this exclusive check task [5]. The checks carried out on single disciplinary models are comparable to those foreseen for a coordination level 1 (LC1) according to UNI 11337-5 [12].
• COOR (coordinator, designers side): this is a figure within the design team with the function of coordinating the individual project disciplines (BIM coordinator) [37], which has the main task of creating the federated model through the aggregation of the single disciplinary models already checked by the BIM specialists (MOD) and check the model itself both in native format and in open format (not modifiable) [5], taking care to report any problems directly to the modelers, who will make the corrections required within the native files of competence. Before proceeding to merge the single models into a single file, the coordinator has the task of reading the reports received from the modelers, which will allow the BIM coordinator to consciously judge the history of the corrections made to the model and understand which points, if any, are still open and waiting to be solved. The check of the federated model within the design team is comparable to that foreseen for a coordination level 2 (LC2) according to UNI 11337-5 [12].
• CLI (client side): it is the client structure (the client himself or a competent figure in the BIM field who takes his/her place, which can be an internal figure of the client structure [38] or also an independent third party, such as an accredited inspection body [12]), which lead the task of carrying out the last cycle of checks of the federated BIM model in open format. This is the most important cycle, as it is the last step necessary to complete the design phase, and an essential tool for having the necessary elements to validate the model and extrapolate from it the documents required by the authorities for the issuing of authorization tools. This is an absolutely necessary cycle of controls, as it is carried out in contradiction to the design team, therefore any error that may be detected in the model must be reported immediately to the designers, so that they can make the necessary corrections in time. It should be borne in mind that any problems affecting the quality of the model could represent a cost to the client. In addition, errors not detected during the design phase could lead to serious delays in time planning, or even cause an increase in operating costs for many years to come [5]. The check of the federated model by the client is comparable to that foreseen for a verification level 3 (LV3) according to UNI 11337-5 [12].

Each of the three figures mentioned above has been assigned to specific checks for a total of n.3 check flows. In this regard, some important considerations have been made to complete the attribution:

• It is the task of the modelers (MOD) to check everything that can be controlled within a single disciplinary model. Therefore, a check that requires the combination of two or more disciplinary models (e.g., clash detection checks involving several disciplines) is not the responsibility of the modelers. However, it should be emphasized that the information contained in a single model (e.g., architectural model) can come directly from models of other disciplines (e.g., structural model), as they are coordinated with each other. For example, the architectural modeler will have to receive information about the dimensions of the holes in the floors or of the shafts (vertical empty spaces) and insert /check them within his own model.
• It is the task of the coordinator (COOR) to check everything that has not yet been checked previously, namely to carry out all the checks that require the combination of two or more disciplinary models to be carried out. It would also be advisable for the coordinator to carry out again all the checks already carried out by the modelers, but the process would then be too costly. Furthermore, since the modelers have to deliver to the coordinator a report containing the results of the checks, the coordinator already has immediate evidence of what has been verified, making further similar checks partly superfluous. In fact, automatic checks will return clear and tangible results which, if positive, will not require further analysis by the coordinator. On the other hand, great attention must be paid to all the checks that, since they cannot be automated by the rules currently present in the model checking software, require manual and sample checks within the model (e.g., visual checks of the model carried out through its free exploration [5], selection of single sample elements with analysis of the information associated to it and abacuses extrapolation, to show all the elements present in the model belonging to a given category and highlight all the information associated with them, possibly also applying mathematical formulas to obtain partial and/or overall totals), whose positive or negative outcome is therefore at the total discretion of the verifier. In these cases, then, it is appropriate for the coordinator to carry out a second check in contradiction to the modelers, in order to guarantee greater objectivity of the results obtained. However, since it is not possible to establish in a universal way and for all commercially available software which checks are manual and which are automatic, it has been preferred not to attribute to the coordinator checks already assigned to the modeler, making it necessary to carry out specific considerations on the basis of the model checking software used and the possibilities granted by it: if the adopted software is able to perform the check in question in an automatic way, it should not be re-performed by the coordinator, who will simply read the result on the report delivered by the modelers; if the adopted software does not allow to perform a check in an automatic way but only in a manual way, it will be the coordinator task to re-execute the check in contradiction to the modelers making sure that the results obtained correspond. This also guarantees the validity of the flow in the years to come. In the future, in fact, new model checking software may be developed or new functionalities implemented in existing programs, which will allow the automatic performance of checks that, to date, can only be performed manually. In fact, given the considerable progress made by model checking software in the last decade, it is reasonable to think that in the future there may be artificial intelligence (AI) in revision software based on the experience of the experts, capable of assessing the action to be performed for each check of the ruleset on the basis of statistical data.
• It is the responsibility of the client (CLI) to perform all the checks that can be made on the open format BIM models received by the design team. It is not responsible, therefore, for all checks that can be carried out only on the proprietary format model (e.g., check of weight optimization and readability of proprietary format files), since this publication refers to an ideal BIM process in which the passage of information between designers and clients occurs only by means of open format files, which by their nature are “locked” and cannot be modified. Therefore, it is essential and mandatory for checking the models, as well as for a proper and efficient workflow throughout the entire life cycle of the building, that the client specifically requests designers to export the models in an open format, such as IFC.

Below is an image schematically illustrating the proposed method (Figure 1): the modelers (MOD) and the coordinator (COOR) perform controls reported within the check flow and deliver the models in open format to the client (CLI). The client performs its own checks, in particular: (1) ascertains the fulfilment of the authorization requirements of the competent administrations; (2) ascertains the completeness of the delivered detailed model. If both of these constraints are fulfilled, the client will be able to validate the detailed model and start the next phase of the process. On the contrary, if one of the constraints is not satisfied, a revision of the model by the designers will be necessary, with the consequent repetition of the above-mentioned operations.

5. The Check Flow

The flow has been divided into five main check phases of the BIM model (the three typical phases of model checking to which two have been added), listed below in the chronological order in which they must be carried out:

• Minimum requirements: necessary and indispensable phase to be able to perform the checks foreseen in the following phases and, for this reason, called “phase 0”.
• BIM validation: phase necessary to ascertain the level of quality and internal consistency of the model.
• Clash detection: phase of check of geometric interferences.
• Code checking: phase of check of conformity of the model to the reference standards for building design.
• Model output: phase of check of the correct production of drawings extrapolated from the model. In particular, model output phase ascertains the completeness of drawings in terms of their content, not the correctness of the content itself, which is checked with the other phases. For this reason, it could be carried out at any time of the analysis, as it is not bound by the completion of the previous phases; however, as it concerns a conclusive aspect of the process, it has been inserted as the fifth and last phase to be carried out.

On the basis of this chronological order, the ideal model checking procedure foresees first of all that the verifier (designers and/or clients) carries out the checks of the minimum requirements and BIM validation phases, and then immediately communicates to the modelers the changes to be made to the model on the basis of the criticalities found. After making the necessary corrections, the modelers will return the corrected model to the verifier who can then re-perform the above checks and, if successful, proceed to the next three control phases: clash detection, code checking and model output. At this point, all errors detected will be communicated again to the model authors, who will make the final corrections and return the file to the verifier, who will perform a final check to ensure that the required changes have been correctly made. If this is not the case, the process will be repeated until a BIM model is obtained that is free of errors or in line with the requirements of the client and local authorities. Finally, it should be noted that some checks are marked with a symbol (🖹) instead of the usual number: these are minimum requirements, namely necessary and indispensable conditions to be able to carry out the checks proposed in the following phase.

The total number of checks is n.124, excluding the minimum requirements and without taking into account the countless examples given for each of them which, by their nature, can be implemented as needed. These examples are just the controls considered most important in relation to the nature of the verification in question, added in the flow to achieve a greater level of detail. Below (

Table 1. Extract of the complete check flow of the coordinator, divided into its five phases: minimum requirements, BIM validation, clash detection, code checking and model output.

Check Flow—Coordinator (COOR)
-The coordinator carries out checks on the federated model, minimum n.2 aggregated disciplinary models (proprietary and open format); -The coordinator may also carry out checks on individual disciplinary models in contradictory to the modelers (MOD), not specified below
Phase 0 minimum requirements To be performed before any other phase
	Minimum requirements	Notes
🖹	Check of the availability of models based on the destructuring foreseen in the Master Information Delivery Plan (MIDP)
🖹	Check of the preparation of individual disciplinary models for union in a single model (federated model), ensuring that they are comparable in many respects. Examples:
i	Models must share the same software version
ii	Models must share the same language
iii	Models must share the same phase
…
Phase 1BIM validation -Previous phases: phase 0 minimum requirements -Restrictions: modelers must have completed their BIM validation checks
A	Check of compliance with the Exchange Information Requirements (EIR) and the BIM Execution Plan post-contract	Notes
🖹	Check of the presence and availability of an Exchange Information Requirements (EIR) and a BIM Execution Plan post-contract, containing the information to be verified. Examples:
i	Model uses
ii	Level of Information Need
iii	Nomenclatures
iv	Parameter management rules
v	System for classifying and naming objects
🖹	Check of compliance of the model with the defined model uses
1	Check of quantitative aspects. Examples:
i	Maximum file size
Phase 2clash detection -Previous phases: phase 0 minimum requirements, phase 1 BIM validation -Restrictions: modelers must have completed their clash detection checks -Check order: A, B
A	Check of intersection between elements belonging to the same discipline—hard clash	Notes
🖹	Check of the availability of a possible clash matrix defined in the Exchange Information Requirements (EIR) and in the BIM Execution Plan post-contract
1	Check of the absence of intersections between plant elements belonging to different types of plant. Examples:
i	Fire protection system pipes vs. air ducts
…
Phase 3code checking -Previous phases: phase 0 minimum requirements, phase 1 BIM validation, phase 2 clash detection -Restrictions: modelers must have completed their code checking checks
A	Check of accessibility and overcoming architectural barriers	Notes
🖹	Check of the presence and availability of local regulations
🖹	Check of the presence and availability of regional and/or state regulations
1	Check of the existence of architectural and/or plant elements necessary for overcoming differences in height by people with reduced or impeded motor skills. Examples:
i	Ramps
ii	Elevators
iii	Stairlift
iv	Lifting platforms
2	Check of the existence of toilets accessible to people with reduced or impaired mobility in the minimum number required by current regulations
3	Check of the existence of sufficient maneuvering space within certain environments to allow wheelchair users to properly use the spaces and/or equipment therein. Examples:
…
Phase 4model output -Previous phases: phase 0 minimum requirements -Restrictions: modelers must have completed their model output checks
A	Check of correct production of the project drawings	Notes
🖹	Check of the requests, in terms of project drawings, for the issue of administrative authorizations (e.g., building permit, fire prevention, etc.) by the competent authorities
1	Check of the existence in the model of the project drawings necessary for the production of the documents required for the issue of administrative authorizations. Examples:
i	Project drawing showing the context of the property to be involved, made from an extract of the adopted urban planning tool
ii	Project drawing showing the existing and project status and comparison in conventional colors
iii	Significant plans, elevations, and sections at scale 1:100
…

), an extract of the check flow of the coordinator, in which, for each phase, general indications are given concerning the preceding phases, the constraints to be met and the order of the checks.

6. Case Study

Once the writing of the flow was completed, the actual applicability of it was verified through the check of a real BIM model belonging to a detailed design phase in progress, with a private client and carried out by the various figures involved in the process using entirely BIM methodology. This is a new building complex mainly for office use, including other uses such as restaurants and auditoriums, as well as an underground garage on two levels. The total surface area of the project (including the raised floors) is approximately 30,000 square meters. Different disciplinary models have been used for the model checking analysis, namely: architectural, structural, MEP, electrical systems, facades. The software used jointly by the designers for parametric modeling is Autodesk Revit. Interoperability is in any case guaranteed by the exportation of the native files in the open IFC format (2 × 3), which shall be delivered to the client at the end of the detailed design phase, by virtue of the contractual agreements between the parties. The realization of the federated model through the aggregation of the single disciplinary models in IFC format took place directly within the software adopted for the model checking analysis, namely Solibri Model Checker.

For privacy reasons, it is not possible to provide further details about the project, nor will it be possible to show large portions of it. It should also be noted that the flow applied to this project could have been applied to another building project, after a different configuration of the ruleset needed to check it, according to local regulations and information contained within the project Exchange Information Requirements (EIR).

6.1. Phase (1) BIM Validation

6.1.1. A1—Check of Data Existence

The purpose of the check is to ascertain the existence in the model of all the data prescribed in the Exchange Information Requirements (EIR) and BIM Execution Plan (BEP). The rule (SOL/203) used for the check requires to specify the type of elements to be checked and the respective data to be verified, in this case the “Structural Material” parameter relating to all the structural objects of the model (Figure 2).

The instances that failed the check belong to three categories of structural element: IfcRoof, IfcSlab and IfcStair. By selecting one of them (e.g., “Roof 3.1”), it is possible to visualize it inside the model with a color that makes it immediately recognizable (Figure 3).

6.1.2. C1—Check of Absence of Duplicate Elements

The purpose of the check is to ascertain the absence in the model of duplicate elements and/or duplicate environments, which inevitably leads to a double counting of the materials associated with them, with consequent computational errors in the quantity take-off phase [9] and overestimation of the costs reported in documents such as the budget or the estimated bill of quantities. In the image below (Figure 4) it is possible to notice the overlap between two structural pillars highlighted by a flicker in their respective colors (red and grey).

6.1.3. C11—Check of the Existence of at Least One Access Door for Each Room

In this case, the check revealed a total of n.7 problems resulting from as many environments without an access door. Consider in detail one of these, the filter of a stairwell (Figure 5): observing the environment by means of a 3D perspective view it is possible to ascertain the effective lack of the access door to the filter, despite the presence of the wall space.

6.1.4. C12_C13—Checking That Each Room Does Not Intersect and Is Defined within a Volume That Is Well Delimited Vertically and Horizontally

For the case study in question, it is checked that each room does not intersect elements such as walls, floors, roofs, curtain walls and other rooms (considering a tolerance of 500 mm) and that their lower and upper surfaces are correctly delimited by horizontal components. The check of the model returns a large number of problems, among which an environment which intersects the lower floor, or which is suspended with respect to it (Figure 6), determining incorrect surfaces and volumes; or again an environment completely superimposed on another with the consequent extra calculation of its volume and surface (Figure 7).

6.1.5. C14—Check That Stairs Are Connected to Floor Slabs

To carry out this check, Solibri requires the classification of all the staircase elements existing in the model, in order to be able to analyze them individually and thus exclude all the other types. In the case study, all the vertical connection elements have been classified, identifying as “Scale” all the IfcStair components and as “Rampe” all the IfcRamp components, as well as any other component having the wording “Ramp*” (namely “Ramp” followed by any number of textual/numerical/symbolic characters etc.) in the name or type (Figure 8).

Once the elements to be analyzed have been classified, it is possible to configure the rule and start the check of the model, which returned negative results for n.14 elements out of a total of n.257, highlighting a lack of connection of the stairs sometimes to the lower slab, sometimes to the upper slab (Figure 9).

6.2. Phase (2) Clash Detection

C1—Check of the Existence of Sufficient Distance between Plant Elements and Architectural and/or Structural Elements to Allow Proper Installation and/or Maintenance of These Elements by Qualified Technicians

In this specific case, the Solibri SOL/226 rule was adopted to check that there is a free space of at least 700 mm in front of the electrical panels, in order to allow their correct use in accordance with the regulations in force. The following images show the results of the check, from which it is possible to observe the non-observance of the aforementioned free space, highlighted by the software with a blue surface (Figure 10).

6.3. Phase (3) Code Checking

6.3.1. A4—Check of the Existence of Sufficient Maneuvering Space within Certain Areas to Allow Wheelchair Users to Properly use the Spaces and/or Equipment

In this case, the aim is to check that there is sufficient space inside the bathrooms intended for disabled users for the rotation of the wheelchair, corresponding to a circumference with a minimum diameter of 150 mm, in accordance with Ministerial Decree 236/89 containing prescriptions on the accessibility of buildings. The Solibri rule used for the check (SOL/209) requires first of all the classification of all the bathrooms intended for users with motor disabilities, which, however, it was not possible to create based solely on the name of the intended use of the rooms in the model, since the modelers did not give them a specific name, but simply named them “Bathrooms”, lumping them together with both normal toilets (not intended for users with motor disabilities) and ante-bathrooms. Therefore, it was necessary to add a filter on the surface area, classifying as “Bagni disabili” all the rooms named “Bathrooms*” with an area between 3.00 and 5.00 m² (Figure 11). Obviously, this is not a scientifically exact method, but it does allow an initial useful skimming, to be accompanied later by a precise control of the problems returned by the audits that will use this classification. The alternative would have been to manually classify each individual environment corresponding to the desired characteristics, which would have been effective but time-consuming.

Once the classification of the environments has been completed and inserted into the rule, it is possible to start the check of the model, after which problems are detected for n.4 “Disabled bathrooms” environments out of a total of n.46 analyzed. A more in-depth analysis, however, reveals the presence of false negatives for the reasons stated previously: the environments reported are in reality ante-bathrooms of access to toilets not intended for disabled users, therefore the problems in question do not represent an error and are accepted (Figure 12).

6.3.2. A5—Check of the Existence of Sufficient Free Space in the Planimetric Surroundings of Architectural Elements Whose Proper Use by Each User Must Be Guaranteed

After defining the free space to be specifically 1350 × 1400 mm in accordance with the prescriptions of Ministerial Decree 236/89, the check found n.17 critical components out of a total of n.44 checked. The following figure shows an example of an intersection between the respective area in front of an internal door and the walls of the surrounding corridor (Figure 13).

6.3.3. A6—Check of the Compliance of the Geometrical Characteristics of the Elements with the Minimum Normative Requirements, with Exclusive Reference to the Architectural and/or Plant Engineering Elements Whose Correct Use by Each User Must Be Guaranteed

The check of the geometric characteristics of the stairs can be carried out using the classification of the stair elements already introduced previously and entering, as data, the minimum standards imposed by Ministerial Decree 236/89 and the local building regulations, including:

• v_depth of treads: minimum 300 mm.
• vii_number of consecutive risers: maximum n.12 for new construction.

Some examples of unfulfilled checks are given below (Figure 14).

6.3.4. B9—Check of Compliance of Fire Compartment Surfaces with Minimum Regulatory Requirements

For the case study under analysis, the intention is to check that the surface of the fire compartment of the underground garage complies with the minimum dimensions imposed by the fire prevention code (Ministerial Decree 03/08/15), namely 4000 m² per floor for garages with risk profile A2 located at a height of less than −5 mt from ground level. To carry out the check it is necessary to define, within the model, the perimeter of the fire compartment that is to be analyzed, by simply selecting the walls that surround it (Figure 15).

Model checking returned problems only for all the rooms for which no compartments were indicated, while it was positive for the only one that was defined and that was to be analyzed, the basement garage. It should be noted that, if the information model had contained specific data regarding the fire behavior of the elements (in particular the walls), it would have been possible to automatically and immediately define all the compartments existing in the model, without the need to carry out manual object selection operations.

6.3.5. C2—Check of Existence of Minimum Sanitary Equipment for Toilets

The purpose of the check is to verify that the rooms have the necessary sanitary equipment as required by current regulations. The rule adopted for this check (SOL/225) requires, in addition to the toilets classification, also the classification of the sanitary fixtures. The elements classified as sanitary fixtures, namely “WC” and “Washbasins”, contained within the toilets which are in turn classified as “Disabled toilets”, are shown below (Figure 16).

In accordance with the local building regulations, at least n.1 WC and n.1 washbasin are required in bathrooms of non-residential units, so the types of problems that can be detected in the analysis can be:

• Lack of washbasin.
• Lack of WC.
• Simultaneous lack of WC and washbasin.

Starting the check of the model, problems of all three types have emerged, however it is necessary to make some observations. In fact, as already mentioned above, the classification of bathrooms necessarily includes all the rooms named in this way by the modelers and, in the case in question, also the anti-bathrooms and the “bathroom cabins”, for which it is evident that the detection of the error actually constitutes a false negative. In order to overcome this problem, it would have been necessary, on the part of the modelers, to name the bathrooms differently, distinguishing the aforementioned cases, or to classify each bathroom in the model directly within Solibri according to its nature, an operation that is far from rapid.

In any case, one of the environments that failed the test is analyzed in detail, for example a bathroom cabin in which the simultaneous absence of WC and washbasin is reported. While the absence of the washbasin is correct given the nature of the environment (therefore the respective problem is accepted), the actual absence of the WC is ascertained through the use of a three-dimensional view (Figure 17), which confirms the truthfulness of the rule adopted and the modeling error that must be solved.

7. Results

At the end of the application process, it has been demonstrated that the check flow is perfectly applicable to a complex real model, in the same way as presented, and that the use of a model checking software allows, as expected, to simplify the nature of the checks, making them automatic on a large scale rather than on a sample basis. In this regard, it should be noted that, although the study in question used models made solely with Autodesk Revit, a survey was also carried out on the most famous modeling software on the market (Allplan, Archicad, Rhino + VisualArq, Graphisoft, Tekla, Vectorworks), which made it possible to ascertain the possible interoperability through the open IFC format and therefore the applicability of the proposed flow.

However, a hypothesis already formulated earlier was confirmed, namely that not all checks can be performed automatically. In fact, for many of them, Solibri Model Checker does not provide any automatic rule for their execution, forcing the verifier to proceed with manual checks on the components that he considers appropriate to screen—given the obvious impossibility to check them all—thus leaving out many others. This greatly increases the risk of error in the analysis and of losing sight of elements which may subsequently prove to be deficient for one reason or another.

Another consideration to be made concerns the specific preparation of the model for the model checking analysis, where one of the main limitations of the process was found. In fact, from the application of certain checks, it emerged that a correct and effective analysis of the model requires a prior preparation of the same (by the modelers) to their implementation. To better understand this concept, it can be considered for example the check of the compliance of the useful surfaces of the rooms with the minimum regulatory requirements (code checking—C4), during which the authors found themselves faced with the aforementioned problem regarding the classification of the toilets for users with motor disabilities, since the modelers did not have the foresight to identify them as such, but decided to merge them with all the other toilets and ante-bathrooms. As a result, it was necessary to classify these rooms using a filter on the surface, which of course did not guarantee the accuracy of the results, but only skimmed them, making a second manual skimming of the rooms necessary in order to ascertain whether they were actually of the desired type. This hitch only slowed down the entire process, generating an important reflection: the only way to compensate for this limitation is to prescribe specific modeling rules in the Exchange Information Requirements (EIR), already having in mind the methods for doing the checks that will be carried out. In this way, returning to the previous example, the modelers would be required to distinctly identify the toilets for users with motor disabilities from all the other toilets, in order to allow a rapid and precise classification of the same during model checking operations. Therefore, against an operation that is all in all banal required to modelers, a great saving of time would be obtained during the model analysis operations, as well as greater reliability in the results obtained. In this sense, therefore, an important preventive action is required from the client, who must be able to anticipate any problem that may occur during the checking process and that are strictly dependent on the model checking software that will decide to use, as well as the types of checks that has in mind to apply. Although this preventive action may be complex when first applied, once the analysis process has been tested and applied to several projects, it will certainly be simpler and more natural. It is emphasized that, since designers also have the task of checking the model, they may themselves realize that it is necessary to model components and/or input data in a certain way rather than another in relation to future check requirements, and therefore they may themselves make up for any gaps or omissions of the client regarding such preventive countermeasures.

As regards the communication of the results, Solibri Model Checker allows the user to associate with each problem detected a slide summarizing the main information concerning it and which must be transferred to the author of the model, for suitable correction (Figure 18). Alternatively, the user has the possibility of exporting the results of the analysis in a classic report format, xlsx and pdf, or dynamic BCF (BIM Collaboration Format), an extension that allows them to be viewed directly within the modeling software so as to automatically trace the elements to be modified, thus favoring the rapidity of the correction process and a lower probability of incurring misunderstandings of any kind.

Finally, the possibility of saving and exporting the set of rules created by the user in a specific format allows it to be reused in other projects, thus alleviating one of the main problems of model checking analysis, namely the time needed to carry it out, 70% of which consists of the correct preparation of the ruleset (taking into account only the automatic checks, since it is impossible to quantify the time needed to carry out manual checks on a sample basis). Obviously, it would be necessary to modify the input data of each rule to adapt them to the project being analyzed each time but, in any case, a considerable stream-lining of the control operations would be obtained; in this regard it should be considered that, if the projects share the same project area (e.g., school buildings, hospital buildings, etc.), the operation of adapting the ruleset will be fairly easy.

To conclude, some statistical data are following reported. For the analyzed project, n.42 checks were carried out of a total of n.124 foreseen (excluding the minimum requirements), namely 34% of the total number of checks, taking into account that each of them did not concern the total number of components and/or data that should generally be examined, since the objective was not to achieve the validation of the model, but to provide an example of the effective applicability of the check flow developed. Out of a total of n.124 checks in the flow, n.60 are currently executable automatically with Solibri, namely 48% of the total checks. After these premises, it is important to provide an indicative estimate of the time required to carry out the above-mentioned checks which, in the case in question, amounted to about 60 h in total (n.7 working days), necessary for the preparation of the models, the creation of the ruleset, the execution of checks and the critical analysis of the results. Assuming that all the checks contained in the flow had to be carried out, about 180 h would be necessary, namely n.23 working days, considering an average working day of 8 h (without considering, however, that the time necessary to carry out manual checks, being a sample on the objects of the model, is difficult to quantify and strictly depends on the project) and always bearing in mind that the project analyzed is particularly complex and extensive (about 30,000 m² of intervention area). Obviously, spending 180 h all together at the end of the detailed design phase is hardly sustainable for the designers and even more so for the client, without taking into account the time needed to correct errors and restart the cycle of controls. Therefore, as already indicated above, it is appropriate to implement the check process during the entire project phase, for example at certain contractual intermediate milestones (e.g., detailed project delivery 40%, detailed project delivery 70%, etc.).

So, it is therefore possible to hypothesize a check process that subdivides the total hours necessary to carry out the checks in the following way (Figure 19):

• Start phase: time needed for model preparation and complete ruleset configuration (the latter requiring approximately 70% of the total number of hours).
• Milestone 1 (hypothesis: delivery of a 40% complete project to the client): time necessary to carry out the checks on a 40% complete model (those that become available according to the evolution achieved by the model, hypothetically 40% of the total number), for the critical analysis of the results obtained and for the preparation of the reports to be sent to those responsible for the modifications to be made. The checks to be carried out have already been prepared during the previous phase and it will be sufficient to “put on stand-by” the checks that cannot be carried out yet in order to keep valid only those that are necessary.
• Milestone 2 (hypothesis: 70% delivery of a complete project to the client): time condition similar to that foreseen for milestone 1, taking into account here a longer time for carrying out the checks (hypothetically, 70% of the total checks are carried out), for the critical analysis of the respective results and for the preparation of the reports.
• End of phase (delivery of a 100% complete project to the client): time needed to carry out all the checks contained in the flow, to critically analyze the results obtained and to prepare reports. It is necessary to carry out again the checks already applied in the intermediate milestones because, in the intervening time, the objects of the model may have been changed; however, if this was not the case, the result of the check will be the same as the previous one and all the considerations already made will remain valid (therefore less time for the critical analysis of the results and for the preparation of the reports).

A check procedure of this type, is evident, requires the use of a greater amount of time at the beginning of the phase, due essentially to the preparation of the ruleset, which however will no longer have to be configured in the subsequent phases, facilitating the process in the most critical moments of the design phase (delivery milestones). Leaving aside the peak at the beginning of the phase, as the informative evolution of the model increases, so does the number of checks that can be carried out and the time needed to complete them, until the end of the phase, in which it will be necessary to complete 100% of the checks foreseen (it should be noted that, with the above subdivision, the total number of hours is greater than 180, as the checks are repeated at each stage as the modeling progresses; moreover, the time needed to prepare reports containing corrections to be made to the model has also been included here). In this way, it is possible to spread the total hours necessary to carry out the checks over a longer period of time and at the same time guaranteeing greater control of the process and less time and costs during the most critical moment of the phase, the final one (delivery of the model for the designers and validation of the project for the client). It should be borne in mind that if an ideal and exhaustive application of these checks is envisaged, namely in respect of all the components and/or data that each check should include, the total number of hours would be even higher than that just indicated. This number of hours is further increased by considering the necessary communication and coordination phase of the results obtained from the analysis, in terms of meetings or, in any case, comparisons necessary to discuss the problems detected, and the possible time needed to carry out the checks again after the corrections made by the modelers. Obviously, these data are purely indicative as well as specific for the project in question, since it is impossible to establish an average time necessary for the application of the check flow that has general validity, since it depends on many factors such as the complexity of the project, the entity of the requests made by the client in the Exchange Information Requirements (EIR), the regulations to be adopted, etc.

In any case, it is clear that the time data reported, even if spread over the phase, are certainly high. In common practice, there is generally not enough time to carry out such a detailed check and, even if there were, it would be necessary to consider the allocation of the necessary resources and the relative cost. Obviously, a complete check of the model would achieve a very high degree of its quality, but it is also true that it is possible to meet the objectives of the publication without necessarily carrying out all the checks contained in the flow. This can only occur through a process of conscious selection of the checks necessary and indispensable for the satisfaction of the prefixed objectives, namely the obtaining of a BIM model suitable for a detailed design phase, correctly prepared for validation by the client and for the issuing of permits by the competent administrations. Consequently, it is intended to initiate a process of optimization of the check flow that is, as mentioned above, conscious, therefore based on criteria that are as objective as possible, rooted in one of the most important disciplines of project management activities: the risk management.

8. Corrective Actions

In line with the risk management principles, the objective is to establish which checks are to be kept within the flow and which are to be excluded, after a conscious assessment of the risk that would be run by not doing them, in terms of extra time and extra cost required to correct errors once they have occurred. In literature, the risk is generally quantified on the basis of the probability of occurrence and the significance of its impact on the project [1], concepts that allowed to define the n.3 indices to be adopted for the assessment of the risk associated with each control, understood here as the degree of risk that would be incurred if a certain check contained in the flow should not be performed:

(1)

Impact index on the release of authorizations (I_authoris.): this index evaluates the importance of the check in terms of the release of authorizations by the competent administrations, as well as the entity of the impact of any modeling and design errors on this process. Since this criterion is the most important, as well as being of the on/off type, in that it must necessarily be satisfied for certain checks, it was decided not to assign a numerical score to each check, but rather an abbreviation that identifies a necessary (Y) or unnecessary (N) check for the release of permits. In particular, a necessary check requires that the content of the audit be subject to observation by the competent administrations and it is of paramount importance that it is correct. An unnecessary control, on the other hand, provides that the content of the check is not binding in any way to the issuance of authorizations from municipality, so even if it were incorrect it would not affect the process in question.

(2)

Impact index on detailed project delivery (I_det.): the index evaluates the importance of the check in terms of delivering, to the client, an information model that is free of errors and contains all the information that must exist in a detailed project. Therefore, all controls that are already relevant for a detailed design phase will have a high index. On the other hand, all controls which, although important, acquire greater relevance in subsequent phases, or which are considered less important for the purposes of validation of the project itself by the client, will have a reduced index. In other words, the consequences of a non-correction of any errors within a detailed project are being assessed here, namely the extent of the impact of such negative aspects on costs, time and quality of the design.

(3)

Probability index (P): the last index evaluates the importance of the check in relation to the probability that its content is incorrect/incomplete or not, regardless of the consequences of the error. Therefore, a high degree of risk exists for all those checks whose content has a high probability of being incorrect or incomplete. In this regard consider, for example, the modeling phases in which there is a large number of data/elements involved and therefore a greater probability of incurring errors or forgetfulness of any kind, or the cases in which, more frequently, designers make an error due to mistaken habits that have become part of common practice.

Excluding index n.1 (I_authoris.) of the on/off type, the other two indices were placed in a range of values going from n.1 (minimum value) to n.3 (maximum value) as, following preliminary tests, this was found to be the ideal interval for the evaluations to be carried out. The Risk degree (R), namely the index measuring the amount of risk that would be incurred in the event that a given check was not carried out, was determined for each check through a weighted average of the individual indices attributed to each criterion:

$$\mathrm{R}=\frac{{\mathrm{I}}_{\det }\times 1+ \mathrm{P}\times 0.7}{1.7}$$

It was decided to give a greater weight to the index of impact on the delivery of the detailed project I_det. (weight 1) compared to the index of probability P (weight 0.7) as it is certainly more relevant to the objectives of this research, as well as characterized by greater objectivity and therefore less discretion. Obviously, the index n.1 I_authoris. was not taken into consideration in the operation, as it is only of the on/off type.

The following is an extract of the complete check flow including the indices and the risk degree (R) of each check (

Table 2. Extract of the complete check flow, with indices (I_authoris., I_det., P) and the calculation of the degree of Risk (R) for each control.

Phase 1 BIM Validation	Indices			Risk
Correct modeling checks	Iauthoris.	Idet.	P	R
Check of the absence of duplicate elements and/or environments	N	3	2	2.59
Check of the absence of suspended elements	Y	-	-	Required
Check that the elements are discrete	N	3	3	3.00
Check of association of elements to the level on which they actually lie	N	3	3	3.00
Check that the elements and/or environments have an unambiguous nomenclature or are unambiguously referenced	N	3	2	2.59
Check that walls and columns are bound at a lower and upper level	N	2	2	2.00
Check that dimensions of the elements correspond to existing product/construction characteristics	Y	-	-	Required
Check for the absence of objects in an illogical position	Y	-	-	Required
Check of association of an intended use to each room	Y	-	-	Required
Check that the intended use associated with each room is consistent with the characteristics of the room itself	Y	-	-	Required
Check of the existence of at least one door or access system for each room	Y	-	-	Required
Check that each room is defined within a volume that is clearly delimited vertically and horizontally	N	3	2	2.59
Check that the rooms do not intersect horizontally or vertically	N	3	2	2.59

), before which, however, some considerations must be made:

• The minimum requirements, namely the checks marked with the symbol 🖹 in the check flow, have not been assigned any index and have been excluded from the skimming operation since they are, by their nature, indispensable controls to be able to carry out the subsequent checks and therefore must necessarily be performed. For the same reason phase 0 minimum requirements was excluded.
• Since the criterion relating to the release of authorizations is the most important, if a check has to satisfy this criterion (I_authoris. = Y) the other two indices will not be assigned, since the check in question represents a necessary prerequisite for the completion of the detailed design phase: it already has the highest priority (R = Required) and will therefore certainly be included in the check flows that will result from this optimization process.

It should be noted that, although the score given to each check is the result of a subjective judgement, it is based on objective data, in this case relating to the impact in terms of time and cost on the detailed project. In particular, for the present study, an attempt was made to make the assessments as objective as possible by gathering information as a result of direct comparisons with professionals in the field (designers, modelers, project managers, BIM coordinators and BIM managers) and an in-depth analysis of BIM models relating to real projects in progress, from which were learnt both the extent of the consequences of a modeling error and the probability of its occurrence. In general, the best way to carry out a risk management assessment is to have a large amount of data, to use benchmarks as reference indices for risk assessment and to carry out analyses on several projects in order to compare them with each other and to identify the areas where errors are most frequent or have the greatest impact on project costs and time.

After assigning the indices and calculating the risk for each audit, they were inserted into the so-called “priority matrix”, a table summarizing the analysis just carried out, which has the purpose of ordering the checks according to their urgency and thus allowing an informed selection of the most important ones to be carried out. It should be noted that the selection of the most important checks to be carried out is similar to what happens following a classic risk management assessment: if in the latter case, in fact, once the risk associated with an event has been identified, it is decided whether or not to counter it, in the specific case of model checking it is decided whether or not to carry out a given check and, consequently, whether to include it in the optimized check flows. Within the matrix, the checks were ordered on the basis of:

(1)

Impact index on the release of authorizations (I_authoris.): checks with index Y precede those with index N.

(2)

Risk: in descending order, from grade 3.00 to grade 1.00.

(3)

Phase: the chronological order of the controls has been maintained which, as explained above, should be as follows: BIM validation, clash detection, code checking and model output.

(4)

Sub-phase: A to Z, as within the complete check flow.

(5)

Check number: in series, as within the complete check flow.

Finally, after ordering the controls, two thresholds and as many optimized flows were identified:

• Checks necessary for the granting of authorizations, which shall constitute the “optimized check flow for the authorization process”.
• checks considered necessary for the validation in the detailed design phase of a BIM model, which will constitute the “check flow optimized for the detailed design phase validation”.

Checks with a grade lower than 2.18 were consciously excluded from the optimized flows, as they were characterized by an acceptable degree of risk.

9. Discussions

The analysis work carried out in this publication has made it possible to achieve the objective initially set that is to provide public and private appointing parties with a useful tool to complete the check of BIM models during the detailed design phase, as well as to assist designers in carrying out a complete cycle of controls that must begin with them. By implementing all the controls contained in the flow, it is possible to obtain an information model that is complete in content and correct in all its components (geometric and informative), capable of favoring a conscious validation of the same by the client and facilitating the release of authorizations by the competent administrations. The time required to complete all the checks of the flow, which was too high (at least 180 h by carrying out the checks once the modeling has been completed; a greater number of hours, albeit spread out, in the case of splitting the checks into several stages as shown at the end of Section 7), determined the need to reduce the number of checks and led to the definition of two additional flows, optimized to achieve the set objectives. Moreover, the guarantee of having information models that are complete and with accurate information is a fundamental step to facilitate the development of BIM based processes. Hence the contribution of this research in the BIM4EEB project and the possibility to generalize the results and the value of the research to all projects that aim at integrating BIM base processes in their development.

The advantages of adopting any of the three check flows developed can be summarized as follows:

• Obtaining an exhaustive and correct building information model of the detailed design phase, compliant with the regulations in force and suitable for the end phase validation by the client, as well as for the release of authorizations by the competent administrations. The model also constitutes a solid basis for the completion of subsequent phases, including the management of the building.
• Increase in the quality of the detailed project, by virtue of a concrete decrease in the errors contained in the model; increase in the quality of the executive, construction and as-built project, as a direct consequence.
• Pave the way for the development of BIM based renovation and construction processes.
• High applicability due to the complete versatility of the flows, which can be applied to building projects of different types and geographical locations.
• Greater client security during the validation of the BIM model of the detailed design phase (necessary for the purposes of the wider act of validation of the project), the result of a greater awareness of the correctness of the information and geometries contained therein.
• Advantages deriving from the use of advanced model checking software able to automatically perform many of the checks contained within the flow, against the prior configuration of a set of parametric rules necessary to carry them out.

According to these advantages, the proposed flow will be applied within client structures and design studies in detailed design phase and the implications will be as follows:

(1)

For designers, the application of the flow gives them the certainty of delivering to the client a complete and correct model that complies with the contractual requirements. This allows to optimize the detailed project delivery process, as the prior check by the designers of the transmitted content would reduce the need for subsequent revisions, which usually occur in the case of missing or gaps detected by the client.

(2)

For the client, the application of the flow guarantees the possibility of receiving a complete detailed model from the designers, checking it in contradiction and validating it with awareness, based on objective data returned by calculation software. In addition, the compliance of this model with the regulations in force makes it possible to deliver to the competent administrations drawings that meet the requirements and thus obtain the necessary authorizations for the completion of the detailed design phase of the building process. Also in this case, the application of the flow allows to optimize the exchange flow between designers and client, since, being based on a high-quality model, it will certainly require fewer corrections. Finally, the possibility offered by the flow to the client to check a BIM model with awareness without requiring the help of third parties, can represent the starting point for an evolution of its competences in the field of model checking, creating the necessary conditions to develop an ideal BIM process in all its phases, in which the collaboration between the client and the other operators involved is the basis for the realization of different operations perfectly integrated with each other, with a consequent increase in the overall quality of the resulting construction.

On the other hand, some disadvantages also emerge, some of them due to intrinsic limits of the model checking process:

• High time consumption necessary to carry out the checks contained in the flow (even with the use of automatic model checking software, which in any case manages to mitigate this problem). In fact, although the process of optimizing the complete check flow has generated two distinct flows characterized by more streamlined and compact controls, the time necessary to complete them correctly and exhaustively remains high. Moreover, as far as the use of model checking software is concerned, the reuse of the ruleset in other projects requires a reconfiguration of the same on the basis of the needs of the specific job, which is certainly not an immediate operation.
• The impossibility for the model checking software on the market to automatically execute many of the checks contained within the flow, by virtue of the intrinsic inability of such software, at least to date, to translate some digital requirements into parametric rules [39]. The manual execution of these controls only further exacerbates the time-consuming limitation.
• Some of the checks contained within the flow will never be automatable as they are strictly dependent on human judgement (e.g., many of the checks on compliance with design choices). The manual execution of such checks on sample objects contained in the model is certainly more time-consuming than others that can be performed automatically.
• Necessary costs for: purchase of model checking software and possibly of performing computers in case they are not available (the start-up of the analyses implies a discrete use of the CPU of the computer); staff training; human resources to be allocated for the performance of the numerous checks proposed (for the operations of model preparation, rules configuration, critical analysis and preparation of results etc.). If each of these factors taken individually might not represent a problem (for some realities), it is evident that the three aspects together require the allocation of a not insignificant budget for the sole activity of check of the information models.
• Applicability limits of the flow in the public sphere due to the legislation in force which, in Italian context (code of public contracts), identifies economic thresholds of the contract above which the check of the project (and therefore of the model) can be carried out by the client structures only if accredited in accordance with the technical regulations in force. In any case, it is emphasized that the flow has been developed with the idea that it could be a valid help both today and in a hypothetical future in which the regulations in force could change and, in the case in question, assign greater responsibilities to the clients, even without the above-mentioned accreditation systems, all with a view to a process of evolution of clients competences which, to date, is still in its initial stages.
• Less effectiveness of the flow in the case of non-ideal use of the BIM methodology since, as the objectives and uses of the model decrease, the need to carry out some of the proposed checks disappears. Furthermore, the correct applicability of the proposed flow requires that the main feature of an ideal BIM process is respected: the effective coordination between the different figures involved.
• Applicability limits of the flow due to working methodologies and work teams (both of design studies and client structures) which are, to date, not adequate and not able to support a continuous process of constant revision and readjustment, as well as the use of digital applications for semi-automatic validation.
• Applicability limits of the flow due to a limited diffusion of the model checking process on a national and international scale [40,41,42]. Among the factors there is a lack of information about the process itself and its benefits, which is rooted in a deep-rooted culture, not yet open to the digital evolution of the construction world (it should be considered, however, that in Italy the gradual introduction of compulsory BIM in public procurement is already mitigating this deficit). For some clients, model checking and the broader building information modeling represent technological innovations that are not economically sustainable or simply not necessary. In this respect, it is necessary that “future research translates more paper-based regulations into a BIM-based environment to convince construction professionals of the real potential that model checking offers” [40].

10. Conclusions

In conclusion, the advantages of the proposed method have shown that, by adopting the check flows, it is possible to successfully complete the detailed design phase of the construction process and to obtain the necessary authorizations from the competent administrations. This is in spite of some disadvantages, partly intrinsically linked to the model checking process, partly due to a difficult diffusion of the BIM process in the national and international market.

Furthermore, the elaborated flow can be the basis for possible future lines of investigation of the BIM model checking process. First it is possible to develop new flows that extend the check activity also to all other phases of the building process (schematic design, construction design, management), in relation to the respective objectives and uses. In this way, the complete panorama of checks that can be carried out against a BIM model in all the phases of the process would be available, favoring the continuity of the checking activity between one phase and another and guaranteeing, without any doubt, a very high quality of the asset. In addition, the proposed check flow could either be applied as presented or be checked and/or supplemented by each user on the basis of their own needs. The transposition of these customized flows within the rulesets present in the model checking software could favor their sharing on the network in order to streamline the process of configuring the rules which, as previously stated, is certainly time-consuming. These sets of rules could then constitute a sort of digital library of model checking available online, possibly subdivided according to the geographical location of the intervention, in order to unite all the controls that must comply with a specific regulation. In this sense, the development of a specific open format for these rulesets could guarantee interoperability between model checking software and allow each user to import the desired set of rules downloaded from the network into their own program, regardless of which it is. Another possible development concerns national technical regulation. The diffusion of the BIM methodology, favored by the compulsory introduction of the same in the public sphere when certain conditions are met, makes it increasingly necessary to provide, within a regulatory text, precise provisions relating to the model checking, which go beyond the drawing of simple general indications and can describe in detail the operations to be carried out, so as to define a “standard” process for all verifiers. In this sense, the check flow elaborated could represent just a base to start from, with the conscious need to extend the proposed model also to all the other phases of the building process. Taking into consideration, instead, the process of “business intelligence”, that is the company’s internal activity of data collection for the development of new strategies and technologies, there is the possibility, by adopting the proposed flow, to have output data of the check process always characterized by the same structure, which can be compared even within different projects in order to understand the areas in which the modelers commit more errors and in which the projects are more deficient, so as to have in hand the necessary tools to make conscious improvements to the entire process. Finally, a last important future development depends on the progressive evolution of model checking tools available on the market today. The possibility that, in the future, such software will implement the ability to automate an increasing number of checks would undoubtedly favor the spread of the model checking, which, to date, is still too anchored to traditional dynamics that are not very effective. In this sense, the ultimate goal would be to replace human checks completely (or almost completely) with automatic checks performed by computer systems; this could be possible through the use of artificial intelligences (AI) based on the experience of the experts which, after an initial configuration of the ruleset necessary to start the controls, are able to use the (hopefully few) basic information supplied to them to complete the analysis. This would allow a considerable reduction in the time and costs needed to implement the model checking process internally, thus overcoming two important limits to its diffusion.