Adapting to an OpenBIM Building Permit Process: A Case Study Using the Example of the City of Vienna

Abstract

The adoption of building information modelling (BIM) enables data-driven decision-making for many participants in the construction process. Building authorities are stakeholders that have not yet benefited from data integration using BIM. In many cases, parts of their processes have already improved through digitisation initiatives. Now they are on the threshold of a major digital transformation enabled by the integration of BIM into their processes. This study examines a building permit process based entirely on BIM, developed at the Vienna Building Authority in Austria. In a series of workshops with all important stakeholders, the current building permit process was captured in detail and transferred to a data-driven, BIM-based process. The study shows that the complete capture and digitisation of the building approval process not only enables the automation of traditional processes such as code compliance checks and neighbourhood hearings but also supports the introduction of innovative sub-processes such as a pre-check of BIM models and augmented reality-based hearings with neighbours (in a pilot phase). The results suggest that the developed process not only significantly increases the efficiency and transparency of building permit procedures, but also represents a decisive step towards integrating the authority into the BIM process of a building.

1. Introduction

Digitisation is one of the main topics of the building industry right now. More and more processes along the lifecycle of a building use digital model-based data (BIM data) and these models are integrated into a digitised workflow. Building information modelling (BIM) is a multi-faceted concept that, narrowly defined, refers to the collaboration of people, information systems, databases and software of construction projects throughout their lifecycle [1]. While this practice is common during the design phase, building permission is the first process in the lifecycle of a building that is not seamlessly integrated into the digitised workflow. In general, submission, review and examination of building designs are carried out based on 2D plans available in printed form or as a digital 2D plan (e.g., PDF)—with a few exceptions (e.g., Singapore [2,3,4]). This submission type represents an additional workload for BIM planners since conventional 2D plans must be generated from the models and enriched with further information. By this, only very little of the available model-based data generated during the design phase can be used in the permit process. The advantages of having BIM data in the building permit process, e.g., for automated building code checking, are lost. This massive media break can also lead to a significant gap in data integrity. This is a disadvantage for planners and building authorities.

The problem of the building permit process not being included in the BIM workflow and the potential of doing so was recognised already [5,6,7,8]. According to Noardo et al. [8], the building permit process is considered among the most promising use cases of automation through digitisation in the building industry. There are plenty of academic and practical digitisation efforts on this topic, but hardly any of these are holistically implemented in building authorities and in use already. Research and developments so far focus on specific parts of building permission. Noardo et al. [8] argued that this fragmentation of developments is due to the challenges of the many sub-processes the building permission process consists of. The process ranges from preparing and submitting the required documents over the code compliance checking procedure to disseminating information to the relevant parties, including many sub-processes and stakeholders. The information flow between these particular sub-processes of digital building permission has hardly been addressed, even though its importance is often stated [9]. Considering the entire process is essential for practical implementations.

This paper aims to fill the gap of missing holistic solutions for the digitised building permit process by presenting the Vienna Building Authority (Austria) example. The City of Vienna is, with 1.9 million citizens, by far the biggest city in Austria. Vienna’s building authority must deal with 13,000 building permit applications annually. Furthermore, in Vienna, the building permit process for building projects is almost exclusively carried out on paper. Therefore, their building authority officers sought digital support to handle this amount. This led to the research project BRISE-Vienna [10]. The BRISE project combines the technologies and methods of building information modelling (BIM), artificial intelligence (AI) [11] and augmented reality (AR) to create a model-based and semi-automated permit process. The central focus of the BRISE-Vienna project is the development of an openBIM permit process [12]. OpenBIM is a universal approach for the collaborative planning, realisation and operation of buildings based on open standards and workflows. It allows different stakeholders to participate in the BIM process regardless of the software used [13]. In terms of the authorities, this means a permit process based on digital building models in open formats. In the future, 2D plans should no longer be submitted. The submitted BIM models will then enable data-driven decision-making by the building authority and the integration of the data into other services of the building authority. We are, therefore, heading towards a data-integrated authority. The openBIM permission should be seamlessly integrated into openBIM project processes, terms, requirements and role models to leverage synergies and avoid redundant work.

This paper describes the adopted openBIM permit process in detail and thus, provides a holistic example, which has been missing in the literature so far. Moreover, the implementation of the system for a pilot phase in the Vienna Building Authority is presented to demonstrate the applicability of the developed processes. The paper is structured as follows: First, existing work on digital building permission and its shortcomings are summarised. Afterwards, Section 2 describes the methods and materials used to develop the new process. This includes describing the legal documents to be considered and the new digital elements to be developed. Section 3 presents the developed openBIM permit process in detail and Section 4 demonstrates the implementation during the pilot phase in BRISE-Vienna. These results are finally discussed and concluded in Section 5, presenting the direction in which digital building permission in Vienna heads.

Related Work

Noardo et al. [8] conducted a detailed review and analysis of the current status of research and projects concerning digital building permission. They found that the focus in recent years was on the development of new technologies for the digitisation of regulations and code compliance checking on top of that. Examples of attempts to translate and represent regulations written in natural language into a computer-interpretable format are found in [14,15,16,17,18,19,20]. Research on code compliance checking includes [5,7,21,22,23]. While refs. [5,7] describe general requirements and challenges in code compliance checking, refs. [21,22,23] present prototypical code compliance systems. Battisti et al. [21] developed automated checking rules for eight building regulations in Austria and implemented them in a prototype system. Some cover the addressed building regulation sufficiently, while others are simplifications and need further development to be used in an actual building permit process. Noardo et al. [22] focused on one building regulation of the city of Rotterdam and Olsson et al. [23] analysed two building regulations in Sweden. Both teams developed automated checking rules for their specific use cases.

