Project Data Categorization, Adoption Factors, and Non-Functional Requirements for Blockchain Based Digital Twins in the Construction Industry 4.0

Abstract

As key technologies of the fourth industrial revolution, blockchain and digital twins have great potential to enhance collaboration, data sharing, efficiency, and sustainability in the construction industry. Blockchain can improve data integrity and enhance trust in the data value chain throughout the entire lifecycle of projects. This paper aims to develop a novel theoretical framework for the adoption of environmentally sustainable blockchain-based digital twins (BCDT) for Construction Industry (CI) 4.0. The paper identifies which key data from construction projects lifecycle should be anchored in BCDTs to benefit CI 4.0 and the environment. The paper also identifies key factors and non-functional requirements necessary for the adoption of BCDTs in a decentralized and sustainable CI 4.0. At first, a content analysis of the literature allowed the identification of which data from projects lifecycle would benefit from blockchain technology (BCT) adoption and what the key factors and non-functional requirements necessary for the adoption of BCDT in the CI4.0 are. Furthermore, the analysis of structured interviews and online survey permitted to firstly validate the hypotheses raised from the literature and to offer a novel framework for BCDT of CI 4.0 in the context of the circular economy (CE). The findings are that (1) the key project lifecycle data relevant for BCDTs relate to the BIM dimensions (3D, 4D, 5D, 6D, 7D, and 8D) and a new dimension called the contractual dimension (cD) is also proposed. (2) Ecosystems of BCDTs should embrace a novel form of collaboration that is decentralized and presented as Level 4 maturity for BCDTs. This new level of maturity leverages distributed blockchain networks to enhance collaboration, processes automation with smart contracts, and data sharing within a decentralized data value chain. Finally (3), the main non-functional requirements for BCDTs are security, privacy, interoperability, data ownership, data integrity, and the decentralization and scalability of data storage. With the proposed framework including the BCDT dimensions, the Maturity Level 4, and the key non-functional requirements, this paper provides the building blocks for industry practitioners to adopt BCDTs. This is promising for CI 4.0 to embrace a paradigm shift towards decentralized ecosystems of united BCDTs where trust, collaboration, data sharing, information security, efficiency, and sustainability are improved throughout the lifecycle of projects and within a decentralized CE (DCE).

1. Introduction

1.1. General Information

The industrial revolution 4.0 powered by digitization is transforming industries and improving efficiencies by leveraging new technologies [1]. Despite being rigid and slower to adopt new technologies, the CI is embracing BIM, IoT, DT, VR, AR, 3DP, ML, AI, Cloud Computing, DT, and CPS [1]. However, the data value chain in the CI is still fragmented in data silos, which limit collaboration and data sharing [2]. This leads to inefficiencies and a lack of trust and generates adversarial behaviours such as contractual litigations and a financial race to the bottom for competitiveness, which affects projects delivery and quality [3].

This paper focuses on the data value chain throughout the lifecycle of construction projects (funding, planning, design, scheduling, manufacturing, construction, operation, maintenance, decommission, demolition, and recycling) for the adoption of BCDT, which comprise the following emerging technologies for CI 4.0: BCT, DT, IoT, CPS, BIM, Big Data, Cloud computing, ML, and AI.

A DT is a digital replica of a physical asset such as a smart building. According to Microsoft, a digital twin is the virtual model of an IoT-enabled smart physical asset combined with ML and data analytics to simulate, visualize, interact, and generate outcomes on the actual physical asset [4]. This paper considers particularly DT throughout the lifecycle of a smart infrastructure project, including key phases such as planning, design, manufacturing, procurement, supply chain, construction, operations, and maintenance.

BCT encompasses P2P networks and cryptography to secure a distributed database of historical timestamped transactions. BCT is secure by nature and provides a single source of truth for its transactional data history. Data recorded in a blockchain are trusted, immutable, public or private (depending on the type of network), cryptographically secured, and traceable. Blockchain protocols are decentralized, and they run on P2P networks, which do not rely on any centralized trusted third party. This decentralization ensures that the data anchored in a blockchain are not controlled by any single entity and hence are censorship-resistant. Additionally, BCT can automate business logic with programmable transactions called smart contracts. Smart contract automation can increase efficiency by automating various business processes.

The CI suffers from a lack of trust [3], a lack of collaboration [2], inefficiencies, and faulty waste management [5]. BCT has the potential to increase trust, security, efficiency, collaboration, and sustainability in CI 4.0. Based on a previously developed framework that evaluated the need for BCT for Industry 4.0 applications [6], it is likely that BCT is required for applications in CI 4.0. Indeed, in CI 4.0, the information is transacted among multiple parties who do not necessarily trust each other and are all not particularly willing to trust a third party [7]; hence, blockchain could be useful to exchange data. Secondly, the entities who handle payments are also not necessarily trusted [2]; hence, blockchain could be useful to handle payments. Thirdly, the IT infrastructure providers are also not particularly trusted; hence, blockchain could contribute to enhancing trust through the use of blockchain-based distributed storage services. Hence, BCT could be beneficial for DTs of CI 4.0, particularly for data exchange, payments services, and distributed data storage.

DTs leverage various technologies of CI 4.0 such as 3D simulations, BIM, IoT, 4G and 5G networks, blockchain, edge computing, cloud computing, ML, and AI. DT integrates data from the information value chain to improve assets performance and benefit customers, owners, operators, governments, investors, and society as a whole [8]. The data value chain relates to key processes of the data lifecycle, such as data acquisition, data analysis, data curation, data storage, and data usage [9]. Hence, the Big Data from the data value chain of CI projects form a key component of DT, and it is essential to categorize the project lifecycle data that should be considered for sustainable BCDT in CI 4.0. The BIM dimensions [10] provide a widely accepted and sustainable framework to categorize BIM data from the lifecycle of projects.

The four emerging themes for DT are supply and demand, operational performance, live data management, and simulation purposes [4]. BCT can improve applications leveraging these themes by automating processes and business logic, facilitating real-time monitoring, leveraging transparency, traceability, immutability, security, and trust in the data value chain. DT ecosystems should align with the Gemini principles [11] described as follows. Firstly, DT should have a purpose for the public good, for value creation, and to provide valuable insights. Secondly, DT should guarantee trust through security, openness, and data quality. And thirdly, DT should function effectively and leverage model federation, data curation, and embrace technological evolution. Smart cities and DTs should also tend towards ecosystems of united twins where multiple DTs can benefit from one another’s data by leveraging cross-organizational collaboration and data sharing [8].

DTs can be classified by levels of autonomy, intelligence, learning, and fidelity [4]. BCT can contribute to DT autonomy with smart contracts automation. Moreover, BCT can secure the integrity of the data value chain by providing a trustworthy audit trail of historical data transactions. BCT could be the missing component to resolve the problem of maintaining accurate data over time. Trusted historical data can be used to describe smart assets states with fidelity, audit financial and contractual data, improve asset management, reduce maintenance costs, and inform, plan, design, and build future smart infrastructures with data mining of trusted information. Hence, BCT could ensure the integration of a secured and trusted data value chain for DT and legitimate BCDT autonomy, intelligence, learning, and fidelity.

Data security is essential for DTs, and the CIA triad (confidentiality, integrity, and availability) should be considered for their data security; Moreover, the seven pillars of cybersecurity to consider for DT are security, data encryption, identity, and authentication, the principle of least privilege, security audit, monitoring life events, responding to incidents, and management of devices [4]. Data integrity for DTs can be improved by blockchain networks that are cryptographically secured and provide an immutable history of transactional data. Hence, BCT could provide a tamper-proof history of timestamped data from sensors, energy consumption, or any states changes. Additionally, blockchain can facilitate real-time monitoring through smart contracts and offer efficient data availability [12]. Data ownership and data privacy are also essentials for DTs to be user-centric and to benefit data owners, decision-makers, and society in general [4]. BCT has the potential to address requirements in terms of data ownership [13]. However, data confidentiality and privacy are challenges for BCT, which is typically open.

BCT offers a paradigm shift that removes intermediaries and creates new business models. BCT powers the narrative of the new decentralized internet called Web 3.0, which challenges the current centralized internet infrastructures and the model referred to as Web 2.0, which is controlled by tech giants. Web 3.0 aims to decentralize the internet, remove middlemen, and redistribute control and data ownership towards users and data owners. Blockchain-based decentralized storage networks for Web 3.0 can improve data security and availability while incentivizing the participating providers to secure the network by storing data in a P2P way. The tokenization of data using blockchain smart contracts, cryptocurrencies, and decentralized oracles can incentivize data owners and bring tangible value for the data value chain along the project lifecycle [4]. BCT is decentralized and secured by nature; it can facilitate data sharing and ensure data trustworthiness and immutability for CDE gathering static and live project data.

DTs will also play a major role in the environment and reduce wastes through energy tracking, monitoring, optimization, and reporting [4]. Moreover, BCT can contribute to the environment and the circular economy. BCT can improve waste management with materials’ tracking for recycling and reuse; BCT can also optimize smart grids energy management [2]. Hence, BCDT has strong potential to enhance environmental sustainability.

Hence, to develop a framework for the adoption of environmentally sustainable BCDT for Construction Industry (CI) 4.0, this paper aims to address the research questions presented below.

1.2. Research Questions

To develop a framework for the adoption of BCDT in CI 4.0, it is essential to identify which data from the project’s lifecycle would need to be anchored in the blockchain. Hence, the Big Data value chain of construction project lifecycles is at the core of the research. Due to the very limited storage capacity of BCT, it is essential to filter the type of data to anchor on the blockchain while less critical data can be stored off the blockchain.

Secondly, as BCT offers a paradigm shift from the traditional centralized data silos towards decentralized peer-to-peer networks, it is crucial to identify the key factors affecting the transition towards that paradigm shift.

Thirdly, as BCDTs represent a novel form of software platforms, it is required to identify what the key non-functional requirements for these applications are. Hence, the three research questions that this paper aims to answer are:

• What are the project lifecycle key data to consider for sustainable blockchain-based digital twins (BCDT) in CI 4.0?
• What are the key factors necessary for the Web 3.0 paradigm shift of decentralization that BCDTs embrace to reduce data silos; improve collaboration, data sharing, and trust; and create new business models in CI 4.0?
• What are the key non-functional requirements for BCDT in CI 4.0?

1.3. Aim and Scope

The aim of this paper is to develop a novel theoretical framework for the adoption of sustainable BCDT for CI 4.0.

The first section of the paper identifies initial themes from the literature for each research question. The research hypotheses are raised from these emerging themes. The second section of the paper validates the emerging themes and offers new themes based on the analysis of data from interviews and an online survey. Hence, to address the three research questions, the paper will follow the three objectives listed below.

• The first objective is to validate the hypothetical categorization of key project data for BCDTs (extracted from the literature) in order to define which essential data from the project lifecycle are relevant to transact with sustainable BCDTs.
• The second objective is to validate the hypothetical key factors (extracted from the literature) that are necessary for a paradigm shift powered by BCDTs in CI 4.0.
• The third objective is to identify and validate the main non-functional requirements for BCDTs of CI 4.0.

To achieve these objectives, the paper is organized as follows. Section 2 presents the emerging themes identified in the literature and the related research hypotheses for each objective. Section 3 describes the research method followed to achieve the research objectives. Section 4 presents the results of the analysis data collected from semi-structured interviews and an online survey. Section 5 explains the findings and the new themes obtained from the data analysis to address the research objectives. Section 6 and Section 7, respectively, contain the discussion about the paper findings and the conclusion.

Lastly, the paper proposes a novel theoretical framework for the adoption of environmentally sustainable BCDT in CI 4.0.

2. Identification of the Research Themes

A content analysis of the literature was initially carried out to extract preliminary themes related to the research questions. The literature reviewed was selected for its relevance to the technologies discussed in this paper: blockchain technology (BCT), building information modelling (BIM), the Internet of Things (IoT), and DTs (digital twins) in CI 4.0. The key themes identified in the literature for each research question are presented in the chapters below.

2.1. Project Lifecycle Key Data for BCDT

To answer the first research question, it is essential to identify and categorize the key data that would benefit the project if they were transacted with blockchain-based digital twins (BCDTs) throughout projects’ lifecycles. BIM and 3D modelling represent central components of spatially enabled DT. Hence, the first approach was to use the existing BIM framework consisting of dimensions [10] and levels of maturity [14]. The BIM dimensions are the spatial dimension (3D), time dimension (4D), costs dimension (5D), maintenance dimension (6D), sustainability dimension (7D), and safety dimension (8D).

The literature was analysed to identify the analogies between the BIM framework (BIM dimensions and levels of maturity) and the key benefits and drivers of BCT and DTs in the CI4.0. Thus, the classification of project lifecycle data relevant to BCDTs was performed in accordance with the BIM dimensions [10], which hypothetically appeared suitable to capture most of the key project lifecycle information relevant for BCDTs. Consequently, the BIM framework was extrapolated to a similar novel framework for BCDTs, forming the first hypothesis of this paper. However, a data container was missing to gather some key information related to contracts, data ownership, and data notarization. Indeed, with the emergence of BCT, it is necessary to implement a contractual framework between BIM and blockchain smart contracts [2]. To address this requirement, a new dimension nD [10] is hypothetically proposed by this paper to integrate a contractual level of information to BIM and DTs by using BCT. Hence, this paper proposes another hypothetical novel contractual dimension (cD) for BCDTs that leverages BCT and smart contracts. The cD dimension comes as the apparent missing link to enhance trust, data integrity, and security of the data value chain over time. The cD dimension would leverage blockchain technology to improve trust, transparency, immutability, security, traceability, data ownership, contractual processes, accountability, identity proofs, intellectual property (IP), and copyrights [15].

Hence, the key findings and project lifecycle data relevant to BCDTs identified in the literature are shown in

Table 1. Summary of the literature related to project lifecycle data required for BCTDs categorized as per the BIM dimensions.

