Enhancing BIM security in emergency construction projects using lightweight blockchain-as-a-service

Abstract

Rapid design and construction of mobile cabin hospitals (MCHs) have become imperative in the COVID-19 response. However, due to unique design specifications (e.g., parallel design and model pre-revision), collaboration in emergency construction projects (ECPs) like MCHs presents data security vulnerabilities, including a lack of traceability and transparency. These hazards invariably reduce design effectiveness, leading to undesirable rework and project delay. Blockchain technology is a potential solution to address the aforementioned security issues in ECPs because it offers immutable and traceable data storage. Nevertheless, directly implementing blockchain in ECPs is impractical, for the blockchain has a complex deployment process and provides limited functions supporting BIM-based design. Therefore, this paper develops a lightweight blockchain-as-a-service (LBaaS) prototype to enhance the ECPs design efficiency by securing and automating information exchange while eliminating the difficulties of deploying and using blockchain. This paper contributes three elements: (1) Security vulnerabilities of design in ECP are identified. Taking an MCH in Hong Kong as an example, this paper investigates its design process and determines two design characteristics and associated security flaws. (2) Key technologies to support easy deployment and usage of blockchain in ECPs are developed. New technical elements, including a Multi-to-One mapping (MtOM) kit for easy blockchain registration, an integrated workflow retaining existing design practices, and smart contracts for secure interaction with blockchain, are developed to support LBaaS functionality. (3) An LBaaS prototype is validated and evaluated. The prototype is illustrated and evaluated using design examples based on actual MCH project data. Results show that the LBaaS is a feasible and secure approach for ECPs collaboration. This paper deepens the understanding of data security issues in ECPs and offers technical guidance in establishing blockchain solutions.

1. Introduction

The COVID-19 pandemic poses a severe threat to the public medical and health system throughout the world. Over 600 million confirmed cases and over 6 million deaths have been reported by November 2022 [1]. The escalating number of infected and suspected cases overwhelmed the admission capacity of designated hospitals [2]. Faced with such a grim situation, governments initiated a number of emergency construction projects (ECPs), building several mobile cabin hospitals (MCHs) to satisfy the huge demand of quarantine facilities for patients. MCHs, sometimes referred to as shelter hospitals or Fangcang hospitals, are a type of emergency service that assembles temporary hospitals out of containers in a modular fashion to address the ongoing scarcity of medical supplies [3]. For example, two large-scale MCHs, Huoshenshan hospital and Leishenshan hospital, were constructed and delivered at an ultra-rapid speed in Wuhan in early 2020, when the city was severely affected by the COVID-19 outbreak [4]. Nine MCHs were also built (or reformed) in Hong Kong to lessen the treatment pressures caused by the fifth wave of the omicron pandemic. Creating temporary MCHs is essential for saving lives and enhancing the recovery rate [5], facilitating the suppression of epidemic outbreaks.

MCHs share similarities with other emergency construction projects (ECPs), which generally have arduous tasks, complex design requirements, and short design and construction periods [6,7]. These requirements bring new challenges to design work and necessitate the adoption of Building information modeling (BIM) technology. BIM's benefits that enable fast design and construction have been verified in ECPs, including post-disaster recoveries [8,9] and MCH projects [2,10]. In the context of MCH, BIM contributes to the following three aspects: (1) Quickly checking container functions. The MCH adopts modular integrated construction (MiC). Thus, in the design phase, BIM visualizes each single MCH container (or ward) in 3D models so that clients, project managers, and stakeholders outside the construction domain (e.g., medical experts) can quickly and easily examine whether the container functions satisfy the demands [2]. (2) Facilitating design optimization. Instead of single container visualization, MCH design requires significant optimization efforts in container combination and mechanical, electrical, and plumbing (MEP) engineering, some of which cannot be finished purely by relying on experience. BIM in the MCH projects detects potential conflicts and bottlenecks to minimize changes throughout the building phase. Practices revealed that instead of complicating ECP projects, BIM reduces excessive repetitious work and design errors to free up valuable time to combat the pandemic [10]. (3) Enhancing design simulation. Ventilation in negative pressure systems is an essential concern in MCH design. In the Huoshenshan hospital and Leishenshan hospital cases, BIM has been used in conjunction with Computational Fluid Dynamics (CFD) software to analyze the effectiveness of negative pressure wards and model the spread of viruses [4]. Besides, BIM was also used to assess the impacts of MCH's contaminated air and waste gas discharge on the surrounding environment [2]. However, these simulations are not supported by traditional 2D drawings.

Despite these benefits, BIM security concerns from unique ECPs collaboration have inevitably impeded design efficiency. Three principal security vulnerabilities, weak transparency, no traceability, and time-consuming permission, are identified based on literature and interviews with BIM participants from an actual MCH project (Appendix A). The transparency problem is caused by the parallel design. Due to the lack of referenced models and a transparent collaboration environment, synchronizing BIM information among teams risks data omission and inconsistency, resulting in design errors and rework. Additionally, peer-to-peer (P2P) communication leads to inadequate traceability. This communication style sometimes is messy and ineffective for lacking traceable records, making coordination time-consuming and inefficient. For example, as designers work in a “relay race” way that each member takes turns to complete parts of the model, the designer being reached out to may not know the detail of the problem if he/she just took over the job from another designer (the issue proposer). The last problem occurs due to the pre-revision mechanism. Raising issues and pre-revising require manual permissions and signatures, which are cumbersome and insecure as it is challenging to audit signature authenticity in such urgent projects. Although cloud-based approaches have been implemented to strengthen design information sharing and communication in ECPs, the security risks that have adversely affected the design work have not been thoroughly solved. For example, BIM data are often placed in a centralized project server or a third-party BIM cloud platform, risking the vulnerability of single-point-failure [11] and denial of access [12] like the Trant case [13] in 2017, thereby leading to data loss and even project interruption. Moreover, in the MCH project, since time constraints and complex organizations, online folders are often established to share non-graphic documents without fine-grained access control. Thus, modifications or unintentional deletions cannot be traced and recovered.

Blockchain, known as distributed ledger technology, is a promising complement to existing BIM platforms [14]. Blockchain is a decentralized database paradigm that integrates multiple technologies to build a secure and transparent collaboration network [15]. The benefits of blockchain in construction payment [16,17], supply chain management [18,19], and design collaboration [12,20] have been preliminarily investigated. Recent studies have attempted to integrate blockchain in BIM-based collaborative design. For example, Celik et al. [21]proposed a blockchain-based BIM data provenance model to support information exchange. Results show that blockchain removes additional data verification and enforces continual sharing of information across disciplines by tagging “blockchain proof” to each BIM metadata, including attributes of objects and identification of organizations. Tao et al. [12] created a distributed BIM common data environment (CDE) combining blockchain and interplanetary file system (IPFS) to augment the robustness of BIM storage against single database crashes. Abhinaw et al. [20] developed a prototype leveraging blockchain and smart contracts to streamline the process and control design liability. New workflows in the prototype validated that the blockchain-aided solutions outperformed existing BIM systems in information exchange automation and design recode traceability. Nawari et al. [22] investigated post-disaster recovery projects for the ECP projects. They claimed that the employment of BIM and blockchain could assist in rebuilding after-disaster events by reducing the time and resources needed to issue design permission.

However, incorporating blockchain into BIM in ECPs encounters two barriers: (1) Limited functions supporting BIM collaboration and (2) Ineffective implementation. First, instead of commercial collaboration, blockchain was initially designed for bitcoin trading [22]. Despite the recent emergence of new blockchain platforms for more widespread commercial uses, complex BIM design only obtains limited feature support in a single blockchain. Second, the deployment and registration processes for blockchains are complex engineering processes that are prone to error [23], which is not allowed in ECPs. Typical mistakes like generating wrong configuration files or downloading discarded components will fail blockchain connection and registration. Considering the vast commercial potentials of blockchain, tech giants like IBM [24] and Amazon [25] have proposed Blockchain-as-a-service (BaaS), which is a kind of cloud service that combines cloud computing and blockchain to enable users to build, configure and manage their blockchain applications, ignoring the complexity of the underlying architecture [22]. However, these BaaSs are “heavy” as they encapsulate multiple modules (e.g., subscription module, deployment module, business selection modules, logic define module, etc.) that are not easy to configure. Some modules are even unnecessary and will increase the operation difficulty. Moreover, construction or BIM-related collaboration services have not been offered in these BaaSs. Project members have to devote extra efforts to adapt to the new platform and even conduct secondary development on them, which is impractical in ECPs with a rapid construction schedule. Recent studies have explored the potential of BaaS in BIM-based MiC supply chain management [26] and BIM security management [27]. However, BaaS research in BIM is still in its infancy, and very few efforts have been devoted to BIM-based design collaboration, let alone collaboration under the context of ECPs. Two research gaps are identified: (1) there is a lack of an easy-to-use blockchain solution that enables secure and efficient BIM collaboration in ECPs, and (2) there is a lack of evaluation on how the blockchain solution promotes BIM collaboration and delivery.

