Next Article in Journal
Construction and Demolition Waste Management Actions and Potential Benefits: A Perspective from Trinidad and Tobago
Next Article in Special Issue
Identification of the Best 3D Viewpoint within the BIM Model: Application to Visual Tasks Related to Facility Management
Previous Article in Journal
Reducing the Seismic Vulnerability of Existing Buildings: Assessment and Retrofit
Previous Article in Special Issue
An Exploration of Synergies between Lean Concepts and BIM in FM: A Review and Directions for Future Research
Open AccessEditor’s ChoiceReview

Blockchain and Building Information Modeling (BIM): Review and Applications in Post-Disaster Recovery

School of Architecture, College of Design, Construction & Planning, University of Florida, Gainesville, FL 32611, USA
*
Author to whom correspondence should be addressed.
Buildings 2019, 9(6), 149; https://doi.org/10.3390/buildings9060149
Received: 29 April 2019 / Revised: 23 May 2019 / Accepted: 12 June 2019 / Published: 19 June 2019
(This article belongs to the Special Issue BIM in Building Repair and Maintenance)

Abstract

Blockchain Technology (BCT) is a growing digital technology that in recent years has gained widespread traction in various industries in the public and private sectors. BCT is a decentralized ledger that records every transaction made in the network, known as a ‘block’, the body of which is comprised of encrypted data of the entire transaction history. BCT was introduced as the working mechanism that forms the operational basis of Bitcoin, the first digital cryptocurrency to gain mainstream appeal. The introduction of decentralized data exchange technology in any industry would require strengthened security, enforce accountability, and could potentially accelerate a shift in workflow dynamics from current centralized architectures to a decentralized, cooperative chain of command and affect a cultural and societal change by encouraging trust and transparency. BCT aims at creating a system that would offer a robust self-regulating, self-monitoring, and cyber-resilient data transaction operation, assuring the facilitation and protection of a truly efficient data exchange system. In the state of Florida, climate change and unpredicted weather disasters have put pressure on state and local decision-makers to adapt quick and efficient post-disaster recovery systems. Part of the recovery efforts is the reconstruction of buildings and infrastructure. The introduction of new technologies in the Architecture, Engineering, and Construction (AEC) industry can contribute to addressing recovery and rebuilding after the event of a natural disaster. With parallel technological advancement in geospatial data and Geographic Information System (GIS), as well as worsening climatic conditions, concerns can be suitably addressed by employing an integrated system of both Building Information Modeling (BIM) and BCT. While several potential applications of BIM must provide solutions to disaster-related issues, few have seen practical applications in recent years that indicate the potential benefits of such implementations. The feasibility of BIM-based applications still rests on the reliability of connectivity and cyber-security, indicating a strong use case for using BCT in conjunction with BIM for post-disaster recovery. This research depicts a survey of BCT and its applications in the Architecture, Engineering, and Construction (AEC) industries and examines the potential incorporation within the BIM process to address post-disaster rebuilding problems. Moreover, the study investigates the potential application of BCT in improving the framework for automating the building permitting process using Smart Contract (SC) technologies and Hyperledger Fabric (HLF), as well as discussing future research areas. The study proposes a new conceptualized framework resulting from the integration of BCT and BIM processes to improve the efficiency of building permit processes in post-disaster events.
Keywords: Blockchain; BIM; Post-Disaster Recover; rebuilding after a disaster; distributed ledger; Hyperledger Fabric; Smart Contract; AEC Blockchain; BIM; Post-Disaster Recover; rebuilding after a disaster; distributed ledger; Hyperledger Fabric; Smart Contract; AEC

1. Introduction

The rebuilding process after a disaster is critical for communities affected by disaster events. The time required to rebuild ideally should be as short as possible. However, building permits for new homes and structures must be issued in compliance with county zoning and state codes. This permit process currently takes considerable time, which has a negative impact on communities affected by these disasters. This study explores the employment of Building Information Modeling (BIM) and Blockchain Technology (BCT) to assist in the rebuilding process after disaster events by reducing the time and resources needed to issue building permits.
In post-disaster recovery, the challenges facing the local governments are the need to spend time to reflect on taking well-planned decisions and enacting quick response, to the willingness of the community to rebuild faster [1,2,3]. The federal-wide efforts provided by FEMA to local governments have been limited to the short-term rebuilding level. FEMA assistance is restricted by The Stafford Act and presidential emergency declarations [4]. Therefore, many areas at risk need a proactive plan and local vision to streamline the efforts of rebuilding after a disaster. One of the areas that requires improvements is building authorities operations.
A study by Gunes and Kovel [5] defines a disaster as “an action that may pose threat to life, well-being, properties, material goods, and the environment from processes or technology” [6]. Technological advancements in recent years have presented several new applications that can address the issue of disaster management and relief efforts. While the loss of life has reduced over the past decade, buildings and infrastructure are still subject to considerable damage. Hurricanes Harvey and Irma that struck Texas, Florida, Cuba, and the Caribbean Islands in 2017 are estimated to have inflicted around $150--$200 billion in damage in the states of Florida and Texas alone, which is comparable to costs incurred in the state of New Orleans after Hurricane Katrina in 2005. Disaster management and loss reduction have gained much traction in recent years, owing to exacerbating environmental issues and global change [7]. The Federal Emergency Management Agency (FEMA) is the body responsible for coordinating federal natural disaster assistance for state and local governments in carrying out disaster management practices and providing relief aid to citizens.
Even with a system of recovery processes in place, there are many unprecedented factors that can crop up at any stage, which can severely impede disaster response. This is due to the cumbersome logistics planning and coordination between multiple parties [8] that include contractors, stakeholders, transport companies, government authorities, and other regulatory bodies. The Cato Institute has issued criticism towards the governmental response to Hurricane Katrina in 2005, stating insufficient resource supply and communication breakdown [8]. A sudden spike in demand for resources can force contractors to seek contractors that may be located at faraway locations, which may ultimately lead to delayed delivery times. Transportation companies must often traverse through perilous or impenetrable routes to reach the delivery destination [8].
Apart from delays in transportation, the sanctioning of permits, and communication between various parties in post-disaster recovery; there is also the possibility of outright fraud as malicious entities can take advantage of the urgency and nature of an emergency. The complexity in coordination is further worsened by suppliers often forced to use carrier networks they do not normally use, owing to urgency and situational pressure [8], as it is unfeasible to verify the qualifications of every contracted company involved in carrying out relief efforts. For example, during the onset of Hurricane Maria in 2017, an entrepreneur based in Atlanta delivered only 50,000 meals out of the 18.5 million meals contracted by FEMA [9].
The unsustainable expansion of the human-built environment and climate change as a consequence of increasing urbanization have exacerbated the frequency and impact of natural disasters. Further, urban hazards cannot be addressed by technological fixes alone, but also necessitate a pro-active study and the involvement of urban landscapes and socio-economic characteristics [10]. It is, therefore, imperative to adapt to the changing climatic patterns, natural and urban landscapes by building resilience and minimizing costs [11], as noted in the ‘Stern Review’ (Cabinet Office/HM Treasury 2006).
The prevention and avoidance of threats and hazards fall under the umbrella of the ‘Disaster Risk Management’ (DRM) framework [11], but there has been little research conducted in formulating an effective mainstream framework for implementation in the Architecture, Engineering, and Construction (AEC) industry. One agreement, however, is that resilience should be systematically built-in to each phase of building (design, construction, and operation) [11], although there is not yet any concrete progress in erecting a framework.
A primary requirement of an effective disaster management system is the maintenance of a high degree of accuracy of vital information communication pertaining to the disaster on site that is to be disseminated to government and relief bodies. The AEC industry has developed a process over the years to deal with the disaster cycle. This process generally involves four stages [12], namely: prevention and mitigation: risk assessment and planning; preparation: pre-impact activities; response: emergency management and operations; and recovery: rebuilding and restoration of communities, infrastructure, and services.
Evolving technologies like BIM and blockchain have seen significant advances in recent years and have been widely tipped to disrupt existing socio-technological hierarchies and workflows. The transformative potential of these new developments is evident, but they are still in their nascent stages. BIM is at the forefront of digital transformation in the AEC industry, and there is an increasing interest in integrating BIM workflow and BCT, with a view toward streamlining a number of operations, such as collaboration and design review while addressing issues such as speed, cybersecurity, and data exchange integrity.
The blockchain is a digitized, decentralized public ledger of data, assets, and all pertinent transactions that have been executed and shared among participants in the network. While it is most associated with digital cryptocurrencies such as Bitcoin, blockchain is viewed as an emergent technology that could potentially revolutionize and transform the current digital operational landscapes and business practices of finance, computing, government services, and virtually every existent industry [13,14]. The chief hypothesis behind blockchain is the creation of a digital distributed consensus, ensuring that data iare decentralized among several nodes that hold identical information and no single actor holds the complete authority of the network. This enables transparency of activity and enhancement of data security. Figure 1 depicts the general schema of blockchain technology. While initially developed solely for financial transactions with an aim to create a system that enables secure data transfer between two parties without the requirement of an intermediary, the tremendous disruptive potential of blockchain was later evident with the exponentially increasing development of various cryptocurrencies in recent years. By placing emphasis on trust and cooperation between participants, blockchain radically reorganizes existing workflow paths in any organization in which it is implemented, bringing with it a plethora of benefits that include shared learning, instantaneous data exchange, automated contract execution, network security, and improved collaboration.
In general, three generations of BCT can be distinguished: blockchain 1.0, which covers applications enabling digital cryptocurrency transactions; blockchain 2.0, which expands blockchain 1.0 by introduction Smart contracts and a set of applications beyond cryptocurrency transactions; blockchain 3.0, which enhances the capabilities of blockchain 2.0 in terms of transaction time, scalability, and ease of implementation using DApp;
This research contributes to a thorough understanding of the BCT and its current state-of-the-art applications, particularly its relationship to the rebuilding process after disaster. Moreover, this paper provides new approaches for integrating BCT with the BIM workflow, such as improving the framework for automating building code compliance checks and the permitting processes.
The rest of the paper is structured as follows. In Section 2, the purpose of the study and research questions are described. The objectives of this work are given in Section 3. The methodology employed to conduct a systematic literature review is introduced in Section 4. The findings and evaluation of the retrieved literature about BCT are presented in Section 5, while Section 6 addresses the applications of BCT in different industries. Section 7 discusses the relationships between the BCT and BIM processes. In Section 8, the paper introduces a new approach for enhancing the framework for building permitting process using BCT and BIM workflow. Conclusions and future research areas are presented in Section 8.

2. Problem Statement

Post-disaster recovery and construction market growth are pushing the efforts of streamlining the submission and review of design documents by the building authorities. A growing number of local building departments are switching their paper-based process to an electronic-based process. The Alliance for Building Regulatory Reform in the Digital Age at FIATECH investigated the total savings generated per year from 3000 permit applications after the adaptation of the e-permitting process. The investigation result have shown that the shift to the new process has reduced the driving mileage by 31,2000 miles and saved 20,800 gallons of gas, decreased the omission of carbon monoxide by 457,600 lbs., cut the cost of the fuels by $57,200, gained 12,480 h of driving, and eliminated storage location for 12,000 lbs. of paper [15,16]. The e-permitting process certainly helps to improve the permitting process; however, it is still based on a manual review of the pdf or CAD files. There is no automation or semi-automation of the review and permitting process. Thus, this research aims to review the fundamentals of Blockchain Technology (BCT) and its application in the AEC industry, focusing on BIM workflow to assist in post-disaster rebuilding efforts.
The hypothesis of this work is that conducting a systematic review of BCT and its current applications would assist in developing an integrative framework BCT+BIM to assist in post-disaster recovery. In particular, the study aims to address the following research questions: (i) How does BCT develop over time? (ii) What are the fundamentals of BCT and its areas of applications? (iii) Is there any potential of integrating BCT with BIM workflow to enhance the post-disaster rebuilding process?