Benefits and Drivers of BCT and DT for Data Type Related to BIM Dimensions	Comparative Use Cases
Design data (3D)
Paradigm shift enabling to design using data mining [5] Design parameters recorded on the blockchain [16] Blockchain to trace and secure versions of the design history [16] Spatially enabled digital twins [17] Collaborative monitoring of design changes with BCT [18]	Notarize design records
Smart contracts to record BIM data in a tamper proof way [2] BIM collaboration including records of all timestamped transactions using BCT [3] Blockchain smart contracts to record BIM changes during design and construction [13] BIM data recorded on the blockchain [13,18] Archival of models changes and modification history using BCT [15,18] Record BIM changes throughout the design using BCT [19]	Record BIM changes
Construction and supply chain data (4D Time dimension)
Blockchain to track goods and services from provenance to in-situ use (procurement and supply chain) [2] BCT for the provenance of construction materials [2,20] Goods ownership proved using BCT [21]	Materials provenance
Smart contracts to track goods and materials [2] BCT to improve efficiency of procurement, progress tracking, data auditability, and logistics in the construction supply chain [2,7] BIM and BCT for supply chain [7] BCT to improve transparency, traceability, and compliance throughout the supply chain [19]	Supply chain traceability
BCT to improve the transparency of regulation of the supply chain [2] All supply chain facts will be recorded on the blockchain for monitoring and to secure to the regulatory system [2,13] BCT for trades management and supply chain logistics [18]	Supply chain logistic and regulations
DT to allow real-time monitoring [17] Real time control of scheduling using BCT [19] Real time sharing of supply chain information using BCT [19]	Real-time Monitoring
One-time and on-budget delivery enhanced by technology [1] Smart contracts for equipment purchase and procurement prefabrication [7] IoT devises to improve procurement process [7] Smart contract automation for quotes and procurement [18] BCT to better manage products demand and supply [22]	Procurement
IoT, BIM, and blockchain can improve construction processes [2] BCT to improve the trust of construction logbooks, work progress, and material quantities [13] BCT enables resource sharing and leasing of construction equipment via smart contracts and DApps without intermediaries [2,18] Simulate, analyse, and optimize the construction with BCT [18] Optimize construction with IoT devices [18] Task completion log and automate payments by Smart Contracts [23]	Construction management
Financial data (5D Costs dimension)
BCT to improve the CI, which currently suffer from low margins, an adversarial pricing model, and financial fragility [2] Blockchain can improve poor payment practices (late or unpaid payments) [2] BCT to improve the race to the bottom effects in the CI due to projects targeting the lowest tender [3] DT should provide value to the economy [17] BCT can establish a trusted financial ecosystem and a trusted financial audit of the supply chain [18] BCT to guarantee a trusted financial audit of the supply chain [18] Finance improved by BCT [20] Blockchain can significantly improve the industry’s poor performance and low productivity [2,22] BCT to increase transparency and trust and eliminate obscure profits generated solely by the main contractors [23]	Strengthen trust in the CI financial ecosystem
BCT to provide virtual incentivization once the physical artifact has been created [3] BCT to reward individual contribution fairly throughout the lifecycle of the asset [3]	Incentivization
BCT as a tool to measure the intrinsic tangible value of labour and professionals [3] Data as a commodity and IP management [3] BCT to protect IP of digital assets (drawings, models, and other digital components) [18]	Tokenize information value
Smart contracts to guarantee and automate payments [2] Smart contracts to overcome payment delays [7] Smart contracts allow payments releases from various parties once conditions are validated [23] Smart contracts to streamline automated payments for maintenance inspections and work orders [23] BCT to automate payments with smart contracts [23,24]	Payments automation
Smart contracts to manage and automate a Project Bank Account (PBA) [2] Funding of projects and financial protection automated by smart contracts [2] Smart contracts to launch tendering processes and update transaction settlements [2] BCT enables a financial paradigm shift for digital payments, loan management, and accounting transactions cycles [15] Machine to machine economy facilitated by BCT and IoT [21] BCT to ensure that project banks are no longer owned solely by the contractors [23] BCT to permit that the role of the contractor will be to coordinate the construction process well but no longer be the central financial authority in the industry [23]	Decentralized finance operations
Operations and Maintenance data (6D Maintenance dimension)
IoT, BIM, and blockchain can improve the management of facilities [2] BCT transactional capabilities for IoT devices to provide a live BIM model of the building performances in real time for facility management [2] Big data for facility management, IoT, and smart buildings [5] Current inefficiencies and time-consuming processes in facility management [5] Lack of unified interface in facility management [5] Optimal integration of IoT, BIM, and blockchain using DAO for a Building Management System [7] BCT to record sensor data to improve facility management [13] Blockchain can secure sensor data (facility management) [13] IoT feedback loops to optimize outcomes [18]	Improve facility management
Predictive maintenance [1] BCT for maintenance of replacement insurance [2] Maintenance and replacement insurance improved by BCT [2]	Improve maintenance
DT to monitor as designed and as-built and info [17] BCT to trace errors and defects [19]	Notarize as-built states
Digital twin data verified by BCT for potential buyers or to provide real-time sensor data secured by smart contracts [2] IoT devices coupled with smart contracts to allow monitoring, automated auctions, and transactions of peer to peer power usage [2]	Decentralized Digital Twin applications
Environmental data (7D Sustainability dimension)
BCT and smart contracts for smart energy and smart grids and to trade energy surplus [2] BCT to improve energy efficiency [3] Building energy management systems (BEMS) to monitor environmental impacts [5] The CI needs to improve waste management, waste analytics, and waste estimation techniques [5] Big data for energy management [5] DT to reduce energy consumption [17] BCT to facilitate energy sharing [21]	Improve waste management Optimize energy usage
Key environmental data captured for smart buildings are CO2, temperature, air flow, and lighting [5] IoT and BIM for green smart buildings design (temperature, air quality, humidity, and energy consumption) with optimized carbon footprint [7] BCT can be used to track environmental records throughout the full supply chain. [20]	Notarize environmental records
BCT to enforce regulatory framework and standards from an environmental point of view [2] BIM and smart technologies offer advantages for sustainability throughout the asset lifecycle [24]	Enhance sustainability along the lifecycle
BCT enables a paradigm shift towards a trusted, transparent, and sustainable system through the circular economy [2] DLT integrated into the digital twin asset’s lifecycle can benefit the circular economy [25]	Benefit the circular economy
Health and Safety data (8D Safety dimension)
BCT to enforce regulatory framework and standards from a safety point of view [2] Big data for smart buildings to improve life safety [5]	Improve smart building’s safety
IoT devices to monitor workers safety on site [7] DT for safety monitoring and buildings safety risks identification [17] BCT to reduce risk through transparency [20] Digitization to enhance safety in CI 4.0 [1,22]	Improve site safety
Contractual data (cD Contractual dimension)
Implementation of a contractual framework between BIM and blockchain smart contracts [2] BCT to improve contracts administration [2] BCT to enhance the lack of enforceability, which is a major problem in the CI [2] Legal issues related to cloud-based BIM models around security, responsibility, liability, and design ownership [5] Smart contracts as a potential solution to overcome disputes [7] Implement an established legal framework using BCT [22]	Enable legal smart contracts
In a distributed collaborative environment, participants can access models based on their rights and responsibilities [2] Blockchain-based digital reputation [3] Access control and digital identity is key requirement for DTs [17] Trusted digital identity with blockchain [20] BCT to enable IoT devices identity [21] RFID and EPC (electronic product code) can identify devices [26]	Improve access control and digital identities
BCT as a social-technical system for the CI with a four-dimensional approach: technical, policy, process, and social dimensions [2] BCT to facilitate the policy dimension to integrate regulations, laws, policies, standards, and compliance [2] Project data recorded in a DLT to verify compliance with regulations [2] Building codes and regulations integrated into smart contract code [15] Blockchain as a security solution for compliance [16] DT to monitor structural integrity regarding compliance to regulations and standards [17] DT for processes approval, assurance, and compliance [17] BCT can improve the regulatory processes (certification, approvals, provenance, testing, liabilities, compliance, standards, and notarization) [20]	Enforce regulatory compliance
BCT to improve data ownership management for IP [3] BCT to improve BIM data creation and control of IP [3] Smart contracts to allocate BIM ownership and responsibilities [7] IP protection is a key challenge for DT ecosystems [17] Blockchain smart contracts to improve challenges for BIM model ownership: BIM Contract, responsibilities, liabilities models reuse, and IP [24] BCT to improve BIM difficulties to assign responsibilities and liabilities, protect IP and copyrights, model ownership, modification, distribution, rights, and risks allocation [2,7,13,15,18]	Preserve data ownership, intellectual property, and accountability
Smart contracts to guarantee payments, increase trust, and record historical data in the ledger [2] Smart Contracts to improve BIM adoption and collaboration: record tamper-proof BIM data for more reliability, trust, transparency, and integrity of the data [2] Support BIM through smart contracts: launch tendering processes, archive documents, control model access, and update transaction settlements [2] BIM data encapsulated into smart contracts logic [15] Smart contracts BIM models checking [15] Maintaining data over time is a key challenge for DTs [17] BCT to avoid fraud [19] BCT to improve the lack of trust that currently benefits the trusted third parties prospering from this weakness of the system [3]	Ensure data integrity
Smart contracts for properties transactions and land ownership [7] BCT for public sector uses: community e-voting, land registration, and real estate monitoring [15]	Data notarization

. The literature references are classified by dimensions (3D, 4D, 5D, 6D, 7D, 8D, and cD) and compared with their relative use cases discussed further in this paper.

2.2. A Paradigm Shift towards Decentralization

This section relates to the second research question and aims to identify from the literature some key factors affecting the paradigm shift powered by BCDT. This paradigm shift would reduce data silos, improve collaboration, data sharing, and trust, and create new business models in CI 4.0. As previously mentioned, the review of the literature about DT and BCT allowed the identification of overlaps between the BIM framework and the BCDT requirements. There are four (4) BIM levels of maturity: Level 0 (unmanaged 2D CAD with low collaboration), Level 1 (managed 2D and 3D CAD with partial collaboration), Level 2 (BIM collaboration including 4D and 5D metadata with separate disciplines models), and Level 3 (8D full integrated single model for lifecycle management).

BIM Level 1 and Level 2 are centralized and prone to generate data silos [27], while BIM Level 3 is more collaborative but still relies on centralized clouds as per the current state of Web 2.0. The technological foundations of BIM Level 3 rely on the centralized databases (acting as data silos) to host models, whereas its working environment is supposed to be fully collaborative. This centralization of BIM hubs is due to the Web 2.0 cyber security models required to protect infrastructures by isolating them with firewalls [18]. The weaknesses of such centralized systems are that they are prone to single points of failure. Moreover, the centralization of IT infrastructures generates data silos leading to fragmentations of the CI information value chain.

Unlike the centralized Web 2.0, blockchain-based decentralized Web 3.0 infrastructures can guarantee a decentralized, secured, and trusted ecosystem for the data value chain of CI 4.0. Thus, BCDTs would be part of a decentralized collaborative ecosystem that forms a paradigm shift from the current environment. This paradigm shift towards decentralization is recurrent in the literature about BCT and its applications for CI 4.0. The three corresponding main themes identified in the literature are related to decentralized collaboration, decentralized data sharing, and the automation of processes using blockchain smart contracts.

The key phases of the Big Data value chain are data acquisition, data analysis, data curation, data storage, and data usage [9]. A decentralized collaboration and data sharing could lead to a decentralization of the data value chain by leveraging decentralized protocols for data acquisition [28,29], data analysis and computation [30,31], data curation [32], data storage [33,34,35], data usage, and data marketplaces [36].

When BCT reaches sufficient maturity and scalability to offer fully decentralized systems for the whole IT infrastructure, a new level of maturity would need to be considered (e.g., BIM Level 4) for BCDTs. This paper hypothetically names it Maturity Level 4 for BCDTs.

Table 2. Key factors affecting the BCDTs paradigm shift implementation.

Decentralization	Comparative Use Cases
Decentralized Collaboration
There is currently a lack of adequate collaboration in the CI [2] Trusted decentralized collaboration enabled by BCT [2] BCT to enhance BIM collaboration, including records of all timestamped transactions [3] Collaborative procurement with BCT [3] Real-time BIM collaboration is currently challenging [15] Blockchain consensus-based collaboration [15] BCT enables a trusted collaborative environment that incentivizes playing by the rules [15] BCT to facilitate a collaborative modification environment for BIM [18]	Improve collaboration efficiency
BIM Level 3 coupled with DLT to create a single source of truth of the BIM model updates in real time in a collaborative environment [2] BCT to establish trust through collaborative design [3] BCT to enable immutable storage of historical BIM data on the blockchain for data sharing and trusted collaborative environment [7] BCT can remove intermediaries and trusted third parties [2,23,37]	Enhance trust
Network-based organizations to replace third parties. Network-based industry rather than a siloed industry [3] Fragmented management is a challenge for data quality [5] Current designs operate in a centralized way based on specific client requirements and local designers experience [5]	Reduce data silos
Decentralized leasing of assets using BCT [2] New business models and restructuration with the rise of DAOs removing unnecessary human interactions [2] BCT allows the disintermediation of actors such as main contractors currently acting as middlemen with a business model depending on profits margins [2] BCT to create a collaborative economy incentivizing information sharing between parties [3] IoT and BCT for external collaboration [7] BCT to enhance resource sharing via smart contracts and DApps [18] BCT to enable a peer-to-peer supply chain [20] Distributed P2P applications [21]	Enable new decentralized business models
DLT can flatten organization’s hierarchy, eliminating centralized management and improving trust and transparency [2] DLT enables a paradigm shift for a more democratic system, giving power back to individuals [2] BCT to enable a paradigm shift from hierarchical organizations to collaborative trusted networks [15]	Flatten hierarchy
Decentralized Data sharing
There is currently a lack of adequate information sharing in the CI [2] Integration of BIM and blockchain to generate networked ledgers of engineering information [2] Integration of BIM, IoT, and blockchain to securely store and manage data throughout the whole building lifecycle in a decentralized common data environment (DCDE) [7] The blockchain paradigm shift towards secured data sharing in an open trusted CDE [15] BCT to share data without compromising IP [15] DT should be as open as possible [17] Paradigm shift where BCT decentralized BIM data sharing (currently relying on the central operator) and removed barriers and data silos [18] Blockchain is decentralized and removes the need for barriers creating data silos [18] BCT as a common medium to share information throughout the value chain [19] BCT offers open ledgers instead of private closed silos [19] Data sharing limitations are a challenge for lifecycle management [38] BCT to enhance data sharing through peer-to-peer networks [38] BCT to allow immutable storage of BIM data to enhance data sharing in a trusted collaborative environment [7] Trusted information sharing using BCT [2,13,19,21] BIM and BCT combined to create a CDE to defragment the industry [24] Decentralized data sharing fuelled by crypto tokens incentivization to enhance collaboration [15] BCT to audit, trace, make tamper-proof, and authenticate BIM historical data sharing [18]	Enable open and secured information sharing
Key challenges of smart buildings systems are the rigidity and siloed nature of services and proprietary APIs [5] BCT to provide a unified format for data sharing and historical BIM data [18]	Open Data standards and interopera-bility
IoT management is limited by centralized databases vulnerable to attacks [7] IoT and BCT for external decentralized database [7]	Decentralized ledgers for IoT
Decentralized Automation
DAO smart contracts for disintermediation of processes and improve efficiencies [2] DLT enables smart automation of processes improving costs and efficiency [2] BCT to improve efficiency, the productivity of all the phases of a building project [7] Smart contracts automation to reduce human work and paperwork [7] Smart contracts to automate processes without middlemen and to save time [2,7] Using BCT to leverage smart contracts automation of time-consuming repetitive tasks [15] Smart contract to automatically executes work orders (e.g., bidding) [23] DT for automated monitoring [17,37]	Improve efficiency with smart contracts throughout the project lifecycle
IoT, BIM, and BC integrated through DAOs for a Building Management System [7] Blockchain to overcome IoT management challenges [7]	Decentralized IoT management
Decentralized Data Value Chain
BCT to control the data and increase trust in the data value chain [2] BCT to facilitate secure data distribution to increase trust in Big Data processing and model sharing [15] Blockchain as a source of truth of the data history [16] Asset lifecycle data recorded on the blockchain (design, delivery/procurement, construction processes, inspection certification, materials, QA, asset management, demolition) [16]	Enable a single source of truth throughout the project lifecycle
Data collected by IoT devices to update the ledger provides a source of truth. Track components and avoid duplication of work [2] Blockchain enables the efficient management, trustfulness, transparency, and security of data [7] IoT collects correct real-world data across the construction value chain [7] BCT to facilitate data transparency [37] and traceability [19]	Ensure data integrity
DT should integrate curation, transparent ownership, governance, responsibilities and regulation, maintenance, and responsible use of data [17] Data integrity, validity, governance, and privacy are essential for the IoT data value chain [39]	Facilitate data governance
BIM Level 3 complies with Industry Foundation Classes (IFC) and BuildingSMART Data Dictionary (bsDD) and would be suitable for blockchain integration [2] The 3Vs of Big Data (variety, velocity, and volume) apply to the CI data value chain [5] Blockchain to store/verify/secure data transactions (e.g., design revisions) without a central authority and in a format-agnostic way [16] DT transmit data between the physical product and the virtual product at each phase of the project lifecycle (design, planning, scheduling, maintenance, energy consumption, and recycling) [38]	Standards for the Big Data value chain
Decentralized IoT data acquisition [28], Decentralized data analysis and computation [30,31] Decentralized data storage [33,34] Decentralized data marketplaces [36]	Leverage decentralized protocols for the data value chain