Therefore, this paper develops a lightweight blockchain-as-a-service (LBaaS) prototype to enhance BIM design efficiency in ECPs by securing and automating information exchange while eliminating the difficulties of deploying and using blockchain. Compared with existing BaaS products that would complicate the ECPs process, the proposed “lightweight” BaaS focuses on BIM-related activities, remains consistent ECPs collaboration manners, and eases blockchain access. Three specific research objectives are:

• •To identify security vulnerabilities compromising BIM design efficiency in ECPs. As the fundamental step towards developing an LBaaS, the characteristics of ECP collaboration are outlined based on an MCH project design workflow in Hong Kong. An analysis of BIM vulnerabilities that harm BIM efficiency is conducted to highlight the benefits and necessity of integrating with blockchain.
• •To develop key technologies to support easy deployment and usage of blockchain in ECPs. Requirements and principles of creating an LBaaS are determined based on ISO 19650 standards [28] and interviews with BIM participants in an actual MCH project. These principles aim at minimizing the degradation of the design process by blockchain and preserving existing design practices. Furthermore, a technical framework is designed to indicate the development roadmap and highlight the technical contributions. In response to mentioned principles, three key technical elements are created. First, a multi-to-one mapping (MtOM) kit is developed for efficient user registration to the blockchain. Second, a new workflow combing current design habits with blockchain is designed to demonstrate how to uphold consistent design practices in a distributed context. Third, three blockchain smart contracts are coded to respectively automate information sharing, permission execution, and history data retrieval.
• •To evaluate the performance of LBaaS in ECPs. An LBaaS prototype is developed and validated in an MCH project design example in Hong Kong. Furthermore, five types of assessments are conducted to assess how the LBaaS is conducive to rapid BIM design collaboration and delivery. These evaluations include (1) qualitative and quantitative evaluation of design performance, (2) computing performance evaluation, (3) LBaaS security evaluation, (4) requirements evaluation, and (5) standard design science research (DSR) evaluation.

The research scope and data are based on an actual MCH project in Hong Kong, such that the practical data requirement and methodological demand of ECPs are identified effectively. Notably, the LBaaS is designed as a generic prototype that also applies to other ECPs in other counties or regions for it incorporates core features of BIM design, utilizes open-source blockchain services, accepts openBIM and native BIM formats, and complies with international standards (i.e., ISO 19650 standards). To avoid ambiguity, the term “ECP”—which is more widely used—is used to refer to the target projects in this paper. The remainder of this paper is organized as follows: Section 2 reviews BIM's benefits in ECPs and blockchain implementations in the construction industry to strengthen the research gap. Section 3 details the development of the LBaaS following a design science research (DSR) method. Section 4 shows the validation process and evaluation results. Section 5 discusses the novelties and limitations of the proposed methods. The conclusion and future work are presented in Section 6.

2. Literature review

2.1. BIM-based design in ECPs

ECPs are typically more challenging than conventional projects because of their intricate design processes, constrained timelines, and extensive technical requirements [29]. For instance, only swift coordination of human, financial, and material resources could have ensured that the design and construction of Huoshenshan hospital and Leishenshan hospital took only 9 and 12 days, respectively [6]. Within these investments, BIM plays a vital role by incorporating organization and process information into a shared container to streamline the coordination for efficiently creating, sharing, and collecting digital information to encourage collaboration [2]. In MCH design, BIM is superior to 2D drawings in visualization and simulation. Using 3D models, designers can quickly examine the functions and design details of containers, which speeds up container manufacturing and delivery. Furthermore, MEP engineering among containers demands abundant design optimization and adjusting before construction. Visualizing pipeline and medical equipment installation schemes supports efficient error detection and fast decision-making. Correcting or optimizing these problems in the design phase is conducive to minimizing difficulties in downstream works, thus, shortening project time. Besides, various design solutions, including ventilations in negative pressure wards and internal layout plans, can be simulated and rehearsed using BIM to improve design quality [3]. Zhou et al. [4] introduced that computational fluid dynamics based on BIM were used for analyzing the airflow and pollutant concentration in MCHs under different ventilation schemes.

Nevertheless, BIM implementations in ECPs suffer from several security weaknesses that severely harm design productivity. The lack of a transparent environment for cooperation, for instance, can cause information received by different domains to be incongruous. Moreover, no traceable design records are provided for time limitations and workforce shortages, causing wasting time in locating design problems and finding accountable designers. Furthermore, manual signing in model “pre-revision” in ECPs has proven inefficient and insecure. Although approaches like cloud repositories (e.g., OneDrive [30] and Dropbox [31]) have been used, these centralized tools are easy to tamper with intentionally or unintentionally, affecting the data integrity and authenticity [14].

2.2. Blockchain in BIM-based collaboration

Fig. 1 shows a conceptual framework of blockchain. Blockchain employs a distributed P2P network without a central administration (Fig. 1 (a)) to prevent unilateral control. Fig. 1 (b) details the data structure of the blockchain ledger, in which each block consists of the current block hash, transaction data, and previous hash [32]. The current block hash, representing the digital digest of the block data, is embedded in the next block and chained by a hash link. Hash is an irreversible function that can convert any arbitrary size to fixed-size values [33]. Fig. 1 (c) shows that modification on data in block n leads to a different block hash, thus invalidating all followed hash links. In other words, if a peer manipulates his/her own data copy, he/she will be discarded by the blockchain. Transparency is achieved as any shared transaction will be broadcasted to all peers to reach a data consensus [34].

Fig. 1.

Conceptual framework of blockchain.

Although initial studies have implemented the nascent blockchain in construction [[35], [36], [37], [38]], efforts to integrate blockchain with BIM are still minimal. Existing research regarding blockchain-BIM integration can be generally categorized into three groups: (1) exploring the potentials and benefits of blockchain in BIM, (2) investigating BIM storage in a blockchain, and (3) designing workflows or mechanisms of BIM collaboration in a blockchain. For the first group, Li et al. [39] recommended leveraging blockchain, smart contracts, IoT, and BIM to promote facilities management by tracing components with problems and duplication work. Nawari et al. [40] highlighted that blockchain could provide reliable data storage and management of permissions and ensure BIM change tracing and data ownership. A report from the Institution of Civil Engineers (ICE) [41] indicated that blockchain has the capability to automate BIM review processes by invoking smart contracts. Placing BIM data in a blockchain (the second research category) is an obstacle for blockchain is unsuitable for storing non‑tiny files (e.g., BIM models in megabytes or gigabytes) owing to the block size [42]. Therefore, some studies suggested only putting partial BIM data to alleviate the storage pressure [43,44]. Xue et al. [45] proposed a semantic-based solution to extract BIM changes from files in OpenBIM standards like Industry Foundation Classes (IFC). Tao et al. [12] introduced a distributed common data environment (DCDE) framework in which BIM source data were stored in Interplanetary File System (IPFS), while the generated hyperlink, a unique hash value called content ID, was shared in blockchain for BIM data accessing. Additionally, a confidentiality-mined solution combining blockchain and asymmetric encryption was developed to prevent unauthorized access to sensitive BIM data in a blockchain [46]. In the third group, Dounas et al. [47] explored four methods of integration, namely, (i) entirely operating blockchain in a BIM software; (ii) connecting blockchain and BIM via cloud-based services; (iii) combining blockchain and BIM via blockchain service (e.g., BaaS) and (iv) running BIM services as a decentralized blockchain. Erri Pradeep et al. [20] illustrated three BIM-based design workflows in a blockchain: design review process, design coordination process, and request for information process. These workflows provided lucid references for adopting blockchain to control design liability and accountability. Hamledari et al. [17] designed a workflow that connected BIM, blockchain, and robotics for progress monitoring and payment automation. The findings demonstrated that blockchain provided advantageous functionalities to eliminate BIM data duplications and guarantee consistency without depending on gatekeepers.

However, integrating the blockchain in BIM is still problematic. Due to the complexity of blockchain technology, learning curves for developers and other project participants may be severe [23]. Deploying a consortium blockchain, Hyperledger Fabric [48], for example, is an error-prone and complex process that includes actions like P2P interconnection, smart contract coding, docker container configuration, and private key generation. After building a blockchain, users still need to devote much energy to learning how to operate and coordinate. Moreover, functions of a solo blockchain are too scarce to support BIM-based design collaboration, which requires a comprehensive and systematic technical solution. These limitations necessitate the development of blockchain-as-a-service (BaaS).

2.3. Blockchain-as-a-service (BaaS)