While most approaches tackle specific parts of the entire process or focus on particular regulations only [8], there have also been few attempts to implement automated code checking systems as a part of the building permit process in building authorities. However, Beach et al. [6] state that hardly any approaches were adopted in practice. The most famous exception is the CORENET project of Singapore [2,3,4]. CORENET (Construction and Real Estate Network) is based on the IFC (Industry Foundation Classes) Viewer Fornax, which includes the functionality for automated model checks as described in [3]. IFC [24] is an ISO-standardised open format for digital building models and is globally distributed. CORENET uses IFC models as a basis and enhances the IFC objects to provide the necessary information for checking functions. The results of the code compliance checks are automatically summarised in checking reports. Two other and more recent attempts with a high level of detail include the projects of Estonia and South Korea. The project of the Tallinn City Government in Estonia is described in [25,26]. The backbone of the e-permission system is a web-based digital environment working on openBIM standards provided by MoEAC (Estonian Ministry of Economic Affairs and Communication). The platform includes the submission of BIM models, a graphical user interface and the functionality for BIM-based code compliance checking. A proof of concept for this platform was already in development in 2020 [25]. South Korea developed a prototypical system (KBim) for an IFC-based digital permit process [20,27,28]. They included four main modules in their system to address the challenges of (1) computer-interpretable rulemaking from existing written building code, (2) online building submission via IFC, (3) pre-checking to ensure data quality and (4) code compliance checking. Other attempts with different levels of detail include Great Britain and Norway [3]. They implemented e-permission systems for plans some time ago and enhanced them to process digital building models [26,27]. However, the building law is individual in each country [12], which makes the transferring of implemented solutions to other countries difficult [21,29].

Research showed that technology issues are not the only hurdle to BIM adoption in building authorities. According to Ullah et al. [25], other challenges are organisational structure-related and workforce qualification-related. Both of these challenges are related to the process of digital permission and its differences from the existing systems. There is some research on identifying the current process of building permission to determine requirements for digitisation and BIM adoption [30,31,32]. However, hardly any previous studies have described the adopted process for digital building permission. Exceptions are [21,27], but both do not provide the required level of detail. Another shortcoming of previous studies and implementations is their focus on particular steps of the process [9], mostly steps before and during the code compliance checking, leaving the plan review by relevant parties and the hearing process out of scope. In BRISE-Vienna, a focus was also set on including openBIM in these later stages of the permit process. This was realised by combining AR (augmented reality) and the IFC models to better distribute the information about the planned building to non-experts [33,34].

In conclusion, most previous attempts focus on specific parts of the process or specific regulations. A few very interesting prototypes and systems have been developed, but some aspects are missing in all of them. Moreover, the start of different new European projects on automating the building permit process (e.g., CHEK [35], DigiChecks [36], Accord [37]) in the last years emphasises the fact that research in this area is still very much needed.

2. Materials and Methods

For the development of a new digital building permit system, it is essential to understand the current systems, processes and their shortcomings as well as the goals that should be reached by the digitisation. To seamlessly integrate the building permit into the BIM workflow, a digital transformation of the existing processes must take place. In the first step, the core objectives for an openBIM permit process were defined in two workshops. All departments of the authority involved (building authority, surveying, urban planning, fire protection) and external experts (universities, BIM experts, Austrian Chamber of Architects and Civil Engineers) took part in these workshops. The result was the following four core objectives:

• model-based submission using the open IFC format [24],
• model-based communication using the open BIM Collaboration Format (BCF) [38],
• model-based semi-automatic code compliance checking and
• acceleration of procedures.

In Austria, the authorities are not allowed to dictate to planners which software they should use to produce the building application model (BAM). Submissions are therefore made in open formats. Therefore, the open formats IFC and BCF (from buildingSMART) were chosen. Based on these core objectives, the authors developed a maturity model that illustrates the gradual development of the permit process (Figure 1). The maturity model shows all parties involved in the current development state and defines the subsequent steps.

Level 0 describes the analogue state many building authorities have had to date or still have. The authority receives all documents in printed form and the officers check the printed documents. Building applicants can already submit some documents as PDF files. The first important step towards the digital transformation of the authorisation process is level 1, after a precise target/actual analysis: digital building submission. In this step, the authority develops a central web platform where building applicants can submit all submission documents online. Based on the type of construction process, the usage, the type of permission and the scope of the construction process, documents are defined that must be submitted (e.g., submission plan) or that are optional (e.g., securing of a parking space). The individual authorities’ databases are also merged in level 1. Level 2 involves the integration of BIM models. The submitted IFC model is the basis for model-based communication, checking, control and inspection of the submitted construction project. Communication between the authority and the building applicant is web-based. Level 2 builds on the web platform from level 1. The zoning and development plan and site-specific regulations usually only exist in paper form and 2D. Level 3 extends the model-based process such that the zoning and development plan and site-specific provisions are already available in machine-readable and three-dimensional form. This means all building lines and heights can be checked directly with the BIM model. Level 3 should also enable openBIM-based notification of completion to the authorities. Every owner must keep a so-called building book that lists all structurally relevant components. Maintenance intervals and the condition of the respective maintenance status must be noted in this list and submitted to the authorities at any time. In level 3, this building book should also be model-based. A similar maturity model was developed by Shahi et al. [4]. The two systems define levels 0–2 very similarly and differ only in the highest digitisation level. While the system developed in BRISE-Vienna introduces the integration of a machine-readable, model-based zoning and development plan, level 3 of Shahi et al. [4] focuses on the integration of geographical information system (GIS) and BIM.