below lists the key factors identified in the literature that affect the CI 4.0 paradigm shift towards Web 3.0-based decentralized ecosystems of BCDTs. The literature references are also compared with their relative use cases, as discussed further in the paper.

2.3. Non-Functional Requirements of BCDTs

This section relates to the third research question and identifies from the literature the key hypothetical non-functional requirements of BCDT for CI 4.0. BCDTs represent a new concept that combines BCT and DT to enhance security and data sharing [25]. The non-functional requirements of BCDT need to be identified for future applications leveraging decentralized systems.

Data security is fundamental for BCT [20], and it represents a key requirement for smart buildings [2] and their DT software [17]. Interoperability between data is a fundamental requirement for DTs [17] to ensure that the information can be managed and exchanged in a format-agnostic way. Moreover, blockchain networks are also required to be interoperable between each other to be able to coexist and transact together within ecosystems of united BCDTs leveraging different blockchain networks. The main non-functional requirements for BCDTs that were identified in the literature are listed in

Table 3. Non-functional requirements for BCDT.

Non-Functional Requirements for BCDT
Security
BCT to increase security for smart homes [2] Data security is a key challenge of Big Data [5] There is a lack of cyber resilience of software platforms [15] The current cyber security model relies on isolation, whereas BIM principles are founded on collaboration [15] A key challenge for DTs is to protect private, confidential, and sensitive information [17] DT should be secured by design guaranteeing data security and privacy protection with role-based access [17] Blockchain can provide resilience against malicious attacks [18] BCT to enhance IoT security [19] Data security is a fundamental challenge for blockchain [20] Cyber security is a key challenge for BIM sustainable designs [24] DLT is a well-suited solution to secure digital twin data [25] Secure data management is a challenge for lifecycle management using DT [38] BCT can improve security with the authentication of allowed participants [40]
Privacy
BCT can enhance privacy through cryptographic encryption and authentication [2] BCT can increase data privacy for smart homes [2] Data privacy is a key challenge of Big Data [5] Data privacy cannot be guaranteed by centralized third parties suffering from data leaks [7] Data privacy is a key challenge for DTs [17] Privacy is a key challenge for BCT due to the pseudonymous nature of blockchain [20] BCT facilitates authentication, privacy, and trust for IoT data [21] Data privacy is essential for the IoT data value chain [39] Cryptography to enable privacy-aware access control [40]
Data Authenticity
Data provenance is a fundamental challenge for the data entering the blockchain [20] Data authenticity is a key challenge for BCT [37] Data authenticity is a challenge for lifecycle management using DT [38]
Data Integrity
DT should guarantee data reliability and quality [17] Data integrity is a fundamental challenge for the data entering the blockchain [20] Data integrity is essential for the IoT data value chain [39]
Decentralization and Scalability of Data Storage
Difficulty in storing and processing a large volume of Big Data in the CI [5] Decentralized data storage [21] Storage of a large volume of data throughout the project lifecycle is a challenge for lifecycle management using DT [38]
Interoperability
BCT interoperability is a key challenge for smart homes IoT transactions [2] Big data interoperability is required to facilitate data exchange between different parties and fields [5] BIM interoperability issues [15] Interoperable (format agnostic) data is a key requirement for DTs [17] Open and cross-platform DT standards are required [17] Interoperability between blockchains is a fundamental challenge of BCT [20]
Data Ownership
Data ownership is a key challenge of Big Data [5] There is a lack of a legal framework for model data ownership [15] BCT can prove data ownership [2,21]

.

2.4. Literature Gaps

The literature related to both BCT and DT is scarce, particularly where the combination of a few tools from the CI group of technologies is required for solving a problem in the construction context. In addition, there are not many specific categorizations of the key project lifecycle data to be anchored in BCDT for projects of the CI. Some key requirements such as data integrity, data privacy, data ownership, data validity [39], and data authenticity [37] also need to be considered for BCDTs. Moreover, the literature available on non-functional requirements of BCDTs is also very limited.

3. Research Method

A mixed qualitative and quantitative method was designed and used to address the research questions. These research questions were addressed by identifying the data from projects’ lifecycles, which are relevant to transact with sustainable BCDTs, the key factors affecting the BCDT paradigm shift, and the non-functional requirements for BCDTs in CI 4.0. Due to the exploratory nature of the investigation, a qualitative approach was adopted by interviewing the most relevant and experienced experts in the field. This research method was used since there is a limited amount of in-depth information about BCDT and associated factors and processes from a professional perspective.

The interviews were carefully transcribed, coded, and analysed using a weighted percentage method. In order to triangulate the outcome and collect some more complementary data, a survey was conducted after interviews. The triangulation approach was used to enhance the validity of the outcome as a recommended technique in the field [41]. The basic quantitative tests, including t-tests and descriptive statistics, were utilized to provide further information on the previous qualitative process. The hypotheses about key project data categories, key factors, and non-functional requirements for BCDTs in CI 4.0 were then validated, and a novel theoretical framework was also developed.

Figure 1 shows how the mixed-method and six main steps of the investigation were conducted. These steps show how the key themes were identified from the literature, the interviews, and the survey conducted, and each research question was addressed accordingly. Details of each step and the outcome of relevant coding and t-tests are presented in the following sections.

Step 1: A review of the literature was conducted to firstly identify and raise hypotheses about what are the key project data, key factors, and non-functional requirements relevant for BCDTs in CI 4.0. Thus, the content analysis of the literature defined the directions for this paper.

Step 2a: A total of six interviewees were recruited, and the interviews’ themes related to the context of the entire construction value chain (design, construction, O&M, and demolition). The interviewees were selected based on the criteria of having a broad experience in the CI as well as digital expertise for half of them. Due to this criteria, the interview sample size was limited to relevant and experienced experts available to form a purposive sample. This purposive sample enabled the researchers to acquire and extract an extensive range of consistent key data relevant to the aspects of the CI that can be improved in relation to the BCT taxonomy (trust, transparency, traceability, immutability, efficiency, and security). Hence, the sample was analysed to identify the key issues of the CI that can be addressed by the key features of BCT. The interviews participants are senior experts with a wide experience in the CI, and their very valuable insights fulfilled the data collection requirements.

Table 4. Interviews’ summary table.

Questions/Themes	Participants Region	Participants Industry Sector	Participants Experience
Trust, decentralization, transparency, security, traceability, immutability, efficiency, and digitization throughout the lifecycle of projects of the CI.	Australia	Engineering Transport Digital Engineering	Senior (greater than ten years)

gives an overview of the interviews themes and interviewees’ profiles with six (6) experts working in the CI.

Table 5. Interviews’ questions covering nine features of blockchain.

Blockchain Features	Interviews’ Questions
Trust	Where is trust needed the most in your industry? Who are the trusted third party currently required in your industry? What centralized systems/organizations/stakeholders in your industry are the least trusted? Which process/IT infrastructure do you not trust in your industry?
Decentralization	Who are the intermediaries/middlemen in your industry that feel unnecessary? Which entities of the industry value chain are too centralized and bottleneck processes? Which processes of your industry should be decentralized?
Transparency	What information need to be more open/transparent in your industry? Which data need to be openly auditable? In which specific areas of your industry is there currently a lack of transparency? Why are these lacks of transparency an issue?
Security	Which data in your industry need to be secured the most? Where is there currently a lack of data security in your industry? Why is this lack of security an issue? Which IT infrastructure in the industry needs to be the most resilient?
Traceability	What information need to be traceable in your industry? Which data in your industry need the most to be recorded and made auditable? Where is there currently not enough traceability of information in your industry? Why is this lack of traceability an issue?
Immutability	What information in your industry needs to be recorded in an immutable way? Where is there currently not enough data immutability in your industry? Why is this lack of immutability an issue? Which data need to have censorship resistance? Who could try to modify/change important data?
Efficiency	What are the main inefficiencies in your industry that you have noticed in your career? Which administrative tasks or processes are time-consuming and should be automated? What type of contractual process should be automated?
Digitization	What are the limitations of the digital tools you are currently using? Which physical components/processes of your industry would you like to be able to manage directly from a digital twin software? What features/characteristics would you be expecting the most from that digital twin representation of the physical assets? What benefits/incentivization would you like to obtain from this system?
Blockchain	What are the limitations/challenges of using blockchain technology?

shows the list of questions that were designed to identify problems specific to the CI, key factors, and project lifecycle information related to the taxonomy and properties of BCT: trust, decentralization, transparency, security, traceability, immutability, efficiency, and digitization.

Step 2b: An online survey was designed and distributed to key practitioners using the LinkedIn platform. A total of 103 participants responded to the survey. The survey statements were designed in relation to the objectives themes, which were the project lifecycle data, key factors affecting blockchain adoption, and non-functional requirements for BCDTs.

Table 6. Summary of the survey themes and the data profile, including regions, roles, and experience.

Questions Themes	Participants Region	Participants Industry	Participants Experience	Digital Experience	Blockchain Knowledge
Project lifecycle data, Trust, Privacy, Data Erasure, Decentralization, Data Sharing, Traceability, Automation, Data ownership, Security	Australia (60%) UK (25%) Europe (6%) Middle East (3%) US (2%) Asia (2%) India (2%)	Construction Industry (CI) (60%) Transport (8%) Academia (4%) IT (10%) Blockchain (12%) Finance (2%) Legal (4%)	Director/CEO (23%) Doctor (PhD) (13%) Senior > 10 y (33%) (t-test group 1)	Expert (16%) Advanced (35%) (t-test group 3)	Blockchain Developer (2%) Expert (12%) Advanced (14%) (t-test group 5)
			Junior < 10 y (26%) Graduate < 3 y (5%) (t-test group 2)	Intermediate (32%)Basic (17%) (t-test group 4)	Intermediate (14%)Basic (40%) Nil (18%) (t-test group 6)
		Note: Only the answers from participants from the CI, academia, and transport industry were utilized for this paper.	Note: These five categories were organized into two groups (as delimited above) for the t-tests analysis.	Note: These four categories were organized into two groups (as delimited above) for the t-tests analysis.	Note: These six categories were organized into two groups (as delimited above) for the t-tests analysis.

shows a summary of the survey themes, the participants’ profiles, industries, seniority levels, digital and blockchain experiences, and the related subgroups used for the t-tests statistical analysis.

Step 4: A triangulation approach was used to analyse data from these sources (interviews and online surveys). Methodological triangulation was achieved by using different techniques (NVivo coding, t-tests, and descriptive statistics) to analyse the various data sources and their statistical relevance as needed. A dashboard was developed to visualize, filter, and analyse the descriptive statistics from the survey. The triangulation approach allowed to validate assumptions preventing observation bias.

Table 7. Survey structure based on the selected themes.