BaaS is a rapidly emerging technology that embeds blockchain services into computing platforms to bring efficiencies regarding the development, deployment, and usage of blockchain applications [49]. Similar to Software-as-a-service (SaaS), the BaaS platform leverages the advantages of cloud infrastructures to provide users with convenient, high-performance blockchain service [50]. The suitability of BaaS in ECPs lies in three aspects: (1) Providing a secure and efficient environment for design collaboration. BaaS owns all characteristics of blockchain that assist a transparent, traceable, and immutable collaboration network for quick information exchange, verification, and automated permission; therefore, a significant amount of time could be saved, and rework could be avoided. (2) Offering rich functions for BIM-based design. One primary concern about using blockchain is that it may complicate the BIM process for its laborious deployment. Deployment of BaaS is easy and fast as all blockchain services have been encapsulated, making blockchain more workable and accessible [51]. Furthermore, other functional modules (e.g., user interface, BIM database management, and design issue resolution) can also be embedded in a BaaS for a completed software ecosystem. In this way, users, such as a construction team, can focus more on frontend logic and explore how to apply the blockchain appropriately to their business scenarios rather than devote significant efforts to building a blockchain platform from the bottom [52]. (3) Enabling fast BIM data delivery. Delivering completed BIM data from the design team to the construction team is a challenge in ECPs. BaaS keeps unchangeable and auditable BIM data. Consequently, fewer disputes would happen, making the data transfer more efficient.

Tech giants like Amazon, Huawei, and IBM have jumped on the bandwagon and started providing BaaS products; however, these services are costly. For example, Amazon BaaS charges 241 dollars per month per blockchain peer for providing one-gigabyte storage [25]. The price of IBM BaaS is 0.29 dollars per hour per peer with only one computing CPU [24]. Huawei fees 1.17 dollars per hour per peer [53]. Furthermore, these products are considered “heavy” and unsuitable for ECP collaboration as they cover multiple business scenarios; thus, some unnecessary features hinder the usage efficiency. Moreover, features supporting BIM collaboration are not available. BaaS is also gaining interest in the construction industry. For example, Wu et al. [11] introduced a BaaS IoT-BIM platform for off-site production management in MiC. This BaaS provides interfaces displaying BIM models and semantics. Furthermore, blockchain ledgers and smart contracts are integrated to secure supply chain traceability. Li et al. [26] stated that implementing blockchain in BIM management suffers a deep technical curve as blockchain development covers multiple technical stacks and complex coding works. Baas, which removes the difficulties of the foundation development of blockchain, alleviates the barriers of blockchain usage, thus creating enormous opportunities for secure BIM management. Bachtobji et al. [54] discussed applications of BaaS in BIM data management. A BaaS architecture containing blockchain, IoT, fog, and cloud layers is proposed to enhance BIM security regarding its ownership and privacy. Siountri et al. [27] asserted that BIM modules could be embedded in BaaS, which serves as an easy-to-use supplementary to existing BIM systems.

However, BaaS development in construction is still in the exploratory stage. Current BaaS solutions cannot be implemented in ECPs for two limitations: (1) Limited works have explored BaaS for BIM-based design, especially design collaboration in ECPs. Thus, the mechanism of integrating ECP design requirements and workflows with BaaS is still awaiting investigation. (2) BaaS technical elements that enable secure and efficient BIM collaboration in ECPs have not been developed. Therefore, this paper presents an easy-to-use lightweight blockchain-as-a-service (LBaaS) to boost data security and allow smooth BIM-based collaboration.

3. Methodology

The development of the LBaaS follows the design science research (DSR) approach, which is a problem-solving paradigm that seeks to advance human knowledge by creating innovative artifacts [55]. The artifacts can be algorithms, prototypes, frameworks, or models [56]. Studies [11,20] have embraced DSR to develop blockchain applications in the construction industry. Fig. 2 presents a DSR process to build a lightweight blockchain-as-a-service (LBaaS) prototype for ECP BIM design with six DSR steps:

Fig. 2.

Methodology based on design science research approach.

(1) Identification of the problem and motivation. The research problem is stated in Section 1 that there is a lack of easy-to-use blockchain solutions for secure BIM collaborative design in ECPs, resulting in low design efficiency.

(2) Definition of objectives. This work aims to develop an LBaaS to secure BIM data while fitting ECPs requirements. Three specific objectives, namely, identifying security vulnerabilities, developing key technologies, and evaluating LBaaS performance, are shown in Section 1.

(3) Design and development. Section 3 displays the development process. Taking a mobile cabin hospital (MCH) project in Hong Kong as a case, Section 3.1 shows workflows of design collaboration based on interviews with BIM managers and designers in this project. Three characteristics of BIM-based design are summarized. Also, corresponding security risks are analyzed to highlight the merits and suitability of blockchain. In Section 3.2, three development principles and LBaaS architecture are proposed ISO 19650 standards [28] and brainstorming with BIM participants so that the raised prototype can meet their needs. An appropriate blockchain platform named Hyperledger Fabric is selected and deployed in LBaaS for four reasons: (i) it is one of the mainstream open-source blockchains whose feasibility has been validated in construction, (ii) it is a privacy-protection platform that only authorized members can access the ledger data [46], (iii) it has high flexibility that developers can configure any modular according to specific business scenarios [57], and (iv) it removes the “mining” mechanism in Bitcoin blockchain that consumes large amounts of computing [58]. According to the designed roadmap, three core technical components, a Multi-to-One mapping (MtOM) kit, an integrated workflow, and blockchain smart contracts are developed in Section 3.3 to support prototype functions. (i) MtOM kit. Registration to a blockchain is a complex process. Furthermore, the computing pressure will be high if each user joins LBaaS as one blockchain node. Actually, most blockchain users are not motivated to maintain a blockchain node in non-financial and ephemeral businesses. Whether the underlying database is a decentralized blockchain or a centralized repository does not matter to them [59]. Thus, a MtOM kit is developed for efficient blockchain registration. (ii) Integrated workflow. The blockchain and BIM collaboration are loosely coupled for the mismatch between blockchain operations and ECPs' unique workflows. A design workflow that integrates blockchain (or BaaS) and complies with existing collaboration practices is presented. (iii) Smart contract. An information-sharing smart contract is developed to exchange BIM information. A history query smart contract is coded for fast query design information in a blockchain ledger. Issue permission is automated by a permission execution smart contract, which advances existing manual signature by generating tagging verifiable hash identity to any data.

(4) Demonstration. The LBaaS is illustrated in a design example of an MCH project to validate its workability (Section 4). Two design scenarios with different purposes are presented to test developed components.

(5) Evaluation of the solution. DSR requires comparing research objectives with the artifact. Therefore, quantitative and qualitative evaluations on LBaaS are conducted in Section 4.

(6) Communication. The utility and effectiveness of the LBaaS should be reached to researchers and industry professionals. A prototype demo is shown to BIM participants to receive feedback, and the development process is published in academic journals.

3.1. Analysis of cyber security vulnerability

Common BIM security risks have been revealed in a study by Das et al. [14], who delivered valuable and solid references for BIM vulnerability analysis. However, where these vulnerabilities exist and how they happen in ECPs have not been deeply investigated due to the limited number of actual cases. In this study, an interview was performed via online meeting with one BIM manager and two designers who directly participated in an MCH project and knew the detailed process of BIM implementation. Data collection lasted one week in March of 2022, when this MCH was finished in Hong Kong. Seven questions have been raised to explore how BIM is used and what benefits BIM brings to the MCH project. These questions are: (1) What is the role of BIM in MCH design? (2) How BIM benefits MCH design? (3) What teams/parties have participated in the BIM modeling? (4) What BIM tools are used in the MCH project? (5) What is the workflow of BIM-based collaboration in MCH? (6) What are the differences in BIM design between MCH generic projects? What new challenges are there? (7) Suggestions/Recommendations on improving ECPs design? The interview outline and critical points of answers are attached in Appendix A.

Communications with the BIM team help us present a workflow of BIM collaborative design in Fig. 3 , which involves four main tasks: (1) parallel model building and cross-domain collaboration, (2) design issue initialization and permission, (3) issue response and CDA drawing revision, and (4) BIM model federation and validation.

Fig. 3.

Workflow of BIM-based design collaboration in the MCH project.

In ECPs, 2D drawings are often initially created to show the design objectives and anticipated results (Step 1). Unlike general construction in which BIM models are established in sequence (e.g., the structural model is built referencing the architectural model), models in the MCH project are developed separately and in parallel (Step 2). Three BIM teams, namely architecture modeling team, equipment modeling team, and pipeline & ventilation modeling team, participate in MCH model creation. The model builds within a domain like a relay race, in which multiple designers work on the same model one by one. One designer may work in the daytime, and another will take over at night to accelerate the design process. Whenever a design problem happens, the proposed issue (Step 3) will be reviewed by several parties before reaching the client team. Firstly, the domain leader will judge if this is an issue; if yes, it will be passed to the next party with an approval signature or rejected (Step 4). Then, the technical engineer will send the issue to the next party with a signature if it cannot be solved internally (Step 5). Finally, the quality manager will review if the problem is related to mandatory standards. If yes, he/she will sign (Step 6) and form an issue to the client and drawing team to request solutions (Step 7). Since no regular coordination meetings are held in ECPs, the client team will perform P2P coordination (i.e., contact the issue proposer directly) via informal phone calls or virtual meetings (Step 8) to quickly form a potential solution (Step 9). And then, the solution is signed (Step 10) and finalized in a solution sheet (Step 11), which is then shared with all domains. To shorten the design period, designers will pre-revise BIM models before the updated drawings are available (Step 12). Meanwhile, the client team will update the drawings accordingly (Step 13) and deliver them to the BIM design team (Step 14) for model comparison and verification (Step 15). After that, models from different domains will be gathered (Step 16) and federated based on the base point (Step 17). The verified federated model is then delivered for downstream works (Step 18).