The City of Vienna achieved level 1 in a previous project in 2019. The subsequent BRISE-Vienna project focused on level 2, integrating openBIM models. An as-is process survey served as a basis for the design of the openBIM permit process. The City of Vienna systematically conducted a study in which relevant department representatives were involved in workshops. In the subsequent phase, the authors analysed the recorded as-is processes and conducted a literature analysis. Analysing the current processes is essential to critically reflect on the existing process structures, redesign them, consider the available technologies and transform them digitally accordingly. By conducting expert interviews and workshops and considering the current process, the authors created the openBIM permit process. As part of the BRISE-Vienna research project, this process was implemented technically and continuously refined, implemented and finally tested in a pilot phase in collaboration with the building authorities and the City of Vienna’s ICT department (IT department). Figure 2 summarises the steps conducted for developing the openBIM permit process.

2.1. Initial Situation in Vienna—Existing Materials and Regulations

The backbone of the building permit is the legal basis—the legal building regulations. The central document for the City of Vienna is the Vienna Building Code [40]. The Vienna Building Code regulates, for example, procedures, buildability, rights and obligations of the persons involved in the permit process. The Vienna Building Code refers to secondary legislation, such as the Vienna Garage Law [41]. This regulates, among other things, the parking space obligation and garage requirements. These regulations are referred to as the building potential of the construction site. Technical specifications, in contrast, are summarised in the OIB guidelines [42]. While building regulations vary from province to province in Austria, the OIB guidelines harmonise the technical specifications for Austria. They are subdivided into OIB guidelines 1–6 and deal with regulations on stability, fire protection, health, safety in use, accessibility, sound insulation, energy saving and thermal insulation. Urban planning and land-use regulations are set out in the zoning and development plan. This plan is available on the City of Vienna website as a subset of the city map and can be viewed digitally [43]. The zoning and development plan contains information on the current zoning (type of zoning area, building class, construction method, special textual provisions, etc.) and other information relevant to planning, such as building restrictions, protection zones, public transport routes (underground trains, trams, etc.), cycle paths, educational facilities, nature conservation areas and interesting information on the subject of energy. The special textual provisions are an essential part of the zoning and development plan. They refer to a limited city area and describe special building regulations in text. These have been drawn up over the last 100 years and in some cases, they describe in great detail what development is permitted. For example, the textual regulations could state that all roofs in a particular area must be a flat roof and 60% of it has to be planted or that the minimum room height to certain streets must be 3 m. In addition, other official project-related specifications (e.g., urban landscape) from different administrative departments must be considered in the approval process for a building application.

2.2. Required Materials/Systems for openBIM Permission

An openBIM building permission aims to replace 2D permit plans with digital building models in open formats, enabling automatic checking and validation of the provided data within the permit process. First, this requires representing the information provided on permit plans in digital building models. In BRISE-Vienna, the building application model (BAM) was defined to represent the submitted project. Applicants must not be disadvantaged by the authoring software chosen to create the BAM. The authority can, therefore, not prescribe a software-specific format, but only an open format. Therefore, the ISO-standardised Industry Foundation Classes (IFC) format [24] was used in BRISE-Vienna. According to Krischmann et al. [12], the required information of permit planning is independent of the submitted format; both a permit plan and the building application model must contain the required information for the building authority. Since automating the building permit process is a new BIM use case, these requirements usually go beyond current exchange information requirements. However, the building application model is not a separately managed domain model. Instead, the typical architectural model is used, with additional geometric (level of geometry—LOG) and alphanumeric information (level of information—LOI) requirements for the building permission.

Another required system for an openBIM permission is a code compliance checking system, in which the digital building models can be validated in an automated manner. For this purpose, a computer-interpretable representation of the building code and the related documents is required. The objective is to convert the building code written in natural language into executable checking rules for each regulation, e.g., for escape route analysis [44]. The required checking rules can be categorised as checking rules for technical specifications for the building itself and the building potential of a construction site (e.g., building alignment, permitted building height and required roof shape). However, building code written in natural language is only partially suited for representation in automated checking rules [8]. Formulations without quantitative criteria require interpretation [18,19]. Therefore, the code compliance checking system should combine automated calculations with human oversight and human decision-making [44]. Besides the submitted plan, 2D plans related to the building regulations require an IFC representation. For the Vienna Building Code, this concerns the zoning and development plan of the construction site and its related special textual provisions. All requirements in these documents concerning geometric information are combined in the reference model (REM). It represents the 3D envelope of the permitted building space (e.g., possible construction height and building distances). In addition to the reference model, the so-called service information model (SIM) is generated from the alphanumeric requirements for the particular construction site (e.g., parking regulations). The service information model (geometrically a cube with a side length of 1 m) contains process-specific property sets.

The code compliance checking requires the combination of the three IFC models (BAM, REM and SIM) to form the Building Authority Checking Model (Figure 3). This overlay of the three models is checked against the automated checking rules to ensure the application meets the building code requirements. The connection of these digitised information representations can be realised on an online platform, where the submission and further information exchange between the applicant and the building authority takes place. This platform must be able to process IFC and BCF data and must be integrated into the IT environment of the building authority to ensure efficient data transfer to existing systems.

3. OpenBIM Building Permit Process

The aim of the BRISE-Vienna research project was not just to digitise individual steps, but to look at the whole process. A focus was on the steps necessary for the authorities to be able to check the submitted model for building code criteria. The entire openBIM permit process is represented by a BPMN2.0 graphic (Business Process Model and Notation). The process was divided into individual phases (see Figure 4):

• Phase 0: Project idea
• Phase 1: Creation and checking of the survey plan
• Phase 2: BAM pre-check
• Phase 3: Digital openBIM submission and checking [11,12,44]
• Phase 4: Neighbour review and hearing [33,34,45]
• Phase 5: Issue of the building permit

The initial event is a project idea from the client, who commissions a planner to evaluate the buildability of the property. The planner uses the zoning and development plan, textual provisions and building regulations to determine the scope of the possible development. After positive feedback from the client, the survey plan is commissioned.