Questions Themes	Statements
Trust	Q6-1—Evaluate if trust is sufficient for these project lifecycle data * (* detailed below with Q6-3).
Data Erasure	Q6-2—Evaluate if the historical records of these project lifecycle data * (* detailed below with Q6-3) need to be deleted after the demolition of the physical asset.
Privacy	Q6-3—Evaluate if these project lifecycle data * (* detailed below) need to be openly accessible or private (but accessible with specific access rights). * Project lifecycle data: Drawings, BIM models, design history, communications, certificates, financials/payments, contracts, stakeholders’ identities, materials provenance, supply chain, procurement, survey, testing, health and safety, as built information, asset information, and environmental data.
Trust	Q7—Customers’ trust in consultants is sufficient in the industry.
Trust Decentralization	Q8—Trust in centralized collaboration software is sufficient in the industry.
Decentralization	Q9—Projects’ lifecycle data must be recorded in a shared ledger to enhance collaboration between all participants.
Decentralization	Q10—Data sharing must be decentralized through peer-to-peer networks to reduce fragmentation (data silos) in the industry.
Decentralization	Q12—The data-sharing capabilities of existing centralized common data environments (CDE) platforms are sufficient to share information in the industry.
Privacy	Q15—Financial data (e.g., payments, transactions, costs, and fees) must be publicly auditable to enhance fairness in the industry.
Traceability	Q21—Professionals’ identities are required to be traceable throughout the lifecycle of projects in case of litigation.
Traceability	Q22—These data types (listed below) captured by IoT sensors (e.g., smart buildings sensors) must be traceable throughout the lifecycle of projects List of data: Temperature, light, humidity, energy consumption, materials tags (RFID), assets information, structural states, motion occupancy, air quality, and weather.
Automation	Q23—Work orders must be automated by blockchain smart contracts to enhance efficiency and reduce paperwork.
Automation	Q24—Regulatory processes in the industry must be automated with standard legal smart contract templates.
Automation	Q25—It is necessary to automate the processes ** (** detailed below) listed below using blockchain smart contracts ** List of processes: Council DA approvals, payments processes, engineering checking/QA, certification processes, contracts, inspections/assessments, claims and disputes, asset management (e.g., maintenance), planning with BIM 4D, costing with BIM 5D.
Liability	Q40—Stakeholders participating in a project must be legally liable for the data they create.
Data Ownership	Q41—Stakeholders participating in a project must own the data they create.
Data Ownership	Q42—Data ownership must be monetized on decentralized data marketplaces to incentivize data owners to produce information.
Data Ownership	Q43—These participants *** (*** detailed below) of construction projects must have ownership of the data they create (rate your answers). *** List of participants:BIM modelers, engineers/architects, property owners, governments, public

summarizes the themes and statements of the online survey. The survey was designed based on the Likert scale of 5, including the options to strongly disagree (SD), disagree (D), neither agree nor disagree (N), agree (A), or strongly agree (SA) with the survey statements.

4. Results: Emerging Themes from the Interviews and Survey

4.1. Interview Results

The transcriptions were coded to extract essential information from the answers collected. The coding analysis permitted the evaluation of the content of the interview quotations and the recurrence of keywords.

Table 8. A summary of coding analysis including parent and child nodes identified from the transcriptions.

Parent Nodes	Child Nodes	Extracted Keywords with the Highest Weighted Percentage	Sub-Theme
Trust	IT infrastructure Least trusted third party Trusted third parties	Design, as-built information, contractors, contracts, contractual, models, data records, clients, certifiers	Project lifecycle data categorization
Decentralization	Centralized entities Processes to decentralize Unnecessary intermediaries	Planning, approvals, design, software, modelling, engineering organizations, processes, data silos, supply chain, government, manager, planning	Decentralized collaboration, data sharing, and automation
Transparency	Auditable data Lack of transparency	Design, design information, materials, information, costs, maintenance information, accountability, financials, activities, data, contracts	Project lifecycle data categorization
Security	Data security Lack of data security Resilience against cyber attack	Smart buildings (BMS), data, project information, confidentiality, sensitive projects, asset information, infrastructure resilience, data sharing, data silos, data reusability, open data, data leak, software, data storage, data breach, data replication	BCDT Non-functional requirements
Traceability	Lack of traceability Traceable data	Design, calculations, checking, reviews, drawings, model, materials, identities, records, contracts, decisions, amendments, reports, accountability, engineering, documents	Project lifecycle data categorization
Immutability	Immutable data Lack of immutability	Design data, maintenance, as-built information, calculations, all data, public records, people’s data, financial information	Project lifecycle data categorization
Efficiency	Administrative tasks Automation Inefficiencies	Processes, automated designs, digital automation, digital twin automations, contracts, system, terms and conditions, changes, project management, review process, checking, rework on rechecking, design, avoid rework, program changes, forms	Decentralized collaboration, data sharing, and automation
Digitization	Digital tools limitations Blockchain limitation Digital twin features	Data, manager, information as an asset, risk, digital twin (DT), digital marketplaces, asset management, energy, maintenance, inspections, building management system (BMS), digital twins, asset information, asset tracking, facility management, smart alerts, smart insights, costs, models	Project lifecycle data categorization

shows the eight parent nodes as the key features and taxonomy of BCT. The parent nodes were supported by a total of twenty-one (21) child nodes related to the key interview questions within their parent node theme.

From the coded interviews, a word frequency analysis was performed to extract keywords with the highest weighted percentage (WP). The criteria for the word frequency analysis consisted in limiting words to the first four (4) letters and extending the search to second-degree synonyms. The WP range was isolated from 0.5% to the maximum WP value for each node to ensure that the keywords extracted would capture the essential insights. Relevant words falling within that range were selected as key project data, factors, or non-functional requirements to be considered for answering Research Questions 1, 2, and 3, respectively.

The WP analysis allowed the association of parent nodes and their child nodes with sub-themes related to the nature of the keywords extracted and in relation to the research questions. The keywords extracted from the parent nodes, trust, transparency, traceability, immutability, and digitization, allowed the identification of the key project lifecycle data that could benefit from the key features and taxonomy of BCT. The keywords extracted from the parent nodes decentralization and efficiency allowed the identification of key processes and entities that would benefit the most from the decentralization of collaboration, data sharing, and processes automation resulting from the integration of blockchain networks and smart contracts in CI 4.0. Finally, the keywords extracted from the parent node security permitted to obtain key information in relation to non-functional requirements of BCDT in CI 4.0.

Table 8 summarizes these findings for each parent node, their child nodes, the extracted keywords, and the sub-theme associated with them.

Table 8 shows that trust is needed the most for data records such as design data, contractual data, and as-built data. Four participants discussed that the least-trusted third parties are certifiers and contractors, and two participants mentioned the least-trusted IT infrastructures are local servers and centralized cloud services.

According to the interviewees, the project lifecycle data requiring transparency the most are design data (design options, and design history), accountability (stakeholders’ responsibilities), costing data (financial data, material costs, project delivery costs, and construction costs), materials (provenance, supply chain information, suppliers, and costs), information records in general (construction records, data records, data mining, data history, and decision-making data), O&M (virtual assets information and real-time asset information). The interviewees also mentioned that there is currently a lack of transparency in contracts (terms, conditions, and obligations), financial data (costs, construction, and materials), and siloed information.

In terms of traceability, the interviewees mentioned that the information that requires to be traceable the most is design data (drawings, models, calculations, designers, verifiers, checkers, and reviewers), materials, stakeholders’ identities, contracts, reports, accountability information, decision making information, and most data records in general.

There is currently a lack of immutability in the industry, which makes it problematic to guarantee the trustworthiness of the information. This applies particularly to design data, as-built information, and any siloed data that cannot be verified. The interviewees raised that project lifecycle key information requiring immutability and censorship resistance are design data (design information, calculations, drawings, verifications), environmental data, financial data, as-built data, and all data records in general (political, public records, people’s welfare and rights, RFID tags).

In terms of decentralization, Table 8 indicates that the industry is fragmented in data silos and that it is key to decentralize entities such as governments, organizations, and planning institutions. It also reveals that the inefficient processes required to be decentralized essentially to reduce bottlenecks are design (planning, modelling, engineering, collaboration, and changes), supply chain (information, handover, and changes), organizations, data silos, and other processes in general (approvals, validation, document control, governmental management, and DA). Moreover, processes related to middlemen such as certifiers, managers, and quantity surveyors could become decentralized to enhance efficiency.

The interviews revealed that the main inefficiencies in the CI are linked to reprocessing (rework and rechecking, program changes, forms, and checking and reviewing), administrative tasks, contracts (terms and conditions and contract administration), and design aspects (initial design phase, preliminary design, iterations, changes, rework, and doubled work). Moreover, it is necessary to reduce inefficiencies in the CI by automating design processes (ML automated designs), contractual processes (terms and conditions, standard contracts, contracts review, and contractual processes), digital twins, and generally most lengthy processes (DA, invoicing, project onboarding, project management tasks, and program changes).

The interviewees’ answers suggest that there is currently a lack of security associated with open data APIs, data silos, and data storage, which can lead to security breaches and data leaks. Table 8 shows that it is key to secure data related to sensitive projects (infrastructure, banking, and defence projects), financial data, assets information, smart buildings data, personal information, Big Data, confidential information, processes related to data sharing, and project data in general. Additionally, it is necessary to secure the entire IT infrastructure, including data storage, databases, and the systems transferring data. The security of smart building management systems (BMS) is also an essential requirement.

Finally, in terms of digitization, the key takeaways from the interviews regarding DT are related to key aspects of the Big Data value chain such as data capture, data storage, data analytics, data history, data connectivity, open data formats, data silos reduction, data loss avoidance, GIGO effects avoidance, and the usage of data as an asset. DT can benefit facility management for smart buildings by improving real-time asset management, monitoring of asset information, asset tracking through IoT sensors, energy efficiency, BMS, maintenance, inspections, and providing smart insights. Moreover, DT can contribute to risk mitigation and assist with the prevention of natural disasters. DT will tend to be self-managed with proactive maintenance leveraging cognitive DT using AI and ML; additionally, DT could form part of a DAO system leveraging BCT. DTs could also lower energy consumption with AI analytics and by using BCT to incentivize users to reduce their energy consumption and carbon footprint. DT automation and analytics would contribute to the reduction of operational costs and contractual costs. DT platforms could be leveraged for data marketplaces, allowing stakeholders to participate in a decentralized circular economy (DCE), including ecosystems of BCDTs. Moreover, ecosystems of united BCDT running interoperable blockchain networks would guarantee a single source of truth. The management of DT could become democratized with BCDT running as DAO.

Table 9. Interview quotes in relation to the project lifecycle data categorization sub-theme.

Blockchain Features	Keywords	Interview Quotes
Trust	Design	“Trusting that when a contractor provides insurance that the design and the build is appropriate, some way of measuring that would be great.”
	As-built information	“That’s a massive problem at the moment: what’s documented is not updated to what’s built, because there’s no real digital twin of what’s built, there’s only a model and therefore, this is a lack of trust in documentation.”
	Contractors	“Who are the least trusted: dodgy contractors.” “Contractors who turn out to have no clue of procedures don’t give you any real kind of assurance that your designs have been built in accordance with your documentation. And then they ask you to sign off that it has been done. So yeah, they are probably the least trusted.”
	Contracts, Contractual	“Contractually there’s a huge degree of distrust in terms of how people think others will behave or are behaving throughout the last of a project” “For contractual data, nobody is trusted.”
	Models	“…create absolute reliance and trust on reports or models and things that you receive from others” “…coordinated with the architect’s model but it does not let you know that you they’ve changed their model, so you’ve coordinated with the old model”
	Data records	“…if there was this absolute ability to rely on the recording of data that what you’ve received is in a no-one-can-fiddle-with-it now you can have complete compliance and trust to sort of move forward”
	Clients	“When communicating with collaborators, architects, clients, they have to trust the information given to them is correct”
	Certifiers	“Profit certifiers are now required to be paid in full before they even take a project done so that they can’t be no coercion to say: Oh, sign this off and then I’ll pay you” “But if there was a way that documentation could be so clearly recorded that you could get rid of the whole profit certifier potentially and have each of the entities self-certified possibly.”
Transparency	Design	“design information process” “…all the activity is taking place under the design screen, where you could probably get better training for AI to do some of that task. Because we would have a history of what’s been done so you can then predict more easily what needs to be done on future projects.”
	Materials	“Material supply chain.”
	Information	“the lack of transparency generally is around worrying about risk, litigation, people finding fault, information being used the wrong way”“Everyone just keeps on to their own information; they don’t really share information.”
	Costs	“cost of materials” “construction costs” “the transparency of costs on delivering of projects is obviously required to a certain extent…after the tender”
	Maintenance	“I think that data around the engineering performance, the construction reality and then the operation and maintenance virtual assets need to be openly auditable.” “all of that kind of data that feeds into products or materials, in terms of their maintenance in operation regimes. If that was all kind of decentralized and held in a system that everyone can access.”
	Accountability	“the information around accountability would be good: who’s responsible for what, when, how?” “It’s the accountability bit: if you’re accountable for, you need to be auditable, and you need to be auditable for the client as well”
	Financials	“public financial information”
	Data	“data behind the decision-making is not transparent, it’s only held within each individual entity and not shared.”
	Contracts	“in some industries, contracts complete transparency of the supply chain would be considered ok, but projects like defense or infrastructure projects data may be restricted on a matter of national security” “lack of transparency across interfaces between different companies or different contracts on a project”
Traceability	Design	“It would be great to be able to trace, and what got designed and got built” “Design verifiers” “Design verifications, who actually said that this beam is good enough” “Design development” “traceability of how things got onto those drawings, or as we move away from drawings, how things got into the models.”
	Calculations	“calculations and revisions” “tracing calculation” “if we can trace the model is showing a beam of this size, into the model itself had embedded the calculations process or the traceability to the robot model and the loads”
	Reviews	“all the necessary reviews have been done” “I think for a construction…and supply chain, it’s about the check review and approval.”
	Materials	“Materials and identities. Materials for the modern slavery and non-complying materials requirements.”
	Identities	“Identities for who did what, who certified what, what are their qualifications and are they qualified to do that task, and insurances of those parties, do they have sufficient cover and is it the correct type of cover.”
	Records	“certainly, anything which is a record, according to the state records, that needs to be fully traceable.” “the deliverables, the records themselves” “correspondences, documents, reports, calculations”
	Contracts	“Contract variations” “to do things better in the future or settle financial agreements, we need to know who records, where decisions happen, or when the contract changes, who said what, who did what… we need to find out why”
	Decisions	“decision tree” “We should be able to track decisions that have been made…we need to be able to interrogate and say: Why did that decision happen?”
	Amendments	“trace the time of amendments.” “knowing when an amendment was changed, when was it really issued”
	Accountability	“accountability and traceability on those would probably drive a more focused effort to make sure that the work is done.”
	Engineering	“find out who did the drawings or engineering.”