In summary, how the workflow accelerates the BIM design process lies in three aspects. The first advantage is parallel design In Step 2. Unlike general construction projects where BIM models of different disciplines are developed sequentially, several models are produced simultaneously in this MCH project, saving time waiting. The second benefit is P2P communication in Step 8. Given the time striction, no regular meetings are held for BIM coordination. Instead, a P2P communication style is employed in which project members contact accountable designers directly and personally via virtual meetings or phone conversations when design problems arise. This is proven to be an efficient way to ease communication since unnecessary meetings are avoided, and design issues can be figured out quickly by accountable people. The last merit is pre-revision in Step 12. BIM models in ECPs are built based on 2D drawings. Pre-revision means that BIM model problems or design issues can be solved before the client issues formal revised drawings or documents, avoiding wasted time waiting. Leveraging this workflow, only two days were taken to deliver the BIM models (in the first finalized version).

However, security flaws are also caused by such unique collaboration methods (Fig. 4 ). Fig. 3 shows that each model is developed independently without referenced models in the parallel design. However, there is a lack of a transparent channel to synchronize updated information, resulting in discrepancies among models, design errors, and delays. Blockchain shows the potential to secure transparent data exchange. Furthermore, during the P2P discussion, the BIM manager complained that they often wasted time tracing design records when solving issues, for no efficient logging tools have been applied in ECPs. Blockchain can immutably record all design logs and actions to strengthen collaboration traceability. Pre-revision requires permission from multiple parties. Physical signing is time-consuming and laborious to verify signature authenticity. Combined with smart contracts, blockchain can automate permission executions and provide unforgeable digital signatures.

Fig. 4.

Security vulnerabilities in the mobile cabin hospital project.

3.2. Principles and technical stacks of developing the LBaaS10

3.2.1. Principles

The development of the LBaaS should comply with the requirements and characteristics of ECPs. Therefore, three principles are proposed in Fig. 5 : (1) easier usage of blockchain, (2) consistent manner for BIM collaboration, and (3) secure BIM data management.

Fig. 5.

Principles and requirements for developing the LBaaS.

The first principle aims to improve the applicability and efficiency of blockchain services in ECPs. The blockchain services (i.e., Hyperledger Fabric) are directly packaged in the LBaaS without users' additional efforts for configuration. Furthermore, blockchain registration is daunting even for sophisticated blockchain engineers since adding a new project member will take much time. Therefore, a new Multi-to-One Mapping (MtOM) kit is developed in the LBaaS to simplify blockchain registration (Section 3.3.1).

The second principle highlights that blockchain supplements existing BIM software, procedures, and standards instead of a replacement. However, most blockchain users are not motivated to maintain a blockchain node for ephemeral business collaboration, let alone internal BIM collaboration within one project [59]. What makes a difference for users is not whether the underlying blockchain is decentralized but whether the work logic and collaboration conventions have been changed. Thus, the new LBaaS should keep collaboration conventions to reduce the time for adaptation. An integrated workflow consisting of existing ECPs practices and blockchain merits is designed in Section 3.3.2 to ensure data transparency and consistency.

The third emphasizes that blockchain should secure data integrity, traceability, and unforgeability in the design process. The latest ISO 19650-5 standard [28] encourages utilizing security-minded and risk-based approaches to secure BIM processes. Two important security aspects, integrity and authenticity, are recommended. Data integrity can be achieved by maintaining the completeness, accuracy, consistency, and coherence of BIM information. Authenticity refers to data input and output from a system being genuine. Accordingly, two actions are taken in the LBaaS: adding data fingerprints and developing smart contracts. A fingerprint-hash value of data is automatically generated for each shared data and stored in the blockchain as data integrity proof. Besides, three new smart contracts are designed and codded in Section 3.3.3 to accelerate information exchange and design permission.

3.2.2. Technical stack

A prototype architecture is designed in Fig. 6 in compliance with the proposed principles. The architecture containing seven layers illustrates the technical stack in building an LBaaS prototype. Users in the user layer can register to the LBaaS via the application layer, which offers a frontend for user management. The application layer enables collaboration activities (e.g., model management and design issue management) and automatically registers users to blockchain services in the blockchain layer via a MtOM kit. In this way, user operations can be recorded in the blockchain. Such “one-stop” registration alleviates users' difficulties in accessing blockchains as they only perform normal registration procedures like on other SaaS platforms. In addition, the blockchain layer has a blockchain core service and a testing service for administrators or developers to maintain the LBaaS. Smart contracts in the smart contract layer execute the interaction between the backend blockchain databases and the frontend inputs. Collaboration actions will be described as event transactions, including model event transactions (metadata of actions regarding BIM models), issue event transactions (metadata of actions related to design issues), and permission transactions (metadata of permission execution). Except for on-chain data (transactions), an off-chain database (e.g., a local server or cloud server like Autodesk BIM 360 [60]) layer is also utilized to place large-sized data like BIM models and non-graphic documents. A digital signature generator using a secure hash algorithm 256-bit (SHA-256) [61] is embedded in this layer to calculate files' data hashes (or data fingerprints) which are then distributed in the blockchain. The infrastructure layer is the cornerstone of a BaaS platform that offers essential services like cloud data storage, operation systems, and hardware (e.g., GPU and CPU). One advantage of the LBaaS is that it can be deployed anywhere instead of subject to a specific third-party vendor, who still owns the administration privilege.

Fig. 6.

Technical stack of the LBaaS.

3.3. Development of LBaaS

3.3.1. Multi-to-one mapping (MtOM) kit for blockchain registration

The MtOM kit (Fig. 7 ) allows multiple users to share one blockchain node. The kit is developed based on the Spring Boot [62] architecture and coded using Java. Four services: transaction package service, token extraction service, transaction encapsulation service, and blockchain node mapping service, are packaged in the kit. Inputs in the frontend will be transferred to the backend via the HTTP protocol. Then, the transaction package service will convert the data into a JSON string and form it into an initial transaction in a key-value data model. As several users use one blockchain node, it is necessary to distinguish which user creates a transaction. Thus, a token extraction service is designed to extract user information (e.g., user ID, role, and department). Next, the transaction encapsulation service will add user information to the initial transaction. In this study, blockchain nodes are assigned in the granularity of the department. Thus, before recording a transaction in the ledger, the mapping service will verify the department address (or name) to connect the user to the right blockchain node service. After determining the address, the kit will invoke Hyperledger Fabric SDKs to trigger smart contracts to execute the transaction.

Fig. 7.

Framework of the Multi-to-one mapping kit.