3.1. Phase 1: Creation and Checking of the Survey Plan

In phase 1, the survey plan is created and checked. A survey plan comprises the exact geometry of a particular site and is the basis for planning a construction project. The building authority requires a digital survey plan for a BIM permit process, including the GIS-based location of the building lines in accordance with the zoning and development plan. The survey plan is the basis for the building application model. If no digital survey plan exists for the site, a survey planning office creates a survey plan (.dxf file) on behalf of the applicant. The process of creating the survey plan is described in Figure 5. The survey plan is created based on the information requested by the building authority in the exchange information requirements (EIRs). The EIRs define which elements, as well as their type and layer name, are to be included in the survey plan. This clear definition is necessary to enable the automatic generation of a reference model upon submission of the building application model. In addition, the precise definition enables the automatic checking of the survey plan for compliance with the formal criteria, increasing the plans’ quality and reducing the checking effort for the building authority. The plan author can use this automatic formal check before submission by uploading the survey plan to the authority’s front end and performing a pre-check. This pre-check automatically checks for compliance with the naming convention of element types and layer names used in the EIRs. The check has no legal validity but assures the plan author that the formal criteria have been met. Any formal errors can then be corrected before submission. However, this pre-check can be skipped and the survey documents can be submitted directly online to the authority. There, the same automatic formal checks as in the pre-check are performed.

Based on the checking report of this automatic formal check, the building authority officers begin the actual manual review of the survey plan and other documents. This step ensures the completeness of the documents and compliance with the EIRs. The results are recorded in a checking report, which is used to decide on approval. If approval is not possible, the checking report will contain the improvement requirements for the survey plan to be adapted accordingly. If approval is possible, the survey planning office will receive the approval for the survey plan. At the same time, the approval and the survey plan are stored in an internal authority database. The documents can be used for other purposes, e.g., the use of survey data to improve the existing data related to the city, such as the 3D city map. The procedure for this phase can be different in other cities. This step is not necessary if the city already has legally valid GIS-based data for the sites.

3.2. Phase 2: BAM Pre-Check

The digital transformation of the building permit process and adoption of openBIM enables the introduction of new phases, like the pre-check of the building application model (BAM) without submission to the building authority. This phase does not exist in the current permit process. The openBIM submission of digital building models allows for the semi-automatic checking of legal issues as the model data, unlike plans, are available in machine-readable form. Some checks can be fully automated. This is the basis for the development of the BAM pre-check process. The result is an automatic preliminary check of the building application model using a reduced set of checking rules. The process is shown in Figure 6.

First, the building application model is to be created following the authority’s exchange information requirements (EIRs). The designer or applicant uploads the building application model as an IFC file via an authority web service. General data about the building not included in the building application model are additionally entered into the web service (e.g., type of use and number of apartments). Based on this information, several permitting procedures are proposed to the applicant. These data enable the automatic selection of an application-specific rule set against which the building application model is checked. These rule sets contain as many checks as possible from the permit process and serve to increase the quality of the model. The rules should meet the following requirements to be included in the pre-check:

• Help the applicant to improve the quality of the model in the submission,
• Check the legal part fully automatically as often as wanted,
• Ensure high reliability and
• No submission to building authority.

The last point reduces the pre-check in Vienna to check the technical specifications of building regulations and exclude building potential related regulations (e.g., compliance with the building height and alignment lines), as they require the creation of the reference model. The reference model is only created upon the BAM submission to the building authority (see phase 3). The result of the BAM pre-check is an automatically generated checking report in BCF and PDF format. The checking report in the form of a BCF file summarises the results of the BAM pre-check in relation to the model element. The model author receives the BCF checking report and can import it into the BIM authoring software to view the errors. This makes it easier to correct the BIM model. The BAM pre-check can be carried out at any time, as often as required and from anywhere, but it does not constitute a submission and therefore, the checking report has no legal validity. It is a service provided by the building authority to improve the quality of the application documents when they are submitted later.

3.3. Phase 3: Digital openBIM Submission and Check

This phase is the central part of the openBIM permit process. It includes the submission and checking of all application documents (Figure 7). The openBIM submission and checking in phase 3 can be carried out without a BAM pre-check. In the first step, the applicant finalises the application documents. The application documents include the building application model and, depending on the building structure and procedure, further documents as PDF files. The applicant digitally authenticates themself on the website and uploads the building application model. Based on the metadata from the building application model, form fields for general information about the project are automatically filled in, e.g., address, author of the data and number of flats. The applicant can edit and complete these general information form fields. Based on the input, possible permission procedures are suggested, from which those desired can be selected. Once submitted, the building authority stores the data in an internal database and an electronic act is created in the central electronic administration system within the Austrian e-government, called ELAK. One of the main functions of this system includes the documentation of ongoing business processes and the generation of legally binding decisions. In ELAK, a separate electronic file is created for each individual building process, in which all approval processes and communications, for example, in the form of permit notification, are systematically recorded and archived.

Simultaneously, the corresponding approved survey plan and the special textual provisions of the submission are assigned via the specified address. The building authority then formally checks that all documents are available and signed. In the next step, the reference model is automatically generated from the submitted survey plan and checked by the building authority. The reference model represents the site’s legally possible building potential. At the same time, an artificial intelligence (AI) system analyses the special textual provisions and extracts the information that affects the submitted building. The results are properties with values relevant to the assessment (e.g., flat roof = true, planting min = 60%), which are stored in the database in a permit-specific manner. These values are checked and adjusted by the authority officers via a user interface. The properties are grouped into property sets and used for the generation of the service information model (SIM). In addition, alphanumeric requirements and information affecting the semi-automatic checking from other internal databases (e.g., energy certificates) and other departments are included in the creation of the service information model. The service information model and the features it contains, therefore, allow the model checking to be influenced in a transparent and application-specific way. The service information model is regenerated and archived each time a change is made. Examples of special textual provisions are:

• If the building is close to public transport, the required parking spaces can be reduced by up to 90%. Property: ReductionParkingspace = XX%
• The waste collection service can give a statement on the maximum ramp gradient for access to waste rooms below the legally prescribed gradient. Property: MaxRampInclination = XX%

The next step is automated checking of the building application model. The rule sets are taken from a selection checking catalogue, which is suggested based on the data in the application form (e.g., type of construction project). In the case of a repeated check due to a subsequent application or an already-approved building application model, this check considers old application data (building application model, checking report and rule sets) for an automatic version comparison, which can highlight changes compared to the old application data. The results of the check are model-based checking results. These are viewed and processed by the building authority. The building authority can decide whether further comments from other authority departments in the city are required. The enquiry and the comments are noted in the ELAK. Data relevant to the model check from comments are taken into account in the SIM.

If the departments have already integrated BIM into their processes, communication can be model-based via BCF files, similar to the classic openBIM processes. Once the authority has processed the model-based checking and considered any comments, the checking report is produced as a BCF file and a PDF file. In addition to the results of the code compliance checking, other application documents must be checked manually (e.g., fire protection concept). Further documents and expert reports may be generated as the checking results are processed. If the application documents do not comply with the legal requirements, a notice of correction will be issued in accordance with the General Administrative Procedure law of Austria and the results of the review (PDF and BFC file) will be attached. In addition to correcting the deviation from the legal requirements, the applicant may apply for an exemption. The possible exemptions are regulated in the Vienna Building Code. The building authority first checks the validity and then a district building committee decides whether to grant the exemption. This sub-process was out of the scope of the BRISE-Vienna research project. In principle, however, the same tools and processes can be used for the presentation to the building committee as for the neighbour review and hearing phase.

3.4. Phase 4: Neighbour Review and Hearing

In Vienna, neighbours as parties involved in the procedure can review the building submission and raise objections to the planned building. The inclusion of neighbours takes place in phase 4 after the openBIM check. So far, the neighbour review and hearing have been carried out using 2D submission plans. The main problem of the current process is the necessity of explaining the plan content to the neighbours involved (who, in most cases, are non-experts). This requires a significant amount of time for the building authority officers. An openBIM permit process enables 3D models and augmented reality to present the information to the people involved, which should increase the understanding of the planned building, even for non-experts.

The phase is shown in Figure 8, which is based on the technical description by Schranz et al. [34].

The first step is determining whether a hearing including the neighbours is required. In the next step, the building authority compiles the documents for review and hearing in the web service. The presentation of the building application model is reduced to the outer envelope of the building. This procedure is in line with the legal requirements in Vienna. Stakeholders can only raise objections about the building envelope but not, for example, the room layout. The possible objections are listed in the building code. The exclusive presentation of the building envelope also protects the client’s privacy and the designer’s intellectual property. The current 2D plan-based procedure does not provide this. Filtering the envelope elements of the model is conducted by the authority centrally using IfcEntity and Property (e.g., IfcWall and IsExternal = True). In addition to the building application model, the reference model is also available. The neighbouring buildings are also represented qualitatively. For this purpose, a section of the 3D city map of Vienna is extracted and overlaid with the building application model and reference model. In addition, specific check results can be selected from the building authority for the building hearing. The next step is to identify and inform the people involved (neighbours and other relevant people) about the possibility of reviewing the building application. The review takes place via tablets at the building authority. The relevant building project is downloaded by scanning the QR code on the invitation. People can then view it and submit objections. The objections are stored and available to the authority as model-based objections in the form of a BCF. The hearing takes place at the end of the review period, providing a final opportunity to raise objections. The hearing procedure is also model-based using augmented reality, with several tablets accessing the documents simultaneously. The tablets allow everyone to view the AR model from their perspective. The tablets can be synchronised to improve communication. When synchronised, the building authority employee can select and highlight specific components in the AR model, which are then displayed on all the tablets. Finally, the building authority reviews the objections by viewing the BCF and models in the checking software. If there are relevant objections according to the Vienna Building Code that cannot be taken into account with conditions in the permission notification, a request for rectification is sent to the applicant (see phase 3). If there are no objections relevant to the procedure, the issue of the building permit phase begins.

3.5. Phase 5: Issue of the Building Permit

Phase 5 includes the semi-automated creation of the issue of planning permission and calculation of fees as part of the openBIM approval process. Once this process has been successfully completed, the building authority will issue planning permission in the form of an official decision. If minor defects are identified during the openBIM review, it is possible for these to be noted as conditions in the decision, avoiding the need for re-drafting. The decision on this is the responsibility of the building authority. In an openBIM permit process, the data are directly available for machine processing. Fees can therefore be calculated semi-automatically using the application documents and results. The permit process is complete when the decision is issued. However, the data generated in the process (BAM, SIM) offer potential for downstream use in other government processes, such as automated updating of the housing register.

4. Implementation of the Process and Its Data Requirements

In BRISE-Vienna, a complete openBIM permit process has been developed. This includes preparing the required documents, submitting them, checking code compliance, communicating the results and negotiating the building project. In the first step, detailed process maps of the actual building permit process and the newly developed openBIM permit process [46] were created, both related to the City of Vienna. The defined new processes formed the basis for the implementation. The implementation took place on the City of Vienna’s test server, meaning that the entire data exchange took place via databases, but no connection to the ELAK was possible by using the test server. The creation of a legally effective notification is only possible via ELAK. Therefore, the pilot projects had to be submitted conventionally as 2D PDF plans in addition to the model submission to be legally approved. Phase 5 primarily involves steps in ELAK, i.e., this was not implemented on the test server but was carried out directly as part of the conventional submission in the existing system. The research project aimed to develop and test the individual components (survey plan pre-check and check, BAM pre-check, openBIM checking and AR review and hearing) and then gradually transfer them to the operational system after the research project. The entire workflow was implemented consistently to test it in the pilot phase.