Immutability	Design data	“design information” “when a design firm provides their native design software files to the client, there is a worry that the client or another contractor would then make a change to the design...So, to be able to provide a file which is immutable... which is the version handed to them.”
	Maintenance	“Immutability is a problem every way, from the calculation to the drawings, to what gets built, to then the maintenance.” “every piece of maintenance would change; you could only do it in a way that was immutably changed in a digital twin”
	As-built information	“you could sort of lock in a as-built that was immutable.” “Design verification, but like the as-built verification, I think that needs to be open, accessible, that needs to be exactly set in stone” “what’s designed and what’s built: there’s a gap and no one knows” “the design companies or the contractors if they could change their as-built information, they go: something happens, you have 40 engineers quickly checking all the calcs, “Oh we’ve made a mistake there”, someone accesses that information, changes it”
	Calculations	“every output that we put on the name to, whether it’s calculation, documents’ reports… you know, that can’t be modified or tampered with”
	All data	“Everyone has a reason to modify any data shared with them as a part of doing their work. Taking shortcuts, modifying the data.” “Sometimes in small areas, there are places where people can edit data, where they shouldn’t be able to edit them.”
	Public records	“This kind of censorship is political censorship of recent history, and I think there are elements of stuff like that about records and decisions that have been made that cannot be censored, that should be public record. And although there might be, they might have to go through the 20 years or 10 years.”
	People’s data	“for the security of information around the welfare of people and rights, it would be really about protecting if we could manage to organize information in such a way.”
	Financial information	“if we’re collecting financial information about the project, whether it’s inside a commercial firm or whether it’s in the government, we shouldn’t be able to change the numbers.”
Digital	Data	“data capture tools, and data storage tools” “lack of interest in scripting software to work with open data”“connectivity between the data”
	Information as an asset	“the incentive of the organization is going to be: information as a profitable asset of an organization, or an asset owner.” “benefits in the incentivization thing is…about that digital marketplace, with like the information as a valid, profitable asset in itself”
	Digital Twin (DT)	“a facility manager having a full 3D model, or a full digital twin of your facility, and then having smart alerts” “I think we should be able to manage almost everything from a digital twin” “a digital twin does not need to be one model, it can be multiple aspects that fit into a core infrastructure.” “leveraging a digital twin with AI to give you insights.” “we’re going to leverage most of the digital twin when we can actively use AI and machine learning to give us insights into what could possibly happen, in our maintenance and… even if you’re using this in a construction phase”
	Asset information	“asset information management systems work right, you’ll have a tag ID, which relates to a piece of software”
	Energy	“use less energy” “less energy, less carbon” “energy consumption”
	Maintenance	“heating power, electrical light…operation, maintenance of various components within the building” “preventive maintenance because this could be an indicator of a system failure”
	Costs	“operational maintenance is going to cost, so understanding you know, and then the strategic plan for the future.” “lower operational cost or contractual cost because you’re actively pre-empting challenges, or risks, or anything through a smart system.” (blockchain adoption) “challenges are Knowledge, regulations, lack of skills, implementation costs.”

,

Table 10. Interview quotes in relation to the decentralized collaboration, data sharing, and automation sub-theme.

Blockchain Features	Keywords	Interview Quotes
Decentralization	Approvals	“…getting approval for any position or something, needs to go through so many layers of bureaucracy, it takes a lot of time if that could somehow be taken offline and decentralized that could be really helpful.” “DA approval and it can take 9 months or longer”
	Design	“…the independent certifiers, either give them full design responsibility or remove them completely” “currently what’s happening is: your engineers are doing the design and they are handing it to the modellers, and then the modellers have to redo what the engineer had in his head”
	Modelling	“decentralize modelling of engineering…of modelling aspects of designs so that it’s not one person but many people that contribute towards the modelling aspect”
	Engineering, Organizations	“Engineering organization…would be a smart contract sort of”
	Data silos, Supply chain	“It’s all centralized into big silos, owned by different parts of the supply chain, on the information supply chain” “from the supply chain to deliver it to the client, it’s to hand it over into the client’s operation or maintenance, which is a bottleneck”
	Government	“…the way that a government team would run a project might be a bottleneck, if it’s a not particularly efficient team” “government authorities that sign things off”
	Managers	“external project managers”
	Planning	“The planning institutions, planning bodies, can be a real bottleneck.”
Efficiency	Processes	“DA process” “Tendering, comparison of tenders, claims, assessment of defects, variations, dispute, delays, liquidated damages” “automate more project processes, things like onboarding, offboarding, getting things approved”
	Automated designs	“the design process has too much back-and-forth iterations, and too much taking-it-too-far, and then iterating” “machine design of buildings almost to completion” “what’s off and inefficient is starting design”
	Digital automation	“the whole digital movement in terms of rapidly developing designs in conjunction with rest of the design team is an effort to reduce inefficiencies of the design inspiration process”
	Contracts	“Contracts are especially administration intensive, and only getting worse. Project managers are having to deal with ever more increasing legislative requirements.” “With 5D BIM and smart legal contracts much of it can be semi-automated. “ “We’re still very paper driven, and you still have to make amendments to it, but …there are huge parts of the contractual process that could just be automated” “it would be good for all contracts to be automated” “it would be good to have a standard suit of contracts that everyone has already kind of agreed to and signed up to and then you just pick from that list and you say we’re going to work under this one” “that’s something that could be automated, the contractual process, the review process, that’s certainly the arrangement could be automated so that it happens at once between everybody” “use machine learning to automate almost the entire contract review process”
	Terms and conditions	“standard terms and agreement contracts that are fair and equitable in the industry”
	Project management	“If you look at what a project control manager does or a commercial manager does, I think there should be processes that can initiate that all are connected, rather than… they’re doing so much toing and throwing by email, and trying to track things in spreadsheets and…lots of things”
	Checking, reviewing	“The checking and review process”
	Changes	“the process of changing a program should be automated” “flagging up risks or potential delays should be automated processes” “rework on building, especially building services, because the information changes all the time and then you have to re-root everything, move all your penetrations”

and

Table 11. Interview quotes in relation to the BCDT Non-functional requirements.

Blockchain Features	Keywords	Interview Quotes
Security	Smart buildings (BMS)	“building control systems in terms of smart buildings”“data about things that have been done, like buildings, and all the what goes behind it, that’s all now in electronic models hanging out on a server in a data centre somewhere. If something went wrong with those data centre…”
	Data, information	“security of financial data” “data security is really poor”“secured data transfer, that’s what it’s used for like bitcoin and cryptocurrency banking, because it’s more secure” “... thinking about digital twins in the future, thinking about blockchain as an information, evaluator, mover, verifier: a secure mechanism”
	Confidentiality	“confidential data is the most important” “protecting the probity and the confidentiality of the information that is important”
	Sensitive projects	“We have legislation around personal information, which projects it, and there’s the Critical National Infrastructure Act that protects data about mostly defence information, so defence infrastructure” “the greatest need for resilience is probably whoever information being used is most sensitive. It’s like public health, healthcare, defence and maybe banking”
	Infrastructure resilience	“Any major project with a client that requires information to be sent in and out of a secured server, they have to be the most resilient” “the infrastructure as a whole needs to be resilient”
	Data sharing	“getting consistency and getting Big Data optimisation value…is going to be super difficult until you provide an environment where, all the information can be owned by multiple owners, it can still be related and linked across the entire asset database for the particular sector, or discipline, or type of asset”
	Data silos	“The siloed nature of data within construction is an IT administrator’s nightmare. This requires the data to be copyable, Or API’s opened up.”
	Software	“There’s a big increase in the use of software as a service, and we are not sure that those tools are really secure”
	Data storage	“I would say storage”
	Data breach	“we can lose a significant amount of IP or you can breach you know confidentiality”

below present some key quotes from the interviewees in relation to the sub-themes presented in Table 8 and discussed in the above chapters.

4.2. Survey Results

Since the research questions are specific to the CI (project lifecycle data, BCDT paradigm shift in CI 4.0, and BCDT non-functional requirements for the CI), and the survey questions considered for this paper fall essentially within the context of the CI, the survey’s results were filtered to participants from the CI only to obtain the most relevant and significant results for the survey data analysis. Furthermore, when ambivalences occurred on the results depending on the interviewees’ group, a statistical analysis was carried out to run t-tests for groups of people based on their seniority level, digital experience, and knowledge about blockchain. The groups used for the t-tests are shown in Table 6 and the results of the t-test analysis are shown on

Table 12. Statistical analysis t-tests results of key survey questions.

	Seniority	N	Mean	Digital Experience	N	Mean	Blockchain Knowledge	N	Mean
Q7	1	31	2.94	1	18	2.78	1	7	3.29
	2	14	2.29	2	27	2.70	2	38	2.63
Q8	1	31	2.7097	1	18	2.7778	1	7	3.1429
	2	14	2.6429	2	27	2.6296	2	38	2.6053
Q9	1	30	1.9667	1	17	1.9412	1	7	1.5714
	2	14	2.2857	2	27	2.1481	2	37	2.1622
Q10	1	30	2.2333	1	17	2.4118	1	7	1.7143
	2	14	2.5000	2	27	2.2593	2	37	2.4324
Q12	1	30	2.73	1	17	2.65	1	7	3.43
	2	14	3.14	2	27	3.00	2	37	2.76
Q15	1	30	2.8000	1	17	2.5294	1	7	2.1429
	2	13	2.6923	2	26	2.9231	2	36	2.8889
Q23	1	29	2.1034	1	17	2.2941	1	7	1.8571
	2	13	2.5385	2	25	2.2000	2	35	2.3143
Q24	1	29	1.9310	1	17	1.8235	1	7	1.2857
	2	13	2.0000	2	25	2.0400	2	35	2.0857
Q42	1	26	2.62	1	16	2.63	1	7	2.43
	2	13	2.62	2	23	2.61	2	32	2.66

and

Table 13. Independent samples test—Levene’s test for equality of variances.

	t	df	Sig. (2-Tailed)	Mean Dif	Std. Error Dif
Seniority groups
Q7	2.313	43.000	0.0261	0.650	0.281
Q8	0.259	43.000	0.797	0.067	0.258
Q9	−1.257	42.000	0.216	−0.319	0.254
Q10	−0.961	42.000	0.342	−0.267	0.277
Q12	−1.272	42.000	0.211	−0.410	0.322
Q15	0.308	41.000	0.760	0.108	0.350
Q23	−1.415	40.000	0.165	−0.435	0.307
Q24	−0.279	40.000	0.781	−0.069	0.247
Q42	0.000	37.000	1.000	0.000	0.312
Digital experience groups
Q7	0.263	43.000	0.794	0.074	0.281
Q8	0.610	43.000	0.545	0.148	0.243
Q9	−0.844	42.000	0.403	−0.207	0.245
Q10	0.509	22.980	0.616	0.153	0.300
Q12	−1.142	42.000	0.260	−0.353	0.309
Q15	−1.217	41.000	0.230	−0.394	0.323
Q23	0.318	40.000	0.752	0.094	0.296
Q24	−0.941	40.000	0.352	−0.216	0.230
Q42	0.055	37.000	0.957	0.016	0.299
Blockchain knowledge groups
Q7	1.781	43.000	0.082	0.654	0.367
Q8	1.683	43.000	0.100	0.538	0.319
Q9	−1.867	42.000	0.069	−0.591	0.316
Q10	−2.115	42.000	0.0401	−0.718	0.340
Q12	1.659	42.000	0.104	0.672	0.405
Q15	−1.776	41.000	0.083	−0.746	0.420
Q23	−1.191	40.000	0.241	−0.457	0.384
Q24	−2.867	40.000	0.0071	−0.800	0.279
Q42	−0.597	37.000	0.554	−0.228	0.382

¹ Sig. (2-tailled) values in bold indicate statistically significant t-tests results with Sig. < 0.05. Note: Equal variances are assumed.

. Table 13 shows that the data are not normally distributed for Q7 (in the seniority groups category), and Q10 and Q24 (in the blockchain knowledge groups category) since the p-values are less than 0.05 for these three questions. The significant differences between these groups are discussed further in this section with the presentation of the survey results.

Table 14. Triangulation of the survey and interview outcomes in reference to parent nodes and child nodes from data analysis (interviews and surveys).

Parent Node	Child Nodes	Survey StatementReference	Results of the Triangulation
Trust Traceability Immutability Transparency	Design data (3D) BIM models Design history Engineering checking/QA	Q6-1	19% total, SD and D that trust is sufficient in BIM models (Q6-1).
		Q6-1	15% total, SD and D that trust is sufficient in Design history (Q6-1).
		Q7	25% total, SD and D that trust in consultants is sufficient in the industry (Q7). However, there was a significant difference in mean trust between senior and junior practitioners (t43 = 2.313, p < 0.05). Senior practitioners perceive trust 0.65 greater than junior practitioners.
		Q25	53% SA that Engineering checking/QA should be automated with smart contracts (Q25).
		Q43	76% total, A and SA that engineers/architects must own of the design data they have produced (Q43).
	Construction/ Supply chain (4D) Materials Construction Supply chain	Q6-1	15% total, D that trust is sufficient in Supply Chain info (Q6-1).
		Q22	80% total, A and SA that materials tags data from sensors/RFIDs must be traceable throughout the lifecycle of projects (Q22).
	Financial Data (5D) Payments Tendering Costs Incentivization Digital assets	Q6-1	31% total, SD and D that trust is sufficient in financial data (Q6-1).
		Q25	71% SA that payment processes should be automated with smart contracts (Q25).
		Q25	64% SD that is tendering processes should be automated with smart contracts (Q25).
		Q42	27% SA that data ownership must be monetized on decentralized data marketplaces to incentivize data owners to produce information (Q42).
		Table 8	Refer to interview, Table 8
	O&M (6D) As-built informationAsset Information Asset management Maintenance	Q6-1	48% total, SD and D that trust is sufficient in as-built data (Q6-1).
		Q22	90% total, A and SA that asset information data from sensors must be traceable throughout the lifecycle of projects (Q22).
		Q6-1	29% total, SD and D that trust is sufficient in asset information (Q6-1).
		Q22	87% total, A and SA that structural states must be traceable throughout the lifecycle of projects (Q22).
		Q25	69% SA that asset management should be automated with smart contracts (Q25).
		Q43	76% total, A and SA that property owners must own the data generated by their smart asset (Q43).
		Table 8	Refer to interview, Table 8
	Environmental data (7D) Energy management Materials recycling and reuse. Waste reduction	Q6-1	40% total, SD and D that trust is sufficient in environmental data (Q6-1).
		Q22	90% total, A and SA that energy consumption data from sensors must be traceable throughout the lifecycle of projects (Q22).
		Q22	84% total, A and SA that air quality data from sensors must be traceable throughout the lifecycle of projects (Q22).
		Q22	73% total, A and SA that weather data from sensors must be traceable throughout the lifecycle of projects (Q22).
		Q6-3	Environmental data should be openly accessible according to 63% of participants (Q6-3)
		Table 8	Refer to interview, Table 8
	Health and Safety (8D) Risk management Site safety Safety regulations	Q6-1	12% total SD and D and 19% N that trust is sufficient in health and safety data (Q6-1).
		Q6-3	Health and Safety data should be openly accessible according to 63% of participants (Q6-3)
	Contractual (cD) Information records Contracts Certificates Accountability Identities Data ownership Regulations Data notarization	Q6-1	27% total, D that trust is sufficient in contracts (Q6-1).
		Q6-1	12% total D and 31% N that trust is sufficient in certificates (Q6-1).
		Q8	21% D that trust in CDE is sufficient in the industry (Q8).
		Q25	56% SA that contracts should be automated with smart contracts (Q25).
		Q25	59% SA that certification processes should be automated with smart contracts (Q25).
		Q24	78% total, A and SA that regulatory processes must be automated with standard legal smart contracts templates (Q24).
		Q40	85% total, A and SA that stakeholders participating in a project must be legally liable for the data they create for a legally defined period of time (Q40).
		Q21	86% total, A and SA that professionals’ identities need to be traceable throughout the lifecycle of projects in case of litigation (Q21).
		Q41	60% total, A and SA agree that stakeholders participating in a project must own the data they create for a legally defined period of time (Q41).
		Q41	55% total, A and SA agree that stakeholders participating in a project must own the data they create until the data is handed over to another party (Q41).
		Q42	27% SA that data ownership must be monetized on decentralized data marketplaces to incentivize data owners to produce information (Q42).
		Q43	68% total, A and SA that BIM modelers must own of the model data they have produced (Q43).
		Q43	76% total, A and SA that engineers/architects must own of the design data they have produced (Q43).
		Q43	74% total, A and SA that property owners must own the data generated by their smart asset (Q43).
		Q43	62% total, A and SA that governments must have ownership of the data generated by the smart cities assets (Q43).
		Table 8	Refer to interview, Table 8
