Content uploaded by Xingyu Tao
Author content
All content in this area was uploaded by Xingyu Tao on Mar 07, 2022
Content may be subject to copyright.
1
Distributed Common Data Environment Using Blockchain and Interplanetary File System for Secure
1
BIM-based Collaborative Design
2
Xingyu Taoa, Moumita Dasa*, Yuhan Liua, and Jack C. P. Chenga*
3
a Department of Civil and Environmental Engineering, The Hong Kong University of Science and Technology, Clear Water
4
Bay, Hong Kong
5
* Corresponding authors (Email): moumitadas@ust.hk (Moumita Das); cejcheng@ust.hk (Jack Cheng)
6
Abstract
7
Existing platforms for collaborative BIM design have a centralized system architecture, which suffers cybersecurity risks of
8
design data manipulation and denial of access, leading to a loss of data traceability, a decline in design productivity, and
9
project delays. Blockchain is a promising technology to solve such risks by providing decentralized and immutable data
10
storage. However, integrating blockchain with BIM faces a problem that blockchain is inherently unsuitable for storing large-
11
sized design files like BIM models, hindering blockchain from protecting BIM data integrity. Therefore, this paper proposes
12
a distributed common data environment (DCDE) framework for BIM-based design leveraging two distributed technologies:
13
blockchain and Interplanetary File System (IPFS). The DCDE framework guarantees irreversible design changes storage
14
using blockchain while secures design file storage using IPFS. A blockchain transaction data model and a smart contract are
15
also developed within the framework to support DCDE functionalities. Lastly, framework applicability and performance are
16
tested in an illustrative design example. Results show that: (1) DCDE is a feasible solution for secure design collaboration,
17
and (2) DCDE latency (in millisecond-level), TPS (60 transactions per second), and storage cost (12.5KB per day) are within
18
an acceptable range.
19
Keywords
20
Blockchain, Collaborative BIM, Common Data Environment (CDE), Hyperledger Fabric, Interplanetary File System (IPFS),
21
Smart contract
22
1. Introduction
23
Building information model (BIM) technology is a digital foundation for collaborative design in AEC (architecture,
24
engineering, and construction) projects as it enables interdisciplinary team members to collaborate through sharing design
25
2
attributes, changes, and issues [1]. Academia and the AEC industry have been increasingly developing methods and platforms
26
supporting collaborative BIM design. The latest ISO 19650 standards [2] recommends a common data environment (CDE)
27
defined as “the single source of information to collect, manage and disseminate documentation, the graphical model and non-
28
graphical data (i.e., project data including BIM models and project documents) for the whole project team”. CDE promotes
29
design collaboration efficiency by (1) specifying standard workflows to separate the life cycle of project data into four stages,
30
namely “WIP” (Work in Progress), “Shared”, “Published”, and “Archived”, and (2) providing explicit data status definition
31
and a greater version control ability to improve data reusability. Hence, CDE is an ideal model for efficient BIM-based design
32
collaborations [2,3].
33
Design CDE is a CDE that specific to collaborative design. Design CDEs developed for BIM model transformation and
34
federation [4], real-time communication [5], and efficient data access [6] have been discussed in the available literature.
35
However, existing design collaboration platforms and design CDEs are all centralized and therefore vulnerable to data security
36
issues, especially design data manipulation and denial of access. For design data manipulation, security measures such as
37
firewalls [7,8] and database access control [1,9] have been investigated to defense against external threats. Nevertheless,
38
these platforms are still susceptible to internal attacks, especially data manipulation by authorized users with malicious intent
39
[9]. For example, an insider has a motive and an opportunity to unwittingly modify design change records to exonerate himself
40
when liability issues occur [10]. Inside commercial espionage can even delete BIM models, thereby disrupting the stream of
41
data production and interrupting the design work [11]. For denial of design data access, current BIM-based collaborative
42
design functionalities are facilitated via a centralized server (e.g., Autodesk BIM 360 and Graphisoft BIM server), where one
43
project participant or a third-party vendor has the complete authority to manage design data [12]. Thus, project team suffers
44
from a high risk of denied access if the administrator’s server breaks down or the administrator withdraws BIM model access.
45
As a result, massive design collaboration information would be unavailable, and the design work may come to a halt [13].
46
Therefore, a securer CDE for BIM-based design collaboration is worthily developed.
47
Blockchain is an emerging and promising technology that ensures data immutability and traceability in a distributed
48
environment [14]. Unlike conventional centralized systems, blockchain employs a decentralized peer-to-peer system
49
architecture to allow every peer to own a complete blockchain ledger. Blockchain is supported by technologies including
50
cryptographic algorithms, distributed ledgers, and consensus mechanisms to verify and store transactions irreversibly.
51
Applications of blockchain have been investigated for securing digital collaborations in construction, such as construction
52
quality information management [15], supply chain management [16], and interim payments management [17]. As for
53
integrating blockchain with BIM, Nawari et al. [18] and Zheng et al. [19] discussed the feasibility and benefits of
54
implementing blockchain in BIM-based design, highlighting blockchain could build a trustworthy BIM data source since any
55
3
data in blockchain are traceable and unchangeable. Several conceptual frameworks have utilized blockchain to enhanced
56
reusability of BIM data [20], improve BIM change traceability [21], and accelerate approval process [22].
57
Although blockchain shows potential in solving cybersecurity risks in BIM-based collaboration, deploying blockchain
58
for design CDE (or collaborative BIM design) management is not widely addressed. One main challenge is that blockchain
59
is inherently unsuitable for storing large-sized data (e.g., BIM models and CAD files) due to the block size limit. Placing BIM
60
models in a blockchain would cause high latency and network congestion [18]. Methods to alleviate such data storage pressure
61
have not been investigated in the construction industry, preventing project members from sharing and storing BIM models in
62
a blockchain network. As a result, BIM data integrity and immutability could not be secured.
63
Interplanetary File System (IPFS) technology, a peer-to-peer distributed (without a centralized server) file system
64
arrangement, is expected to be a suitable technical complement for blockchain for securely storing and distributing large files
65
[23]. IPFS generates an irreversible and verifiable cryptographic identifier called content identifier (CID) based on file
66
content. CID represents the “hyperlink” and content proof of a file; thereby, receivers could access and verify the file via a
67
CID. More importantly, CID (256-bit long strings) is much smaller in size and may be easily distributed in blockchain for
68
data integrity verification and data accessing [24]. Unlike previous attempts that still store BIM models in a central database
69
and only share partial BIM information (e.g., BIM hash value [19] or semantic BIM changes [21]) in blockchain, this novel
70
blockchain-IPFS integrated method stores both BIM models and design changes in a distributed manner.
71
The blockchain-IPFS integrated method is new for BIM-based design collaboration; very few studies have investigated
72
the mechanism of implementing it in a CDE to enable secure collaboration. Fundamental problems like what is the workflow
73
when collaborating in a blockchain-IPFS-based CDE and how project members could exchange information in such CDE
74
necessitate further exploration. Therefore, this paper proposes a distributed common data environment (DCDE) framework
75
to solve large-sized file storage problems when applying blockchain in BIM-based collaborative design. Three objectives of
76
this research are summarized as:
77
(1) To develop a DCDE framework integrating blockchain and IPFS. The DCDE framework employs
78
blockchain and IPFS to store design records (e.g., design changes) and large-sized design files (e.g., BIM
79
models), respectively, in a distributed and unchangeable manner. BIM models (in IPFS) are linked to
80
corresponding design changes (in blockchain) through their CIDs. This framework aims to illustrate the logic
81
of how a CDE is integrated with blockchain and IPFS.
82
(2) To develop technical components to support DCDE functionalities. An original blockchain transaction data
83
model compliant with ISO 19650 standards is developed to record BIM design changes. A smart contract is
84
developed to share design transactions, facilitating design coordination in a DCDE.
85
4
(3) To evaluate the performance of DCDE framework. Firstly, the framework is deployed in a BIM-based design
86
example to verify its feasibility. Subsequently, three performance metrics, namely, network latency, throughput,
87
and storage cost, are measured. Latency means the time cost for sharing and querying design transactions in the
88
DCDE. Throughput indicates how many design transactions the DECD could handle per second. Storage cost
89
refers to the amount of computer memory spent over the holding of the blockchain ledger. One hypothesis is
90
that the results must be within a reasonable range. Existing studies [15,25] have suggested that: (1) the average
91
latency should be at the millisecond level, (2) the average TPS should be larger than collaboration requirements
92
(10 transactions per second in this study), and (3) the storage cost should be in KB of MB level.
93
The remainder of this paper is organized as follows. Section 2 introduces the technical background and highlights
94
research gap. Section 3 presents details of the DCDE framework development. Section 4 illustrates framework feasibility and
95
evaluates framework performance. Section 5 discusses the novelty, potential impacts, and limitations of the DCDE
96
framework. Finally, conclusions and future work are presented in Section 6.
97
2. Literature review
98
This section reviews existing studies from two perspectives: BIM-based collaborative design and distributed database
99
technologies. As shown in Figure 1, Section 2.1 aims to introduce existing methods used for design collaboration and
100
summarize problems of these methods. Section 2.2 reviews the benefits and necessity of adopting a design CDE in
101
collaboration work. More importantly, this section highlights data security risks that design CDE faces. Section 2.3 focuses
102
on reviewing blockchain feasibility in the construction industry and stating the research problem of large-sized design file
103
storage in blockchain. Section 2.4 introduces the technical background of IPFS and indicates the novelty of integrating it with
104
blockchain in a design CDE.
105
5
106
Figure 1. Overview of literature review
107
2.1 BIM-based collaborative design
108
Currently, there are tools and platforms for design collaboration in construction projects. They can be divided into two
109
general categories: (1) single tools that promote data exchangeability and interoperability, and (2) integrated BIM-based
110
collaborative design platforms that facilitate comprehensive collaboration.
111
Single tools that belong to the first category were developed with a view to enhance design collaboration through a
112
specific aspect, such as the compatibility of data formats [26], element versioning management [27], and tracking design
113
changes [28]. However, data access and data sharing are inefficient in these studies. Fortunately, this problem can mostly be
114
resolved using integrated design platforms (second category), which provide more comprehensive functions for BIM
115
collaboration. Liu et al. [29] introduced a cloud-based BIM data hub allowing users to store BIM models, share none-graphical
116
design documents, and retrieve design changes. Valeh Moayeri et al. [30] developed a novel visualization model to visualize
117
design changes and their further ripple effects on a project. Sotirios Logothetis et al. [31] presented a cloud-based open-source
118
system for online viewing, storing, and analyzing BIM models. A python plugin is developed to connect various BIM-based
119
platforms to enhance seamless design data transmission. Tamer El-Diraby et al. [5] merged an online design platform with
120
energy simulation software to make “green building” decisions. All the arrangements, energy data comparisons, and
121
comments are shared in a separate “chatroom” developed to aid real-time communication. These attempts improved
122
understanding of design information in a collaboration process and provided practical solutions to stimulate continuous
123
collaborative communication. However, problems, including cumbersome workflow and poor model version management,
124
still exist in these platforms and inevitably lead to extensive data redundancy and rework overlaps.
125
6
2.2 Design common data environment (CDE)
126
Common data environment (CDE) is recommended by ISO 19650 standards [2] to promote the efficiency of BIM-based
127
collaborative projects. As shown in Figure 2, the workflow of a design CDE comprises four information containers – (1) WIP,
128
(2) SHARED, (3) PUBLISHED, and (4) ARCHIVE. The WIP container is where design teams develop domain-specific
129
models using their own software. At this stage, data should not be visible or accessible to other teams. The SHARED container
130
is used for sharing design data that have been verified for multi-discipline collaboration. Information in this container should
131
be visible and accessible but should not be editable. The PUBLISHED container stores design information that has been
132
authorized to be used in downstream works (e.g., tender, construction, or operation). The ARCHIVE container holds a journal
133
of all information that has been shared and published during the collaboration. Before a model can transfer from one container
134
to the next, design leaders or clients must review and confirm that it is compliant with all relevant requirements. Except for
135
standard workflow, CDE also specifies well-defined data status, file naming conventions, and clear version regulations for
136
smooth and efficient collaborative design [32].
137
Design CDE can be implemented with any suitable toolset, including a cloud-based server, a local database, a file-based
138
retrieval system [4]. For example, Cornelius Preidel et al. [4] introduced a cloud CDE database called the BIM Integration
139
Framework (BIF) to let project members access and share BIM models easily. Stefan Mordue et al. [33] proposed a design
140
CDE framework, which enhanced design information management by (1) reducing the time and effort required to check,
141
version, and reissue information, (2) reducing the time and cost of producing coordinated information and (3) providing
142
greater data reliability. Minho Oh et al. [6] recommended a BIM-based design CDE consisting of three components, namely,
143
a BIM modeler, a BIM checker, and a BIM server, which are responsible for model creation, quality checking, and data
144
sharing, respectively. The results showed that coordination in standard workflow could help to prevent rework and improve
145
design productivity. Similarly, commercial CDE products such as BIM 360 [7] and BIMcloud [34] have tried an aggregated
146
model approach in a single, cloud-based environment to help design teams work on the same, up-to-date models. It has been
147
shown in practice that design CDEs are conducive to reducing data redundancy, raising information reusability, and
148
accelerating the coordination process [32,35].
149
However, both existing BIM-based design platforms and design CDE models are built on centralized databases or
150
servers, suffering cybersecurity risks, especially design data manipulation and denial of data access [1]. Parn et al. [11]
151
analyzed cyber threats confronting in design CDEs. This study highlighted that design data manipulation has a profound
152
impact upon the whole lifecycle of a project as it would cause loss of data traceability and accountability, endangering project
153
success. Data manipulation in a centralized and single database is hard to be detected and may result in unrecoverable data
154
damage [36]. Security defenses, including antivirus, access control paradigms, and firewalls, have been adopted to mitigate
155
7
external threats [1]. However, they are not sufficient to avoid attacks from insiders, who can abuse their authorized access to
156
a CDE database and tampers with it unwittingly [37]. Boyes et al. [12] investigated three data manipulation risks from inner
157
members: (1) non-malicious insider may cause data loss through error, omission, or ignorance; (2) malicious insiders change
158
design records to evade responsibility or (3) malicious insiders tamper with design files (e.g., illegally delete or modify BIM
159
models) for their own gain. Besides, a third-party vendor or one project member controlling the complete authority to manage
160
design data would pose a high risk of denial of access due to server breaks down, or the administrator refuses to provide
161
service [13] Therefore, developing methods to solve such cybersecurity vulnerabilities is an urgently needed for a secure
162
BIM-based collaborative design.
163
164
Figure 2. Common data environment (CDE) workflow [2]
165
2.3 Blockchain in construction
166
Blockchain, also known as distributed ledger technology (DLT), is a decentralized data storage solution that enables
167
every peer in the network to maintain complete and immutable records in their local database [38]. Hash algorithm is an on-
168
way function that can convert any string into a unique hash value. Each block in the blockchain has two hash values: block
169
hash and previous block hash. Hash link means a block could link to its predecessor via the "previous hash" to generate a
170
hash-chained block sequence. As shown in Figure 3, any slight modification of block information would dramatically change
171
8
the block hash value. Therefore, if someone attempts to manipulate the blockchain ledger in his local database, the whole
172
chain cannot add a new block, nor would it be recognized by other peers due to the hash value mismatch [39]. Besides, no
173
single peer can manipulate all data in the blockchain. Attackers can control the blockchain network only if more than 50% of
174
the peers are compromised. However, obtaining that much computing power is almost impossible from the current technical
175
perspective [19,22]. Thus, blockchain redefines the trust relationship by enabling every node in the network to save an
176
identical, unchangeable, traceable, and intact data copy [40].
177
Recent research in the construction industry has highlighted the feasibility of deploying blockchain to drive digital
178
transformation, accelerate collaboration, and maximize trust [41]. For example, Wang et al. [16] proposed a blockchain-based
179
framework to enhance supply chain traceability in off-site construction. Yang et al. [42] compared two types of blockchain,
180
indicating that the private blockchain is suitable for the construction industry for the advantages of privacy projection. Lee et
181
al. [43] presented a framework to integrate blockchain with digital twin technology to trace records in construction projects.
182
Li et al. [44] investigated applying blockchain in a housing IoT system; results showed that blockchain could enhance project
183
data reusability and project sustainability. Moumita Das et al. [17] developed a blockchain framework for securing project
184
interim payments. The payment process was automatically executed through a smart contract, and payment records could be
185
shared among all members. Sheng et al. [15] designed a construction quality chain based on blockchain technology, which
186
ensured the quality information would not be modified by a centralized party, enhancing trust among project members.
187
As for the integration of blockchain and BIM-based design, Winfield-Rock Report [40] indicated that blockchain shows
188
excellent potential to overcome many BIM adoption issues by providing consistent, change-resistant, and hack-resistant
189
design records. Nawari et al. [18] stated that blockchain could be advantageous in the BIM workflow by emphasizing network
190
security and reliable data storage. Elghaish et al. [41] asserted that the fusing of BIM and blockchain could easily trace all the
191
changes in three-dimensional (3D) models throughout the design and construction stages. Li et al. [45] recommended
192
leveraging blockchain to protect intellectual property, data ownership, and copyright in BIM-based design collaboration.
193
Current investigations of integrating blockchain with BIM-based design collaboration are limited to proposing
194
conceptual frameworks [46]. One obvious obstacle that has not been solved is that large-sized design files are not suitable for
195
being stored in blockchain due to the block size. However, methods that enable blockchain to secure both design files and
196
design changes have not been developed yet in the construction industry, this necessitates coupling blockchain with another
197
technology — InterPlanetary File System (IPFS).
198
9
199
Figure 3. Conceptual framework of blockchain
200
2.4 InterPlanetary File System (IPFS)
201
The problem of storing large-sized data necessitates that blockchain could be incorporated with another technique — the
202
InterPlanetary File System (IPFS) [24]. IPFS is a novel protocol that builds an addressable and peer-to-peer file storage system
203
without a centralized server [47,48]. More importantly, IPFS facilitates large-sized file storage in a distributed and verifiable
204
10
manner. Figure 4 shows how IPFS allows file storage among multiple peers [49]. Every file uploaded in the IPFS network
205
would be encrypted into a cryptographic hash value called content identifier (CID), the “address” or “hyperlink” of the file
206
(Figure 4 (a)). Other members who have the CID could access or download the file as shown in Figure 4 (b). In IPFS, every
207
peer is a “file sever”, enabling IPFS to store and share large volume of files with high throughput. Figure 4 (c) shows a peer
208
could access file from multiple data sources. This distributed manner prevents data from being manipulated by the central
209
administrator. The CID is also a proof for file integrity as CID would change with file content modification (Figure 4 (d)).
210
Thus, IPFS is regarded as a compelling building block in blockchain since it has great potential to solve the problem of
211
inefficient, bulky data storage in blockchain [24,25]. That is, peers can choose to store design files or documents in IPFS and
212
place CIDs into blockchain transactions to provide traceability and authenticity.
213
However, implementing the blockchain-IPFS integrated method in the design CDE still faces two challenges: (1) what
214
is the collaboration workflow of a CDE that integrating blockchain and IPFS and (2) how to exchange design information in
215
such CDE. As for the first challenge, very limited studies have explored which CDE container (s) should use blockchain and
216
what is the logic of collaborating in such a distributed environment. As for the second one, in a blockchain network, peers
217
exchange information via proposing transactions and invoking smart contracts. But the transaction data model and smart
218
contract satisfying CDE requirements have not been developed yet, hindering the communication among designers. Therefore,
219
this paper proposes a distributed CDE framework to solve mentioned problems.
220
11
221
Figure 4. Workflow of storing and downloading files in IPFS
222
3. Development of distributed common data environment (DCDE) framework
223
The development of a DCDE framework for collaborative BIM design is explained in this section. The main challenges
224
of developing the DCDE are to (1) explain the logic of how CDE could integrate with blockchain and IPFS to facilitate secure
225
and feasible design collaboration and (2) develop a transaction data model and smart contract compliant with CDE standards
226
to support DCDE functionalities. Figure 5 shows the methodology, which introduces methods and outputs of each step.
227
In Step 1, a DCDE framework is proposed (Section 3.1). This step explains (1) the logic of how a blockchain-IPFS
228
integrated approach could address the problem of design file storage and (2) the workflow of how multiple disciplines could
229
collaborate in a distributed CDE. Besides, mechanism of how the DCDE framework secures design data security is also
230
explained. Step 1 focuses on illustrating the concept of DCDE framework. Technical components (i.e., transaction data model
231
12
and smart contract) that support DCDE functionalities are developed in Step 2 and Step 3.
232
In Step 2, a transaction data model to record design changes is developed (Section 3.2). Requirements for blockchain
233
transaction data model are summarized from two aspects: (1) data model requirements of blockchain platform and (2) data
234
model requirements of design collaboration in CDE standards. Based on that, a transaction data model is developed to record
235
design changes in DCDE.
236
In Step 3, a smart contract for design changes sharing is developed (Section 3.3). Smart contract functions are
237
identified based on design activities in DCDE. Then, a smart contract is developed to share and query transactions (design
238
changes) to support design coordination.
239
240
Figure 5. Methodology of DCDE framework development
241
3.1 DCDE framework
242
A DCDE framework is proposed in Figure 6. This framework displays the logic and workflow of BIM-based
243
collaborative design in a distributed environment, where seven steps are involved:
244
(I) Upload design files to IPFS. A member of the design team, for example, an architect, develops an architectural BIM
245
model in work in progress (WIP) container using domain-specific software. After obtaining permission from the team
246
leader, the architect uploads the file to the IPFS network for collaborations to follow.
247
(II) Return file CID. A unique CID is returned to the architect.
248
(III) Share transaction in blockchain network. The architect then proposes a transaction containing necessary
249
13
collaboration information (e.g., the file CID, file version, ownership, etc.) to blockchain network through a smart
250
contract. The transaction would be packaged in a block (the green block in Figure 6) and be automatically
251
synchronized to all project members.
252
(IV) Download design file using CID. Another designer, for example, a structural engineer who wants to access and
253
reference the architectural model, can download the file from the IPFS network using the CID he has received in
254
Step III.
255
(V) Be the second file provider. After downloading the file, the structural designer, in this case, becomes the second file
256
provider in IPFS network.
257
(VI) Download file from either provider. Another peer in this framework, for example, the client, wants to check the
258
BIM model and to make some new design requests. He could download the file from either provider. After reviewing
259
the model, the client and structural designer would repeat steps I to III to upload feedback to the architect team. This
260
way, the IPFS and blockchain network, linked by the CIDs, form a distributed “SHARED” container for a continuous
261
collaboration process.
262
(VII) Change file status to PUBLISHED. At the end of the design phase, the client would approve all checked design
263
files used in downstream collaboration (e.g., construction and operation). Meanwhile, the statuses of the design files
264
would turn from “SHARED” to “PUBLISHED”.
265
Figure 7 shows the DCDE architecture, consisting of five layers: database, network, smart contract, WIP, and user. In
266
the database layer, each project member holds a blockchain ledger and an IPFS database. Design recodes (transactions) are
267
distributed in the blockchain, while large-sized design files (e.g., BIM models, No-graphical assets, and design issue
268
documents) are shared in the IPFS database. This layer functions as the single source of information as (1) it provides
269
unchangeable data storage for SHARED, PUBLISHED, and ARCHIVE containers and (2) members could access design data
270
shared by other design teams from here. In the network layer, each project member enrolls in both the blockchain network
271
and IPFS network. The smart contract layer offers smart contract functions and a consensus mechanism. Members could
272
invoke different functions to upload new or querying existing transactions. The consensus mechanism guarantees data
273
consistency by ensuring members receive transactions in the same order. In the user and WIP layers, members work locally
274
to build BIM models, detect clashes, and conduct design collaboration.
275
Figure 8 summarizes the mechanism of how the proposed DCDE solution can solve the mentioned security risks. First,
276
the problem of access denial in the centralization platform can be avoided since (1) there are multiple sources for design files,
277
(2) every peer owns a complete set of design records, and (3) peers are equivalent, and no single peer could control the whole
278
network. Besides, the DCDE protects data immutability in two aspects: (1) All the design recodes (i.e., transactions) are stored
279
14
in blockchain ledgers, which are unchangeable and traceable. (2) CIDs provide data integrity proof since modifying the file
280
content would lead to a different CID.
281
282
Figure 6. Distributed common data environment (DCDE) framework
283
284
15
285
Figure 7. Architecture of DCDE framework
286
287
288
Figure 8. Proposed DCDE solution solves two data security problems in BIM collaboration
289
16
290
3.2 Development of blockchain transaction data model
291
Blockchain transaction is the carrier that contains any kind of information that needs to be shared in a blockchain network
292
and record in the ledger. Developing an appropriate transaction data model for design information exchange is a challenge for
293
DCDE implementation. This study proposes an original transaction data model specific for BIM-based design collaboration
294
following three principles: (1) compatibility, (2) completeness, and (3) interoperability.
295
For compatibility requirement, the transaction data model must be compatible with selected blockchain platform. This
296
paper employs a private blockchain network, Hyperledger Fabric [50], as the blockchain platform. Hyperledger Fabric is
297
chosen due to following four reasons: (1) Hyperledger Fabric protects data privacy by allowing only authorized project
298
members to participate in and maintain the network [18]. (2) Hyperledger Fabric is a modular, extensible open-source platform
299
that users can customize according to their needs [50]. (3) Hyperledger Fabric can be implemented using standard, general-
300
purpose programming languages (e.g., Go, Java, and Node.js), thereby making it easier to develop [51]. (4) Several initial
301
explorations have demonstrated the applicability and feasibility of Hyperledger Fabric in the construction industry [15,41].
302
Hyperledger Fabric only accepts the transaction in key-value data model; thus, a key-value format transaction is proposed in
303
Figure 9. For example, if a structural designer finds clashes in the architectural model, he would file a clash report to DCDE.
304
Figure 9 shows information of a clash report whose key (file ID) is ISU001, and values (attributes) are name, version, and
305
CID, etc.
306
For completeness requirement, a transaction must provide complete collaborative design information for all participants.
307
For example, the clash report in Figure 9 is tied to a model with a specific version; thus, a “Dependent file” row is designed
308
to record which model and version this clash depends on or associated with. This method would enhance the efficiency and
309
accuracy of locating clashes in a BIM model.
310
For interoperability requirement, the transaction should be in an understandable, exchangeable, and compatible format
311
in a CDE workflow. Thus, items such as data version management and data status definition have complied with the ISO
312
19650 standards regulation. Table 1 explains the attributes and corresponding values in the transaction data model.
313
17
314
Figure 9. Illustration of the developed blockchain transaction data model
315
316
18
Table 1. Explanation of transaction data model
317
Attributes
Explanation of values
ID
It is the key of a transaction and the unique identifier for a file. Project members can use the
key to inquire the latest status of this file in the blockchain network. It would be used
throughout the whole design pross and would not be changed. The file ID is different from
file CID, which varies from file content modification.
Name
ISO 19650 standards offer conventions and optional fields for file naming. Project team can
choose fields (e.g., project name, originator, file domain, file type, and locations) they need
to make up the file name. In Figure 9, USTSH-ARCH-M3 means this is a Hong Kong
University of Science and Technology Sports Hall (USTSH) project file, and it represents a
3D model (3M) in the architecture domain. The file USTSH-ARCH-M3-CLASH shows it is
a clash report of an architecture document.
Version
ISO 19650 standards specify data versioning method in CDE. If the data is updated in the
internal WIP container, it should use a minor version change (e.g., from P01 to P01.1). When
the data is updated to the SHARED container, the revision code is updated to indicate a major
revision (e.g., from P01 to P02).
Ownership
ISO 19650 standards define that the ownership of information in CDE remains with the
originator.
From to
Who uploads this file, and who is the target receiver.
Status code
ISO 19650 standards define the status code to describe the suitability of the content of an
information container. Several codes that would be used in this study are listed:
In the SHARED container
● S1: Fit for coordination. The file is available to be shared with other disciplines.
● S3: Fit for internal review and comment. The file is used for transfer issues like
comments, reviews, and requests.
● S4: Fit for construction. The file is suitable for seeking approval from the client for
construction.
In the PUBLISHED container.
● A: Fit for construction. The file is suitable for construction.
Hash value (CID)
File CID generated by the IPFS network.
Dependent file
Another file that the previous file is depending on or associated with.
Dependent file hash
(CID)
Dependent file CID generated by the IPFS network.
Date
The date when this transaction is proposed.
3.3 Development of smart contract
318
A smart contract, or what Hyperledger Fabric calls a “chaincode”, functions as a trusted algorithm or computer program
319
that allows transactions to interact with the ledger automatically (e.g., broadcasting new transactions or executing payment
320
procedure) [50]. In this study, the development of smart contract involves two steps. Firstly, major activities of design
321
collaboration in DCDE are identified to determine functions that should be defined in the smart contract. Secondly, a smart
322
contract is developed accordingly.
323
Table 2 shows five major design activities in DCDE. Four (number 1 to 4) of them need to share file CID in the
324
blockchain network. Thus, an “UPLOAD” function is designed in the smart contract to facilitate transaction broadcasting.
325
19
The fifth activity queries existing transactions in blockchain ledger; therefore, an “INQUIRE” function is developed in the
326
smart contract for information querying.
327
Table 2. Identification of smart contract functions based on design activities in DCDE
328
Number
Design activities in
DCDE
Explanation
Function in smart
contract
1
New BIM model
sharing
⚫
A transaction that contains CID of a new BIM model
should be shared in blockchain network so that other
members could access this new model for clash detection or
reference design.
UPLOAD
2
BIM model version
updating
⚫
A transaction containing the CID of an updated BIM
model should be shared in blockchain network so that all
members could access the model in the lasted version.
UPLOAD
3
Design issue files
sharing
⚫
Design issues files include but are not limited to (1) files of
design changes in BIM collaboration format (BCF), (2) files
of Request for information (RFI), and (3) files of new design
requirement.
⚫
A transaction containing CID of a design issue file should
be shared in blockchain network so that other members
could understand what and where changes have been made
or what new design requirements have been raised.
UPLOAD
4
Contract documents
sharing
⚫
When collaborating in a CDE, new and updated contracts
need to be shared among design teams
⚫
A transaction containing CID of a contract should be
shared in blockchain network so that members could be
informed of the new contract terms.
UPLOAD
5
Design information
querying
⚫
All the transactions should be queried in blockchain
ledger in case of a dispute happens
INQUIRE
329
Figure 10 shows how a developed smart contract enables design transaction being stored and queried in blockchain.
330
When a project member (e.g., an architect designer) tries to share a transaction containing the CID of a new BIM model, he
331
would invoke the “UPLOAD” function in smart contract. In Step 1, the smart contract would send this transaction to pre-
332
execution members, who would check the legality of input parameters (i.e., function name and transaction data model). Illegal
333
parameters would be rejected, while legal transactions would be sent back to smart contract with signatures in Step 2. This
334
mechanism prevents incorrect transactions from clogging the network. In Step 3, the smart contract would send the transaction
335
with signatures to an ordering service, where all transactions during a certain time would be assembled into a new block. In
336
Step 4, the smart contract broadcasts the new block in blockchain network. Peers would verify this block and append it to
337
their local ledger. In Step 5, the smart contract generates a notification message to the initiator (i.e., architect designer) to
338
20
indicate a successful transaction sharing and storage.
339
For invoking INQUIRE function in Figure 10, project members only need to input the “key” of a design file and function
340
name. In Step 1, a smart contract would check whether the input key exists in the blockchain ledger. If yes, the smart contract
341
would query corresponding values (Step 1) and send them back (Step 2).
342
Pseudocode of smart contract algorithm is also developed and shown in Appendix. In short, this developed smart contract
343
satisfies function requirements in terms of BIM model updating, recording of design issues, document sharing, and design
344
information querying. Project members could conduct necessary design activities by invoking different smart contract
345
functions. Besides, as shown in Figure 10, this smart contract mechanism helps project members to reach a consensus by
346
ordering transaction sequences and verifying signatures, ensuring data consistency in the blockchain ledger.
347
21
348
Figure 10. Workflow of smart contract enabling sharing and querying design transaction in DCDE
349
4. Illustrative example
350
This section aims at (1) illustrating framework feasibility in a BIM-based collaborative design example and (2)
351
evaluating framework performance. Figure 11 shows the methodology.
352
22
Feasibility is verified by testing whether transactions could be successfully shared and whether multiple disciplines could
353
coordinate on design issues via a DCDE. To facilitate this, preparation works, including configuration of blockchain and IPFS
354
network, induction of project background, and standardization of design file formats, are conducted in Section 4.1. In Section
355
4.2, the DCDE is deployed in an illustrative design example with three scenarios.
356
Performance of framework could be evaluated through testing metrics like network latency to see whether the DCDE
357
performance is within an acceptable range. In Section 4.3, three metrics, namely (1) latency, (2) throughput, and (3) storage
358
cost, are measured. Latency is the time cost for sharing or querying a transaction in the DCDE network. High latency (in
359
minutes or even hours) would damage collaboration efficiency and members’ willingness to use such a system. Throughput
360
is the rate of processing design transactions. Low throughput is not acceptable as it indicates the DCDE cannot handle many
361
design transactions simultaneously. Calculating storage cost aims to ensure the blockchain ledger in DCDE would not add
362
additional data storage pressure to mem bers’ local databases. Network latency and throughput would be tested using
363
Hyperledger Tape, a benchmarked tool for the blockchain network. Blockchain storage cost is calculated based on block size
364
and amounts.
365
366
Figure 11. Methodology of framework illustration and evaluation
367
4.1 Illustration preparation
368
⚫ Configuration of blockchain and IPFS network. A Hyperledger Fabric network is configured with three organizations
369
(i.e., architectural design team, structural design team, and client team). Each organization is made up of two peers. They
370
are ARCH Peer 0, ARCH Peer 1, STRUCT Peer 0, STRUCT Peer 1, CLIENT Peer 0, and CLIENT Peer 1. Besides, an
371
IPFS desktop app is adopted to upload files and generate CIDs.
372
● Format of BIM model and issue file. The Hong Kong University of Science and Technology Sports Hall (USTSH)
373
23
BIM models are used in this example. USTSH BIM models are developed in Revit and shared with other disciplines in
374
Industry Foundation Class (IFC) formats. IFC is an open, international standard (ISO 16739-1:2018) that facilitates data
375
exchange across various hardware devices and software platforms in BIM-based collaborations [52,53]. Besides, BIM
376
Collaboration Format (BCF), also a buildingSMART International openBIM standard, is adopted for the design
377
collaboration as a medium that allows participants to communicate model-based issues such as clashes and new requests
378
[54]. A BCF file contains three components, namely, issue type, issue location, and issue snapshot. Thus, embedding the
379
BCF information into the BIM model allows designers to locate the place where the issue has arisen quickly and
380
accurately.
381
● BIM-related tools. In this example, the BIM model developed by Revit would be checked by structural designers and
382
clients using BIMcollab Zoom, an IFC-based model viewer in which users can check the model and add BCF issues
383
efficiently. After receiving BCF files from other participants, a BCF manager plugin in Revit would directly help the
384
designer lookup issues.
385
4.2 Illustration scenarios
386
Three scenarios are shown in Figure 12:
387
Scenario 1: Sharing a BIM model to start collaborative design. Checking participants’ access to the shared resources
388
within CDE is the priority task of collaboration [2]. In this trial, an architect would initiate e a transaction that contains a new
389
BIM model (M103-P01) CID to the blockchain network to (1) start a BIM-based collaborative design and (2) test connectivity
390
of the proposed DCDE framework.
391
Scenario 2: Conducting BIM-based Collaborative design among multiple teams. Multiple design teams perform
392
several collaborative actions to test whether the DCDE can provide a workable collaboration environment for communication
393
and model updating. Briefly, the structure team would check and modify a clash and propose a BCF issue (i.e., ISU001-P01)
394
to the architecture team for approval. The Client team would raise a design request issue (ISU002-P01) pertaining to the
395
USTSH architecture BIM model. After that, the architect would check these two BCF files and revise the model accordingly.
396
As a result, two issue files with the responses (i.e., ISU001-P02 and ISU002-P02) and a revised BIM model (M103-P02)
397
would be uploaded to DCDE for further collaboration.
398
Scenario 3: Changing BIM model status from SHARED to PUBLISHED to complete design phase. Design process
399
would come to an end when a BIM model file is transferred from a “SHARED” container to a “PUBLISHED” container in
400
CDE [2]. Thus, after multiple design iterations, the architect seeks approval from the client to change the status of the BIM
401
model (M103-P15) to “PUBLISHED”. In response, the client proposes an approved document (i.e., ISU001-P20), which
402
24
indicates the completion of the design phase.
403
404
Figure 12. Illustrative scenarios and objectives
405
4.2.1 Scenario 1: Sharing a BIM model to start collaborative design
406
This scenario involves two steps. First, the architect would propose a transaction to the DCDE network by invoking
407
smart contract. Second, if smart contract is successfully invoked, blockchain ledger status would be checked to ensure
408
everyone has received the new transaction. Figure 13 shows the process map of scenario 1. Specifically, an architect tends to
409
share the USTSH BIM model with the structure designer and client for reference design. As activity 1 in Figure 13 shows, he
410
uploads this model, whose file ID is M103 in version P01, to the IPFS network and to get its CID. Subsequently, this architect
411
prepares a transaction in which the model status code is S1, meaning this model fits sharing and coordination. He then invokes
412
the smart contract to upload this transaction.
413
Results in Figure 14 show that a new block containing the transaction has been delivered to every project member. Each
414
peer could (1) check the transaction (indexed by file key) information in blockchain ledger and (2) download the M103-P01
415
25
model using the CID stored in the block. Thus, the connectivity of the proposed DCDE framework has been validated.
416
417
Figure 13. Process map of scenario 1: Sharing a BIM model to start collaborative design
418
419
420
Figure 14. Results of scenario 1: Transaction in Activity 1 has been successfully shared
421
4.2.2 Scenario 2: Conducting BIM-based Collaborative design among multiple teams
422
This scenario aims at verifying that information exchange, model revision, and communication across multiple
423
disciplines should be smooth in proposed DCDE. Figure 15 shows the process map of scenario 2. In activity 2 (Figure 15), a
424
26
structural designer downloads the M103-P01 USTSH model as a reference for structural design work. However, when he
425
checks the model, a clash is detected on the third floor, where a column crosses a wall. Therefore, the structural engineers
426
check and modify the clash in the BIM model and validate its corresponding performance and structural integrity. Then, the
427
structure team prepares a clash issue file (ISU001-P01) for architect approval. A new transaction containing the issue CID
428
and the associated BIM model (i.e., M103-P01) CID is proposed. The file status code is S3, which means an issue file is used
429
for internal review and comments. This structure designer then invokes smart contract to share this transaction. This way, all
430
project members would receive the block and be notified.
431
Afterward, a client wants to change the type of window in the design. The client marks the location of a window and
432
prepares a request issue in BCF format. As shown in activity 3, a new transaction (ISU02-P01) containing the issue CID and
433
the associated model (i.e., M103-P01) CID is then proposed. This client then invokes smart contract to share this transaction
434
to notify all members there is a new design change request for M103-P01.
435
After receiving feedback from the structure designer, the architecture downloads the BCF file (ISU001-P01) from the
436
IPFS network and opens it using the BCF manager, a plugin in Revit. Activity 4 in Figure 15 shows that the BCF manager
437
plugin helps the architect locate the clash and associated modifications quickly. The architect responds to the clash issue
438
(ISU001-P01) that the clash modification is approved. Thus, a new version issue file (ISU001-P02) with the response from
439
the architect is generated. He then prepares a transaction that contains the CID of the updated issue file. This architect then
440
invokes smart contract to share the transaction.
441
Similarly, the architect changes the window type from Awing - 2L(AUS) AW2550 to Awing - 2L(AUS) AW0505, as
442
requested by the client. Then the architect files a response to the clash issue (ISU002-P01): that the requirement has been
443
fulfilled. Thus, an updated request issue file with the response of the architect is generated (ISU002-P02). As activity 5 in
444
Figure 15 shows, he prepares a transaction that contains the CID of the revised model (MI03-P02) and the issue file (ISU002-
445
P02). This architect invokes smart contract to share the transaction. This way, all participants would receive a new block and
446
be notified that all participants would receive a new block and be notified that the window type has been changed in the latest
447
version of the BIM model (M103-P03).
448
Figure 16 shows all transactions in scenario 2 have been successfully shared. In other words, four new blocks (or
449
transactions) have been delivered to every project member, and project members can check transaction information in
450
blockchain ledger. Thus, the proposed DCDE framework is proven to have the ability to provide a transparent communication
451
channel and a feasible collaborative design environment.
452
27
453
Figure 15. Process map of scenario 2: Conducting BIM-based Collaborative design among multiple teams
454
28
455
Figure 16. Results of scenario 2: Transactions of Activity 2 to Activity 5 have all been successfully shared
456
4.2.3 Scenario 3: Changing BIM model status from SHARED to PUBLISHED
457
At the end of the design phase in CDE, design files would be transferred from the “SHARED” container to the
458
“PUBLISHED” container with authorization from the client. After many design iterations, the architect team is ready to seek
459
approval for publishing. As shown in activity 6 in Figure 17, an architect prepares a transaction that contains the CID of the
460
latest BIM model, for example, version P15 and status S4 (this status code means that the file is now fit for publishing). This
461
architect then invokes to share this transaction to notify all project members the M103-P15 model is ready for the next status.
462
After checking the compliance of M103-P15 (e.g., model completeness and dimensional accuracy), the client team
463
approves the request from architect. As activity 7 in Figure 17, a client prepares a transaction that contains the CID of approval
464
document (ISU020-P01) and the CID of associated BIM model (M103-P15). The client then invokes smart contract to share
465
this decision. This way, all members would receive the new block and be notified that the status code of the issue file is A,
466
which means the information in this transaction is permitted to enter the “PUBLISHED” container and is fit for downstream
467
work (e.g., construction).
468
29
469
Figure 17. Process map of scenario 3: Changing BIM model status from SHARED to PUBLISHED
470
Figure 18 shows that two new transactions have been delivered to every project member. Figure 19 presents the current
471
status of the blockchain ledger, indicating the proposed DCDE framework facilitates a complete BIM collaborative design
472
process as the model can be successfully transferred to the “PUBLISHED” container.
473
474
Figure 18. Results of scenario 3: Transactions of Activity 6 and Activity 7 have all been successfully shared
475
30
476
Figure 19. Blockchain ledger status in DCDE after three scenarios illustration
477
4.3 Framework performance evaluation
478
Performance metrics of a blockchain network mainly include network latency, throughput, and storage cost [55]. The
479
followings are the testing conditions: (1) DCDE is developed based on a long-term supported Hyperledger Fabric version
480
(v1.4). The Hyperledger Fabric is deployed in an Ubuntu (Linux) system in version 16.04. (3) Three virtual machines (or
481
31
dockers) representing three design teams are built. Each virtual machine has an Intel(R) Core (TM) i5-9300H CPU and has
482
4GB RAM. (4) Hyperledger Tape (HT) [56], a lightweight benchmarked tool, is used to test latency and throughput of
483
Hyperledger Fabric blockchain. (5) Both latency and throughput would be tested ten rounds, each of which would generate
484
five blocks. Each block contains ten transactions. (6) For storage cost calculation, an assumption is made those 500 design
485
transactions are generated in a project per day and the DCDE should be able to process 10 transactions per second.
486
4.3.1 Latency and throughput
487
In this study, a round-trip time latency (time duration from sending a request to blockchain to receive confirmation from
488
blockchain) is calculated. HT tested latency by automatically invoking a smart contract developed in Section 3.3 to upload
489
and inquire transactions. The result of ten rounds of test is shown in Figure 20. Latencies of both uploading transactions
490
(153ms on average) and inquiring transactions (144ms on average) are relatively low and at a millisecond level. In other
491
words, the time it takes for project members to share or query design transactions in DCDE could be negligible.
492
For the throughput, transactions per second (TPS) and query per second (QPS) are measured to show how many
493
transactions the DCDE could handle (i.e., upload and inquire) in a second. Figure 21 shows test results, in which 64
494
transactions (in average) could be uploaded simultaneously per second, while 63 (in average) transactions could be queried
495
per second. Thus, it is reasonable to claim that this throughput could meet the requirements of most design work. It also should
496
be noted that latency and throughput would fluctuate with different network configurations.
497
498
Figure 20. Latency of uploading and inquiring design transactions in DCDE
499
32
500
501
Figure 21. Throughput of DCDE
502
4.3.2 Storage cost
503
The average size of the developed transaction is 179 B (Table 3). As ten transactions are packaged in a block, the size of
504
transaction data in a block is 1790 B. Sizes of other components (e.g., block header and Merkle tree) are relatively fixed as
505
shown in study [15]. Figure 22 presents the Merkle tree structure in DCDE. Each node contains a fixed-length hash string
506
(32Byte); thus, the total size of Merkle tree in DCDE is 32*19 = 608 Byte. Therefore, the total size of a block is 2.5 KB, as
507
shown in Table 4. 500 transactions would be stored in 50 blocks. If 50 blocks are generated per day, each member's storage
508
cost is approximate 12.5 KB, within an acceptable range.
509
510
33
Table 3. Size of a design transaction
511
Item
Data type
Size (Byte)
ID
Varchar
7B
Name
Varchar
23B
Version
Varchar
5B
Ownership
Varchar
6B
From to
Varchar
13B
Status code
Varchar
3B
Hash value (CID)
Varchar
47B
Dependent file
Varchar
14B
Dependent file hash (CID)
Varchar
47B
Date
Varchar
14B
Total
179B
512
513
Table 4. Size of a block in DCDE
514
Item
Size (Byte)
Header
Hash of previous block
32B
Hash of current block
32B
Merkle root
32B
Timestamp
15B
Merkle tree
Hash number
608B
Transaction data
Transactions of design records
1790B
(179*10)
Total
2509B
515
34
516
Figure 22. Merkle tree structure in DCDE
517
5. Discussion
518
Novelty of this study could be summarized as:
519
⚫ Proposing a blockchain-IPFS integrated DCDE framework. The blockchain-IPFS integrated solves large-sized
520
design file storage when collaborating in blockchain and provides a secure BIM-based collaborative design process. (1)
521
Both blockchain and IPFS technologies employ cryptographic hash, a one-way encryption method that can convert “plain
522
text” data into “cyphertext” data (a unique hash value) irreversibly, to facilitate the data immutability. Blockchain
523
provides immutable design records storage, while the IPFS provides data integrity proof for design files. (2) The DCDE
524
framework adopts distributed data storage to avoid data being manipulated by a centralized administrator, who may
525
cause a denial of access. Doing so has such advantages as project members in DCDE are equivalent and can access
526
multiple sources. Besides, there are multiple design records as every member holds a complete set of blockchain ledger.
527
⚫ Developing key technical components to support a feasible DCDE framework. (1) An original transaction data model
528
is designed to enable design information exchange in blockchain network. The transaction provides comprehensive
529
collaboration information so that designer can quickly and accurately identify what happens to which model. The
530
transaction design follows the ISO 19650 standards and the blockchain data format requirement to achieve a compatible
531
application. (2) A practical smart contract algorithm is developed to manage design information in blockchain ledger.
532
This algorithm supports project members to upload new transactions or inquire existing information in blockchain ledger.
533
⚫ Extending blockchain applications in the construction industry. This paper advances the concept of blockchain in
534
the construction industry from two perspectives: (1) It is one of the very first research to implement blockchain to CDE
535
35
for a secure and trusted BIM-based design collaboration; (2) This paper also extends existing research by moving beyond
536
theoretical blockchain models to a workable solution in the construction industry.
537
Possible practical impacts are:
538
⚫ Maximizing trust to stimulate collaboration. One key challenge facing BIM-based collaboration is the lack of trust
539
among project members, who may be afraid to lose ownership of their BIM data or BIM data being illegally modified.
540
Thus, they tend to keep BIM data privately in their domain and reluctant to collaborate [14]. DCDE framework provides
541
unchangeable data storage to facilitate a trustworthy collaboration environment, where project members will be more
542
confident to exchange information, thereby enhancing project efficiency. Moreover, blockchain guarantees authenticity
543
and traceability of project data without requiring an intermediary, reducing time and costs in providing data proofs for
544
disputes or payments.
545
⚫ Promoting digitalization in the construction industry. The adoption of blockchain in CDE shows that blockchain
546
could serve as a fundamental technology for data storage. Blockchain can remove some barriers (e.g., data manipulation
547
and denial of access) that exist in the adoption of other information technologies (e.g., BIM, IoT, and GIS), accelerating
548
the rate of digital transformation of the construction industry. Besides, integrating blockchain with other technologies
549
offers a new idea for the industry to develop “decentralized” AECO software applications and systems. In this way, what
550
digital information needs to be shared, how many members could participate, and what other technologies would be
551
integrated are highly customizable within a blockchain network, without restrictions from a third-party vendor. As a
552
result, the threshold of digital collaboration is lowered.
553
6. Conclusion
554
An immutable data storage and reliable data access security are desired in the AEC industry to secure collaborative
555
design. Therefore, a distributed common data environment (DCDE) framework for collaborative BIM design is proposed,
556
leveraging blockchain and InterPlanetary File System (IPFS). Three research objectives have been achieved in this study.
557
Firstly, a DCDE framework that uses blockchain to guarantee data security of design changes is proposed. Large-sized design
558
files are placed in IPFS and linked to a blockchain via files integrity identifier—CIDs. Secondly, technical components are
559
developed to support DCDE functionalities. A transaction data model is developed so that design changes could be recorded
560
in an interoperable format. This study also developed a smart contract to share design transactions in DCDE to facilitate
561
design coordination. Lastly, framework feasibility and performance are illustrated in a design example. Results show that (1)
562
multidisciplinary design teams could coordinate via a DCDE and (2) performance metrics (i.e., latency, throughput, and
563
storage cost) of the developed DCDE framework are within a reasonable range. The proposed DCDE framework has been
564
36
illustrated and evaluated in an example that was developed based on real-world project scenarios. The framework has also
565
been presented to industry practitioners and engineers, who have provided positive feedback on the framework, especially on
566
the satisfaction of industry practices and requirements of a typical CDE.
567
This study is not free from limitation. One uncertainty is that this paper evaluates the performance of a DCDE with six
568
peers with nine design transactions. However, in a real project with tens of participants and thousands of design transactions,
569
the latency may vary. Thus, network optimization solutions are worthy of developing in the future when applying the DCDE
570
in contraction projects for full implementation. Besides, usage of the current DCDE framework could also be a task for project
571
members as it is developed in a Linux Ubuntu system and operated using command lines in a terminal. A DCDE system with
572
a user-friendly interface and easy operations is needed and will be developed.
573
Acknowledgement
574
The authors would like to thank the Innovation and Technology Fund, HKSAR (No. ITP/052/20LP) for providing partial
575
support to this research. The authors declare that they have no known competing financial interests or personal relationships
576
that could have appeared to influence the work reported in this paper.
577
578
37
Appendix
579
580
Appendix figure 1. Pseudocode of smart contract algorithm
581
Reference
582
[1] C. Argiolas, N. Dessì, M.G. Fugini, B. Pes, Enabling secure and collaborative document sharing in
583
BIM processes, Information sciences and systems Springer, 2016, pp. 393-402 DOI:
584
https://doi.org/10.1007/978-3-319-22635-4_36
585
[2] ISO, Organization and digitization of information about buildings and civil engineering works,
586
including building information modelling (BIM) — Information management using building
587
information modelling — Part 1: Concepts and principles, (2018), p. 34 URL:
588
Algorithm of invoking UPLOAD function in smart contract
Input: transaction data, function name
Output: New transaction in blockchain ledger
Step 1: Smart contract proposes a transaction to pre-execution peers to validate inputs legality
if transaction data model = key-value format
function name = UPLOAD
return signatures of pre-execution peers
else
validation false
Step 2: Smart contract sends transaction with signatures to an ordering service
Step 3: Ordering service generates a new block
New block
Transaction data||signatures||block hashes||Merkle tree||timestamp
Step 4: Every member verifies and adds the block to blockchain ledger
New block
→
existing blockchain ledger
Step 5: Smart contract sends back a notification message to the initiator
if step 4 successes
return notification message
“
transaction has been successfully shared”
else
transaction sharing false
End
Algorithm of invoking INQUIRE function in smart contract
Input: key (ID) of a design file, function name
Output: corresponding values of design file
Step 1: Smart contract checks legality of file key and function name
if a file key exists in the existing ledger
function name = INQUIRE
return inputs are validated
else
Inquire false
Step 2: Smart contract queries and gets corresponding file value in blockchain ledger
Inquire results
values of design file
End
38
https://www.iso.org/standard/68078.html
589
[3] ISO, Organization and digitization of information about buildings and civil engineering works,
590
including building information modelling (BIM) — Information management using building
591
information modelling Part 5: Security-minded approach to information managem, (2020), p. 43
592
URL: https://www.iso.org/standard/74206.html
593
[4] C. Preidel, A. Borrmann, C. Oberender, M. Tretheway, Seamless integration of common data
594
environment access into BIM authoring applications: The BIM integration framework, European
595
conference on product and process modelling, Vol. 11, Limassol, Cyprus, 2015 DOI:
596
https://doi.org/10.13140/RG.2.1.4487.4488
597
[5] T. El-Diraby, T. Krijnen, M. Papagelis, BIM-based collaborative design and socio-technical analytics
598
of green buildings, Automation in Construction, 82 (2017), pp. 59-74 DOI:
599
https://doi.org/10.1016/j.autcon.2017.06.004
600
[6] M. Oh, J. Lee, S.W. Hong, Y. Jeong, Integrated system for BIM-based collaborative design,
601
Automation in Construction, 58 (2015), pp. 196-206 DOI:
602
https://doi.org/10.1016/j.autcon.2015.07.015
603
[7] Autodesk, BIM360, Available at: https://www.autodesk.com/bim-360/, Last accessed on 23 July 2020
604
[8] CYPE, BIMserver center, Available at: https://bimserver.center/en, Last accessed on Aug 30 2020
605
[9] A.-M. Mahamadu, L. Mahdjoubi, C. Booth, Challenges to BIM-cloud integration: Implication of
606
security issues on secure collaboration, 2013 IEEE 5th International conference on cloud computing
607
technology and science, Vol. 2, IEEE, Bristol, UK, 2013, pp. 209-214 DOI:
608
https://doi.org/10.1109/CloudCom.2013.127
609
[10] M. Das, X. Tao, J.C.P. Cheng, BIM security: A critical review and recommendations using encryption
610
strategy and blockchain, Automation in Construction, 126 (2021), p. 103682 DOI:
611
https://doi.org/10.1016/j.autcon.2021.103682
612
[11] E.A. Parn, D. Edwards, Cyber threats confronting the digital built environment, Engineering,
613
Construction and Architectural Management, (2019) DOI: https://doi.org/10.1108/ECAM-03-2018-
614
0101
615
[12] H. Boyes, Building Information Modelling (BIM): Addressing the cyber security issues, The
616
Institution of Engineering and Technology, (2014) URL: https://www.theiet.org/impact-
617
society/factfiles/built-environment-factfiles/bim-cyber-security/
618
[13] F. Elliott, The first reported UK BIM case: Trant v Mott MacDonald, Available at:
619
https://www.fenwickelliott.com/research-insight/annual-review/2017/uk-bim-trant-mott-macdonald,
620
Last accessed on Nov 17 2020
621
[14] J. Li, D. Greenwood, M. Kassem, Blockchain in the built environment and construction industry: A
622
systematic review, conceptual models and practical use cases, Automation in Construction, 102 (2019),
623
pp. 288-307 DOI: https://doi.org/10.1016/j.autcon.2019.02.005
624
[15] D. Sheng, L. Ding, B. Zhong, P.E. Love, H. Luo, J. Chen, Construction quality information
625
management with blockchains, Automation in Construction, 120 (2020), p. 103373 DOI:
626
https://doi.org/10.1016/j.autcon.2020.103373
627
[16] Z. Wang, T. Wang, H. Hu, J. Gong, X. Ren, Q. Xiao, Blockchain-based framework for improving
628
supply chain traceability and information sharing in precast construction, Automation in Construction,
629
111 (2020), p. 103063 DOI: https://doi.org/10.1016/j.autcon.2019.103063
630
[17] M. Das, H. Luo, J.C. Cheng, Securing interim payments in construction projects through a blockchain-
631
based framework, Automation in Construction, 118 (2020), p. 103284 DOI:
632
https://doi.org/10.1016/j.autcon.2020.103284
633
[18] N.O. Nawari, S. Ravindran, Blockchain technology and BIM process: review and potential
634
applications, ITcon, 24 (2019), pp. 209-238 URL: https://www.itcon.org/paper/2019/12
635
[19] R. Zheng, J. Jiang, X. Hao, W. Ren, F. Xiong, Y. Ren, bcBIM: A blockchain-based big data model for
636
BIM modification audit and provenance in mobile cloud, Mathematical Problems in Engineering, 2019
637
(2019) DOI: https://doi.org/10.1155/2019/5349538
638
[20] Z. Liu, L. Jiang, M. Osmani, P. Demian, Building information management (BIM) and blockchain
639
(BC) for sustainable building design information management framework, Electronics, 8 (7) (2019),
640
p. 724 DOI: https://doi.org/10.3390/electronics8070724
641
39
[21] F. Xue, W. Lu, A semantic differential transaction approach to minimizing information redundancy for
642
BIM and blockchain integration, Automation in Construction, 118 (2020), p. 103270 DOI:
643
https://doi.org/10.1016/j.autcon.2020.103270
644
[22] N.O. Nawari, S. Ravindran, Blockchain and building information modeling (BIM): Review and
645
applications in post-disaster recovery, Buildings, 9 (6) (2019), p. 149 DOI:
646
https://doi.org/10.3390/buildings9060149
647
[23] IPFS, IPFS, Available at: https://ipfs.io/, Last accessed on 10th May 2020
648
[24] M. Steichen, B. Fiz, R. Norvill, W. Shbair, R. State, Blockchain-based, decentralized access control
649
for IPFS, 2018 IEEE International conference on Internet of Things and IEEE green computing and
650
communications and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data,
651
IEEE, Halifax, Canada, 2018, pp. 1499-1506 DOI:
652
https://doi.org/10.1109/Cybermatics_2018.2018.00253
653
[25] E. Nyaletey, R.M. Parizi, Q. Zhang, K.-K.R. Choo, BlockIPFS-blockchain-enabled interplanetary file
654
system for forensic and trusted data traceability, 2019 IEEE International conference on blockchain
655
(Blockchain), IEEE, Atlanta, USA,, 2019, pp. 18-25 DOI:
656
https://doi.org/10.1109/Blockchain.2019.00012
657
[26] L. van Berlo, T. Krijnen, Using the BIM collaboration format in a server based workflow, Procedia
658
Environmental Sciences, 22 (2014), pp. 325-332 DOI: https://doi.org/10.1016/j.proenv.2014.11.031
659
[27] A.J. Zada, W. Tizani, A. Oti, Building information modelling (BIM)—Versioning for collaborative
660
design, Computing in Civil and Building Engineering (2014), 2014, pp. 512-519 DOI:
661
https://doi.org/10.1061/9780784413616.064
662
[28] M.T. Shafiq, J. Matthews, S. Lockley, A study of BIM collaboration requirements and available
663
features in existing model collaboration systems, ITcon, 18 (2013), pp. 148-161 URL:
664
https://www.itcon.org/paper/2013/8
665
[29] F. Liu, A.K. Jallow, C.J. Anumba, D. Wu, A framework for integrating change management with
666
building information modeling, Computing in Civil and Building Engineering (2014), 2014, pp. 439-
667
446 DOI: https://doi.org/10.1061/9780784413616.055
668
[30] V. Moayeri, O. Moselhi, Z. Zhu, Design change management using a BIM-based visualization model,
669
International Journal of Architecture, Engineering and Construction, 6 (2015), pp. 1-11 DOI:
670
http://dx.doi.org/http://dx.doi.org/10.7492/IJAEC.2017.001
671
[31] S. Logothetis, E. Karachaliou, E. Valari, E. Stylianidis, Open source cloud-based technologies for
672
BIM, The International Archives of the Photogrammetry, Remote Sensing and Spatial Information
673
Sciences, Riva del Garda, Italy, 2018, pp. 4-7 DOI: https://doi.org/10.5194/isprs-archives-XLII-2-607-
674
2018
675
[32] J. Radl, J. Kaiser, Benefits of implementation of common data environment (CDE) into construction
676
projects, World multidisciplinary civil engineering, architecture, urban planning symposium, Vol. 471,
677
Institute of Physics Publishing, Prague, Czech public, 2019, p. 22021 DOI:
678
https://doi.org/10.1088/1757-899X/471/2/022021
679
[33] S. Mordue, Implementation of a common data environment: The benefits, challenges & considerations,
680
Edinburgh (2018), p. 32 URL: https://iopscience.iop.org/article/10.1088/1757-899X/471/2/022021
681
[34] Graphisoft, BIMcloud, Available at: https://graphisoft.com/solutions/products/bimcloud, Last
682
accessed on 23 July 2020
683
[35] Rafael Sacks, Charles Eastman, Ghang Lee, P. Teicholz, BIM handbook: A guide to building
684
information modeling for owners, designers, engineers, contractors, and facility managers, John Wiley
685
& Sons, 2018 DOI: https://doi.org/10.1002/9781119287568
686
[36] M. Aljarman, H. Boussabaine, K. Almarri, Emerging technical risks from the application of building
687
information modelling, Journal of Facilities Management, (2020) DOI: https://doi.org/10.1108/JFM-
688
12-2019-0063
689
[37] M. Das, X. Tao, J.C. Cheng, A secure and distributed construction document management system using
690
blockchain, International Conference on Computing in Civil and Building Engineering, Springer,
691
2020, pp. 850-862 DOI: https://doi.org/10.1007/978-3-030-51295-8_59
692
[38] J. Wang, P. Wu, X. Wang, W. Shou, The outlook of blockchain technology for construction engineering
693
management, Frontiers of Engineering Management, (2017), pp. 67-75 DOI:
694
40
https://doi.org/10.15302/J-FEM-2017006
695
[39] M. Risius, K. Spohrer, A blockchain research framework, Business & Information Systems
696
Engineering, 59 (6) (2017), pp. 385-409 DOI: https://doi.org/10.1007/s12599-017-0506-0
697
[40] M. Winfield, The winfield rock report: Overcoming the legal and contractual barriers of BIM, UKBIM
698
alliance, (2018), pp. 1-60 URL: https://www.ukbimalliance.org/project/winfield-rock-report/
699
[41] F. Elghaish, S. Abrishami, M.R. Hosseini, Integrated project delivery with blockchain: An automated
700
financial system, Automation in Construction, 114 (2020), p. 103182 DOI:
701
https://doi.org/10.1016/j.autcon.2020.103182
702
[42] R. Yang, R. Wakefield, S. Lyu, S. Jayasuriya, F. Han, X. Yi, X. Yang, G. Amarasinghe, S. Chen, Public
703
and private blockchain in construction business process and information integration, Automation in
704
Construction, 118 (2020), p. 103276 DOI: https://doi.org/10.1016/j.autcon.2020.103276
705
[43] D. Lee, S.H. Lee, N. Masoud, M. Krishnan, V.C. Li, Integrated digital twin and blockchain framework
706
to support accountable information sharing in construction projects, Automation in Construction, 127
707
(2021), p. 103688 DOI: https://doi.org/10.1016/j.autcon.2021.103688
708
[44] C.Z. Li, Z. Chen, F. Xue, X.T. Kong, B. Xiao, X. Lai, Y. Zhao, A blockchain-and IoT-based smart
709
product-service system for the sustainability of prefabricated housing construction, Journal of Cleaner
710
Production, 286 (2021), p. 125391 DOI: https://doi.org/10.1016/j.jclepro.2020.125391
711
[45] J. Li, M. Kassem, A. Ciribini, M. Bolpagni, A proposed approach integrating DLT, BIM, IOT and smart
712
contracts: Demonstration using a simulated installation task, 2019 International conference on smart
713
infrastructure and construction ICE Publishing, Cambridge, UK, 2019, pp. 275-282 DOI:
714
https://doi.org/10.1680/icsic.64669.275
715
[46] T. Dounas, D. Lombardi, W. Jabi, Towards Blockchains for architectural design-Consensus
716
mechanisms for collaboration in BIM, 37th Education and research in computer aided architectural
717
design in Europe and XXIII iberoamerican society of digital graphics, joint conference São Paulo,
718
Brazil, 2019 DOI: https://doi.org/10.5151/proceedings-ecaadesigradi2019_296
719
[47] S. Muralidharan, H. Ko, An InterPlanetary file system (IPFS) based IoT framework, 2019 IEEE
720
International conference on consumer electronics IEEE, Las Vegas, USA, 2019, pp. 1-2 DOI:
721
https://doi.org/10.1109/ICCE.2019.8662002
722
[48] J. Benet, InterPlanetary File System (IPFS), Available at: https://ipfs.io/, Last accessed on 1 Aug 2020
723
[49] N. Nizamuddin, K. Salah, M. Ajmal Azad, J. Arshad, M.H. Rehman, Decentralized document version
724
control using ethereum blockchain and IPFS, Computers & Electrical Engineering, 76 (2019), pp. 183-
725
197 DOI: https://doi.org/10.1016/j.compeleceng.2019.03.014
726
[50] Linux, Hyperledger Fabric, Available at: https://www.hyperledger.org/use/fabric, Last accessed on 1
727
Aug 2020
728
[51] P. Yuan, X. Xiong, L. Lei, K. Zheng, Design and implementation on hyperledger-based emission
729
trading system, IEEE Access, 7 (2018), pp. 6109-6116 DOI:
730
https://doi.org/10.1109/ACCESS.2018.2888929
731
[52] buildingSMART, Industry foundation classes (IFC) - An introduction, Available at:
732
https://technical.buildingsmart.org/standards/ifc, Last accessed on 10 Aug 2020
733
[53] S. Tang, D.R. Shelden, C.M. Eastman, P. Pishdad-Bozorgi, X. Gao, BIM assisted building automation
734
system information exchange using BACnet and IFC, Automation in Construction, 110 (2020), p.
735
103049 DOI: https://doi.org/10.1016/j.autcon.2019.103049
736
[54] buildingSMART, BIM collaboration format (BCF) – An introduction, Available at:
737
https://technical.buildingsmart.org/standards/bcf/, Last accessed on 10 Aug 2020
738
[55] X. Li, L. Wu, R. Zhao, W. Lu, F. Xue, Two-layer Adaptive Blockchain-based Supervision model for
739
off-site modular housing production, Computers in Industry, 128 (2021), p. 103437 DOI:
740
https://doi.org/10.1016/j.compind.2021.103437
741
[56] S. Yuan, Hyperledger Tape, Available at: https://github.com/Hyperledger-TWGC/tape, Last accessed
742
on 20 March 2021
743
744