Figure 9 shows an overview of the software ecosystem. Its parts and their purpose are explained in the following subsections.

4.1. Submission of Documents and Their Requirements

The external users interact with the system via an online submission platform of the City of Vienna. The two kinds of external users are applicants and surveyors. They use the platform to submit their building application model (.ifc) or survey plan (.dxf). The basis for this platform was the e-permission system for plans and documents. The platform was extended from the PDF upload in the original version to the integration of IFC and DXF for submission of the building application model and survey plan, as well as BCF for providing results.

Open data standards such as IFC and BCF ensure that planners are not restricted in their choice of BIM software. In addition, open data standards guarantee the long-term and independent use of data within the building authority. The data provided must meet specific requirements regardless of the modelling software selected. Each model must meet specific information requirements and modelling guidelines to ensure the compatibility of the models in the compliance checking system [26]. This requires a detailed and explicit definition of how objects must be modelled and which information they must contain. In BRISE-Vienna, the LOG and LOI requirements for each element were defined. These requirements for the building application model and reference model/survey plan are essential for an openBIM permit process. Only standardised data structures guarantee a semi-automatic check of the model. The requirements for the modelling data were developed in an iterative process. The first step focused on analysing relevant legal standards, including the Vienna Building Code, the OIB guidelines and the Vienna Garage Law. Paragraph by paragraph, it was assessed whether the paragraph was relevant to the building application model or the reference model. The extent to which an automatic or semi-automatic check could be implemented was assessed for each paragraph. The next step was to define the level of information (LOI) and level of geometry (LOG) for each potential model check. The results of this analysis phase were summarised in a table referred to within the project as the regulatory information matrix. Based on this well-founded documentation, the development of specific checking rules began. Considering the defined LOI and LOG, test models were created and the corresponding checking mechanisms were tested. The lessons learned were used to develop the LOI and LOG specifications and checking rules further. During the pilot phase, the planners created and submitted models considering these requirements. The experience gained led to a final adjustment of the LOI and LOG and checking rules. Significant changes were made based on feedback from the pilot phase, particularly in describing features and option sets, as some definitions were initially not sufficiently precise.

Figure 10 shows the LOI definition for an IfcWall. This LOI description was created for each element in the building application model. This documentation includes detailed information on the features or property sets. A distinction is made between standard features, which are defined in accordance with the ISO 16739-1 standard [24], and properties explicitly developed for the context of the building permit. The free text format (IfcLabel) was converted into a limited selection of options (option set) for specific properties. One example of this is the “Status” property, for which the options “New”, “Existing” and “Demolish” are predefined in the option set. This limitation of the selection options is necessary for a semi-automatic check. The formulated requirements were made available to the planning stakeholders as part of the project in PDF and Excel (XLSX) documents.

4.2. Checking System

The submission platform distinguishes between the pre-check (Phase 2) and the openBIM submission (Phase 3). The two options trigger different processes in the software landscape of the building authority. The BAM pre-check covers fully automated checks concerning the building application model only. At the beginning of the pilot phase, the pre-check was purely a classic LOI check, in which the existence of property per entity was checked in accordance with the information requirements. Whether the property has the correct value was not checked. The pre-check was continuously developed and now comprises four categories:

• LOI check,
• Plausibility check,
• Normative check (e.g., ISO, Austrian standards) and
• Technical specification check (e.g., Vienna Building Code, OIB guidelines and Vienna Garage Law).

The plausibility check includes the data’s logic in a building’s context. Examples are the presence of a foundation, the assignment of objects to the correct floor and an unusually high number of polygon points for an element. The normative check covers rules that are not in the building regulations but in the standards and are necessary for the quality of the submitted building, e.g., minimum object dimensions such as wall thickness. The technical specification check includes all fully automatic checks from the Vienna Building Code, OIB guidelines and the Vienna Garage Law that have been approved for the pre-check (check only requiring the building application model and not the reference model). Thus, the BAM pre-check only requires the submitted building application model and a part of the checking rules.

In contrast, the BAM submission contains all checks, including semi-automatic checks (checks that require interpretation) and requirements concerning the building potential of the construction site. Therefore, the BAM submission involves the creation of the reference model and service information model. The reference model is automatically generated from the survey plan using the FME Workbench software (version FME 2022.0). This automation can only be achieved if the components of the survey plan are designed according to a standardised data structure. In addition, the generation process requires a systematic mapping of the elements of the survey plan to the corresponding elements in the reference model. This step requires specific requirements for the reference model’s level of information (LOI) and level of geometry (LOG). The data requirements for the survey plan, reference model and mapping process have been developed in the same way as the definition of LOI and LOG for the building application model. Figure 11 shows an extract from the specified requirements for the survey plan and the reference model. The left-hand section gives a description and legal basis of the relevant elements. The middle section explains how the elements are to be geometrically represented and labelled in the survey plan. The right-hand section shows the corresponding component of the reference model generated from the information in the survey plan. In the reference model, the elements are managed under the IfcBuildingElementProxy entity and specified using the predefined type and the property TypeOfElement. The surveying plan pre-check only includes a classic LOI check, in which the existence of the label and element type in the surveying plan is checked. The quality check of the survey plan and the check of the generated reference model are carried out manually by the authority, which is why the reference model is only generated during the actual submission.