Decentralization Efficiency	Design collaboration Supply chain information Project lifecycle	Q9	75% total, A and SA that project lifecycle data should be recorded in a shared ledger (Q9).
		Table 8	Refer to interview, Table 8
	CDE Data sharing Data silos	Q8	21% D that trust in centralized collaboration software is sufficient in the CI (Q8).
		Q12	25% D that data-sharing capabilities of centralized CDE are sufficient to share information in the CI (Q12).
		Q10	68% total, A and SA that data sharing should be decentralized through P2P networks to reduce fragmentation (data silos) (Q10). However, there was a significant difference in mean between practitioners with and without blockchain knowledge (t42 = −2.115, p < 0.05). Blockchain experts believe that data sharing should be decentralized at a level that is 0.7 more than practitioners with basic blockchain knowledge.
		Table 8	Refer to interview, Table 8
	Processes Contracts Government Automation Digital twin automation Decentralized data value chain	Q23	67% total, A and SA that work orders must be automated by smart contracts to enhance efficiency and reduce paperwork (Q23).
		Q24	78% total, A and SA that regulatory processes must be automated with standard legal smart contracts templates (Q24). However, there was a significant difference in mean between practitioners with and without blockchain knowledge (t40= −2.867, p < 0.01). Blockchain experts believe that regulatory processes must be automated with smart contracts at a level that is 0.8 more than practitioners with basic blockchain knowledge.
		Q25	59% SA that certification processes should be automated with smart contracts (Q25).
		Q25	60% SA that council DA approvals should be automated with smart contracts (Q25).
		Q25	71% SD that payments processes should be automated with smart contracts (Q25).
		Q25	64% SD that is tendering processes should be automated with smart contracts (Q25).
		Q25	56% SD that contracts should be automated with smart contracts (Q25).
		Table 8	Refer to interview, Table 8
Security Privacy Data value chain	Security Infrastructure resilience BMS	Table 8	Refer to interview, Table 8
	InteroperabilityData value chainStandardized structured data layer (PDBB)	Table 8	Refer to interview, Table 8
	Privacy Data sensitivity Data erasure Data ownership Data authenticity	Q6-3	Most data should be private except certificates, Health and Safety, and environmental (Q6-3)
		Q6-2	Most of project lifecycle data shouldn’t be deleted after the demolition of the physical asset (Q6-2)
		Q15	Some financial data should be private, whereas others can be openly accessible to enhance fairness in the CI (Q15)
		Q41	60% total, A and SA agree that stakeholders participating in a project must own the data they create for a legally defined period of time (Q41).
		Q41	55% total, A and SA agree that stakeholders participating in a project must own the data they create until the data is handed over to another party (Q41).
		Table 8	Refer to interview, Table 8

presents the answers to Q6-1 (Table 6), which reveals a lack of trust among 40% of practitioners in terms of financial data, as-built information, asset information, and environmental data. It should also be noted that lack of trust can also apply to project data such as BIM, design history, certificates, contracts, and supply chain information according to up to a quarter of the participants. BCT can guarantee data integrity through the auditability and immutability of blockchain historical transactions; thus, BCT can improve trust in the data transacting through the blockchain. Hence, there is great potential to enhance the trustworthiness of the above data categories by transacting them leveraging BCT and smart contracts.

The answers to Q6-2 (Table 6) presented in Table 14 show that participants typically disagree (more than 60% disagree and strongly disagree) that the project lifecycle data shown in Table 7 should be deleted after the demolition of the physical asset. Hence, the project lifecycle data listed in Table 7 should typically not be deleted after the demolition of the physical asset. Hence, an immutable blockchain ledger could be adequate to anchor these key project data permanently since it is not desired to erase them after the lifespan of the physical asset. This also reinforces the concept discussed in the introduction that such data could then permanently be reused for ML and AI to generate new designs based on trusted historical information. However, if project data remain permanently anchored on blockchain-based networks, compliance considerations between blockchain and data protection regulations and policies such as the General Data Protection Regulation (GDPR) would need to be considered and explored further [42].

The descriptive statistics dashboard shown in Figure 2 and the summary Table 14 present the answers to Q6-3 (Table 6), showing that most of the project lifecycle data shown on Table 7 should be private and only accessible with specific privileges except for certificates, health and safety information, and environmental data for which more than 60% of participants believe such data should remain openly accessible. Hence, if sensitive project lifecycle data are anchored in blockchain networks, privacy should be maintained by leveraging either private blockchains, privacy protocols, encryption mechanisms, or off-chain storage solutions to ensure that specific data remain confidential.

Table 14 presents the answers to Q7 (Table 6) and shows that most participants agree (43% agree) that trust in consultants is sufficient in the industry. However, one-third of participants (32% of answers) neither agree nor disagree, and a non-negligible 18% disagree and 7% strongly disagree. Hence, trust towards consultants is likely not sufficient within the CI. Moreover, the t-test analysis revealed there was a significant difference in mean trust between senior and junior practitioners (t = 2.313, p < 0.05, as shown in Table 12 and Table 13), and senior practitioners perceive that there is a lack of trust about 0.65 more than junior practitioners. BCT could be leveraged to increase the trustworthiness of consultants’ activities and processes lacking trust, such as for BIM models, design history, certificates, contracts, as-built information, asset information, and environmental data, as suggested by the answers to the survey statement Q6-1. The measurements of as-built information, asset information, and environmental data need to be recorded physically with measuring tools, sensors, and IoT sensing devices, and, to integrate real-world data into a blockchain, IoT sensors, secure elements [43] and microchips or SRAM PUF [44], middleware, and oracles [29] would be required to authenticate data.

Table 14 presents the answers to Q8, which shows that 54% of participants agree that trust in centralized CDE is sufficient in the CI. However, 25% of people neither agree or disagree and 21% disagree, suggesting that trust in centralized CDE could be improved. BCT could contribute to enhancing trust towards CDE by providing an immutable audit trail of the historical data recorded on the shared ledger. Moreover, a CDE enhanced by decentralized blockchain networks would inherit from the decentralized nature of BCT. This could form a paradigm shift from centralized CDE towards decentralized CDE (DCDE) leveraging blockchain-based distributed storage systems.

The answers to Q9 (Table 6) presented in Table 14 show that 46% of participants agree and 29% strongly agree that project lifecycle data should be recorded in a shared ledger to enhance collaboration between all participants. Hence, DLT and BCT should be explored to improve collaboration in the CI by leveraging decentralized data sharing through P2P networks.

The answers to Q10 (Table 6) presented in Table 14 show that 50% of participants agree and 18% strongly agree that data sharing should be decentralized through P2P networks to reduce fragmentation and data silos in the CI. BCT is decentralized and P2P by nature; hence, it should be explored for data sharing and to reduce fragmentation in data silos within CI 4.0. However, the t-tests revealed a significant difference in mean between practitioners with and without blockchain knowledge (t = −2.115, p < 0.05, as shown on Table 12 and Table 13). Blockchain experts believe 0.7 more strongly that data sharing should be decentralized through P2P networks to reduce data silos in the industry.

The answers to Q12 (Table 6) presented in Table 14 show that a perceptible 25% of participants disagree that the data-sharing capabilities of traditional centralized CDE platforms are sufficient to share information in the CI. Moreover, 28% of participants neither agree nor disagree while 47% agree and strongly agree. These mitigated answers aren’t sufficient to affirm that current CDE platforms are adequate for data sharing. Hence, it is likely that current CDE platforms could be improved for data sharing within the CI. Decentralized open networks such as BCT and blockchain-based decentralized storage systems can enhance the data-sharing capabilities of CDE by reducing data silos and creating a paradigm shift towards DCDEs. Thus, by analogy with the survey insights from Q10 discussed above, blockchain-based storage systems can reduce the fragmentation in data silos in the CI.

The answers to Q15 (Table 6) presented in Table 14 reveal mitigated opinions as about 32% disagree and strongly disagree, 25% neither agree nor disagree, and 43% agree or strongly agree with the fact that financial transactions should be publicly auditable to enhance fairness in the industry. Thus, it is not clear whether financial data should be made openly accessible (i.e., transparent) or be private. The correlation to the answers from statement Q6-3 validates the fact that private blockchains, privacy protocols, or encryption mechanisms might be required for specific financial transactions requiring confidentiality.

The answers to Q21 (Table 6) presented in Table 14 show that 50% of participants agree and 36% strongly agree that professionals’ identities are required to be traceable throughout the lifecycle of projects in case of litigation. Digital identities solutions [45] using BCT and smart contracts have the potential to address this requirement.

The answers to Q22 (Table 6) presented in Table 14 show that more than about 75% of participants typically agree and strongly agree with the data captured from the smart buildings IoT sensors (temperature, humidity, energy consumption, materials tags RFID, assets information, structural states, motion/occupancy, air quality, and weather data) must be traceable throughout the lifecycle of projects. The sensors’ data requiring to be traceable the most appear to be energy consumption, assets information, structural states, and air quality. The traceability of IoT sensor data can be improved by BCT, which could enhance data integrity and provide an immutable shared ledger of historical transactional data.

The answers to Q23 (Table 6) presented in Table 14 show that 67% total of survey participants agree and strongly agree that work orders must be automated by blockchain smart contracts to enhance efficiency and reduce paperwork. A non-exhaustive list of work orders in the construction industry would include processes such as maintenance, repair, operations, service, manufacturing, materials delivery, equipment rental, construction work, and installation. The reduction of paperwork could be beneficial for the environment and reduce the project’s carbon footprint.

The answers to Q24 (Table 6) presented in Table 14 show that 78% of participants agree and strongly agree that regulatory processes in the CI must be automated with standard legal smart contracts templates. However, there was a significant difference in mean between practitioners with and without blockchain knowledge (t = −2.867, p < 0.01 as shown on Table 12 and Table 13). Blockchain experts believe that regulatory processes must be automated with smart contracts at a level that is 0.8 more than practitioners with basic blockchain knowledge. Legal smart contracts are a key application of BCT for the CI. Standard legal smart contracts templates should be developed in conjunction with industry experts and regulatory bodies.

The answers to Q25 (Table 6) presented in Table 14 indicate that key processes of the projects’ lifecycle should be automated with blockchain smart contracts. More than 65% of participants strongly agreed that council DA approvals, payments processes, engineering checking/QA, certification processes, tendering processes, and asset management processes (e.g., maintenance) must be automated with blockchain smart contracts. Additionally, 56% percent of participants strongly agree that contractual processes must be automated by blockchain smart contracts.

The answers to Q40 (Table 6) presented in Table 14 show that 85% of participants agree and strongly agree that stakeholders participating in a project must be legally liable for the data they create for a legally defined period of time, whereas only around 55% of participants agree and strongly agree that stakeholders must be legally liable until the data is handed over to another party or throughout the full lifecycle of the asset. Liability requirements could be programmed within smart contracts to ensure that liabilities about data and asset ownership expire after a legally defined period. Time conditions could be embedded accordingly within the code of the smart contract.

In terms of data ownership, the answers to Q41 (Table 6) presented on Table 14 show that 60% of participants agree and strongly agree that stakeholders participating in a project must own the data they create for a legally defined period of time, whereas 55% of survey participants agree and strongly agree that the data owners must own the data they create until the data are handed over to another party. These mitigated results suggest that further research is required to define the specific contexts in which each of these conditions apply. Data ownership requirements could be programmed within smart contracts, and the ownership of an asset (e.g., data as an asset or a physical asset) would be embedded with access control protection into the smart contract representing the asset; Hence, programming conditions within the smart contract would ensure that the ownership either expires after a legally defined period of time or until the asset is handed over to another party claiming ownership.

The answers to Q42 (Table 6) presented in Table 14 show that 73% of participants neither agree nor disagree on the requirement to monetize data ownership on decentralized data marketplaces. However, 27% of participants strongly agree on the monetization of data on decentralized data marketplaces to incentivize data owners to produce information. This could be achieved by tokenizing data ownership with smart contracts representing the datasets owned. These data tokens could then be monetized on blockchain-based decentralized marketplaces.

The answers to Q43 (Table 6) presented in Table 14 show that more than 60% of participants agree or strongly agree that (1) BIM modellers must own the model data they have produced, (2) property owners must own the data generated by their smart asset (e.g., smart building), (3) governments must have ownership of the data generated by the smart cities assets (e.g., smart buildings), and (4) the data generated by the smart cities assets (e.g., smart buildings) should be publicly owned. As mentioned above, data ownership could be tokenized with smart contracts. For example, at the design stage, CAD or BIM data could be tokenized [46].