Fig. 8 compares workflows of a new user registration among existing BIM collaboration platforms, solo blockchain services, and the LBaaS prototype. Adding a new user involves three steps in a general BIM platform like Autodesk BIM 360 [60]. First is inputting user basic information in a frontend UI. After that, the administrator (or operator) will assign the role, department, and data accessibility to the new user. Finally, the user account will be created, and its information will be registered to the user database. However, joining a blockchain network is complex. Fig. 8 (b) shows that the administrator should build a new blockchain node before creating a new user account. Node creation in Hyperledger Fabric has four main steps (i.e., generating crypto material, updating the network configuration, requiring signatures, and adding the new node to the network [48]. Manually operating and coding this process is time-consuming. Furthermore, user information is then created and mapped (or linked) to the new blockchain node. Verification is required to assess the linkage workability.

Fig. 8.

Comparison of new user registration.

In Fig. 8 (c), the advantages of the MtOM kit can be summarized as follows: (1) It keeps (nearly) the same registration procedures as the generic BIM platforms. All the blockchain nodes have been encapsulated in the backend in advance. The MtOM kit automates tasks like mapping the user to blockchain nodes and verifying mapping correctness without adding any further burden to the operator. (2) Compared with solo blockchain, where each new blockchain node should be built when there is a new user, the LBaaS lowers deployment difficulty and computing pressure as several users can associate with the single blockchain node. (3) Although different users share one node, the MtOM kit still retains the core blockchain feature that each transaction records information of each user for liability auditing.

Instead of directly speeding up the construction process, the development of the Multi-to-One Mapping (MtOM) kit aims to alleviate the difficulty of blockchain implementation in ECPs. A complex blockchain registration process always impedes collaboration efficiency. Easily and quickly registering to and accessing the blockchain has long been desired in the construction industry [63], making the newly developed MtOM kit an integral and fundamental component in LBaaS. The speed of new project member registration is also tested in Fig. 8. The results show that the MtOM kit simplifies blockchain access and has a similar time cost (3.5 mins) to existing BIM platforms (3.2 mins), indicating that the LBaaS will not bring inconvenience or additional workload.

3.3.2. Integrated workflow of BIM design collaboration in LBaaS

The integrated workflow is presented in Fig. 9 . Innovations of this workflow lie in three aspects. First, it shows the logic of collaborating in a distributed LBaaS environment while maintaining nearly all the activities and steps in Fig. 3 to achieve a consistent work style. Blockchain is seamlessly embedded in the existing design conventions to support transparent data sharing, automatic permission execution, and traceable data retrieval. Secondly, sixteen design actions (marked in pink boxes) that need to interact with a blockchain are identified. These blockchain-based actions cover a completed design process from the parallel design to the model delivery to improve data security. Thirdly, different smart contracts are assigned and coded to enable interaction. For example, in parallel modeling and cross-domain collaboration (Task 1), designers can invoke Information Sharing (IS) smart contract to record updated information in the blockchain, synchronizing the information to all project members. In the design issue permission process (Task 2) and model validation (Task 4), the Permission Execution (PE) smart contract is invoked to accept or reject an issue. Execution results containing a decision (e.g., rejection), comments, and executor signature (user's ID in the blockchain), will be broadcasted to all designers. History Query (HQ) recalls existing blockchain transactions for P2P coordination (Step 8) in issue response and CDA drawing revision (Task 3).

Fig. 9.

The integrated workflow for design collaboration in the LBaaS.

3.3.3. Blockchain smart contract development

Although smart contract contains the term “contract”, it serves a different purpose from traditional paper-based contact. A smart contract deployed in a blockchain network is machine-readable code that can self-execute when certain predefined conditions are met. In other words, it is used for secure data interaction with blockchain (e.g., data record and query). A smart contract is necessary for blockchain-aided BIM collaboration. The workflow in Fig. 10 demonstrates how smart contracts secure data consensus among project members. It should be noted that verifications are all automated and executed at the millisecond level (discussed in Section 4.3.2).

Fig. 10.

LBaaS smart contracts.

Three smart contracts are codded and deployed in LBaaS. Appendix B shows the pseudocodes, and Fig. 10 (a) demonstrates how smart contracts facilitate reliable interaction. When a user files a new model (or issue) in the frontend, a transaction containing model ID, fingerprint, user ID, and timestamp will be sent to the IS smart contract. This transaction will be verified by an endorsing node (Step 1), which checks transaction legality. Illegal transactions (e.g., the transaction data model is not subject to a predefined format) will be rejected; otherwise, they can proceed and be returned to the smart contract with endorsing signatures (Step 2). In Step 3, the smart contract passes the transaction to an ordering service responsible for chronologically packaging transactions during a certain time to a new block. The following explanations clarify the legality checks: (1) Checking content. Instead of manually examining the data correctness, Step 1 verifies if the transaction is issued by an authorized blockchain node, if the input parameters can read existing ledger data, and if the new transaction can update or be correctly written to the ledger. So, the signature given by endorsing nodes differs from the paper-based one. The pre-execution offered by Hyperledger Fabric has been validated and recommended in blockchain-BIM integrated research to prevent network congestion [64], improve security [39], and ensure authenticity [65]. (2) Processing efficiency. Without any manual operation, the multiple rounds of checking are performed automatically at the millisecond level. The results of time duration are shown in Section 4.3. (3) Data redundancy. These pre-executions only verify the illegality of transactions. Execution results are only used for verification in the following steps and will not be appended to the blockchain ledger, thus avoiding redundant data. In Steps 4 and 5, the smart contract will share verified transactions with all blockchain nodes, who will inspect the block upon receiving it automatically. Confirmed blocks will be appended to the ledger as immutable records. Finally, execution results will return to the transaction proposer (Step 6).

PE smart contract has a similar logic. Two differences are (1) different smart contract inputs and (2) different status results. After a project member (e.g., a domain manager) reviews an issue, he/she can operate in the LBaaS frontend to give his/her decision. The PE smart contract will send a new transaction, including all necessary metadata (e.g., issue ID, issue decision, reviewer comments, etc.), to an endorsing peer to check if the input adheres to the regulated data model. Accomplishing Steps 1 to 5 will update the blockchain world state, a database built on the top of the blockchain ledger to show the latest status of different files. Hence, the current status of issue AR-P01-ISSUE-01 in Fig. 10 (a) is “approved”. Not only enhances automation, but the PE smart contract generates and records the digital signatures of the user to guarantee the authenticity of the results, thus saving time by removing the complex process of physical permit. The HQ smart contract will retrieve existing transactions based on the input key (e.g., file ID).

Although the proposed smart contracts cover most blockchain interactions under the ECPs context, smart contract updates are still needed owing to the appearance of new design workflows or new client requirements. The Hyperledger Fabric offers a standard “smart upgrading” process containing three steps: install, upgrade and invoke. “Install” means deploying an updated smart contract code to the network. “Upgrade” will instantiate the new smart contract to make it effective. After that, the smart contract is invoked to test if it is workable. Instead of manually inputting commands to execute, the LBaaS packages the process to a “smart contract update” button to simplify the updating process (Fig. 10 (b)). The first step is to select the smart contract (e.g., PE-v1) that needs updates. A new smart contract code file (e.g., PE-v2) will be uploaded to replace the previous version. Finally, clicking the “smart contract update” will automate the updating.

4. Validation and evaluation

4.1. Validation preparation

The prototype validation and evaluation require multiple project members to have a long-term test on a new technology without mainstream adoption in the construction domain. This process is incredibly impractical for ECPs. Therefore, considering the time and technical restrictions, a scenario-based evaluation approach is used. The LBaaS is deployed in different design scenarios to demonstrate its workability and efficiency. The scenario-based evaluation is straightforward and feasible and has been used in blockchain-related studies [12,20]. Fig. 11 shows the illustration environment:

• (1)Hardware configuration. The LBaaS prototype is configured in a private cloud server. It is deployed in a Linux Ubuntu 18.04 system with two Intel(R) Xeon(R) Sliver 4208 CPU @ 2.40GHz processors, 4 NVIDIA Tesla T4 16G GPU, 128GB memory, and 7 TB disk.
• (2)LBaaS prototype.Fig. 11 (a) shows the LBaaS prototype deployed on a private cloud server. Three main modules, model management (module 1), issue management (module 2), and blockchain management (module 3), are displayed on the frontend UI. Users can perform collaboration by invoking different modules. It should be noted that a blockchain dashboard called Hyperledger explorer [66] is integrated into the LBaaS to real-time monitor blockchain status. Moreover, an Autodesk BIM 360 [60] is linked as the off-chain database for BIM model storage.
• (3)Blockchain configuration.Fig. 11 (b) shows that six blockchain nodes are configured. Aided by the MtOM kit, several users can use the same node. The node assignment is shown in Fig. 11 (c).
• (4)Project data. Data (e.g., BIM models, workflows, design sheet format) involved in these scenarios are acquired from an actual MCH project in Hong Kong. Fig. 11 (d) presents the BIM model. Modifications have been on the model to avoid exposing sensitive information.

Fig. 11.

Illustration environment: (a) LBaaS prototype UI. (b) LBaaS blockchain configuration. (c) Blockchain node assignment. (d) Modified BIM models of the MCH in Hong Kong.

4.2. Validation scenarios

4.2.1. Scenario 1: New user registration and BIM data sharing

Fig. 12 is the roadmap of scenario 1, whose objective is to validate the workability of the MtOM kit and IS smart contract. The system administrator registers a new user, AR-03, for the architecture team. According to Fig. 11 (c), the new user is linked to blockchain node 1 through the MtOM kit (Step 2). AR-03 then shares a new BIM model by invoking IS smart contract (Step 2). In Step 3, another user checks if the n AR-03 has been successfully connected to the blockchain and if the new model information has been recorded.

Fig. 12.

Roadmap of scenario 1: New user registration and BIM data sharing.

Results in Fig. 12 show that: (1) the model has been uploaded to the BIM 360 cloud folder with a fingerprint in the file name, (2) a blockchain transaction has been successfully generated via IS smart contract, and (3) file metadata including the file fingerprint is stored in the blockchain transaction for integrity verification, and (4) the transaction is proposed by AR-03 account using blockchain node 1. Therefore, the objective of scenario 1 is validated.

4.2.2. Scenario 2: Automatic permission in issue management

Fig. 13 shows the roadmap of scenario 2, which aims to validate the workability of the PE smart contract and the permission workflow. In Step 1, the AR-01 raises an issue that the current window size of a medical block is 600*1200 mm; however, according to the standard, a 900*1200 mm window is suggested. Then, the issue and a design sheet are generated for review. In Step 2, the domain team leader AR-0 checks the issue detail and endorses it with a comment that “this is an issue”. Similarly, the technical engineer (TE-1) approves it and states that this issue cannot be solved internally and need the client's further comments. In Step 3, the quality manager (QM-1) approves this issue as it is related to mandatory standards that should pass to the client and drawing team. All these permissions are executed in the LBaaS frontend by invoking the PE smart contract. Results show that all permission actions have been automatically executed and recorded in the blockchain. Each transaction archives that: (1) user ID performing the action, (2) decisions (“approved” in this scenario) made by different users, and (3) specific comments made by different parties. Thus, scenario 2 has been validated.

Fig. 13.

Roadmap of scenario 2: Automatic permission in issue management.

4.3. Evaluation

4.3.1. Performance comparison of BIM data management between current approaches and LBaaS solution

Although the construction industry has required security protections with the increasing development of digital technology, the ISO 19650-5 standard [28] states that the purpose of adopting security strategies in BIM should not be achieved at the sacrifice of undermining collaboration efficiency and benefits generated by other digital technologies. Thus, this section discusses how the LBaaS advances current BIM solutions and improves MCH design efficiency. According to the interview in Appendix A, two online solutions are adopted for MCH design. A BIM collaboration platform for managing BIM data (e.g., creating and federating BIM models, analyzing clashes, and simulating ventilation) and an online folder for storing non-graphic and temporary data like Excel schedules, resolution sheets, and reference materials from people outside the BIM design team. The LBaaS solution retains the BIM platform and online folder. Unlike the existing practice that the platform and shared folder are loosely coupled, blockchain services allow secure information exchange among different databases. Fig. 14 exhibits the comparison roadmap and results. Three cases where design efficiency is harmed by security vulnerability are selected based on the actual design process.

Fig. 14.

Roadmap of performance comparison.

Case 1 shows inefficiencies caused by weak traceability and transparency. Section 3.1 introduces a “pre-revision” mechanism that a design resolution sheet will be formed to guide BIM model revision. However, when the client and designer A file a sheet and place it in the folder, this is always the case that its proposer may update it. When designer B takes over A's work and is in charge of this issue, he/she always finds it hard to trace who made what change and what is the latest solution in a messy folder. Moreover, the folder cannot actively push notifications; as a result, some designers in other domains always miss updates and new requirements, leading to design errors and data inconsistency. LBaaS largely alleviates these two problems by (1) recording changes in each file and storing their metadata (e.g., file ID and version) in a chronological and immutable manner for efficient data tracing and indexing and (2) actively synchronizing records to all blockchain nodes and users using a blockchain consensus mechanism.

Case 2 introduces inefficiencies caused by insecure permission. In the MCH project, much time is wasted waiting for physical signatures. Therefore, a new problem occurs: some documenting process skips or ignores the signing step to accelerate the design process. A phenomenon that a resolution sheet is broadcasted without verifiable signatures appears frequently. Consequently, more time is consumed in disputes and unnecessary rework.

Case 3 displays inefficiencies caused by single-point-failure. Since existing data management rarely relies on a single and centralized database. Maloperations like deleting files or unwitting changes are always the cases, leading to a loss of valuable MCH data. Although the project team often has backups for source data like BIM models and other reference documents, design records, and some temporary data are hard to recover. Using blockchain technology, LBaaS sets serval independent and distributed blockchain nodes, each of which owns a completed ledger of records. Design records data can be retrieved even if crashes or deletions occur, strengthening data availability and the robustness of MCH collaboration.

Fig. 15 shows the quantitative evaluation of how the BIM delivery could benefit from automated smart contracts in the LBaaS. Three project members (one BIM manager and two designers), who have participated in the MCH project, were invited to perform (1) BIM design coordination and (2) model delivery process in both the current solution and the LBaaS platform. The BIM coordination scenario (Fig. 15 (a)) comes from an actual case in which the client required “Adjusting the height of hospital dorm from 72 m to 66 m. The MEP system design and installation should be revised accordingly”. The BIM team conducted the same task in two solutions. Since the LBaaS adopts a similar workflow to existing practice; thus, the time cost in the initial model revision is the same (30 mins). During the model modification, the design team needed to check historical data. Owing to weak traceability, as analyzed in Fig. 11, Fig. 15 mins were taken to retrieve the change history of a CAD drawing. Empowered by the HQ smart contract, the BIM team only spent 3 mins finding all recodes in LBaaS traceable blockchain ledger, saving 73% of the time in this step. During P2P coordination, both solutions took 8 mins. A design sheet was formed and required a signature from the team leader for pre-revision. The existing solution took 10 mins to have the physical signature (including the waiting time). On the contrary, 6 mins (including the waiting time) were spent in LBaaS via invoking the PE smart contract. As a result, 40% of the time was reduced. Moreover, the BIM team encountered rework for they missed an update from the suppliers, who were working on another system; thus, they spent additional 10 mins to solve the issue via existing solutions. 29% of the time are lessened in LBaaS as it owns transparent information sharing supported by IS smart contract. Finally, compared with using the existing solution (94 mins in total), 23% of the time was lowered by leveraging LBaaS and smear contracts (72 mins in total).

Fig. 15.

Evaluations of smart contract benefits: (a) Time cost in a BIM design coordination case; (b) Time cost in BIM models delivery.

In the model delivery case (Fig. 15 (b)), the domain team leader took 15 mins to validate and approve (including preparing change logs and signing approval) the domain BIM model. As discussed before, HQ and PE smart contracts could accelerate these processes, and as a result, only 4 mins were put into validation, saving 73% of the time in this step. Similarly, the BIM manager saved 67% of the time in federating and authorizing BIM models via the PE smart contract. Leveraging IS smart contracts, the LBaaS delivered and synchronized the BIM data to downstream parties faster and more transparently. 50% of the time is decreased compared to the existing solution's time cost. Finally, 62% of the time was saved in total.

4.3.2. Latency and throughput

Latency and throughput are two integral metrics that need to be measured in blockchain application studies to see if the performance of the developed prototype, framework, or architecture meets the requirements of the target business [63]. Blockchain latency indicates how long a smart contract will cost to record a transaction in the blockchain. Latency is an essential metric in blockchain evaluation as it describes if its “speed” satisfies the business requirements [67]. High latency (e.g., 10 min to generate a block in bitcoin) is unacceptable in ECPs that demand timely information sharing [68]. This paper measures the latency of three smart contracts. Ten rounds of the repetitive test are performed to avoid abnormal results. Results in Fig. 16 shows that all latency at the millisecond level. Briefly, the average latency of IS smart contract is 167 ms, PE smart contract is 283 ms, and HQ smart contract is 156 ms. PE latency is higher because the PE smart contract often processes transactions in a larger size; thus, more time is needed. As the blockchain is still new in construction, no latency benchmark has been set. Fatokun et al. [69] introduced that users will not notice the delay if the maximum response time of the blockchain application is less than 1 s. According to recommendations and practices from studies [38,46], blockchain latency at a millisecond level is reasonable in design and construction processes. Thus, the LBaaS latency is acceptable.

Fig. 16.

Latency of LBaaS smart contracts.

Throughput is vital to blockchain applications because it describes the capability of blockchain processing transactions [70]. Low through will lead to blockchain congestion and even data invalidation. Two metrics, “transactions per second (TPS)” and “query per second (QPS)”, are often adopted to evaluate blockchain throughput. TPS is how many transactions a blockchain can execute per second, while QPS means the number of transactions a blockchain can read and query. Different from the financial domain, which has a demand for high throughput, design collaboration is not that sensitive to this metric as hundreds of blockchain-related actions (e.g., upload models and share issues) are unlikely to happen simultaneously in a second in a single project. A throughput of roughly 50 is adequate and reasonable based on the replies from BIM participants in the MCH project and recommendations in [38,46,63]. The results in Fig. 17 show that the LBaaS has a practical throughput: IS has an average TPS 60, PE has an average TPS 35, and HQ has an average QPS 64.

Fig. 17.

Throughput of LBaaS.

4.3.3. Smart contract code vulnerability

Transactions that have been hashed and added to a blockchain are normally not hackable. But if smart contracts are not built correctly, they could have flaws that cause them to execute unexpectedly [71]. Since the smart contract is an integral element in blockchain-BIM integration research, its security is critical. Therefore, during the coding process, this paper chooses logic and SDKs (e.g., GetFunctionAndParameters, PutState, and GetState) that have been used and verified in the construction industry [12,65,72]. Moreover, a security assessment tool, revive-cc [73], is used to check the smart contract codes in the LBaaS. Revive-cc is an open-source application to identify common vulnerabilities of smart contracts in Hyperledger Fabric. Risks like “importing block listed libraries” and “phantom read of ledger” will lead to inconsistent computation and lacking consensus. Detailed metrics can refer to Appendix C. Results in Fig. 18 show that no common problems, errors, or warnings are detected, indicating that the proposed smart contracts are reliable for ECP design information exchange, permission, and query.

Fig. 18.

Security evaluation results of LBaaS smart contracts.

4.3.4. Function evaluation

Table 1 depicts the evaluation of the LBaaS prototype against the predefine principles and requirements. For the first principle, a suitable blockchain service (i.e., Hyperledger Fabric) that only allows authorized data access and removes the “mining” process has been adopted in the prototype; thus, requirement A1 is met. A frontend having essential collaboration functions is also developed to fulfill requirement A2. To satisfy requirement A3, Users in the same domain can connect to one common blockchain node to simplify the registration procedure via the MtOM kit. For the second principle, B1 is achieved by retaining (nearly) the same collaboration workflow in the LBaaS. Core collaboration modules are enclosed in the prototype; therefore, requirement B2 is also met. Requirement B3 is partially completed because although a hierarchy including four domains is established, data access based on the hierarchy is awaiting further development. For the last principle, C1 is satisfied for the hash fingerprint of each BIM data is stored in the blockchain. To fulfill C2, smart contracts are coded to automate permission execution and data sharing. Digital signatures generated by smart contracts safeguard data authenticity. C3 and C4 are met because the LBaaS has an underlying blockchain service to ensure data transparency, traceability, and immutability. The prototype was also demonstrated to the BIM team in the MCH project. One BIM manager and two designers participated in the interview and gave constructive comments and improvement suggestions shown in Table 1.

Table 1.

Function evaluation of the LBaaS prototype.

Requirements	Fulfilled?	Feedback from BIM participants
A.Easier usage of blockchain
A1. An appropriate blockchain platform should be selected and deployed	Yes	•“The proposed prototype offers a good opportunity to access the blockchain services while removing skills requirements in development and deployment. We sometimes are unaware that there is a blockchain. But when we need secure BIM data, the blockchain benefits come to our mind.” (BIM manager)
A2. A user-friendly frontend should be developed	Yes
A3. Registration to the LBaaS should be easy	Yes
B.Consistent manner for BIM collaboration
B1. Collaboration in the LBaaS should keep existing workflows	Yes	•“Yes, we feel familiar when using LBaaS. The procedures of uploading models, solving issues, and pre-revising models are nearly identical to our current practices. It is practical and has great potential to be implemented in ECPs like the MCH project.” (Designer 1) •“We understand this prototype is an initial version. But functions like establishing user hierarchy to control data access privilege have not been thoroughly developed.” (Designer 2)
B2. Basic collaboration functions should be provided	Yes
B3. Role hierarchy should comply with existing settings	Partially
C.Secure BIM data management
C1. Data integrity can be verified	Yes	•“What impressed me is the automatic permission. As the design process is sometimes messy, a tool (i.e., smart contract) that can securely execute permissions and push all results to all members is helpful and urgently wanted.” (BIM manager) •“Undoubtedly, the traceable design records provided by blockchain are what we desperately need. It seems blockchain ledger plays a single source of truth and thus, can save our time in data verifying and tracing.” (Designer 1) •“Data verification using the fingerprints is reasonable. However, the current LBaaS still compares the fingerprints manually. I suggest a more automatic tool can be integrated to perform the comparison to save time.” (Designer 2)
C2. The permission process should be digitalized and unforgeable	Yes
C3. The LBaaS should provide a traceable data storage	Yes
C4. The LBaaS should have a transparent environment	Yes

A comparison among LBaaS, solo blockchain, and commercial BaaS is performed in Table 2 . In this study, solo blockchain means a basic Hyperledger blockchain network and architecture. Commercial BaaSs refer to the mainstream products provided by tech giants like Microsoft and Huawei. Two perspectives, function and operation, are adopted in the comparison. The function perspective has two metrics to describe whether the service supports design collaboration in a blockchain. The operation perspective, with three metrics, focuses on service availability and ease of operation. For the deployment and registration, project members should build the distributed environment from the first step in a solo blockchain. LBaaS and commercial BaaS have encapsulated these steps to ease the entrance to the blockchain. Unlike LBaaS, solo blockchain and existing BaaSs are not fit for ECPs since limited function modules related to design collaboration are provided. Subscription flexibility indicates where to deploy the blockchain. Hyperledger Fabric is an open-source consortium blockchain that could be installed on local servers to protect data confidentiality. However, if the user subscribes to commercial BaaSs, the vendor will entirely control the databases and configurations, which may be unacceptable in ECPs that often involve enormous sensitive data. Cost is a vital concern. Hyperledger Fabric can be accessed freely. However, these commercial BaaSs are expensive, as mentioned in Section 2.3. As for the extendibility, new modules can be added to solo blockchain and LBaaS. But the secondary development on commercial platforms is not that effortless, as some have not provided APIs and related documents. In summary, under the context of ECP collaboration, the proposed LBaaS outperforms solo blockchain and commercial BaaS in terms of its function availability and ease of operation.

Table 2.

Comparison of LBaaS with solo blockchain and BaaS.

Blockchain services	Function perspective		Operation perspective
	Difficulty of deployment and registration	Richness of design functionality	Subscription flexibility	Cost	Extendibility
Solo blockchain	★★★	★	★★★	★★	★★★
LBaaS	★	★★★	★★★	★	★★★
Commercial BaaS	★	★	★	★★★	★

Note: One star means the level is low, two stars indicate the level is fair, and three stars represent the level is high.

4.3.5. DSR evaluation

Seven DSR guidelines are prosed by Hevner et al. [55] to evaluate the methodological rigor and relevance. Results in Table 3 show that the development process of LBaaS is scientific.

Table 3.

Methodology evaluation based on DSR guideline.

Guidelines	Evaluation
Design as an artifact	This paper proposes an LBaaS prototype. Key technical elements have been developed to support prototype functionality
Problem relevance	Special collaboration methods in ECPs have raised insecure actions that inevitably hinder design efficiency, resulting in rework and even project delay. A blockchain-aided solution is developed to solve the problem of insecure and inefficient BIM collaborative design in ECPs
Design evaluation	This paper quantitatively and qualitatively evaluates the LBaaS. The quantitative evaluation follows metrics in published papers regarding blockchain implementation. The qualitative evaluation conforms to the DSR guidelines to reach a rigorous research process. Results show that the performance of the prototype is acceptable
Research contributions	Three contributions are summarized as follows: •Identifying security flaws that hinder design efficiencies in ECPs •Proposing development principles and technical stacks of LBaaS that satisfy ECP requirements •Developing an LBaaS prototype and validating its workability and applicability •Evaluating the performance of LBaaS in ECPs' BIM design
Research rigor	The development process follows a DSR paradigm with six steps. The workflows, principles, and technical solutions are presented based on ISO standards and interviews with participants in an actual MCH project. A proof-of-concept prototype is validated and evaluated in design examples from an actual project to show its feasibility
Design as a search process	This study investigated the industry people and reviewed the literature to capture what is missing. Moreover, a secure and efficient artifact is proposed following existing practices and industry standards
Communication of research	The study communicates with the industry from problem identification to artifact illustration. Valuable comments have been acquired from the managerial audience and other BIM designers. Moreover, the authors tend to publish the development process in academic journals for academic communication

5. Discussion

The discussion is conducted through (1) technical contributions to the body of knowledge, (2) theoretical contributions, and (3) practical implications.

5.1. Technical contributions

• •Providing a consistent workflow for secure collaboration in blockchain-aided ECPs. This paper integrates blockchain with the design process in an MCH project to solve security-related problems like lacking transparency and traceability. As the ECPs emphasize urgency, flexibility, and short-term timeliness, the paper does not “reinvent the wheel” to design new workflows. Instead, this paper retains the existing manners to the greatest extent possible in the LBaaS, where blockchain is supplementary to augment data security and automate the design process.
• •Proposing a fast blockchain registration method. Registration is one of the primary tasks in developing blockchain applications. In construction, members are usually temporary participants and are not motivated to maintain blockchain nodes [59]. Registering and deregistering a blockchain node requires an amount of additional development work. Therefore, a novel Multi-to-One mapping (MtOM) kit is developed to mount several users to one blockchain node to accelerate registration and ease blockchain access. A user not being an independent blockchain node is a new mode for blockchain application in the construction industry.
• •Developing new smart contracts for efficient data interactions in ECPs. Blockchain 2.0 [74] indicates that smart contracts are integral in blockchain for automated and autonomous data exchange. Three new smart contract algorithms are developed in ECPs to speed up BIM coordination. These smart contracts perform interactions and reach consensus at a millisecond level, greatly reducing the time wasted in information sharing and approval.

5.2. Theoretical contributions

• •Exploring the mechanism of integrating ECPs design requirements and workflows with blockchain. The industry and academia are continually investigating the knowledge of how to combine blockchain with construction management. However, limited work has touched on secure BIM data exchange and storage in ECPs, who own unique collaboration manners and security risks. A complete methodology from problem definition to solution finalization is established in this paper. First, three major weaknesses in ECPs' BIM security are detected. Besides, three principles are proposed for creating blockchain solutions. These principles guide technical development in ECP and provide references for blockchain implementation in general projects. More importantly, a system stack is built to offer the technical roadmap. Referring to this stack, developers in other domains could be more targeted in producing their blockchain applications. Furthermore, a comprehensive evaluation is conducted, demonstrating the efficiency and merits of blockchain in BIM management.

5.3. Practical implications

• •Developing a generic blockchain-based solution. Although ECPs are not limited to MCHs, and the ECPs collaboration methods vary from project to project, the necessary design modules and data storage solutions in the LBaaS can be applied to various scenarios. Besides, the LBaaS is not subjected to a specific vendor; therefore, project members can customize the placement of the data to protect privacy. Extendable APIs are set so that new functions can be added to adapt to different collaboration requirements. The World Health Organization said COVID-19 would not be the last public health emergency [75]. Thus, the proposed feasible and general solution offers a technical reference to develop blockchain applications in other ECPs.
• •Balancing the centralization and decentralization. One interesting concern is that the BaaS, like LBaaS, reintroduces an intermediary betraying the core blockchain value of “decentralization”. However, whether BaaS raises security concerns depends on the particulars of the service [49]. Adopting blockchain in ECPs is a trade-off among cost, security, ease of use, and functionality. In practice, the deployment of the LBaaS is controlled by an internal trusted project administrator (e.g., an information manager) who shares the same interests with other members. Although part of the LBaaS relies on centralized services, the blockchain nodes are still constructed in distributed docker containers to independently maintain ledger immutability, non-repudiation, and verifiability. Therefore, LBaaS provides a practical and reasonable example of how project members can effortlessly collaborate in a secure environment with which they are familiar.

6. Conclusion

The outbreak of the COVID-19 pandemic has exacerbated a crisis in healthcare facilities and exceeded the hospital admission capacity. To this end, mobile cabin hospitals (MCH) are built to isolate and treat infected patients to control the sources of infection and cut off the transmission channels. However, strict time limitations and complex design processes in such emergency construction projects (ECPs) have caused several data security risks that will impede work efficiency. As a plausible solution, blockchain benefits secure data integrity and immutability. Thus, this paper proposes a lightweight blockchain-as-a-service (LBaaS) to improve ECPs' design efficiency while lowering the barriers to accessing blockchain merits. Three objectives have been achieved. Firstly, through interviewing BIM participants from an MCH project, three risks, namely, lacking transparency, lacking traceability, and lacking permission automation, that will harm the design process are identified. Secondly, three principles and a technical architecture are presented to guide the development of the LBaaS. An LBaaS prototype is developed with three key features: (1) a Multi-to-One mapping (MtOM) kit is developed to allow easier registration to the blockchain service; (2) an integrated workflow is designed to enable a consistent design manner in a distributed environment, and (3) three smart contracts are developed for secure information sharing, permission execution, and historical data query. Finally, the LBaaS is demonstrated in design scenarios to validate its functions. Quantitative and qualitative evaluations are also conducted to assess the performance of the LBaaS. Results show that: (1) Designers can collaborate within the LBaaS without additional efforts in configuring and deploying the underlying blockchain. (2) Compared with existing BIM design practices and platforms, the LBaaS exhibits advantages in enhancing MCH BIM data traceability, automating permission, and strengthening data robustness. (3) Performances of the LBaaS, in terms of its latency, throughput, and security, are reasonable and acceptable, and (4) Feedback from BIM participants indicates that the LBaaS provides valuable insights on how to implement blockchain to secure BIM collaboration in ECPs.

This study aims to demonstrate the benefits of blockchain in ECPs collaboration. As an initial exploration, limitations still exist due to time and technical constraints. The first is nonautomatic data verification. Data fingerprint is generated and documented in the blockchain ledger. However, the verification process is still manual. A method for automatically comparing a file with its fingerprint still needs further investigation. The second is lacking fine-grained data access control in the blockchain. Although the LBaaS can be implemented in a private cloud, the blockchain data is exposed to all project members, risking data leaking. Hence, a role hierarchy with finer granularity should be established. Therefore, two further research includes: (1) developing an automatic comparisons method to check data integrity quickly and (2) optimizing the access control in the LBaaS to maintain data confidentiality.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Appendix A Interview outline and key points of answers

Q1	What is the role of BIM in MCH design?
	•Container design visualization. Including determining the equipment (e.g., hospital bed and medical equipment) install location, examining the layout, and ward function • Container structure optimization. Although 2D drawings are provided, a large amount of detailed design work is needed based on BIM. For example, the reserved holes and openings require modification to coordinate the latest MEP solution • MEP modeling. BIM owns advantages in fast visualizing pipelines and plumbing layouts over 2D drawings. Furthermore, in the MCH project, BIM is adopted to detect the clash between MEP installation and container structure design. Correcting these defaults in advance significantly reduces construction rework and saves value project time • Ventilation simulation. Ventilation design is critical in MCH. BIM, integrated with CDF, different ventilation schemes are simulated and analyzed to prevent pollution from diffusing
Q2	How BIM benefits MCH design?
	• Support design schemes comparison. Design changes frequently happen. There was a case that the placement of beds and furniture changed four times a day. In that scenario, BIM can visualize each scheme quickly so that the client can make decisions easier • Support fusion of multi-discipline knowledge. To speed up the project, the construction team can refer to 2D drawings and BIM models. For example, site formation work will be done based on the drawings before BIM model delivery. However, relying only on drawings results in reworking and disputes, as drawings are sometimes outdated in frequent design changes. Furthermore, the MCH project requires comprehensive information. BIM models that combine expertise from different domains (architecture team, MEP team, equipment team) assist in quickly locating and assembling by providing accurate and integrated data
Q3	What teams/parties have been involved in the BIM modeling?
	• Architecture Modeling team. This team is responsible for container design, including the layout design, ventilation design, definition of functional zones, and preservation of pipeline holes from a structural perspective • Pipeline & Ventilation modeling team. This team works on the comprehensive design of mechanical, electrical, and plumbing (including sewage discharge and ventilation pipeline). Additionally, the team will consider the connection of the MCH MEP system to the municipal MEP network • Equipment modeling team. This team is in charge of medical equipment, furniture, and interior decoration placement
Q4	What are BIM tools used in the MCH project?
	Even though these teams are from one company, not all people are in the same physical location due to the COVID-19 lockdown. Thus, coordination work involves both online and offline models. For the online work, an internal cloud BIM-based collaboration platform is implemented for model coordination and information sharing. A shared cloud folder is also created for storing temporary documents and files from people outside the design team (e.g., size references of medical equipment from medical experts)
Q5	What is the workflow of BIM-based collaboration?
	The issue management has two workflows For the issue raised in a single model development, a “model pre-revision” workflow is adopted. In MCH, BIM models are built based on 2D drawings. When a BIM designer proposes an issue related to the drawing, he or she will directly contact the client to coordinate a solution. This solution will be formed in an issue sheet or just delivered orally. Instead of waiting for the revised drawings, the designers will pre-vise the model to save time. When revised 2D drawings are available, the BIM designer will compare the BIM model with the drawings to verify its compliance. If the issue happens in the process of the model federation, a BIM checker with rich BIM modeling experiences will decide who should be accountable for this problem. Accordingly, the issue will be assigned to the designer, who will update the federation model
Q6	What are the differences between MCH BIM design and generic BIM design? What new challenges are there?
	There are three main differences: • The first is that all models are built simultaneously instead of in sequence. This could save the waiting time; however, it brings new challenges because no reference models are available. The collaboration is sometimes not transparent in such an urgent project. As a result, model discrepancies and mistakes will hinder model development •The second point is the communication style. Unlike the traditional design process in that a BIM manager will organize regular meetings to coordinate design issues, the MCH project employs a peer-to-peer and straightforward method for discussion. However, such communications are always informal, ad hoc, and untraceable, resulting in a rework and inefficiency if another (or new) designer takes over the issue • The last one is the pre-vision mechanism. Yes, this approach improves modeling speed. But the permission process needs improvement as we still require manual signatures (or signature softcopy) on the solution sheets or design change documents. This process may waste time and sometimes causes disputes for the absence of signatures
Q7	Suggestions/Recommendations/Thinkings on improving ECPs design?
	• Design requirements should be more clear to avoid unnecessary changes • Since different companies and stakeholders have participated in this urgent project, we hope the coordination can be smooth in a more transparent and traceable environment. In our MCH case, more than 20 companies have been involved. Information acquisition and exchange is a time-consuming process • Some processes could be automated, like the permission, approval, and generation of issue resolution sheets, to save time • The client should strengthen the organization of integrated management to streamline information flow • Methods should be introduced to prevent misoperation, like deleting and modifying BIM data by mistake

Appendix B Pseudocode of LBaaS smart contracts

Appendix C Metrics for smart contract security evaluation

Security metrics	Explanation
Blacklisted chaincode imports	Coding a smart contract inevitably introduces libraries to facilitate necessary functions. However, importing blacklisted libraries (e.g., time library) in a smart contract would bring non-deterministic behaviors and cause inconsistent computation between peers, leading to a lack of consensus
Global state variables	A secure smart contract should avoid using global state variables, which are only global to a single peer and are not tracked on the blockchain. Thus, computation results on different peers would generate different read and write sets, resulting in all transactions being marked as invalid
Goroutines	Using goroutines in a smart contract is highly discouraged as it would cause concurrency and invalidate transactions
Phantom read of ledger	Querying or reading existing data must not use methods (or APIs) to write new data to the existing ledger. Phantom reads of the ledger would affect the execution of transactions and cause unintended results
Range over map	Execution processes of smart contracts involve iteration calculation. However, using “range over map” for elements iteration would cause indeterministic results due to the change of iteration order. Thus, it is hard for ledger data to reach a consensus

Data availability

Data will be made available on request.