The special textual provisions influence the site’s development and have been described in text over the last 100 years. The project aimed to evaluate and test how these special textual provisions can be transformed into a machine-readable form using AI. This transformation allows the rules to be integrated into automated checking software. The first step was to manually analyse the textual provisions to identify key properties (attributes) relevant to model checking that occur frequently in the regulatory texts. The result was 100 properties that occur frequently in the various textual provisions and could be used for the BAM check. Based on these findings, the AI use case was launched [11]. As part of this application, the AI was first trained to recognise the relevant properties in the textual provisions. For the training, the pertinent properties of the provision texts were marked in several annotation phases by students and employees of the building authority. The training of the AI resulted in a ranking of the properties according to the probability of their recognition by the AI. The 24 properties with the highest likelihood of recognition were given gold status within the project. Based on this list of properties, specific conditions and property sets were developed in collaboration with technical experts to group the identified features into appropriate property sets for checking. In addition to automatically filling property sets, the instructor was able to manually fill predefined checking-relevant property sets via a web service. The results of AI analysis could also be reviewed and edited. These lists of filled property sets and properties were saved as a JSON file and converted to an IFC using IfcOpenShell. The result was the service information model, a model with a 1 m × 1 m cube containing property sets. The data in the service information model were now available for checking in the software.

BRISE-Vienna integrated Solibri Office (version 9.13.1) as BIM checking software. Solibri Office has the advantage of existing parameterised checking rules, which can cover most of the required checks and thus, reduce the development effort. For functionalities not covered by the existing checking rules, the software offers an API (application programming interface) to add individual checking rules using the programming language JAVA. According to the selected check (pre-check or submission), the autorun of Solibri Office loads the required models and selects all relevant rules (checking set—.cset).

On the one hand, the checking rules can be categorised according to the information they cover: LOI check, plausibility check, normative check, technical specification check or building potential check. On the other hand, they differ in the degree of automation: fully automated, semi-automated and graphical assistance rules. First, fully automated rules can check a regulation completely with the given information. Second, semi-automated rules require interpretation or decision-making after automated calculations. For example, the developed escape route analysis [44] can automatically create and check the escape routes along predefined courses. Still, due to the lack of a clear definition, a building authority officer has to decide whether the destination is a safe place. Third, graphical assistance rules can assist the building authority officers with regulations requiring interpretation. For example, objects that must be available “to a sufficient extent” can be highlighted to reduce the human search effort.

After the checking process, a checking report in BCF is created. For the pre-check, it is automatically provided via the submission platform and can be downloaded in PDF and BCF. For the BAM submission, building authority officers must verify the results and edit or comment on them beforehand. Another difference is that for a BAM submission, the building application model and the checking report are permanently stored in a building authority database.

4.3. AR Platform for the Neighbour Review and Hearing

After the building authority had reviewed the submitted project and determined that no improvements were necessary, the model-based AR-supported neighbour review and hearing took place. The platform was developed specifically for this purpose and is based on the knowledge gained from another project, AR-supported Teaching [45]. A fully web-based application was designed to manage the documents provided and to allow the responsible building authority officer to authorise viewing. The AR viewer was also integrated into the platform as a web-based component. The chosen full web version facilitates the integration into the existing IT infrastructure of the City of Vienna. The libraries ifc.js and three.js were used to process and render the IFC data, while WebXR was used to implement the augmented reality functionality. To participate in a test run of the review process, the test subjects were invited to access the AR-based review via a QR code. In the first step, the participants are presented with a pre-built model as a training scene, which is used to visualise and explain building law concepts step by step. For example, participants learn the definitions of building class and building height, including the methods used to measure these parameters. This is followed by the review and, in a subsequent step, the hearing process. All objections are stored model-based and viewed by the building authority on the platform. If, after reviewing the objections, the authority does not identify any improvements to the building application model, the model is released. This step also marks the end of the implementation on the test server in the BRISE-Vienna research project.

4.4. Competencies at the Building Authority

Implementing such a new technology and process requires a change in competencies and capabilities in the building authority. Building authority officers trained to assess buildings based on 2D plans must adapt to the use and maintenance of BIM checking rules. This paradigm shift requires the definition of new roles and training for the building authority officers [25,26]. In BRISE-Vienna, three roles were defined:

• building authority BIM basic user,
• building authority BIM officer and
• building authority BIM administrator.

The competencies of the roles build on each other step by step. The building authority BIM basic user has a fundamental understanding of openBIM and is familiar with the BIM permit process in general and the submission platform. This person can assist the applicants with the submission. The building authority BIM officer evaluates a submission using the new technology. This person is additionally capable of the code checking environment, including the execution and evaluation of the checking as well as the processing of results. By this, the building authority BIM officer can handle all tasks using the permission system. The building authority BIM administrator maintains the permit process, particularly the code compliance checking system. In addition to the mentioned competencies, this person must be capable of creating and editing checking rules and information requirements. Based on the stepwise structure of these competencies, a training concept was created that enhances the knowledge from one role to the next. During the project, building authority officers were trained to BIM basic users and BIM officers to conduct a pilot phase.

4.5. Pilot Phase

The objective of the pilot phase was to optimise the developed openBIM permit process under realistic circumstances. The pilot phase consisted of 24 real projects. The projects included one to six buildings per project and buildings with three to nine floors and ten to nearly three hundred units (offices, apartments). Thirteen of the related building application models (Figure 12) were submitted by planning offices. For 11 other projects, students used the documents of earlier approved projects as an information basis to create building application models. The submitted IFC models were created using three authoring software platforms: Archicad, Revit and Allplan.

The use of the implemented system in the pilot phase demonstrated the developed process’s applicability, from submitting documents via a web platform to the AR-based hearing process. Figure 13 shows excerpts of the implemented process during the pilot phase.