5. Findings

5.1. Project Lifecycle Data Classification for BCDTs

The data analysis summary shown in Table 14 permits the validation of the initial hypotheses, stating that the existing BIM dimensions are an adequate framework to classify the project lifecycle data relevant for BCT applications in CI 4.0. Indeed, the taxonomy and properties of BCT (trust, transparency, traceability, immutability, efficiency, and security) offer significant benefits for the data value chain throughout the lifecycle of construction projects. BCT would contribute to enhancing data integrity and the trustworthiness of the data value chain by enabling traceability, immutability, transparency, and security of information records. BIM, IoT, and DTs are key enablers for the digitization of the CI. The data analysis revealed that BCT could also become a technological enabler to enhance trust, data integrity, cyber security, and efficiency within CI 4.0. As summarized in Table 13, the project data that would benefit the most from BCT adoption relate to the BIM dimensions (3D to 8D) and the new proposed contractual dimension cD. DTs extend the usefulness of BIM throughout the full lifecycle and particularly at O&M by enabling live monitoring and retroactive control with IoT and actuators. The proposed dimensions framework allows categorizing the key project data relevant to BCTDs to bring the most benefits during the project lifecycle. The rest of this paper refers to 3D, 4D, 5D, 6D, 7D, 8D, and cD as BCDT dimensions, as illustrated in Figure 3. In this context, BCT acts as the trust layer to enhance integrity and security of the data transacting through BCDTs for each dimension of the project lifecycle: design data (3D spatial dimension), scheduling and construction supply chain data (4D time dimension), financial data (5D cost dimension), operation and maintenance data (6D maintenance dimension), environmental data (7D sustainability dimension), health and safety (8D safety dimension), and contractual data (cD contractual dimension).

At the design stage, the 3D spatial dimension of the DT, is essential to define and represent DTs in space and achieve a spatial DT [47]. Spatial BCDTs would enhance the trustworthiness of design data such as BIM models, design history, calculations, engineering Q&A, and design data records in general through an open, trusted, and immutable audit trail of design records anchored in the blockchain. Spatial BCDTs would also improve trust towards the design consultants involved.

BCDT would also enhance trust in the construction supply chain. The integrity of key data associated with the 4D time dimension would be improved through traceability and timestamped supply chain information transparency. BCDTs would also strengthen the integrity of as-built data and the traceability of materials and facilitate real-time monitoring for site activities. Consequently, BCDTs would improve construction management and processes and hence enhance the trustworthiness of contractors.

The 5D financial dimension is fundamental for BCDTs, which can offer an open and trusted financial ecosystem leveraging BCT for financial operations. BCT has been disrupting the financial industry, which is the main sector for blockchain applications. Public and decentralized blockchain networks such as Bitcoin [48] have demonstrated that tamper-proof financial transactions can operate securely without trusted third parties such as banks. Moreover, smart contracts platforms such as Ethereum [49] enable DApps and Decentralized Finance (DeFi) solutions offering financial instruments in a decentralized way without middlemen. DeFi solutions in the Fintech sector include decentralized exchanges [50], lending and borrowing [51], derivatives [52], and stable coins [53]. DeFi tools could be integrated into CI 4.0 to decentralize the traditional financial ecosystem of the industry and offer innovative solutions for funding, transacting, lending, borrowing, and trading tokenized assets. BCDTs would enable traceability of trusted immutable financial records and allow transparency of these records when required. However, privacy is a challenge for BCT, which is open by nature. Therefore, if privacy is required for confidential data, BCDTs could leverage privacy protocols such as the Baseline protocol [54], use encryption mechanisms, or store confidential data off-chain. Blockchain smart contracts would allow BCDTs to automate processes such as payments and tendering. Moreover, BCDTs could facilitate the monetization of data and enable the transfer of data ownership through trading of tokenized datasets or assets metadata on decentralized marketplaces.

During the operation and maintenance phase, BCDTs can offer essential benefits for the project data related to the 6D dimension. Indeed, BCTDs can enhance trust, immutability, and traceability for 6D key data records such as-built information, materials metadata, structural states, asset information, maintenance information, and operational data captured by IoT sensors. Moreover, the transparency of asset information for maintenance purposes can lead to new decentralized business models leveraging open tendering for maintenance contractors to receive work orders and maintenance work offers. Hence, BCDTs will improve asset management and facility management through a decentralized economic ecosystem of DTs within CI 4.0.

The 7D sustainability dimension also gathers key information relevant for BCDTs, which can be virtuous for the environment. Indeed, BCDTs can improve trust in projects’ carbon footprints by providing immutable open audit trails of environmental data records. Moreover, the energy consumption of smart buildings and infrastructures could be traced and monitored with sustainable BCTDs. Blockchain smart contracts could enable tokenization mechanisms to incentivize stakeholders to reduce their carbon footprint. The air quality, water supply, and weather information can be monitored in real-time by BCDT and enable proactive behaviours facilitated by data analytics and blockchain-based incentive mechanisms that measure and reward environmentally friendly behaviours. BCDTs can also facilitate the traceability of materials to reduce construction waste and facilitate material recycling and reuse for the circular economy.

There is a significant lack of trust in health and safety (H&S) information, which should be openly accessible. Hence, the 8D dimension is also relevant to BCDT, which can enhance trust and compliance throughout the lifecycle of construction projects by providing an immutable and open audit trail of H&S data. BCDT can also improve the security of BMS systems and secure the Big Data used to improve life safety [5]. BCDTs can contribute to improving the safety of buildings through real-time monitoring and risk identification [17] and mitigation. BCDT would contribute to reducing risks through information transparency from openly accessible H&S data records. Moreover, the site workers’ safety could be traced and monitored from the BCDTs by leveraging H&S data captured using IoT sensors.

Furthermore, the data analysis revealed that a contractual dimension (cD) is relevant to group the contractual and regulatory data transacting with BCDTs. The cD relates specifically to the self-sovereign characteristics of BCT and smart contracts, which enable trusted data notarization, decentralized identities, and data ownership and provide an immutable audit trail of timestamped regulatory and contractual information records. Blockchain smart contracts can automate regulatory and contractual processes in an open manner and strengthen the implementation of regulations and reforms in CI 4.0. Blockchain smart contracts can also guarantee the traceability and trustworthiness of digital identities to prove accountability and data ownership (during legally defined periods of time) for the data produced by the stakeholders involved in the project (BIM modelers, engineers, architects, owners, government bodies, or even the public). Smart contracts can also strengthen the certification processes by enabling automated decentralized tamper-proof certificates mapped to immutable open data records about the certified assets.

Finally, the seven (7) BCDT dimensions allow categorizing the essential components of the project data value chain that are relevant to BCDTs throughout the lifecycle of the physical smart asset represented by the BCDT. BCT act as the trust layer for sustainable BCDTs of CI 4.0 and provide an immutable distributed ledger of traceable and open (or private if required) timestamped data records for each dimension. The BCDT dimensions and their key data (from the project lifecycle) are illustrated in Figure 3 below.

5.2. Towards a Level 4 Collaboration

The data analysis revealed the key factors affecting the paradigm shift powered by BCDTs to improve data sharing and trust, reduce data silos, and create new business models in CI 4.0. These key factors relate to the decentralization of collaboration, enhancement of data sharing to reduce data silos, decentralization of the data value chain, and processes automation with smart contracts.

The concept of decentralized collaboration, or more accurately distributed collaboration (using P2P networks), designates a novel collaborative paradigm where project participants collaborate in a P2P way by leveraging blockchain-based networks. This model contrasts with the traditional collaborative methods relying on centralized organizations, databases, and networks. The data analysis indicated, for example, that the decentralization of processes such as the design, modelling, planning, certification, and approvals would reduce inefficiencies in the CI. Moreover, in the longer-term horizon, organizations such as engineering organizations or government bodies would become decentralized and operate as DAOs to automate business logic, operations, and governance using blockchain networks and smart contracts. Repetitive management tasks would also benefit from decentralization and smart contracts automation to decongest cumbersome activities and increase efficiency.

The supply chain information of the CI is currently fragmented in Big Data silos owned by different centralized entities. BCT adoption would decentralize supply chain processes, such as procurement, handover, delivery, and O&M activities; it would streamline processes and improve the trustworthiness and traceability of the information value chain. Thus, BCT would contribute to decentralizing the data value chain throughout the supply chain of projects along their lifecycles.

In such a decentralized ecosystem, the digital collaboration between stakeholders sharing project data and transacting value would operate through BCDTs leveraging BCT and smart contracts running on distributed (P2P) blockchain networks. The key information (related to BCDT dimensions) from the projects’ lifecycle would be anchored in shared blockchain ledgers, enabling trusted distributed collaboration between stakeholders who transact data via BCDTs (connected to P2P blockchain networks). BCT would act as the backbone layer for DTs, to guarantee trust, data integrity, and efficiency, reduce data silos, and facilitate collaboration and data sharing. This novel model of distributed collaboration is referred to in this paper as the BCDT Maturity Level 4 of collaboration, which is a theoretical extension to the BIM maturity Level 3. The Level 4 distributed collaboration for sustainable BCDTs throughout the lifecycle of smart infrastructures projects is illustrated in Figure 4.

The decentralization of data sharing is the second key factor affecting the paradigm shift powered by BCDTs adoption for CI 4.0. Data-sharing capabilities of centralized CDE can be improved with BCT. Data storage and sharing systems would transact through decentralized blockchain-based P2P networks to reduce the fragmentation of the information value chain in data silos within CI 4.0. This decentralization of data storage infrastructures would lead to new forms of CDEs designated as DCDEs. The project’s lifecycle data, related to the BCDT dimensions, would be anchored in a blockchain shared ledger to enhance trusted data sharing between projects’ participants. Hence, the decentralization of data sharing through BCDTs would contribute to reducing data silos in CI 4.0. This blockchain-based P2P data sharing model between projects participants is illustrated in Figure 4.

The decentralization of the data value chain is the third key factor affecting the BCDTs paradigm shift in CI 4.0. Indeed, the Level 4 distributed collaboration and data sharing resulting from ecosystems of united BCDTs would comprise a decentralized data value chain throughout smart cities projects’ lifecycles. A decentralized Big Data value chain would embrace the philosophy of the Web 3.0 paradigm shift. For this purpose, it would require decentralized protocols for data acquisition [28,29], data analysis [30], data curation [32], data storage [34,55], and data usage [36]. A decentralized data value chain powered by BCT would enhance the security, traceability, transparency, authenticity, and integrity of the project lifecycle data transacting through BCDTs. The decentralization of the data value chain using BCT will increase trust in the data distribution within the industry, reduce data silos, and benefit the DCE and the environment through recycling, reuse, waste reduction, and energy management.

Finally, the automation of processes in CI 4.0 using BCT is the fourth key factor enabling the BCDTs’ paradigm shift. The main processes requiring automation by blockchain smart contracts are work orders, approvals (e.g., DA approvals), design, checking and Q&A, certification, management, maintenance, payments, contracts, BIM 5D, tendering, and regulatory processes. Moreover, back-end processes of BCDTs would also be operated and automated by blockchain smart contracts. BCT would act as a back-end layer to guarantee trust, data integrity, and enable smart contracts automation for BCDTs key operations involving data from the BCDT dimensions. This automation of BCDT back-end operations with blockchain smart contracts would guarantee the trustworthiness of BCDTs DApps and DAOs and the integrity of the data value chain transacting through them.

5.3. Non-Functional Requirements for BCDTs

The data analysis allowed the authors to extract some essential non-functional requirements for BCDTs in CI 4.0.

The first two key non-functional requirements relate to information security and data integrity, which are key requirements for the data value chain along the lifecycle of projects. Sensitive project information such as financial data, confidential data, personal data, asset data, intellectual property, and sensitive projects information (e.g., defence, healthcare, and infrastructure) require the most security against cyber threats. Moreover, data security is crucial for smart buildings and their BMS. BCT is inherently secure by nature and can permit BCDTs to enhance the security of smart buildings. It is also essential to guarantee the security of data sharing and the resilience of IT infrastructures against cyber threats. Data transfer needs to be secured and encrypted; in Web 3.0 ecosystems, the security of P2P data sharing can be strengthened with resilient blockchain protocols secured by cryptography.

The third and fourth key requirements are the decentralization and scalability of data storage systems. Indeed, the data analysis also revealed that the security of data storage is essential for CI 4.0. Blockchain-based decentralized storage services such as IPFS [55] or Filecoin [35] will contribute to the security of data storage in Web 3.0 and reduce the single point of failure vulnerabilities of the currently siloed Web 2.0 data storage infrastructure. The security of Software as a Service (SaaS) also needs to be improved. DApps running on blockchain networks would improve the resilience and trust of software solutions within the Web 3.0 ecosystem. BCDTs will be part of this paradigm shift and improve the security of DT software for CI 4.0. Web 3.0 infrastructure such as decentralized cloud storage and computing will need to be adequality scalable to deal with the large volume and velocity of Big Data throughout the lifecycle of projects of CI 4.0.

In the context of Web 3.0, the preservation of data ownership during the lifecycle of projects is the fifth key requirement for BCDTs as project participants would require ownership of the data they create for a legally defined period or until the data is handed over to another party. The notion of data ownership is key for the BCDT contractual dimension (cD) as projects participants have self-sovereignty of the information they produce and transact with (e.g., data creation, data acquisition, identity proof, and contractual signature).

Data privacy is the sixth key non-functional requirement for BCDTs of CI 4.0. Indeed, the data analysis revealed that most of the project lifecycle should remain private except for environmental, health and safety, and certification information. Even though permissionless blockchain networks are typically open and provide data transparency, privacy could be achieved with private blockchains, encryption mechanisms, off-chain storage, or with privacy protocols such as AZTEC [56], Phala [57], or the baseline protocol [54]. Hence, despite the challenge to achieve confidentiality with BCT, the privacy requirements for sensitive project information such as financial transactions, identities, or design data could be achieved with BCDTs as required.