3. Methodology

The research is designed as a non-experimental, retrospective–prospective study, which examines and curates blockchain technology and BIM integration to improve the post-disaster rebuilding process. The research approach is based on a systematized review of the current development of Blockchain Technology (BCT), and its applications in the AEC to enable the development of an integrative framework for enhancing the rebuilding process after disasters. The procedure comprises two phases. Phase 1 includes identifying the research’s key aspects, selecting the relevant studies, assessing the quality of the content, extracting data, and synthesizing the information. The second phase deals with the development of an integrative BCT + BIM framework, using the information from phase 1 to improve the post-disaster rebuilding efforts.
A comprehensive investigation of the current literature is essential to further the knowledge base of significant topics, enable the formulation of a viable narrative, and justify the research goals and future studies. Figure 1 illustrates the overall method employed in this study. The first phase of the research protocol focuses on the scope identification and the survey background on the current state of BCT and its applications. This phase covers the existing knowledge base, to provide background on the historical developments of prominent BCTG, the significant development of key features, market impact, and uptake. The knowledge of ongoing research efforts could provide a fair prediction of future developments. This phase ascertains the upper and lower limits of relevant fields with respect to the current capabilities and limitations of BCT and BIM. This includes classifying the publications according to the main categories: BCT related only, BCT and the AEC, BCT and BIM, and the post-disaster rebuilding and BIM. Since there has been minimal overlap between the fields of BCT and BIM (or between post-disaster reconstruction and BCT), it was necessary to develop a cache of descriptive data and conceptual underpinnings pertaining to both fields. This review helped to strengthen the research question, clarify the scope and objectives, and validate the direction of the paper. Finally, conclusions about the potential applications of the emerging BCT in the post-disaster rebuilding are presented, as well as a proposal for a new integrative framework resulting from incorporating BCT in the BIM workflow, which could simplify the rebuilding process after a disaster.
Phase 1 of the study centers around assembling evidence through an extensive literature review. The literature review provides definitions, background, historic development, current knowledge areas, and ongoing research efforts on each relevant area. The prevalent aspects currently discussed and researched are used to identify the keywords, which have served to widen the search process in search tools, such as Google Scholar, Mendeley, Microsoft Academic, Bielfeld Academic Search Engine (BASE), arXiv, WorldWideScience, RefSeek, Science.gov, ResearchGate, and Virtual Learning Resources Center. The first set of articles collected was examined for relevancy by reading the abstracts. A closer examination of the papers determined the relevancy of the papers to the post-disaster rebuilding investigation. A preliminary study of literature articles suggests that BIM interoperability, BIM collaboration, data integrity and cybersecurity, Smart Contract (SC), and Hyperledger Fabric (HLF) are the primary aspects of the scope of this research. Figure 2 depicts a summary of the literature review papers that have been studied.
While many publications exist that tackle the fundamentals, operational mechanisms, and research directions of BCT, limited research papers address areas of BCT that overlap with application in the AEC industry and post-disaster recovery. Even fewer publications are available that focus specifically on the use of BCT in BIM processes in connection with rebuilding after a disaster. However, the current number of papers tackling these subjects are reassuring, as many research results published in recent years propose the employment of BCT, precisely its Smart Contract (SC) concept, to achieve different solutions in a BIM environment.

4. Blockchain Technology (BCT)

4.1. BCT Basics

Blockchain concepts, functionality, present implementation, mining, cybersecurity, and transaction protocols are discussed by many studies, such as [13,14,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33]. The advantages of using different types of BCT are studied by [21,34,35,36,37]. In a blockchain network, the ledger consists of a chain of sequentially arranged blocks of discretized, encrypted data, which is created and stored with cryptographic hashes upon validating a transaction. The two main parts that constitute an individual block are:
  • Block header, consisting of the block version, a timestamp, Merkle tree root hash equivalent of the transactions, nBits, Nonce, and a parent block. A Block version indicates the set of the block validation. Timestamp displays the current universal time. Nonce is a 4 byte field that generally starts from zero, and increases by one for every hash calculation, thus acting somewhat as a transaction counter. The parent block hash is the 256 bit hash value that references the parent block, i.e., the sequentially preceding block to the one in the discussion. The first block in the chain that does not have a precursor is called the genesis block.
  • Block body, which contains the actual transaction data. This is the part of the block that effectively dictates the upper limit of the possible transactions, as well as the transaction time [18].
The digital infrastructure of the blockchain network can be divided into two layers of code [38]:
Fabric layer: consists of the actual blockchain code base, communication protocols, public key infrastructure, data structures for database maintenance, and smart contract capabilities. Since the blockchain network is owned and controlled by the developers, the fabric layer cannot be tampered with.
Application layer: contains the application logic of smart contracts. It is collectively controlled by the participants who deploy the code onto the blockchain network when it is operational. Any participant that holds access and control of the deployed code can write the application layer.
The blockchain networks can be generated in several ways. These are typically organized according to the network’s management and permissions, such as public (permissionless), private (permissioned), and federated [18,39,40,41]. It is worth mentioning that in a public blockchain network, any entity can join as a new user and perform operations, such as transactions or authentications.

4.2. Decentralized Systems

A centralized network is one that tasks a single central node with monitoring, controlling the flow of information between the other nodes, and dictating operational controls. From a personal standpoint, one decision-maker could reduce the likelihood of conflicts and disagreement, but on the other hand, several other factors could affect coherent interoperability and collaborative decision-making, such as if even one of the two parties is acting with malicious intent, or is negligent or incompetent.
A decentralized database structure, which is known as Decentralized Ledger Technology (DLT), is a peer-to-peer network that typically integrates a decentralized agreement mechanism, distributing the computational workload across multiple nodes present throughout the network, facilitating the nodes to create connections, and ensuring the links stay alive, while also ensuring every node in the network receives and transfers out data [18,20,42]. This mechanism excludes the likelihood of a system failure or a complete network blackout. DLTs usually achieve this by integrating a decentralized consensus structure before the blockchain initiating transaction operation. The network participants agree in advance and decide on a consensus mechanism appropriate to their requirements. Every endorsing node in the network runs the same consensus algorithm. Thus, the system does not need any third-party administrator to oversee the data exchange operations [43].

4.3. Trust Systems

Members of the network must prove themselves as legitimate members. Thus, reaching a consensus agreement is one of the key features of a distributed technology [43]. A consensus between all participants in the blockchain network is agreed on prior to the implementation of the BCT, and this agreement ensures that the ledger is shared, unchangeable, and immutable throughout its life.
After agreement on the consensus mechanism, the peers execute the consensus protocol to validate transactions, create blocks and hash chains. The ledger is updated and appended in the event of the occurrence of errors, instead of overwriting them. New transactions recorded on the ledger are validated by miners. A block is mined every few minutes. The Byzantine Generals (BG) problem is central to determining consensus in a BCT, and all consensus mechanisms are developed with the aim to overcome this issue. The Byzantine General Problem was a security flaw in distributed systems developed prior to Bitcoin, in which the nodes aim to reach a consensus despite having a faulty component [44]. This increases the possibility of malicious intent or network irregularities. The different mechanisms through which consensus is reached are:
  • Proof of Work: ‘Mining’ or the Proof of Work (PoW) mechanism works by determining the node that writes a block on ledgers using a combination of game theory, cryptography, and incentive engineering [18]. The nodes in the network compete to solve a mathematical puzzle (generally a computationally difficult but easily verifiable pattern) to record a transaction. Upon resolving the puzzle, a consensus is reached by broadcasting the resolved solution to other nodes in the network, thereby ensuring transparency, robustness, and incorruptibility of the network. Consequently, the group with larger total computing power dictates the decision-making and reaching consensus. The two most popular BCT systems, Bitcoin and Ethereum, operate on a PoW mechanism. However, this involves expensive transaction fees, extensive computing tower, and cumbersome mining processes to create new blocks.
  • Proof of Stake: The creator of the block is chosen in a deterministic method, depending on the stake held by the participant. An algorithm is employed to determine collective decision-making and the level of privacy between participants. This mechanism requires the credibility of data, which is denoted by proof of ownership of cryptocurrency coins. If a created block can be validated, the cryptocurrency will be returned to the original node as a bonus. This method involves no block rewards but operates solely on transaction fees. It is thus an energy-saving alternative to PoW and presents several economic benefits. Ethereum aims to shift the paradigm by transitioning to a PoS mechanism.
  • Practical Byzantine Fault Tolerance (PBFT): This is a Byzantine agreement consensus method that can tolerate a maximum of 1/3 malicious byzantine replicas. A primary is selected in each round and is responsible for ordering the transaction. A node enters the next phase if it receives 2/3 of votes from the remaining nodes in the network [18]. Thus, PBFT requires each node to query other nodes. Hyperledger fabric uses the PBFT algorithm;
  • Delegated Proof of Stake (DPOS): Stakeholders elect representatives to validate blocks. Since this mechanism features a relatively small number of nodes, the processing of transactions is quicker [18]. The delegates are authorized to modify the network parameters.

4.4. Mining

Mining is the mandatory process of recording transactions on the blockchain network using the computer’s processing power. The subset of nodes in the network that are equipped with special software that validate the transactions to be added on the blockchain is called miners [28].

4.5. Privacy

A blockchain can address the accessibility and visibility of the data in a secure and efficient manner, since the ledger is distributed [43,45,46,47,48]. This ledger facilitates setting different levels of privacy, as every participant is essentially a stakeholder and no single participant has full administrative privileges. Thus, formulating and enforcing consensus is crucial to the blockchain operation, with respect to data updates, error-checking, and collective decision-making. The selection of which BCT to use depends much on the method of the agreement to reach consensus.
Based on the privacy, blockchains can be classified as:
  • Permissioned blockchains: Permissioned Blockchains restrict the actors that can contribute to the consensus of the system state. Only a restricted set of users have the rights to validate transactions and may also restrict access to approved actors who can create smart contracts. HLF is an example of this permission type.
  • Permission-less or public blockchains: Blockchain networks that are permission-less allow any participant to create consensus, as well as smart contracts, and uses the PoW mechanism to reach a consensus. They typically use a native cryptocurrency or none to validate transactions. Bitcoin and Ethereum blockchains are good examples of this type of permission.

4.6. Smart Contracts

Smart contracts are contracts programmed with the blockchain that automatically execute upon the fulfilment of certain conditions. This removes the requirement of a third-party intermediary for overseeing the transaction in real-time [45,46,48,49,50]. They are an extension of the blockchain that can independently enforce rules without requiring manual intervention. Figure 3 illustrates the concept of a smart contract in a blockchain network.
The following is a definition for the concept of smart contracts [28]: “Smart contracts are digital contracts allowing terms contingent on the decentralized consensus that is self-enforcing and tamper-proof through automated execution.” The introduction of smart contracts in blockchains has opened many new possibilities, such as complete lifecycle management of legal contracts, automated execution of contracts, and personalization of customizable contracts.
In the context of the BCT taxonomy, two different definitions for the term ‘smart contracts’ are given, since the term is used interchangeably for the written code and the binding contracts [45,46]. Smart contracts codes: They are software agents fulfilling pre-set obligations and exercising certain rights and may take control of certain assets within a shared leger.
  • Smart legal contracts: This term focuses on the expression and implementation of the software and encompasses operational aspects and issues about the composition and interpretation of the contract.