The first row shows the submission platform interface for the applicant (on the left) and the rule selection for the BAM pre-check in the checking software Solibri (on the right). The BAM pre-check consists of the LOI check, a plausibility check, a normative check and a reduced technical specification check (only fully automatic checking rules are included). The second and third rows show screenshots related to the openBIM check after submitting the building application model. In the second row is an overlay of the building application model and reference model (on the left) and the selection of checking rules for technical specification and building potential checks categorised in modules (on the right). The third row displays checking results from the semi-automated escape route analysis [44] developed in BRISE-Vienna. These results are communicated to the applicant via BCF after manual oversight by a building authority officer. The fourth row presents screenshots of the AR-based review and hearing process. The left picture shows the integration of the building application model and the reference model in the 3D city plan of Vienna for review by a neighbour. In the right picture, the use of AR during the hearing process is displayed.

5. Discussion

As part of BRISE-Vienna, the authors have researched and developed a comprehensive openBIM permit process. Such a comprehensive approach is unique among other research or projects on implementing an openBIM permit process. The developed process fills the research gap mentioned by Noardo et al. [8] that projects on building permission are fragmented and there are hardly any comprehensive solutions. BRISE-Vienna includes rethinking the traditional process and developing the necessary tools for a digitised building permit process from an online submission platform over an automated code checking system to an AR platform for the plan checking and hearing process. The pre-check of the building application model was introduced as an entirely new process step in the building permission of Vienna. However, while pre-checking is a sub-process that has also been introduced in other research projects on digital building permits [8,27], the consideration of the neighbour review and hearing process is a novel extension. The digital transformation was possible because the research project team involved all stakeholders in the approval process: the staff of the various departments of the building authority, the planners (Austrian Chamber of Architects and Civil Engineers), BIM consultants and researchers (TU Wien). As the critical stakeholders were actively involved as project partners, their experiences and needs could be incorporated into the new process. The involved people being a very important factor affecting BIM adoption was pointed out by Ullah et al. [26]. Based on the development process, the data requirements for the newly developed submission documents were defined.

The implementations and tests carried out during the pilot phase showed, in particular, the positive response to the BAM pre-check, which was rated as extremely positive by both the authorities and the planners. This procedure provides an automated, basic quality check before the actual building application is submitted. This reduces red tape, improves the quality of the building application model and speeds up the building application process. Most 2D plans are derived from models, so the quality improvement achieved by the BAM pre-check was also seen in the 2D plans.

In contrast, a challenge remains in the creation of the survey plan and reference model due to the manual review per submission and the error-prone, event-driven automatic generation of the reference model. This process is required by the legal framework of the City of Vienna, as the development plan is approved as a printed 2D plan. The identification of this problem highlights the need for a more efficient design of these process steps, for example, by using already digitally available geo-referenced data as the legal basis for a city-wide generation of the reference model. The next step would be to convert the 2D plans of the zoning and development plan into a 3D development plan. The already-defined requirements for the reference model cover lots of preliminary work for that. Ideally, the 3D development plan would be GIS-passed, so that a GIS-BIM integration must also be developed for the model check.

Another challenge concerns the use of existing checking software with regard to its integration in the City of Vienna’s IT infrastructure and its long-term availability. The City of Vienna’s IT infrastructure is now based on server solutions rather than desktop solutions. The checking software used, Solibri Office, is a desktop application. Thus, additional desktop computers had to be connected to the system to perform code compliance checking. This had disadvantages in terms of usability and maintenance. The building authority officers had to log into the system separately and also update Solibri individually when new versions were launched. The need to move to a server-based solution that can be integrated into the existing IT infrastructure is highlighted as a long-term goal. It must be ensured that the checking rules remain transparent and traceable and that the data be stored internally by the City of Vienna.

In general, the development and implementation of structured, machine-readable data requirements (BAM, REM, SIM) for the building permit process represent a significant step forward. They not only enable the automation of the checking process, but also open up new perspectives for digital transformation processes within the public administration landscape. The IFC-based data structuring forms the basis for a large number of potential use cases. Model-based neighbour review and hearing is one of these use cases that could only come about thanks to the data foundation. During the pilot phase, the authority identified other use cases for future development and research, for example, automatic filling of the housing register, handing over models to the fire brigade during operations and completion notice (as-built documentation). For designers, a standardised request for information (LOG and LOI) from the authority is also a major step forward in BIM design. The exchange information requirements for projects and the associated LOG and LOI requirements vary widely. Many designers in the pilot phase wanted confirmation that the BRISE model had been reviewed—a kind of seal of approval, as the approved BIM model met clear LOG and LOI requirements.

The presented openBIM permit process meets level 2 of the maturity model in Figure 1. The results of the research project are currently being transferred to the operational system. The first step is the introduction of the pre-check. In the pre-check, checking rules can be further tested for reliability before they are used with legal effect in the openBIM submission. The medium-term goal is to reach stage 3, where the zoning and development plan and textual provisions are available as a 3D model with parameterised machine-readable data. This means that the REM will always be available and can be used for the BAM pre-check. With the operational introduction of the openBIM permit process, an openBIM completion notice should ultimately also be possible with a time delay. The development of the BRISE-Vienna project shows the importance and potential of a digitised building permit process. It shows how such a process can be designed and the benefits it offers. The findings from BRISE-Vienna provide a valuable impetus for the further development of digital building permit processes and underline the importance of continuously adapting and optimising these processes to meet the requirements of modern and efficient authority. While the structure and content of building codes and the legal documents required for building permits vary locally and nationally [21,29], the challenges of developing a digital building permit process are similar. Existing research projects highlight, for example, the challenges of building code interpretation [17,18], ensuring model quality [22] and stakeholder acceptance [26]. Therefore, the concepts and processes developed are highly relevant to other building authorities, even if they have to consider different local characteristics.