Interoperability is the seventh key non-functional requirement for BCDTs of CI 4.0 and sustainable smart cities. Within a decentralized Level 4 collaborative ecosystem, the Big Data value chain needs to be format-agnostic to facilitate interoperable data sharing between separate BCDTs systems forming the ecosystem. BCDTs need to be adequately interoperable to deal with the data variety from the Big Data value chain of projects of the CI. Standardized data structures are required to organize project lifecycle information for each BCDT dimension. Hence, it is fundamental to develop open cross-platforms, and format-agnostic data standards for BCDTs and, more generally, for DTs.

Moreover, if several different underlying blockchain networks are leveraged for multiple BCDTs, the interoperability between these blockchain networks becomes a key requirement to ensure transactional capabilities between BCDTs and to maintain a single version of truth despite the plurality of blockchain networks.

From the previous sections presenting the analysis from the interviews and online survey, we can validate the initial hypotheses (derived from the literature) and address the three research objectives. The findings are presented in

Table 15. Data analysis keywords, parent nodes, and emerging themes forming the proposed framework.

Keywords	Parent Node	Sub Themes Linked to Research Questions	Proposed Emerging Themes, Limitations, and Future Directions
Design data Calculations Engineering Reviews Operations and maintenance As-built information Asset information Materials Contracts Certificates Accountability Identities Data records Public records Amendments Environmental data Energy consumption Financial data Information as an asset Health and safety Construction Supply chain Regulations Data ownership Digitization Digital twin	Trust Traceability Immutability Transparency	Project lifecycle data categorization into dimensions	BCDT dimensions (3D, 4D, 5D, 6D, 7D, 8D, and cD) Limitations: The limitations are related to the lack of practical implementation of the BCDT dimensions framework, which is only theoretical at this stage, especially the cD dimension, which is an emerging theme that will need to be further developed. Futures directions: Future research works will focus on implementing practically BCDT solutions leveraging data related to the BCDT dimensions. Additionally, the new proposed cD dimension will need to be furthered structured and standardized to address the requirements for CI 4.0.
Design collaboration Engineering organizations Checking and reviewing PlanningData silos Supply chain information Project lifecycle data Government Project management CDE Data sharing Processes Approvals Automation Contracts Maintenance Digital Twin Decentralized circular economy (DCE)	Decentralization Data sharing Decentralized data value chain Automation	Decentralized collaboration, data sharing, and automation	Maturity Level 4 for BCDTs in CI 4.0. Limitations: The theme of distributed collaboration with P2P data sharing, a decentralized data value chain and smart contract automation is an emerging major paradigm shift, which will take time to be adopted. The slow adoption is due to the current technological limitation of BCT, which is a new technology, and also due to the fact that the CI is slow to embrace changes. Future directions: Future research works should practically implement and test BCDT solutions involving distributed collaboration, P2P data sharing, and smart contract automation of key processes.
Security Smart Buildings BMS Data sensitivity Confidentiality Infrastructure resilience Software Interoperability Data storage Data value chain Data ownership Privacy Data erasure Decentralization Scalability Open data standards Data authenticity Data integrity	Security Privacy Interoperability Decentralization and Scalability of Data storage Data integrityData authenticityOpen data standards	BCDT non-functional requirements	Non-functional requirements for BCDTs in CI 4.0. Limitations: This proposed list of non-functional requirements is non-exhaustive. BCDT are very complex systems and additional non-functional requirements are likely to be discovered. Data privacy and confidentiality is difficult requirement to achieve with blockchain networks, which are open by nature. Future directions: Future research work should identify additional non-functional requirements and also develop some key functional requirements for BCDT applications of CI 4.0. In terms of data privacy, future research work should investigate options to enable privacy and confidentiality of some project data while keeping the advantage of having an open ecosystem of BCDTs.

, which shows the emerging themes (from the literature) that are validated by the proposed framework composed of: the BCDT dimensions, BCDT Maturity Level 4, and non-functional requirements for BCDTs in CI 4.0. Table 15 also includes for each proposed emerging themes, their respective sub-themes (linked to the research questions), and their parent nodes and associated keywords from the data analysis.

The proposed framework composed of Maturity Level 4 for distributed collaboration and the P2P data-sharing model for sustainable BCDTs of the Web 3.0 is illustrated in Figure 4.

6. Discussion

The three main findings of this research study are that (1) firstly, the key project lifecycle data to consider for BCDTs are essentially related to the BIM dimensions (3D, 4D, 5D, 6D, 7D, and 8D), which are extended to the proposed BCDT dimensions framework composed of the following dimensions: spatial (3D), scheduling and construction supply chain (4D), financial (5D), operation and maintenance (6D), environmental (7D), and health and safety (8D) dimensions and a novel contractual dimension (cD). Secondly, the Web 3.0 paradigm shift powered by sustainable BCDTs requires (2) a new form of collaboration that is fully decentralized and symbolized as Maturity Level 4 for BCDTs. This new level of maturity leverages distributed (peer-to-peer) blockchain-based networks to facilitate collaboration, processes automation through smart contracts, and enhanced data sharing within a decentralized data value chain. Thirdly, (3) the key non-functional requirements for BCDTs in CI 4.0 are security, privacy, interoperability, data ownership, data integrity, and the decentralization and scalability of data storage systems.

BCDTs can improve trust and data integrity throughout the lifecycle of smart infrastructure projects by providing auditable and immutable historical transactional data anchored in the blockchain. Moreover, BCDTs enable transparency and traceability of supply chain information and they can be virtuous for the environment by reducing wastes through recycling and reuse of materials. The key data from the projects’ lifecycle that can benefit from these BCDTs attributes, related to data categories falling within the BCDTs dimensions (3D, 4D, 5D, 6D, 7D, 8D, and cD).

The novel BCDT contractual dimension cD leverages BCT and smart contracts as key technological enablers of Web 3.0, enabling self-sovereignty of project participants over their data. The cD dimension enhances trust towards essential aspects of construction projects’ contractual and regulatory structure such as smart legal contracts, data ownership, digital identities, accountability, liabilities, data notarization, intellectual property, policies enforcement, and regulatory compliance. The back-end trust layer provided by BCT would allow transacting without middlemen while ensuring the trustworthiness of information within ecosystems of BCDTs. Future research and consortium works should focus on developing the cD dimension framework with standard smart contracts templates for CI 4.0. Hence, smart contracts standards would be recognized within the CI and utilized for BCDTs and other DApps or DAOs to automate key processes such as invoicing, payments, tendering, contracts, maintenance, and work orders.

The BCDT dimensions framework proposed by this paper provides industry practitioners with a framework of building blocks to identify the most relevant project data that would benefit from BCDTs applications in CI 4.0. Future research works should develop this framework further and potentially provide new dimensions for BCDTs to integrate novel future concepts that would promote the use of sustainable BCDTs to benefit CI 4.0, smart cities, the economy, the environment, the public good, and society in general.

This paper also proposes the novel Maturity Level 4, which is a key enabler for a major paradigm shift in the CI towards a decentralized CI 4.0. The BCDT Maturity Level 4 is important as it enables the decentralization of collaboration, data sharing, and the data value chain. This has great potential to enhance collaboration, reduce data silos, and decrease fragmentation in the industry. Indeed, the proposed maturity Level 4 for ecosystems of BCDTs will enable a paradigm shift from the current Web 2.0-based industry, fragmented in data silos, towards a decentralized trusted data value chain running on decentralized IT infrastructures of the Web 3.0. The Web 3.0 paradigm shift for CI 4.0 will enhance collaboration and data sharing through P2P blockchain-based networks and DCDEs. Moreover, Maturity Level 4 will leverage blockchain smart contracts to automate key processes and enhance efficiency while removing unnecessary middlemen in CI 4.0. Within a decentralized data value chain leveraging BCT, projects’ data would be authenticated at the source by secure elements, decentralized oracles, and other decentralized protocols to limit GIGO effects and maintain data integrity throughout the lifecycle of projects. Processes related to data analysis, data curation, data storage, and data usage would also leverage blockchain protocols to integrate the data value chain of projects to the Web 3.0 paradigm shift. Data ownership would be protected by BCT to fairly incentivize the data creators and redistribute incentives horizontally within CI 4.0. Project participants interacting with BCDTs would also connect to digital marketplaces where information related to BCDT dimensions can be traced and traded as a digital asset.

The projects and assets of a decentralized CI 4.0 could become manageable directly from trusted BCDT that run as DApps and DAOs. The blockchain smart contracts at the back end of these DApps would automate key processes and reduce inefficiencies.

Moreover, organizations such as engineering firms or government bodies could also be represented by DAOs connecting to BCDTs to form semi-autonomous ecosystems of united BCDTs within future smart cities. BCTDs could become self-managed by combining blockchain smart contracts, DAOs, ML, and AI and hence enabling fully autonomous, cognitive, and spatial BCDT, acting as a single source of truth for projects information. Indeed, the key information of the project data value chain would be anchored on blockchain networks to increase information trustworthiness through transparency, traceability, and immutability of the historical transactional data belonging to each BCDT dimension. Moreover, the immutable audit trail of project information offered by BCDTs can ensure that future decision-making and design automation leveraging data mining, ML, and AI are founded on trusted information. Indeed, the immutability of trusted project data would provide a resilient repertory that guarantees data integrity to ensure ML and AI algorithms can automate future designs and decision-making from trusted historical data.

The main non-functional requirements identified for BCDT applications are security, privacy, interoperability, data ownership, data integrity, and the decentralization and scalability of data storage.

Information security is a core requirement to ensure that sensitive and confidential data are protected against cyber threats and remain private as required. Security can be enhanced by BCT, which is secured by design through cryptography. The security of smart infrastructures’ BMS would be enhanced by BCDT applications, and the physical smart infrastructures could be managed securely directly from their BCDTs.

Data integrity is a key non-functional requirement for BCDTs. BCT enhances data integrity through verifiable and immutable historical project transactional data. However, data integrity could be compromised by unauthenticated data, which could lead to GIGO effects. Future research work on microchips, secure elements, and decentralized oracles should focus on data authentication solutions for BCDTs to ensure the correctness of the data entering BCDTs from sensors and other sources of the data value chain in general.

Data privacy is a key requirement for sensitive project information such as design data, communications, financials, contracts, and personal data. However, data privacy and confidentiality form a challenge for blockchains, which are typically open by nature. Future research works should explore how privacy requirements can be addressed by decentralized and open BCDTs and investigate privacy protocols, encryption mechanisms, and off-chain decentralized storage enabling privacy. Moreover, future works should study the compliance between BCDTs and data privacy policies such as the GDPR.

Data storage solutions for BCDTs should be sufficiently decentralized and scalable to be respectively resilient against a single point of failures and be able to deal with large data volumes from the data value chain of CI 4.0. DCDEs solutions leveraging BCT could offer an immutable audit trail of historical project data anchored in a shared ledger. Thereby, the decentralization of CDEs would contribute to enhancing trust in data sharing, reduce data silos, and improve collaboration through fair incentivization for data creators and data owners. Future research work should develop and test practical experiments leveraging scalable decentralized storage solutions capable of dealing with the volume, velocity, and variety of the Big Data value chain from projects of the CI.

Interoperability is another key non-functional requirement to enable Level 4 BCDTs to transact data seamlessly between each other in a format-agnostic way. Interoperability between the blockchains underlying ecosystems of united BCDTs is also essential to guarantee a single unified source of truth. Researchers and stakeholders of the CI should collaborate to develop open data standards for DTs and BCDTs. DT open data standards should be cross-platform and format-agnostic. These data standards could then be leveraged in future works to organize project lifecycle data into structured data layers before they are anchored into BCDT systems.

The non-functional requirements identified in this paper provide the foundations for industry practitioners who want to develop BCDT solutions further. Future research work should focus on identifying a more exhaustive list of non-functional and functional requirements for specific BCDT applications and practically develop BCDT systems addressing these requirements for sustainable applications in CI 4.0. Additionally, since data ownership is a key requirement for BCDTs, the mitigated opinions of survey participants on data ownership duration suggest that future research work should focus on defining the data ownership requirements for BCDTs and identify the key factors affecting data ownership in regard to accountability, data privacy, and legal liabilities of stakeholders throughout the lifecycle of projects.

From an environmental point of view, the 7D BCDT dimension aims to reduce the carbon footprint of projects with better environmental management, such as reducing the energy consumption of smart infrastructures’ assets. Moreover, BCDTs can contribute to reducing waste by improving the recycling and reuse of construction materials for a decentralized circular economy (DCE). The 5D BCDT dimension would enable the decentralization of the financial ecosystem within CI 4.0 and leverage BCT to enhance trust, improve payments practices, tokenize assets, and leverage DeFi applications and decentralized marketplaces to trade digitized assets. Sustainable smart cities would include ecosystems of interoperable BCDTs transacting between each other within a DCE.

This paper discusses the advantages of BCDT for the environment and the circular economy. However, a quantitative carbon footprint analysis should be carried out to measure the environmental benefits of BCDT within a decentralized Web 3.0 compared to the traditionally siloed systems leveraging centralized Web 2.0 solutions.

7. Conclusions

To conclude, this paper answers the three research questions raised in the introduction. Indeed, the BCDT dimensions framework is firstly proposed to categorize the key data from the project’s lifecycle that should be considered for sustainable blockchain-based digital twins (BCDT) in CI 4.0. The key data included in the BCDT dimensions framework are design data (3D spatial dimension), scheduling and construction supply chain data (4D time dimension), financial data (5D cost dimension), operation and maintenance data (6D maintenance dimension), environmental data (7D sustainability dimension), health and safety data (8D safety dimension), and contractual data (cD novel contractual dimension). Secondly, the paper identifies the key factors necessary for a paradigm shift powered by BCDTs. These key factors are encompassed within the novel Maturity Level 4, which includes distributed collaboration, data sharing, decentralized data value chain, and the automation of processes with smart contracts. The Level 4 maturity will contribute to reducing data silos and improve collaboration, data sharing, trust, efficiency, and creating new business models in Construction Industry 4.0 (CI 4.0) and within a decentralized circular economy (DCE). Thirdly, the paper identifies that the main non-functional requirements for BCDTs in CI 4.0 are security, privacy, interoperability, data ownership, data integrity, and the decentralization and scalability of data storage.

The theoretical framework developed in this paper contributes to providing factors using a methodical approach. Future research work could develop the framework further and develop structured models in which the relationships between factors can be identified in a numerical way. For example, these factors could be rearranged, and the relationship between them can be further examined using structural equation modelling (SEM). Finally, further research works should develop systems architectures for the implementation of BCDTs and include practical implementations of the framework for CI 4.0 decentralized applications.