A high-level definition that combines both aspects of the smart contract and is based on automation and enforceability is given in [46]:
“A smart contract is an automatable and enforceable agreement, automatable by a computer, although some parts may require human input and control, enforceable either by the legal enforcement of rights and obligations or via tamper-proof execution of computer code.”
Two widely used programming languages for writing Ethereum Smart Contract (SC) are Solidity and Serpent. Further, there are a number of emerging contract-oriented high-level languages under development, such as Viper, Lisk, and chain.
In a Hyperledger Fabric (HLF), SC is known as chaincode, which is executable code, deployed on the network, where it is invoked and validated by peers during the consensus process. The common programming languages used in developing chaincode are Go, Ruby, Java, and NodeJS [51].
In summary, the main characteristics of a smart contract generally include [46]:
  • Automation: Automation is accomplished by linking the legal prose to the smart contract code via parameters that generate instructions regarding the final operational details.
  • Enforceability: The smart contract code must execute successfully, accurately, and within a reasonable timeframe. A smart legal contract must include legally enforceable obligations and rights that are expressed in complex, time-dependent, sequential, context-sensitive prose. These may also include overriding obligations based on the fulfilment of certain conditions.

4.7. Hyperledger Fabric (HLF)

Hyperledger Fabric is a platform for generating distributed ledger blockchain systems, supported by a modular design, offering an elastic and extensible digital framework that delivers high levels of confidentiality and scalability. The Hyperledger Fabric is designed to support pluggable implementations of different components and accommodate the complexity and details that exist across the economic ecosystem. The Hyperledger blockchain aims to be a general purpose, enterprise-grade, open-source DLT that features permission management, pluggability, enhanced confidentiality, and a consensus mechanism, and is developed through a collaborative effort. HLF is one of the blockchain projects within Hyperledger. Like other BCT, it has a ledger, uses smart contracts, and is a system by which participants manage their transactions.
Hyperledger was founded by the Linux Foundation in 2015 to advance cross-industry BCT. It was the first blockchain developed that enabled the development of distributed applications written in standard general-purpose programming languages [52]. Presently, the Hyperledger consortium involves IBM, the Linux Foundation, and other organizations that contribute to the BCT development and related apps [48]. The open source nature of the BCT is augmented by the lack of necessity in mining cryptocurrency or expensive computations to validate transactions. The HLF was the first blockchain developed that enabled the development of distributed applications written in standard, general-purpose programming languages [52]. HLF was founded by IBM and aims to be a platform for developing applications with a modular architecture. It permits plug-and-play components and leverages containers to host smart contracts called chaincodes, which comprise the business logic of the application.
The fundamental difference between HLF and other blockchain systems is that it is private and requires permissions. In contrast to an open permission-less system that allows unknown identities to participate in the network (necessitating rules like PoW to authenticate transactions and secure the network), the nodes (members) of an HLF network join through a trusted Membership Service Provider (MSP). Furthermore, HLF offers several pluggable options, such as ledger data, which can be stored in multiple formats, and consensus mechanisms, which can be exchanged in and out; diverse MSPs are also supported.
Moreover, Hyperledger Fabric has the ability to create channels, allowing a subgroup of participants in the network to establish a separate ledger of transactions. This is an especially important option for BIM workflow where subcontractors can exchange data within the only subgroup of the network. For example, the structural engineer of record of the project can exchange information with steel connection subcontractors only while still being part of the HLF network and sharing those transactions with the rest of the nodes.
The HLF has several design components that provide a comprehensive yet customizable, enterprise blockchain [44,52,53,54].
  • Assets: Assets can range from physical objects (real estate and hardware) to the intangible (BIM models, contracts, and intellectual property). Hyperledger Fabric provides the ability to modify assets using chaincode transactions.
  • Ledger: It is comprised of a blockchain to save the immutable, sequenced records in blocks, as well as a state database to preserve the fabric state. There is generally one ledger per channel. Each node sustains a copy of the ledger for each channel of which a node is a member. The shared ledger encodes the entire transaction history for each channel and includes SQL-like query capabilities for efficient processing.
  • Privacy: Channels enable multi-lateral data exchanges with the high degrees of privacy and confidentiality required by the AEC specialized and other regulated industries that exchange data on a shared network. A ledger exists in the scope of a channel and it can be shared across the entire network (assuming every participant is operating on one common channel), or it can be constrained to only contain a specific set of participants.
  • Security and Membership Services: Permissioned membership provides a trusted blockchain network, where participants know that all transactions can be detected and traced by authorized regulators and auditors.
  • Consensus: It is defined as the full cycle of verification of the correctness of a set of transactions comprising a block in a distributed ledger system. HLF consensus covers the entire transaction flow, from proposal and endorsement to ordering, validation, and commitment. Hyperledger Fabric has been designed to allow a new application to select a consensus mechanism that best characterizes the relationships that exist between participants in the network.
  • Smart Contracts: Hyperledger Fabric smart contracts are written in chaincode and are invoked by an application external to the BCT when that application needs to interact with the ledger. In most cases, chaincode interacts only with the database component of the ledger, the world state (querying it, for example), and not the transaction log. Chaincode can be implemented in several programming languages. The currently supported chaincode language is Go, with support for Java and other languages coming in future releases.

4.8. Limitations

On one hand, there are notable advantages of BCT that include: the trust system (consensus, mining and the public ledger), secure communication on open networks using cryptography, and encryption; transparency; removal of Intermediaries; decentralization; reduced costs; and increased transaction speed. On the other hand, there are also downsides and risks associated with the standard BCT that can be ignored at this time. These limitations may involve [13,18,25,30,32,33,43,55]:
Lack of Privacy: Decentralized public blockchains lack privacy, which will make full acceptance difficult. Not only is the information not private, but it is also readily accessible at any given moment to anyone using the system This is also concerning considering that the computers running a large amount of the blockchain networks are in countries like Russia and China, where computer crime rates are high and personal information may be used against people living in or traveling to those countries. This is particularly an issue for Bitcoin and Ethereum systems.
Security concerns: Blockchain-based assets are like cash. If the cash in your wallet is stolen or lost, then it is gone. Blockchain-based systems use advanced cryptography and encryption that are more secure than standard internet passwords or number access codes. However, more security can sometimes result in a system being less secure. There are countless examples of cryptocurrencies where someone has forgotten their private key and cannot access their money. With blockchain-based systems, transactions cannot be altered or reversed, and there is no intermediary to assist you if fraud occurs on your account. If you sent funds to the wrong account number (wallet) on the blockchain, then those funds are gone. If someone gains access to your private key, they can access other members’ data easily.
Lack of a centralized management entity: The control is placed with most members of the network, creating issues with regards to control of the blockchain network. The decentralized nature of many blockchains means that the system must agree and decide the future direction of the blockchain system. With a traditional network and software, if an organization wants to make a change, they can make that change after approval from relevant departments within the organization. With a decentralized public blockchain system like Bitcoin, changes must be agreed to by a certain majority of the networks’ participants. This may be over 50% but could be as high as 70% to 80% of the nodes of the network. No single entity has control over the changes or direction of a decentralized blockchain system, making them risky for businesses to use as they cannot manage any changes to the system.
Risk of a 51% attack: If someone were able to control over 50% of the computers on a blockchain network, that person would control the transactions on the blockchain network. A malicious user controlling over 50% of the computers on a blockchain network is known as a 51% attack. Leveraging this control over a cryptocurrency network, they would theoretically be able to block new transactions from confirming, reverse transactions, and allow for moving assets freely in a Bitcoin network.
Cost: The Proof-of-Work (PoW) algorithm that many blockchain networks use requires proof that computing power and resources contributed to the network before a block is added to the network. This proof is in the form of an answer to a puzzle that is attached to the block for the network to confirm it is correct. Solving this puzzle requires an enormous amount of computing power and electricity.
Lack of scalability: At the current rate of energy consumption, the electricity costs of running certain public blockchain system, such as Bitcoin, and using the PoW algorithm make it unfeasible to handle the number of transactions (for example, by credit card companies like Visa and MasterCard). This is one of the factors that is presently affecting the scalability of blockchain networks.

4.9. Summary of BCT

Blockchain systems are generally comprised of four building blocks: (1) a shared ledger, (2) privacy, (3) trust, and (4) smart contracts (see Figure 4). These main blocks are briefly explained below:
Shared ledger: Shared ledger refers to the distributed transaction records in the network. With the bitcoin blockchain system, the intent was to publicize the visibility and transparency of data exchanges. However, enterprise blockchain systems requires a different approach due to the regulation of consumer data.
Privacy: Privacy is achieved through cryptographic encryption of data and ensures that transactions are authenticated and verified. Privacy is a crucial part of the BCT to strengthen security and make the distributed system on the network more difficult to breach.
Trust (consensus): Trust means using the power of the network to verify data transaction. The trust model (consensus) is truly the heart of blockchain applications. Trust is what delivers the tenets of trust, exchanges, and ownership. Trust is what enables the blockchain to displace the transaction system, but this can only happen when trade and ownership are addressed by distributed/shared ledgers. The trust system is modified whenever new participants join the blockchain network and apply BCT to a new use case or change. There is still much work needed to define an optimized trust system for various use cases.
Smart contracts: Smart contracts are business agreements embedded into the transaction database and executed automatically with transactions. Contracts consist of rules that are required in any commerce activities to define the flow of values and the state of transactions. A contract is smart because it uses a computerized protocol to execute the terms of the contract. Various contractual clauses (such as collateral, bonding, delineation of property rights, and so forth) can be transformed into machine language to enforce compliance with the terms of the contract and ensure a successful transaction. Smart contracts are intended to guarantee one party that the other will satisfy their promise. Part of the objective of such contracts is to reduce the costs of verification and enforcement due to the lack of an intermediary party to oversee transactions.
Smart contracts must be transparent (indicating that participants can see or prove each other's actions pertaining to the contract), confirmable (meaning that members can prove to other nodes in the network that a contract has been completed or breached), and private (implying that knowledge of the contents/performance of the contract should involve only the necessary members required to execute it). These advances made it possible for complex business contracts to be codified in a blockchain system.

5. Applications of BCT

5.1. General

While noting that BCT development is still in its infancy, the U.S government has recognized its potential and has begun to study BCT to address various technical issues at different levels, as noted in [56]. The removal of an overseeing third-party as an essential actor in a particular transaction may be viewed less favorably by banks. However, the same report [56] implies an annual $8–$12 billion in savings per bank, stemming from just negating processing fees and paperwork. A critical path for success in governmental implementation that sees widespread systemic integration and use is to lower costs to a minimum well below current levels while providing transparency and secure network services without interruption [56], as is the case for every emergent digital technology. BCT appears to fulfill all these requirements and provides several other applicable use cases as well, and the uptake and direction of development seems to be encouraging at the moment.

5.2. BCT and the AEC Industry

While the digitization of many designs and engineering processes in the AEC industry has seen advances in recent years, it should be noted that the AEC industry has the slowest rate of digital transformation, just above agriculture and hunting [57]. Changes are largely impeded by the fragmented nature of the construction sector, stemming from the current organization of teams and projects, featuring a collaborative process for a project. This is counterproductive in that each party may aim to merely deliver the minimum work order, prioritize profit margins, and minimize liabilities [57]. Thus, the modern economy favors an adversarial environment where firms would be better incentivized by minimizing information exchange between parties. However, in the future, data exchanges in networks can help to achieve significant savings in cost, time, error, and labor, as well as stimulate collaborative learning.
There is still clearly inadequate education at the firm and workforce levels to present an overall holistic picture of how updating current trends could lead to several advantages. Several organizations have not yet recognized the potential and significance of adopting Building Information Modeling (BIM) techniques and have instead concluded that this would, in fact, complicate existing practices, while disregarding the long-term benefit and overhead savings. Further, the collaborative design process in BIM could create difficulties in assigning responsibilities and liabilities due to the overlap of roles and responsibilities, ensuring intellectual property protection, risk allocation, privacy, third-party reliance, and software agents [22,58]. The focus of firms on return on investment, the complexity of projects, large initial capital, firm reputation, untrained personnel, legal considerations, and government restrictions are other factors that still impede digitization.

5.2.1. Current Advances

The advent of Building Information Modelling (BIM) has facilitated a collaborative work environment with a single centralized model, so that the structure can be analyzed, checked for compliance, and cleared of errors in the design stage prior to actual construction. Adopting BIM presents a novel way of integrating all pertinent data into a shared digital model with geometric, temporal, and financial and asset management dimensions. BIM software, like Revit and ArchiCAD, also includes a plethora of plug-in tools that can simulate and assess several important aspects of a building structure, such as operational energy analysis, lifecycle costs, occupancy behavior, connection design, interior acclimatization, building envelope, quantizing ecological footprint, etc. Thus, one can simulate scenarios and focus on one or more specific variables in real-time for every stage in the building lifecycle. This not only avoids unforeseen circumstances and errors in future stages but greatly saves time, manual labor, and the need for excessive paperwork.

5.2.2. Blockchain in Construction Management

Blockchain technology, while still in its nascent developmental stages, has the potential to accelerate and streamline much of today’s design and engineering practices with a multitude of benefits to the firm, individual, industry, clients, and society. The implementation of BCT could lead to the effective management and utilization of several tools that would drive efficiencies, transform industry culture, and advance futuristic advancements, such as [21]:
  • Building information modelling software for intelligent and collaborative 3D design and modelling;
  • cloud-based technology, allowing for real-time creation and coordination of a visualized database and serving as a platform for multi-disciplinary collaboration;
  • smart contracts, a set of coded instructions that can automatically execute upon the fulfillment of certain conditions;
  • reality capture technology, allowing verification and conversion of digital assets into real value;
  • managing the Internet of Things (IoT);
  • functionally permissioned blockchains that facilitate consensus-based collaboration.
BCT can considerably slash administrative costs, effectively protect intellectual property rights, and eliminate cumbersome paperwork, manual verifications, and contract execution. A potentially new stream of revenue for design professionals could be created by evaluating and selling designs and workflows. This, however, would also include addressing future problems that might arise, such as a possible drop in quality standards and continued liability [21].
Building a reputation is an essential asset to any organization, which is difficult to quantify and compare. BCT can facilitate the creation of a registry consisting of past achievements and qualifications, with a goal to enable comparison of team constellations and thus aiding in decision-making processes for clients and project managers to select a well-balanced team with varied skill sets, experience, and versatility [21].

5.3. BCT Applications in Disaster Relief

The management of the post disaster recovery process can be slowed down because of the poor management of permitting process. Incorporating fast-tracked approaches and enhancing collaboration with other stakeholders can reduce the repairs, and new construction permits delays [59]. There are insufficient efforts highlighting such problems when preparing a post-disaster management plan. The post-disaster recovery goals are to reconstruct a built environment that is sustainable and can stand against any future disaster events. Decision makers can learn from the consequences of unplanned recovery process as what happened in Venezuela in 1999, where 15,000 people lost their lives due to mudslides and floods. These people were relocated to an unsafe region after the major landslide of 1984 [1]. In the United States, the Federal governments has created 10 different zones directed by FEMA staff to coordinate and support the local government response to the disasters in their jurisdictions.
According to FEMA, pre-disaster and post-disaster planning can be categorized into four stages. Every stage has a range of activities and decisions that should be taken to achieve a full recovery. The different response activities have been addressed by the National Response Framework (NRF) and the National Disaster Recovery Framework (NDRF). Both are federal Frameworks that complement each other. The tasks that need to be performed during short term and intermediate recovery stages are critical for saving lives and properties and providing basic needs. Some of these activities include sheltering, rescuing, debris clearing, power restoring, and building repairing. These tasks can last for months. The long-term recovery stage tasks focus on the reconstruction of buildings and infrastructures that have been impacted significantly. This stage may last for several years if the damage scope is enormous [60].
The inherent characteristics of a distributed ledger make it an appropriate tool to implement in disaster management systems, as evidenced by recent efforts. Connecting services tasked with transporting food, water, and other aid are often impeded by a lack of transparency between different functionalities, cumbersome coordination between different parties, complicated logistical planning, delayed deliveries, shortages, and a waste of resources [8].
Rohr [61] states that disaster situations necessitate absolute transparency, which only distributed networks can provide [62]. BCT can thus act as the central system of all operations by connecting all involved parties and enhancing convenience in communication while upholding a secure protocol over the network. A model proposed by [63] suggests an integrative model over a blockchain network that connects government bodies, medical suppliers, shelter providers, relief aid, telecom service providers, residents, and transportation providers.
The transparency and automated dissemination of recorded information that is characteristic of BCT can negate the requirement of human involvement and arduous paperwork [8] for sanctioning approvals and can further streamline other managerial operations.
‘Building Blocks’ is a blockchain initiative launched in January 2017 by the World Food Program (WFP). This initiative targets the Azrap refugee camp in Hordan, with the aim of increasing the overall efficiency of the cash-based transfer scheme in a number of processes, such as refugee registration and financial accounting [63]. Initial development and deployment were achieved in under five months. Building Blocks was meant to augment and increase the efficiency of the existing digital infrastructure of WFP’s processes for beneficiary information registration and payment mechanisms by streamlining back-end processing while the cash system used by the beneficiaries was unchanged [63]. It involves an integrative synthesis of blockchains, digital databases, and biometrics, and is estimated to have saved WFP monthly costs of $150,000 by eliminating 98% of bank-related fees [63].

6. Blockchain and BIM

This section addresses issues related to the potential capabilities of BCT in scaling and enriching the BIM process. It explores various aspects of existing BIM workflow that could benefit from the integration of blockchain technologies.
BIM is at the forefront of digital transformation in the AEC industry, encouraging collaboration and trust and simplifying data exchange. McGraw-Hill reports that BIM adoption increased to 71% in 2012 from 49% in 2009 [17,64]. BIM models present a comprehensive design model of the building that can include all aspects of the structure, like architecture, structural elements, and MEP design areas. Further, several built-in plug-ins in BIM platforms, like Autodesk Revit, enable the simulation of external site conditions, geography, weather, as well as carry out energy analysis, building energy modeling, structural analysis, etc. In the future, BIM development will eventually aim to unify all design and analysis tools in one platform.
In terms of the benefits incurred from the adoption of BIM in the AEC industry, Cannistrato [65] studied data from 408 projects over 6 years, totaling $558,858,574, to quantify how much BIM contributed to saving money. The report indicated that BIM saved more money and the project team became more collaborative in the process. Another example is the study by [66], which indicated similar results. Their investigation covered a set of 35 case studies between 2008–2010, which all indicate cost savings due to BIM usage. The study has also noted reduced times in project schedules, improved communication, greater information exchange, and higher levels of coordination. The data clearly implies that initial costs, such as hardware upgrades, software implementation, and training of personnel, are offset on the long term upon BIM implementation. However, the BIM process still bears a number of shortcomings. These include some limitations in the schema, technical toolset, and managerial aspects of the current BIM process. More specifically, these deficiencies involve:
  • an insufficient toolset or methods that can efficiently comment or mark upon Requests For Information (RFIs) [67],
  • no archive of BIM model changes and modification history,
  • impracticality in the generated list of design errors [68],
  • inapplicability of the integrated model for co-designing in real-time [68,69],
  • a clear generation of comparative deviation reports contrast design changes between different file versions,
  • detailed open model templates [70],
  • insufficient communication standards and BIM model sharing that can lead to interoperability issues between different BIM tools [71,72,73],
  • a lack of tools to map complex collaborative workflows and insufficient levels of interoperability [74],
  • difficulties in assigning responsibilities and liabilities due to the overlap of roles and responsibilities, ensuring intellectual property protection, risk allocation, privacy, and third-party reliance and software agents [22,58],
  • insufficient cyber-resilience of the software platform and consequent risks and liability to data theft, tampering, and other cyber-attacks,
  • time-consuming re-modeling, conversions, and other repetitive tasks that could be automated during the project phases [74],
  • the lack of a legal framework detailing model data ownership and legal/contractual issues [74].

6.1. Data Ownership

BIM can address the issue of converting intrinsic value to digital values by creating added value, coupled with BCT’s ability to provide reward mechanisms in the form of virtual currencies that hold validity long after the project’s completion. BIM authoring tools can expand their potentials by adding budget control objects to assist in tracking costs and savings. #AECoin is a recently developed cryptocurrency specifically created for design and engineering transactions. This currency could help address the difficulties in assigning responsibilities and liabilities due to an overlap of roles and responsibilities, ensuring intellectual property protection, risk allocation, and privacy in the current BIM workflow [22]. Connecting the budget control objects with #AECoin will add many benefits to the BIM process. For instance, #AECoin and the proposed budget control objects can be used to measure the added intrinsic and intangible value of a physical artifact and accurately calculate the rewards earned by the participant by assessing the individual/collaborative project contribution over the product’s lifecycle. This concept of monetizing designs throughout the lifecycle would ensure a superior outcome and more effectively motivate engineers and architects to deliver their best efforts by providing proportionate incentives.

6.2. Cybersecurity

6.2.1. BIM workflow and Security

Most industries currently rely on the “security through obscurity” approach to secure engineering, which emphasizes the confidentiality of the implementation and mechanisms of the cybersecurity system. Thus, a small leak of information could potentially endanger the entire network [55]. BIM offers a diverse multifunctional workspace that addresses asset management, performance monitoring, and changes management through the lifecycle, apart from overlooking the planning, design, and construction phases of the structure. To facilitate continuous collaboration among all parties, BIM makes use of Common Data Environment (CDE), which provides a single repository for project information. This repository is used to collect, manage, and distribute data for multi-disciplinary teams [24]. It requires the auditing, monitoring, and tracking of data through the CDE, which will develop throughout the project’s lifecycle. Hence, it is vital to provide suitable governance and curation to address information management and uphold data security, quality, and integrity. Since BIM involves complex interactions involving collaborative actions and information exchange between actors, technology and processes, and inter-relationships, it is crucial to consider cyber-security implications, assess current levels of reliability, address current drawbacks, and reinforce security. In current usage, all BIM data are electronically shared across a common data environment. It is essential for all project members to understand and abide by cybersecurity rules [37]. There are fewer trust issues among BIM actors compared to those in traditional information sharing. However, BIM’s complicated collaborative framework creates security issues of data leakage, information theft, and information protection while dealing.
Both permissioned and permission-less BCTs have their respective advantages and drawbacks, and the BCT for use must be chosen appropriately based on the desired functionality and level of privacy needed. Concerning BIM workflow, there are generally several different parties working simultaneously on one model. In such cases, implementing a permission-less blockchain could produce positive effects, such as improved communication, transparency of work, and opportunities for collaborative design processes. However, the current socio-economic environment of the AEC industry may necessitate tighter management of permissions due to concerns like data theft, conflicting interests, misuse of information, and others concerns arising from the number of third-parties involved in a typical construction project, which usually entails high levels of copyright, budget, and accountability to government bodies and regulatory entities. Hence, employing a permissioned blockchain is a far more realistic option for most BIM projects.
Cybersecurity can be defined as “the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance and technologies that can be used to protect the cyber environment and organization and user’s assets” [24]. The cyber environment includes the Internet, telecommunication networks, embedded processors, controllers, sensors, data storage and control devices, as well as the information, services, and collaborative and business functions that only exist in cyberspace.
Cybersecurity threats that can potentially affect BIM workflow. Its connected systems can be classified into three categories:
  • External threat agents: unconnected malicious outsiders, criminal entities attempting to access data for reconnaissance, hackers, intellectual property theft, the leak of sensitive or confidential information, and malware that can attack the BIM database;
  • Internal threat agents: involved participants who may bear malicious intent, the abuse of authorized access to steal, leak, or corrupt information to disrupt BIM operations, as well as human errors like omissions, ignorance, or negligence of work;
  • Systems and business failures: natural causes by extreme weather, interference from animals, storage device failures, poor maintenance of the centralized IT infrastructure, bankruptcies, and business failures.

6.2.2. Advantages of using BCT for Improving Cybersecurity

The elimination of the requirement of a designated intermediary party to oversee data transactions in the network offers several improvements over existent systems in terms of cybersecurity levels. Blockchain networks ensure that no single node in the network has complete access to all the information. Multi-signature (multisig) protection can add another layer of security in authorizing transactions by accepting more than one key. Hackers can gain complete access in the network only if more than 50% of the nodes are compromised [55].
Effective interoperability can be achieved by ensuring the identifiability and authentication of participants and establishing a ubiquitous and secure infrastructure that serves as a repository for data storage, as well as a reliable platform that facilitates data exchange, subject to required permissibility levels. Key features of a blockchain, such as utilizing secure cryptography, asset sharing, auditing trails of data access, and a resilient peer-to-peer network, present a novel and promising emergent method of addressing cybersecurity and collaborative issues. However, it should be noted that the implementation of BCT does not directly ensure infallibility. Further, blockchain can enable a secure and transparent method of Proof of Delivery (PoD) for the transport and delivery of physical assets [33].

6.2.3. Trust

The immutable, instantaneous, and transparent nature of DLT emphasizes compliance and trust between all involved parties on the network. The current economy, which is inherently adversarial, incentivizes the minimal exchange of information between parties involved in the completion of a project with the intention of protecting one’s interests. The advent of BCT is increasingly disruptive to the existing paradigm and will shift work culture in a direction that rewards collaboration and proves advantageous in the design process by facilitating better-informed decision making, collaborative learning, and easier debugging of errors. This change can be accelerated by the ability of BCT to reward the intrinsic value of any data through an #AECoin cryptocurrency [21]. Blockchain can facilitate the creation of a registry comprised of past achievements and the qualifications of individuals, with a view toward enabling a comparison of team constellations and thus aiding in the decision-making processes for clients and project managers to select a versatile and well-balanced team with diverse skill sets and experience. The BCT platforms can primarily serve as recordkeeping tools to record changes in the BIM model throughout the design and construction phases of the structure.
Moreover, smart contracts can be programmed to automate awarding or revoking privileges based on the satisfaction of certain terms, as well as store an immutable record of all modifications in the BIM model data, along with other associated information [27]. The tamper-proof append-only nature of the records in a DLT also help to enforce compliance among workers. The transparency of the DLT coupled with the database properties of BIM [27] can introduce an ‘evidence of trust’ [21], which would create a new value proposition for the AEC industry.

7. Automation of the Building Permit Process

7.1. Background

The building authorities’ role in post-disaster efforts is to support relief exertions, expedite the inspection of the existing buildings safety, and provide the construction permits for new buildings and retrofitting. In general, these permits are needed if the owner aims to change the size, the structure, or the use of the building. The building authorities use the adopted codes to outline the permissions and the required technical details [75]. Enforcement of the applied building code and design standards in the rebuilding process is obligatory to avoid any imminent destruction, as seen in countries such as Haiti [59]. The permitting process is complicated during post-disaster redevelopment more than pre-disaster development due to the additional responsibilities imposed on the building officials to assess damages and uphold federal and state government requirements.
In response to the challenges and calls to modernize and expedite the local government agencies’ operations, the state of Florida has adopted variety of laws to facilitate electronic transactions and establish a legal framework to solve any interstate business disputes; these laws are known by the Electronic Signature Act and the Uniform Electronic Transactions Act (UETA) [76]. The advantages of going digital were explained in Florida statues 668.001. The Building Authorities in Florida have been slow to adopt and benefit from e-business and other innovations in the AEC industry compared to the private sector. The reasons for this reluctancy are the pushback against change and organizational and technical problems. All changes come with costs and impacts [77]. The shift of some Architecture and engineering firms into digital-based operations has reduced the time and costs of delivering their services and products compared to the traditional way.
Several building authorities have learned that changing their traditional paper-based process to an electronic-based process at the time of submitting and reviewing a construction permit is the best way to cope with the statewide growth of the construction industry. This process is known as e-permitting. The county of Osceola in the south central of Florida has launched a new initiative to expedite the permitting process by allowing their customers to use an e-plan submission system. As a result, the participants’ stockholders can submit and track their permits online. The county building department is discussing the use of an e-plan system internally with more departments, such as the planning department. This attempt has saved the Osceola building department about 60 hours per month for reviewing the plans. The time to review commercial buildings has been reduced to 10 business days compared to 5 weeks in the past. According to The Alliance for Building Regulatory Reform in the Digital Age, the electronic-based process has not just helped in saving time—it has helped to protect the environment. The impacts of such a process on one of the building departments that issue 3000 permits every year included the reduction of 20,800 gallons of gas, the elimination of 312,000 miles and 12,480 h of driving, the saving of $57,200 for fuel, and the preservation of 239 trees [15,16]
In times of disasters, the e-permitting processes can facilitate the ability to review plans from anywhere and anytime. Furthermore, the ability to store the design documents on servers using e-permitting technology can help the first responders have quick access to as-built designs of the collapsed buildings and save people’s lives [15] Further advantage for the Jurisdiction’s switched to an electronic review process is the ability to conduct a parallel review by multiple departments. Introducing the BLT+BIM framework to e-permitting will yield further benefits, particularly for post-disaster rebuilding efforts.
Nowadays, growing numbers of building code communities are looking for the best way to benefit from the technological evolution of Building Information Modeling (BIM) to streamline the plan review process [15]. The existing plan review systems, such as Solibri and CORENET E-PlanCheck, were the first initiatives that demonstrated the ability to develop a smart review system. However, these systems were limited in their use and can only check the model based on specific codes. This research aims to develop a framework approach for Virtual Permitting Process (VPP) to address post-disaster rebuilding in the state of Florida based on the local construction standards and current building codes.

7.2. Automated Code-Checking and Compliance (ACCC) Framework

Regulations are normative texts prescribed by governing entities to enforce constraints to design and engineering processes and manufacturing based on existing conditions and function as the defining text for laws, codes, specifications, standards, etc. Automating or semi-automating code-checking and compliance processes in the AEC industry would benefit the industry by saving time, money, labor, and minimizing the chancefor risk and human errors. While much of the decision-making and consideration of the code is dependent on the experience of the reviewers, automation could at least enforce the upper and lower limits and report results instantaneously. The translation of various clauses and statements into computable language presents a major challenge in achieving automation [78,79]. However, following an ideal framework to develop a tool that successfully accounts for all regulations through an accurate interpretation of formal language and model data exchange could be pivotal in increasing efficiency and upholding safety standards in any AEC projects.
The process tree of an automated rule verification system involves taxonomy development, a logical arrangement of rules, and interpretation in its first phase. This phase is followed by generating building model data and the commencement of information checking. Then, the actual rule compliance verification process is executed, and the results are reported. There are several techniques to translate natural language into a set of rules. There have been developments in Artificial Intelligence, markup document modelling, and hypertext to formulate efficient domain knowledge representation techniques [80,81,82,83,84,85]. Recent research on the ACCC has been focused more on the concept of regulatory text mining and semantic web approaches for creating a computable representation [86,87,88]. Other studies are centered mainly on the automated or semi-automated extraction of information from regulatory texts into rules using Artificial Intelligence (AI) and Natural Language Processing (NLP) [89,90,91,92].
The introduction of the Industry Foundation Classes (IFC) was the most significant data standard for building a model schema [93], since it offered an open-source, flexible, and standardized schema that could interact with many supporting technologies. Taking advantage of the standardized IFC schema to represent BIM model data and the automatable and enforceable properties of smart contracts, ACCC can be carried out in a much more effective, secure, and instantaneous way while instantly transmitting results to various parties [79,94]. Using BCT also negates the need to store all pertinent model checking data in one centralized location.
Clash detection, or clash prevention, is the most frequently employed compliance-checking domain to validate models. This method is popular because of its favorable effort–benefit ratio, which allows the project team members to simultaneously detect discrepancies in the model from design, or detect a clash between two or more facets of the building structure [95]. Most BIM platforms generally provide tools to perform clash detection studies. This technique, however, is limited in that it does not facilitate a comprehensive code review and verification of information-rich content embedded in the BIM objects. A rule-based validation method is, therefore, essential for ACCC to be able to process complex building attributes, design specifications, environmental conditions, and other areas that can be sufficiently validated through visual methods.
The primary objective of developing an efficient framework to automate code-checking and compliance processes is to achieve a computable model with a clear syntax to accurately represent code requirements, reduce model complexity, and develop a unified format to exemplify building regulations and building information modelling [80,81]. The compliance checking process must be secure and collaborative. The following example demonstrates the potential application of the HLF in improving the security and efficiency of the automatic design review process in a BIM workflow.

7.3. Proposed Integrative BCT+BIM Framework

To address the issues related to post-disaster rebuilding, this paper introduces new approaches for automating, or semi-automating, the building permit process. These methods are based upon integrating the ACCC with blockchain systems (see Figure 5). The three primary components of the framework are the Generalized Adaptive Framework (GAF) for the ACCC model, as proposed by [82], smart contracts, and blockchain network systems. The BCT proposed for this framework is described below:
(i) Permissioned Blockchain
Given the multidisciplinary nature of a BIM project, with teams who may belong to different organizations, and considering other project participants with varying levels of functions and privileges, a permissioned blockchain is the most suitable BCT for a collaborative BIM environment. Thus, this study proposes the Hyperledger Fabric (HLF), since it relies on a permissioned blockchain. A permissioned blockchain provides a way to protect data exchanges between members of entities who share a mutual goal but have intellectual properties that they need to secure while exchanging information. A permissioned blockchain depends on the identities of its peers, and, thus, they can use traditional Byzantine-fault tolerant (BFT) consensus mechanisms. BFT is a protocol that has been widely used in IT solutions to reach a consensus on the state of faulty nodes in a network.
The HLF is based upon modular and extensible architectures. An example of possible modules that can be plugged in and implemented in the Hyperledger Fabric include (see Figure 6):
(a)
Membership services: This module deals with permissioning and serves to create a root of trust during network formation. This module is also vital in managing the identity of members participating in the blockchain network. It provides a specialized digital certificate authority for issuing certificates to members of the blockchain network.
(b)
Chaincode services: A chaincode, or a smart contract, is application-level code stored on the ledger as a part of a transaction. The chaincode runs transactions that may modify the data on the ledger. Business logic is written as a chaincode (often in the Go or Java languages). A chaincode is installed on network members’ machines, which require access to the asset states to perform read and write operations. The chaincode is then instantiated on particular channels for specific peers. Ledgers are normally shareable across entire networks of peers or include only a specific set of participants. Peers can participate in multiple blockchain channels.
(c)
Consensus services: These services are at the heart of any blockchain application. They enable a trust system. The consensus service permits digitally signed transactions to be proposed and validated by network members. The consensus is normally pluggable and tightly linked to the endorse-order-validation model that the Hyperledger proposes. The ordering services in HLF represent the consensus system. The ordering service groups multiple transactions into blocks and outputs a hash-chained sequence of blocks containing transactions.
A transaction in Hyperledger is simply a request to the blockchain to invoke a function on the ledger. The function is implemented by a chaincode (smart contract). Cryptography ensures the integrity and security of transactions by linking the transaction to previous blocks and linking the cryptogram or hash from previously linked blocks. Each channel in HLF is its own blockchain. A smart contract functions as a trusted, distributed application and gains its security from the blockchain and the underlying consensus among its network nodes.
The SDK (Software Development Kit) enables the development of applications that deploy and invoke transactions on a shared ledger. Currently, the Hyperledger Fabric supports both Node.js and Java SDK. The SDKs are critical in blockchain application development. With an SDK, one can create the application client, chaincode, users, and events in the HLF.
This study suggested a structure that stores building codes rules and BIM model data off-chain and facilitates the chaincode to function as the model checker and building permit issuer. The details of this mechanism include:
(a)
The building codes or regulations upon which the BIM model data are to be examined must be processed into a computable language. A smart contract (chaincode) can be programmed to process the rules from a natural language using GAF [81]. This contract must be defined carefully to account for all clauses, terms, and variables used in the building code and regulations. After transformation of the rules, the smart contract generates a second appended smart contract that can now be used by the model checker. If the smart contract’s capabilities do not support adequate levels of semantic enrichment, the rules can be directly expressed in the scripting languages.
(b)
The BIM model data are exported from the platform in IFC format (ifcXML) and accessed using the scripting language, such as Java or Go, employed by the smart contract platform. The BIM model data file is now generated and used as off-chain data.
(c)
A model checker is programmed in the form of another smart contract that can extract information from the BIM model data upon calling and verify that information against the translated rules created in step (a).
(d)
The model checker invokes the code-checking functions and creates another smart contract where the results are reported and sent to an authority to confirm the final permit.
(ii) External Oracles
Governing authorities, legislative bodies, and licensing entities can use external oracles to force an external state into the programmed chaincode. The concerned party can directly force the rules required to validate the building model using a smart contract containing the building model data expressed in a scripting language and can view output results directly. External oracles can also be used to directly append changes and updates in existing building codes and regulations that are present in the form of smart contracts.
(iii) Sidechains or Cross-Chain bridges
A sidechain is a mechanism that can provide a solution to address the scaling issue that is essentially a hierarchy of lower tier consensus instances [96], which can provide a lower degree of decentralization. A sidechain is a blockchain that runs in parallel to the main blockchain, which extends its functionality through interoperable blockchain networks, permitting a decentralized method of transactions between the two chains. Figure 7 exemplifies the model of the sidechain data processing framework.

A Case Study

This example depicts a higher-level framework for implementing the proposed approach described in the previous section. This case study assumes that a BIM model has been developed for new construction after a disaster. Figure 8 illustrates the instances of invoking the proposed framework in post-disaster recovery efforts. Sharing BIM data will enable building departments to receive 3D and other building designs and component data that can be used to expedite the electronic plan review and field inspections while facilitating the exchange of BIM data with neighboring jurisdictions, should the need arise during a future disaster or post-disaster event.
Using the proposed integrative BCT+BIM framework, the BIM model data and the building code regulations are encrypted using BCT. The chaincode (containing a set of key-value pairs representing the initial state of the BIM model) is saved on the peer’s computers (nodes) participating in the HLF and invoked on the channel. The chaincode contains logic defining a set of data exchange instructions and any agreed upon financial terms. An endorsement policy has also been set for this chaincode, stating that both node X and node Y must endorse any transaction [51]. A smart contract can be created using a Turing-complete programming language (C# or Java). This contract consists of information relating to the compliance checking of model data against regulations, the order in which it is carried, and the corresponding output. This contract is also discretized and encrypted into blocks. Thus, this method is secure, fast, discrete and efficient in that it records every code-checking transaction in the permanent ledger, and the information is available for peer viewing.
(i) Initiate a Data Exchange
Architect or homeowner A is sending a request to the building department to review the design and issue a building permit (R) for the project. The request includes a BIM model for the project. The request targets node A and node R, who are, respectively, representative of architect or owner (A) and building reviewers (R). The endorsement policy states that both members of the network must endorse any transaction. Therefore, the request is sent to node A and node R.
The next step is to construct a transaction request. This is achieved by leveraging a supported Software Development Kit (SDK) (using Java, Go, etc.) that uses one of the available Application Programming Interfaces (APIs), creating a data exchange proposal. The proposal is a request to invoke a chaincode function so that data can be read and written to the ledger. With the help of the HLF SDK, the transaction proposal is transformed into a proper format utilizing the user’s cryptographic credentials to generate a unique signature for this transaction request (see Figure 9).
(ii) Verify and Execute
The endorsing nodes in the channel verify that: (a) the transaction proposal is well formed, (b) it has not been submitted previously (replay-attack protection), (c) the signature is valid (using MSP), and (d) that the submitter (Architect A, in the example) is accurately approved to accomplish the proposed operation on that channel (i.e., the submitter satisfies the channel’s writer policy (the writing policy specifies, at the time of channel creation, which user is permitted to submit a transaction to that channel).
The nodes consider the transaction request inputs as arguments to the invoked chaincode’s function (see Figure 10). The chaincode is then executed against the current state database to generate transaction results (including a response value), read the dataset, and updating dataset. No updates are made to the ledger at this point. This result, along with the endorsing node’s signature, is conveyed back as a proposal response to the SDK, which parses the information for the application to process.
(iii) Request Authentication
The application validates the nodes’ signatures and examines the request responses to see if the responses are the correct ones. The chaincode will then process the request and send it to the respective parties for further processing (see Figure 11). This can occur, for instance, when requests for an input from the zoning department are needed to verify the site location of the project. The system is generally built in such a way that even if an application decides not to verify responses, or otherwise forwards an unauthorized transaction, the endorsement policy will still be enforced by the nodes and maintained at the validation phase before writing results to the ledger.
(iv) Assemble Replies
The blocks of data are then validated and transmitted to all nodes on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
Then, the application will transmit the transaction proposal and response within a transaction message to the correct code checking services, which can consist of several chaincodes. The transaction will contain the read/write datasets, the endorsing nodes’ signatures, and the Channel identification ID. Then, the application will build up the blocks of the code’s compliance, checking transactions per channel (see Figure 12).
(v) Validation and Transmission
The blocks of data are then validated and transmitted to all peers on the channel of the network. The validation process also ensures that there have been no changes to the ledger state, and blocks are marked as being valid or invalid.
(vi) Updating the Database
The blocks will be appended from each node in the channel for valid blocks and written to the current state of the ledger (see Figure 13). After the transaction is committed to the database, an event is invoked to notify the Architect or the owner (A) that the reply from the building review authority (R) transaction has been appended to the chain, and the owner or the Architect can take further actions.

8. Conclusions

This paper presents a comprehensive survey of BCT and its applications in the built environment and examines BCT’s potential integration with Building Information Modeling (BIM) workflow. This study examines how commissioning distributed ledger technology (DLT), such as the Hyperledger Fabric (HLF), could be advantageous in the BIM working processes by reinforcing network security, providing more reliable data storage and management of permissions, and ensuring change tracing and data ownership.
The building permitting process is more complicated during post-disaster redevelopment than pre-disaster development, due to the additional responsibilities imposed on the building officials to assess damages and uphold federal and state government requirements. The process is often characterized by a longer duration, which adversely affects the rebuilding efforts. The proposed BCT+BIM framework has the potential to enchance the permitting process and positively impact post-disaster recovery efforts.
The present example indicates that the application of BCT in a BIM workflow creates a system that is built on the principles of decentralization, open governance (or self-governance), and transparency, a system that rewards innovation and eradicates disintermediation. Moreover, such systems provide the secure execution of BIM data exchanges and validation through privacy and trust mechanisms, in a secure process that facilities speedy, robust transactions. The cryptographically enforced interconnectivity in the blockchain applications fosters the stability and security of distributed ledgers.
HLF is a BCT that is particularly suited for developing the automation of code-checking compliances (ACCC) in BIM workflows, due to its ease of programming (using SDK), flexibility, user-defined smart contract (chaincode), robust security, identity features, and modular architecture with pluggable consensus protocols. The example presented depicts that the smart contract technologies (also known as chaincodes) available in HLFs are promising technologies for advancing the security and efficiency in the AEC industry, particularly for post-disaster recovery. The removal of an overseeing third-party in the proposed BCT+BIM as an essential actor in any transaction related to post-disaster rebuilding could lead to significant savings by negating processing fees, paperwork, and the time needed to issue building permits. Moreover, the proposed integrative BCT+BIM framework aims to provide transparency and secure network services without interruption during the process of rebuilding after a disaster. In this framework, the HLF can address many of the current concerns, such as data security, privacy, the speed of transactions, and change tracing and permission management that arise from using centralized BIM work processes. Future research will focus on expanding the integrative framework to include other issues related to post-disaster recovery efforts, such as infrastructures and services.

Author Contributions

The authors’ contributions include conceptualization, N.O.N.; methodology, S.R.; software, N.O.N.; validation, N.O.N.; formal analysis, S.R.; investigation, N.O.N.; writing—original draft preparation, N.O.N.; project administration, N.O.N.; funding acquisition, N.O.N.

Funding

This research received no external funding.

Acknowledgments

This research was partially supported by the College of Design, Construction, and Planning (DCP) at the University of Florida. The author would like to extend his sincere gratitude to DCP for providing the seed fund for this research project.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. NOAA National Centers for Environmental Information (NCEI). U.S. Billion-Dollar Weather and Climate Disasters. 2019. Available online: https://www.ncdc.noaa.gov/billions/ (accessed on 22 April 2019).
  2. Berke, P.; Newman, P.; Lee, J.; Combs, T.; Kolosna, C.; Salvesen, D. Evaluation of Networks of Plans and Vulnerability to Hazards and Climate Change: A Resilience Scorecard. J. Am. Plan. Assoc. 2015, 81, 287–302. [Google Scholar] [CrossRef]
  3. Olshansky, R.B.; Johnson, L.A.; Horne, J.; Nee, B. Longer View: Planning for the Rebuilding of New Orleans. J. Am. Plan. Assoc. 2008, 74, 273–287. [Google Scholar] [CrossRef]
  4. Garrett, T.A.; Sobel, R.S. The Political Economy of FEMA Disaster Payments. Econ. Inq. 2003, 41, 496–509. [Google Scholar] [CrossRef]
  5. Gunes, E.; Kovel, J.P. Using GIS in Emergency Management Operations. J. Urban Plan. Dev. 2000, 126, 136–149. [Google Scholar] [CrossRef]
  6. Dakhil, A.; Alshawi, M. Client’s Role in Building Disaster Management through Building Information Modelling. Procedia Econ. Financ. 2014, 18, 47–54. [Google Scholar] [CrossRef]
  7. Link, L.E. The anatomy of a disaster, an overview of Hurricane Katrina and New Orleans. Ocean Eng. 2010, 37, 4–12. [Google Scholar] [CrossRef]
  8. Guillot, C. How Blockchain Could Speed Hurricane Disaster Relief, ThirtyK. 2018. Available online: https://thirtyk.com/2018/07/31/hurricane-relief-blockchain/ (accessed on 20 April 2019).
  9. Muis, S.; Güneralp, B.; Jongman, B.; Aerts, J.C.J.H.; Ward, P.J. Flood risk and adaptation strategies under climate change and urban expansion: A probabilistic analysis using global data. Sci. Total Environ. 2015, 538, 445–457. [Google Scholar] [CrossRef]
  10. Pelling, H. Social Geography of British Elections 1885–1910; Springer: New York, NY, USA, 1967. [Google Scholar]
  11. Bosher, L.; Dainty, A.; Carrillo, P.; Glass, J. Built-in resilience to disasters: A pre-emptive approach. Eng. Constr. Archit. Manag. 2007, 14, 434–446. [Google Scholar] [CrossRef]
  12. Drogemuller, R. BIM support for disaster response. In Proceedings of the 9th Annual International Conference of the International Institute for Infrastructure Renewal and Reconstruction (8–10 July 2013); Barnes, P.H., Goonetileke, A., Eds.; Queenland University of Technology: Brisbane, Australia, 2015; pp. 391–405. [Google Scholar]
  13. Crosby, M.; Nachiappan, P.; Verma, S.; Kalyanaraman, V. Blockchain Technology: Beyond Bitcoin; Sutardja Center for Entrepreneurship & Technology Technical Report; University of California: Berkely, CA, USA, 2015. [Google Scholar]
  14. Crosby, M.; Pattanayak, P.; Verma, S.; Kalyanaraman, V. Blockchain technology: Beyond bitcoin. Appl. Innov. 2016, 2, 6–10. [Google Scholar]
  15. Wible, R.C. Best Practices in Electronic Plan Submittal, Review, Tracking and Storage. Alliance for Building Regulatory Reform in the Digital Age at FIATECH. 2007. Available online: http://www.natlpartnerstreamline.org/documents/WhitePaper_ElectPlan_092107.pdf (accessed on 4 May 2019).
  16. Wible, R.C. Federal Grants to State and Local Governments for Streamlining and Information Technology. Report Prepared by Wible & Associates, Alliance for Building Regulatory Reform in the Digital Age. 2009. Available online: http://www.natlpartnerstreamline.org/documents/GrantReportRW-IT_Streamlining_111009.pdf (accessed on 14 June 2019).
  17. Tama, B.A.; Kweka, B.J.; Park, Y.; Rhee, K.H. A critical review of blockchain and its current applications. In Proceedings of the ICECOS 2017, 2017 International Conference on Electrical Engineering and Computer Science: Sustaining the Cultural Heritage Toward the Smart Environment for Better Future, Palembang, Indonesia, 22–23 August 2017; pp. 109–113. [Google Scholar] [CrossRef]
  18. Zheng, Z.; Xie, S.; Dai, H.; Chen, X.; Wang, H. An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends. In Proceedings of the 2017 IEEE 6th International Congress on Big Data, BigData Congress, Honolulu, HI, USA, 25–30 June 2017; pp. 557–564. [Google Scholar] [CrossRef]
  19. Brandão, A.; São Mamede, H.; Gonçalves, R. Systematic review of the literature, research on Blockchain technology as support to the trust model proposed applied to smart places. In World Conference on Information Systems and Technologies; Springer: Cham, Switzerland, 2018; pp. 1163–1174. [Google Scholar]
  20. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: www.Bitcoin.Org (accessed on 5 May 2019).
  21. Mathews, M.; Robles, D.; Bowe, B. BIM+ Blockchain: A Solution to the Trust Problem in Collaboration? In Proceedings of the CITA BIM Gathering, Dublin, Ireland, 23–24 November 2017; p. 11. [Google Scholar]
  22. Turk, Ž.; Klinc, R. Potentials of Blockchain Technology for Construction Management. Procedia Eng. 2017, 196, 638–645. [Google Scholar] [CrossRef]
  23. Atkins, B.J.B.; Mendelson, A.D. BIM Me Up, Scotty: Navigating Risk in Digital. White Paper. 2013. Available online: https://www.theaiatrust.com/white-paper-bim-me-up-scotty-navigating-risk-in-digital-practice/ (accessed on 22 January 2019).
  24. Boyes, H. Cybersecurity and Cyber-Resilient Supply Chains. Technol. Innov. Manag. Rev. 2015, 5, 28–34. [Google Scholar] [CrossRef]
  25. Swan, M. Blockchain Temporality: Smart Contract Time Specifiability with Blocktime. In Rule Technologies. Research, Tools, and Applications, 10th International Symposium, RuleML, Stony Brook, NY, USA; Springer: Cham, Switzerland, 2016; pp. 399–404. [Google Scholar]
  26. Andersen, M.P.; Kolb, J.; Chen, K.; Fierro, G.; Culler, D.E.; Katz, R. Democratizing authority in the built environment. In Proceedings of the 4th ACM International Conference on Systems for Energy-Efficient Built Environments—BuildSys ’17, Delft, The Netherlands, 8–9 November 2017; pp. 1–10. [Google Scholar]
  27. Wang, J.; Wu, P.; Wang, X.; Shou, W. The outlook of blockchain technology for construction engineering management. Front. Eng. Manag. 2017, 4, 65–67. [Google Scholar] [CrossRef]
  28. Cong, L.W.; He, Z. Blockchain Disruption and Smart Contracts. Rev. Financ. Stud. 2019, 32, 1754–1797. [Google Scholar] [CrossRef]
  29. Coyne, R.; Onabolu, T. Blockchain for architects: Challenges from the sharing economy. Archit. Res. Q. 2017, 21, 369–374. [Google Scholar] [CrossRef]
  30. Puthal, D.; Malik, N.; Mohanty, S.P.; Kougianos, E.; Yang, C. The Blockchain as a Decentralized Security Framework [Future Directions]. IEEE Consum. Electron. Mag. 2018, 7, 18–21. [Google Scholar] [CrossRef]
  31. Li, J.; Greenwood, D.J.; Kassem, M. Blockchain in the built environment: Analysing current applications and developing an emergent framework. In Proceedings of the Creative Construction Conference, Ljubljana, Slovenia, 30 June–3 July 2018; pp. 1–10. [Google Scholar] [CrossRef]
  32. Feig, E. A Framework for Blockchain-Based Applications. arXiv 2018, arXiv:1803.00892v1. [Google Scholar]
  33. Hasan, H.R.; Salah, K.; Member, S. Blockchain-based Proof of Delivery of Physical Assets with Single and Multiple Transporters. IEEE Access 2018, 6, 46781–46793. [Google Scholar] [CrossRef]
  34. Mahamadu, A.M.; Mahdjoubi, L.; Booth, C. Challenges to bim-cloud integration: Implication of security issues on secure collaboration. In Proceedings of the International Conference on Cloud Computing Technology and Science, CloudCom, Bristol, UK, 2–5 December 2013; Volume 2, pp. 209–214. [Google Scholar] [CrossRef]
  35. Mason, J. Intelligent Contracts and the Construction Industry. J. Leg. Aff. Disput. Resolut. Eng. Constr. 2017, 9, 04517012. [Google Scholar] [CrossRef]
  36. Mason, J.; Escott, H. Smart Contracts in Construction: Views and Perceptions of Stakeholders. In Proceedings of the FIG Conference, Istanbul, Turkey, May 2018; Available online: http://eprints.uwe.ac.uk/35123/ (accessed on 10 April 2019).
  37. Hammi, A.; Bouras, A. Towards Safe-Bim Curricula Based on the Integration of Cybersecurity and Blockchains Features. In Proceedings of the INTED, Valencia, Spain, 5–7 March 2018; pp. 2380–2388. [Google Scholar]
  38. Glaser, F. Pervasive Decentralisation of Digital Infrastructures: A Framework for Blockchain enabled System and Use Case Analysis. In Proceedings of the HICSS 2017 Proceedings, Waikoloa Village, HI, USA, 4–7 January 2017; pp. 1543–1552. [Google Scholar] [CrossRef]
  39. Buterin, V. On public and private blockchains; Ethereum blog. Available online: https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains (accessed on 14 June 2019).
  40. Christidis, K.; Devetsikiotis, M. Blockchains and Smart Contracts for the Internet of Things. IEEE Access. 2016, 4, 2169–3536. [Google Scholar] [CrossRef]
  41. Wood, D.G. Blockchains: What and Why. 2016. Available online: https://www.slideshare.net/gavofyork/blockchain-what-and-why (accessed on 11 April 2019).
  42. Wang, Y.; Han, J.H.; Beynon-Davies, P. Understanding blockchain technology for future supply chains: A systematic literature review and research agenda. Supply Chain Manag. Int. J. 2019, 24, 62–84. [Google Scholar] [CrossRef]
  43. Brakeville, S.; Perepa, B. Blockchain Basics: Introduction to Business Ledgers Get to Know This Game-Changing Technology and IBM’s Contribution to It. 2016. Available online: https://scooblr.com/assets/uploads/2016/08/cl-blockchain-basics-intro-bluemix-trs-pdf.pdf (accessed on 22 April 2019).
  44. Xu, X.; Pautasso, C.; Zhu, L.; Gramoli, V.; Ponomarev, A.; Tran, A.B.; Chen, S. The Blockchain as a Software Connector. In Proceedings of the 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), Venice, Italy, 5–8 April 2016; pp. 182–191. [Google Scholar] [CrossRef]
  45. Clack, C.D.; Bakshi, V.A.; Braine, L. Smart Contract Templates: Essential requirements and design options. arXiv 2016, arXiv:1612.04496. [Google Scholar]
  46. Clack, C.D.; Bakshi, V.A.; Braine, L. Smart Contract Templates: Foundations, design landscape and research directions. arXiv 2016, arXiv:1608.00771. [Google Scholar]
  47. Frantz, C.K.; Nowostawski, M. From Institutions to Code: Towards Automated Generation of Smart Contracts. In Proceedings of the 2016 IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS* W), Augsburg, Germany, 12–16 September 2016. [Google Scholar] [CrossRef]
  48. Seijas, P.L.; Thompson, S.; McAdams, D. Scripting smart contracts for distributed ledger technology. IACR Cryptol. ePrint Arch. 2016, 1156. [Google Scholar]
  49. Bhargavan, K.; Delignat-Lavaud, A.; Fournet, C.; Gollamudi, A.; Gonthier, G.; Kobeissi, N.; Kulatova, N.; Rastogi, A.; Sibut-Pinote, T.; Swamy, N.; et al. Formal Verification of Smart Contracts. In Proceedings of the 2016 ACM Workshop on Programming Languages and Analysis for Security—PLAS’16, Vienna, Austria, 24 October 2016; pp. 91–96. [Google Scholar] [CrossRef]
  50. Dhawan, M. Analyzing Safety of Smart Contracts. In Proceedings of the Conference: Network and Distributed System Security Symposium, San Diego, CA, USA, 16–17 February 2017. [Google Scholar] [CrossRef]
  51. Hyperledger. Hyperledger-Fabric Docs Master Documentation. 2017. Available online: https://hyperledger-fabric.readthedocs.io/en/release-1.1/key_concepts.html (accessed on 10 March 2018).
  52. Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Ferris, C.; Manevich, Y.; et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. In Proceedings of the Thirteenth EuroSys Conference on—EuroSys ’18, Porto, Portugal, 23–26 April 2018; pp. 1–15. [Google Scholar] [CrossRef]
  53. Liang, X.; Zhao, J.; Shetty, S.; Liu, J.; Li, D. Integrating blockchain for data sharing and collaboration in mobile healthcare applications. In Proceedings of the 2017 IEEE 28th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC), Montreal, QC, Canada, 8–13 October 2017; pp. 1–5. [Google Scholar] [CrossRef]
  54. Bartoletti, M.; Pompianu, L. An Empirical analysis of smart contracts: Platforms, applications, and design patterns. In Lecture Notes in Computer Science (including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); 10323 LNCS; Springer: Cham, Switzerland, 2017; pp. 494–509. [Google Scholar]
  55. Kshetri, N. Blockchain’s roles in strengthening cybersecurity and protecting privacy. Telecommun. Policy 2017, 41, 1027–1038. [Google Scholar] [CrossRef]
  56. ACT-IAC. Enabling Blockchain Innovation in the U.S. Federal Government. 2017. Available online: https://www.actiac.org/system/files/ACT-IAC ENABLING BLOCKCHAIN INNOVATION_3.pdf (accessed on 10 May 2019).
  57. Belle, I. The architecture, engineering and construction industry and blockchain technology. In Proceedings of the 2017 National Conference on Digital Technologies in Architectural Education and DADA 2017 International Conference on Digital Architecture; China Architecture Industry Publishers: Nanjing, China, 2018; pp. 279–284. [Google Scholar]
  58. Sherif, A.; Jinkook, L.; Chuck, E. Automated Cost Analysis of Concept Design BIM Models. In Designing Together: Proceedings of the 14th International Conference on Computer Aided Architectural Design; Les Éditions de l’Université de Liège: Liège, Belgium, 2011; pp. 403–418. [Google Scholar]
  59. Mannakkara, S.; Wilkinson, S. Post-Disaster Legislation for Building Back Better. Constr. Law J. 2013, 29, 495–506. [Google Scholar]
  60. Smith, G.; Sandler, D. State Disaster Recovery Guide; Department of Homeland Security Coastal Hazards Center of Excellence: Chapel Hill, NC, USA, 2012. [Google Scholar]
  61. Rohr, J. Blockchain for Disaster Relief: Creating Trust Where It Matters Most. Available online: https://www.digitalistmag.com/improving-lives/2017/11/23/blockchain-for-disaster-relief-creating-trust-where-it-matters-most-05527536 (accessed on 24 June 2019).
  62. Zambrano, R.; Young, A.; Verhulst, S. BLOCKCHANGE CASE STUDY: Connecting Refugees to Aid through Blockchain-Enabled ID Management: World Food Programme’s Building Blocks. 2018. Available online: https://blockchan.ge/blockchange-resource-provision.pdf (accessed on 14 June 2019).
  63. Panesir, M.S. Blockchain Applications for Disaster Management and National Security. Master Thesis, Faculty of the Graduate School of the University at Buffalo, State University of New York, Buffalo, NY, USA, 2018. [Google Scholar]
  64. Azhar, S. Building Information Modeling (BIM): Trends, Benefits, Risks, and Challenges for the AEC Industry. ASCE Lead. Manage. Eng. 2011, 11, 241–252. [Google Scholar] [CrossRef]
  65. Cannistrato, M.P. Savings Through Collaboration: A case study on the value of BIM. J. Build. Inf. Model. Fall 2010, 29–30. [Google Scholar]
  66. Bryde, D.; Broquetas, M.; Volm, J.M. The project benefits of building information modelling (BIM). Int. J. Proj. Manag. 2013, 31, 971–980. [Google Scholar] [CrossRef]
  67. Shourangiz, E.; Mohamad, M.I.; Hassanabadi, M.S.; Banihashemi, S.S.; Bakhtiari, M.; Torabi, M. Flexibility of BIM towards Design Change. In Proceedings of the 2nd International Conference on Construction and Project Management, Singapore, 16–18 September 2011; Volume 15, pp. 79–83. [Google Scholar]
  68. Kerosuo, H.; Miettinen, R.; Paavola, S.; Mäki, T.; Korpela, J. Challenges of the expansive use of Building Information Modeling (BIM) in construction projects. Production 2015, 25, 289–297. [Google Scholar] [CrossRef]
  69. Miettinen, R.; Paavola, S. Beyond the BIM utopia: Approaches to the development and implementation of building information modeling. Autom. Constr. 2014, 43, 84–91. [Google Scholar] [CrossRef]
  70. Cerovsek, T. A review and outlook for a “Building Information Model” (BIM): A multi-standpoint framework for technological development. Adv. Eng. Inform. 2011, 25, 224–244. [Google Scholar] [CrossRef]
  71. Nawari, N.O. BIM Standard in Off-Site Construction. J. Archit. Eng. 2012, 18, 107–113. [Google Scholar] [CrossRef]
  72. Nawari, N.O. BIM standards: Advancement and industry deployment. In Proceedings of the 14th International Conference on Computing in Civil and Building, Engineering, Moscow State University of Civil Engineering, Moscow, Russia, 27–29 June 2012. [Google Scholar]
  73. Nawari, N.O.; Alsaffar, A. Advancing BIM Standardization: Floating Structures. In Proceedings of the International Conference on Civil and Building Engineering Informatics (ICCBEI 2015), Tokyo, Japan, 22–24 April 2015; p. 78. [Google Scholar]
  74. Ahn, Y.H.; Kwak, Y.H.; Suk, S.J. Contractors’ Transformation Strategies for Adopting Building Information Modeling. J. Manag. Eng. 2015, 32, 05015005. [Google Scholar] [CrossRef]
  75. FEMA. Building Codes Fact Sheet [Official Website of the Department of Homeland Security]. Retrieved from Building Codes Toolkit—Fact Sheet Website; 2013. Available online: https://www.fema.gov/media-library-data/20130726-1903-25045-6626/building_codes_toolkit_fact_sheet_508.pdf (accessed on 3 May 2019).
  76. Earles, M.D. Clicking on the Dotted Line: Florida’s Enactment of the Uniform Electronic Transactions Act as a Boost to E-Commerce. Nova Law Rev. 2000, 25, 9. [Google Scholar]
  77. Rankin, J.H.; Chen, Y.; Christian, A.J. E-Procurement in the Atlantic Canadian AEC Industry. ITcon 2006, 11, 75–87. [Google Scholar]
  78. Eastman, C.; Lee, J.M.; Jeong, Y.S.; Lee, J.K. Automatic rule-based checking of building designs. Autom. Constr. 2009, 18, 1011–1033. [Google Scholar] [CrossRef]
  79. Nawari, N.O. Automating Codes Conformance. J. Archit. Eng. 2012, 18, 315–323. [Google Scholar] [CrossRef]
  80. Nawari, N. Building Information Modeling: Automated Code Checking and Compliance Processes; CRC Press, Taylor & Francis Group, LLC: Boca Raton, FL, USA, 2018. [Google Scholar]
  81. Nawari, N.O. A Generalized Adaptive Framework for Automating Design Review Process: Technical Principles. In Proceedings of the 35th CIB W78 Conference, Chicago, IL, USA, 1–3 October 2018; pp. 405–414. [Google Scholar]
  82. Dimyadi, J. Automated Compliance Audit Processes for Building Information Models with an Application to Performance-Based Fire Engineering Design Methods. Ph.D. Thesis, The University of Auckland, Auckland, New Zealand, 2016. [Google Scholar]
  83. Dimyadi, J.; Clifton, C.; Spearpoint, M.; Amor, R. Computerizing Regulatory Knowledge for Building Engineering. J. Comput. Civ. Eng. 2016, 30, 1–13. [Google Scholar] [CrossRef]
  84. Lee, H.; Lee, J.K.; Park, S.; Kim, I. Translating building legislation into a computer-executable format for evaluating building permit requirements. Autom. Constr. 2016, 71, 49–61. [Google Scholar] [CrossRef]
  85. Salama, D.M.; El-Gohary, N.M. Semantic Modeling for Automated Compliance Checking. In Proceedings of the 2011 ASCE International Workshop on Computing in Civil Engineering, Miami, FL, USA, 19–22 June 2011; pp. 641–648. [Google Scholar] [CrossRef]
  86. Kiyavitskaya, N.; Zeni, N.; Mich, L.; Cordy, J.R.; Mylopoulos, J. Text mining through semi automatic semantic annotation. In International Conference on Practical Aspects of Knowledge Management; Springer: Berlin/Heidelberg, Germany, 2006; pp. 143–154. [Google Scholar]
  87. Pauwels, P.; Van Deursen, D.; Verstraeten, R.; De Roo, J.; De Meyer, R.; Van de Walle, R.; Van Campenhout, J. A semantic rule checking environment for building performance checking. Autom. Constr. 2011, 20, 506–518. [Google Scholar] [CrossRef]
  88. Cao, D.; Wang, G.; Li, H.; Skitmore, M.; Huang, T.; Zhang, W. Practices and effectiveness of building information modelling in construction projects in China. Autom. Constr. 2015, 49, 113–122. [Google Scholar] [CrossRef]
  89. Zhang, J.; El-Gohary, N.M. Semantic NLP-Based Information Extraction from Construction Regulatory Documents for Automated Compliance. J. Comput. Civ. Eng. 2012, 30, 04015014. [Google Scholar] [CrossRef]
  90. Zhang, S.; Teizer, J.; Lee, J.K.; Eastman, C.M.; Venugopal, M. Building Information Modeling (BIM) and Safety: Automatic Safety Checking of Construction Models and Schedules. Autom. Constr. 2013, 29, 183–195. [Google Scholar] [CrossRef]
  91. Zhang, S.; Boukamp, F.; Teizer, J. Ontology-based semantic modeling of construction safety knowledge: Towards automated safety planning for job hazard analysis (JHA). Autom. Constr. 2015, 52, 29–41. [Google Scholar] [CrossRef]
  92. Zhang, J.; El-Gohary, N.M. Extending Building Information Models Semiautomatically Using Semantic Natural Language Processing Techniques. J. Comput. Civ. Eng. 2016, 30, C4016004. [Google Scholar] [CrossRef]
  93. Bloch, T.; Katz, M.; Sacks, R. Machine learning approach for automated code compliance checking. In Proceedings of the 17th International Conference on Computing in Civil and Building Engineering, Tampere, Finland, 5–7 June 2018. [Google Scholar]
  94. Bloch, T.; Sacks, R. Comparing machine learning and rule-based inferencing for semantic enrichment of BIM models. Autom. Constr. 2018, 91, 256–272. [Google Scholar] [CrossRef]
  95. Getuli, V.; Ventura, S.M.; Capone, P.; Ciribini, A.L. BIM-based Code Checking for Construction Health and Safety. Procedia Eng. 2017, 196, 454–461. [Google Scholar] [CrossRef]
  96. Croman, K.; Decker, C.; Eyal, I.; Gencer, A.E.; Juels, A.; Kosba, A.; Miller, A.; Saxena, P.; Shi, E.; Sirer, E.G.; et al. On scaling decentralized blockchains (A position paper). In Lecture Notes in Computer Science (including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); 9604 LNCS; Springer: Berlin/Heidelberg, Germany, 2016; pp. 106–125. [Google Scholar] [CrossRef]
Figure 1. The outline of the research methodology. BIM, Building Information Modeling.
Figure 1. The outline of the research methodology. BIM, Building Information Modeling.
Buildings 09 00149 g001
Figure 2. Summary of the review articles related to the research key aspects. BCT, Blockchain Technology; HLF, Hyperledger Fabric.
Figure 2. Summary of the review articles related to the research key aspects. BCT, Blockchain Technology; HLF, Hyperledger Fabric.
Buildings 09 00149 g002
Figure 3. The concept of smart contract in a blockchain network.
Figure 3. The concept of smart contract in a blockchain network.
Buildings 09 00149 g003
Figure 4. Main components of BCT.
Figure 4. Main components of BCT.
Buildings 09 00149 g004
Figure 5. Integrative BCT + BIM Framework for Virtual Permitting.
Figure 5. Integrative BCT + BIM Framework for Virtual Permitting.
Buildings 09 00149 g005
Figure 6. Application Programming Interface (API), Hyperledger Fabric (HLF) System. SDK, Software Development Kit.
Figure 6. Application Programming Interface (API), Hyperledger Fabric (HLF) System. SDK, Software Development Kit.
Buildings 09 00149 g006
Figure 7. Sidechain data processing concept.
Figure 7. Sidechain data processing concept.
Buildings 09 00149 g007
Figure 8. Rebuilding after a disaster and the proposed BCT+BIM framework.
Figure 8. Rebuilding after a disaster and the proposed BCT+BIM framework.
Buildings 09 00149 g008
Figure 9. Data exchange initiation between an architect (owner) and building authority.
Figure 9. Data exchange initiation between an architect (owner) and building authority.
Buildings 09 00149 g009
Figure 10. The response of the R nodes (building review authority) to the initial request.
Figure 10. The response of the R nodes (building review authority) to the initial request.
Buildings 09 00149 g010
Figure 11. Constructing blocks of the results.
Figure 11. Constructing blocks of the results.
Buildings 09 00149 g011
Figure 12. Constructing blocks of the results.
Figure 12. Constructing blocks of the results.
Buildings 09 00149 g012
Figure 13. Updating the Hyperledger.
Figure 13. Updating the Hyperledger.
Buildings 09 00149 g013
Back to TopTop