Blockchain-Based Implementation of Building Information Modeling Information Using Hyperledger Composer

Abstract

With the advancement of Building Information Modeling (BIM) technology, BIM gains more importance and becomes a prerequisite in building projects. BIM is useful throughout a building lifecycle; from building bid, design, construction, completion, operation, and maintenance to building demolition. However, current information exchange surrounding BIM is still limited and bound to a single participant or organization and is also limited to a particular phase in the building lifecycle. This paper aims to explore BIM information exchange among many parties involved in a secure manner using a blockchain platform throughout the whole building lifecycle. In this research, many parties involved in the building project will be able to recognize one another through deployment of a permissioned blockchain. This information exchange uses Hyperledger Composer, a permissioned blockchain running on a blockchain platform called Hyperledger Fabric. Our experiment shows that BIM information exchange could be further improved. In this study, BIM information exchange can be implemented not only in one building phase but throughout the whole building lifecycle. It also facilitates BIM information exchange among multiple participants in a secure manner via a permissioned blockchain.

1. Introduction

Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility, creating a shared knowledge resource of information about it and forming a reliable basis for decisions during its lifecycle, from earliest conception to demolition [1,2]. BIM is considered an ideal digital tool for digitally representing the data repository of all information relating to the building lifecycle [3]. BIM is likely to enhance building Life Cycle Assessment (LCA) by managing databases, reducing complexity, improving adaptability to changes, and improving communication and collaboration. LCA is the assembly and estimation of the inputs, outputs, and potential environmental impacts of a building throughout its lifecycle [1]. BIM is also used to calculate Life Cycle Cost (LCC), which is an asset cost or parts of an asset cost throughout a building lifecycle. The LCC should be estimated first to evaluate the economic efficiency of a building, considering all cost elements. In some countries, building projects use BIM software as a requirement. Thus, BIM becomes an essential part of building projects.

BIM saves building-related information throughout a building lifecycle. However, BIM is most often applied at the beginning of design phases, with less use towards the later stages of a building project lifecycle [1,2,3,4]. During this later phase, BIM information is communicated to other (external) parties/companies in limited ways through meetings, emails, and reports. Other parties/companies cannot see BIM information directly. Moreover, other parties do not receive all BIM information, and they probably will not be able obtain it at the same time. Building contractors also mostly use BIM internally in a centralized manner.

In a building lifecycle, first, a building owner conducts a building project tender that building contractors participate in by sending building proposals that include BIM information. Then, the building owner will announce the building project winner who will submit a building design proposal to the building owner. Until the building owner is satisfied with the building design, the building contractor winner will keep reiterating the building design. Once the building owner approves the preliminary design, the building contractor will start the building development, and there will be design changes throughout this phase. Then, the building will enter a building completion stage, and building maintenance will start. The building maintenance phase will persist until there is a need to demolish the building. During building maintenance, Facility Management will update the BIM information.

Currently, one potential way to improve BIM information usage efficiency is to overcome the limitation in BIM information exchange so that it is accessible to all parties involved in the project. On the other hand, it also needs to limit the access of some unrelated parties to BIM. We propose that BIM information could be implemented for the entire building lifecycle and stored in a secured permissioned blockchain. This will also provide a way to access BIM information for many involved parties/organizations—such as building designers, contractors, engineers, architects, and demolition companies—in the entire building lifecycle in a secure manner. A blockchain, in the permissioned model, typically establishes identities and forms a consortium [5]. A permissioned blockchain adds a layer of privileges to decide who can participate in the network system; these parties will not have a chance to commit fraud as the management server exposes their identities [6]. In addition, only specific entities are authorized to use, validate, and access a blockchain [7,8]. This paper aims to explore how a permissioned blockchain framework called Hyperledger Composer runs on a blockchain platform called Hyperledger Fabric. It implements BIM information throughout the building lifecycle and allows secured information exchange among multiple parties. The remainder of the paper is organized as follows: Section 2: Material and Method; Section 3: Result; Section 4: Evaluation of Result; Section 5: Conclusion.

2. Material and Method

2.1. Blockchain

A blockchain is a distributed ledger that records all transactions, such as storage and asset transfer, which take place in a safe, chronological, and unalterable way using peer-to-peer networking protocols. It does not depend on a trusted central authority to validate transactions and extend the blockchain [9]. Blockchains provide a transparent, immutable, and consistent data store [10].

Blockchains have the following characteristics:

• Transparency

Data stored on a blockchain are accessible to all participants within the blockchain network [10].

• Decentralization

Blockchain transactions are peer-to-peer, without central authorization. Decentralization promotes data confidentiality by shielding interactions and communication from third parties and encouraging data sovereignty, giving the user control over their data [11,12,13].

• Persistency

Persistency guarantees a consistent system response of a transaction state. As an illustration: if one network node reports a stable condition, then the other network node should also state as stable when queried and reacted to honestly. Persistency warrants that when a transaction is appended to a block that is located deep in the blockchain of an honest node, this transaction will ultimately be contained in every authentic blockchain node in the network, with high probability [12,13,14].

• Anonymity

Without revealing real user identities, transactions related to users cannot be linked [12,13,14]. Transactions are the atomic data structure of a blockchain. Typically, a set of users/participants create a transaction to indicate the transfer of tokens from the sender to the specified receivers. The functionalities of cryptographic hashing and asymmetric encryption are activated to protect the authenticity of a transaction record [15].

2.2. Hyperledger Composer and Hyperledger Fabric

Hyperledger Composer is a Linux Foundation project that is well known and advancing rapidly. It is an open-source development tool that provides a framework to develop blockchains quickly [16,17]. Thus, users can cut down the development time from months to weeks [17]. Hyperledger Composer allows anyone to contribute to the project as one of many benefits.

Hyperledger Composer is a modeling language that is simple and area-specific to model business networks. The model file can use any available development platforms, while JavaScript is used to implement the blockchain transaction logic shown in Figure 1. Hyperledger Composer is a web-based tool that provides support for development, packing, and testing phases. It also supports writing scripts.

Hyperledger Composer can contain many Business Network Archives (.bna). Each .bna file consists of a Model file (.cto), a Script file (.js), and an Access Control file (.acl). A Model file specifies blockchain items such as participant, transaction, and asset. A Script file defines the transaction logic, and it is invoked during the submission of a transaction. An Access Control file specifies access rules for business network items [13]. Then, there are two types of Business Network Archive deployments. It can be deployed in Hyperledger Fabric or via Web Browser [16,18]. Hyperledger Composer’s framework also provides a flexible development platform, an object-oriented programming language to define Assets, and a JavaScript engine to create Smart Contracts [19].

Hyperledger Composer runs on top of Hyperledger Fabric, which provides developers tools to create permissioned blockchain solutions. Hyperledger Fabric provides an implementation of permissioned blockchains [6,20] and the infrastructure to develop its network. In Hyperledger Fabric, business network participants can specify a policy to validate blockchain transactions by using an alterable blockchain consensus protocol. The business network includes participants who interact with them. Each participant can be associated with a unique identity across several different business networks [17]. In Hyperledger Fabric, one has to obtain credentials to read the ledger or write in it. The participants that are allowed to read or write to the ledger are called peers. Thus, it is easier to control the transactions on the ledger and it has higher system throughput [21,22,23]. Hyperledger Fabric secures the interactions among a group of authorized participants to preserve privacy and confidentiality [22]. A Hyperledger Fabric network consists of the following elements:

• Peer

Each network node executes chaincode and receives transactions from external client applications through the Hyperledger Fabric API. Every node’s identity on a Hyperledger Fabric network is presented by a membership service provider (MSP) [24].

• Ledger

A ledger is a collection of ordered blocks that contain transactions.

• Channel

Organizations can communicate through a channel that offers isolation and privacy. Each channel consists of only one ledger, and that ledger exists only on that channel.

• Orderers

An orderer gathers transactions from all Hyperledger Fabric channels in a blockchain network. Orderers generate blocks and validate transactions in channels issued by a network administrator.

• Consortiums

A consortium gives organizations the capability to produce agreements on which policies will be followed to validate blocks [19].

2.3. Methods

First, we define the phases in a building lifecycle with BIM attached to each stage. The stages are Bidding, Development, Maintenance, and Demolition. Then, we determine the functional needs, as follows:

• To store BIM information.
• To store BIM status.
• To ensure there is BIM information for each building phase.
• To monitor building status.

Then, in the design stage, we design a workflow for exchanging BIM information among multiple parties involved in each phase of the building lifecycle. The Use Case Diagram, which is one component of the Unified Modeling Language (UML), is implemented to model the behavioral aspect of a system. UML is a modeling language with a semiformal syntax and semantics [25]. It is a suitable development model and is used to capture functional requirements [26]. It supports modeling a wide range of component interaction paradigms and addresses the overall system behavior in a usage scenario [25].

Then, we implement Hyperledger Composer Business Network Archive (BNA) elements that define and determine the capabilities of storing BIM information on the blockchain platform [27]. A BNA file consists of the following parts:

a.

Participants

Participants are the involved parties throughout the blockchain network.

b.

Assets

Assets are the data that are kept and exchanged in a blockchain network.

c.

Transaction

Transactions are the business logic or smart contracts of the system that specify the certain conditions or clauses of the contract.

d.

Access Controls

Access Controls determine participants’ access to the blockchain network based on their roles in the transaction types executed therein.

3. Result

Figure 2 shows the system flow using blockchains for exchanging BIM information. A Building Contractor submits a building proposal to the Building Owner, and the Building Owner determines the Building Contractor winner. This activity will be verified and recorded in a blockchain along with BIM information. Then, upon the completion of building construction by the Building Contractor, the Building Maintenance (Facility) Manager will take over control from the Building Contractor. It will make the necessary changes to BIM information to keep it updated. Afterward, when the building needs to be demolished, the Facility Manager will hand BIM information over to Demolition Experts. These experts will ask for a building demolition approval from the Building Owner. All these building lifecycle activities will be verified and recorded in the blockchain.

3.1. Use-Case Diagram

The Use-Case Diagram in Figure 3 is a behavioral model for information systems for exchanging BIM information. The diagram consists of five parties relevant to the building lifecycle, such as: Building Owner, Building Contractor, Building Maintenance Manager, Building Demolition Expert, and Network Admin. Each party has their use case, e.g., the Building Owner can open a building bid and see the bidding details; the Building Contractor can design and construct a building using BIM; the Building Maintenance Manager can maintain the completed building; the Building Demotion Expert can demolish a building upon approval from the Building Owner. A Network Admin can manage all activities and give access to each individual party.

3.2. Hyperledger Business Network Archive

After we create the system flow, we create a few components that form the Hyperledger Business Network Archive as follows:

3.2.1. Participant

Table 1. Participant.

No	Participant
1	Network Admin
2	Building Owner
3	Building Contractor
4	Building Maintenance Manager
5	Building Demolition Expert

lists the Participants, which refer to parties involved in this information system running on the blockchain network.

A Network Admin governs other parties’ privileges and transactions. At the beginning of a building lifecycle, a Building Owner conducts a building bid and can update the bidding information details. A Building Contractor participates in a building bid by sending a proposal, and also participates during building development. Once the building is completed, a Building Maintenance Manager takes over from the Building Contractor. At the end of a building lifecycle, a Building Demolition Expert will receive approval from the Building Owner to demolish the building.

3.2.2. Asset

An Asset is defined as anything that has value. Assets record transaction data.

Table 2. List of Assets.

No	Asset	Key Fields	No	Asset	Key Fields
1.	Bim	bimId	4.	Development	developmentId
		buildingId			buildingContractorId
		Type			buildingId
		url			Amount
		bimStatus			startDate
		bimDate			Bim
		buildingOwner	5.	Maintenance	maintenanceId
2.	Building	buildingId			buildMaintMgrId
		Name			buildingId
		Address			startDate
		dateCompletion			Bim
		Status	6.	Demolition	demolitionId
		statusDate			buildDemoExpertId
		buildingOwner			buildingId
		buildingContractor			demolitionDate
		buildingMaintenanceManager			Bim
		buildingDemolitionExpert
3.	Bid	bidId
		buildingOwnerId
		buildingContractorId
		buildingId
		bidAmount
		bidDate
		Bim

shows a list of assets involved throughout a building lifecycle. Bim is an asset that includes the URL location of the Building Information Modeling (BIM) file, while Bid is an asset containing all bid-related information. The Development asset has building construction information. The Maintenance asset contains information once the building is completed and moves to an operational phase. At the end of a building lifecycle, the Demolition asset records building demolition information. The Building asset saves building-related information during each building phase.

3.2.3. Transaction

A transaction is a process that is done by a business network participant to change the value of an asset. Four transactions cover participants’ activities throughout the building lifecycle, e.g., bidBuilding, developBuilding, maintainBuilding, and demolishBuilding as in the below

Table 3. List of Transactions.

No	Transaction	Participant	Remarks
1	bidBuilding	Building Owner Building Contractor	This transaction verifies a building bid.
2	developBuilding	Building Owner Building Contractor	This transaction verifies building construction.
3	maintainBuilding	Building Owner Building Maintenance	This transaction verifies building maintenance.
4	demolishBuilding	Building Owner Demolition Expert	This transaction verifies building demolition.

. The bidBuilding transaction verifies building bid activity. The developBuilding transaction verifies building construction activity. The maintainBuilding transaction verifies building maintenance activity, and the demolishBuilding transaction verifies building demolition activity.

Each of the four transactions above was then implemented using Hyperledger Composer as shown in Figure 4. The bidBuilding transaction involves two participants, Building Owner and Building Contractor, and three assets: Bid, Building, and BIM. The developBuilding transaction consists of two participants, Building Owner and Building Contractor, and three assets: Development, Building, and BIM. The maintainBuilding transaction consists of two participants, BuildingOwner and BuildingMaintenanceManager, and three assets: Maintenance, Building, and BIM. The demolishBuilding transaction consists of two participants, BuildingOwner and BuildingDemolitionExpert, and three Assets: Demolition, Building, and BIM.

Thus, throughout the building lifecycle, in each stage, each transaction always includes two valuable Assets, e.g., Building and BIM. BIM information is then stored in the form of an encrypted URL string that points to the location of the BIM file to protect the exact location of the BIM files so users cannot access them directly.

3.2.4. Access Control List

Each participant in Hyperledger Composer has a different privilege in each phase of the building lifecycle. The Hyperledger Composer Access Control List reflects these varied privileges as shown in

Table 4. Access Control List.

No	Participant	Bim	Building	Bid	Development	Maintenance	Demolition
1	Network Admin	CRUD	CRUD	CRUD	CRUD	CRUD	CRUD
2	Building Owner	CRUD	CRUD	CRUD	R	R	R
3	Building Contractor	CRUD	RU	CRUD	CRUD	R	R
4	Building Maintenance Manager	RU	RU	R	R	CRUD	R
5	Building Demolition Expert	RU	RU	R	R	R	CRUD

. There are four types of privileges, i.e., Create (C), Read (R), Update (U), and Delete (D), given to a Participant to access the Assets. The Create privilege allows a participant to create an Asset; the Read privilege allows a participant to Read Asset information; the Update privilege allows a participant to change the Asset information, and the Delete privilege allows a participant to delete an Asset. There are six Assets involved, i.e., BIM, Building, Bid, Development, Maintenance, and Demolition.

3.3. Transaction Processing

When a participant submits a transaction, the participant executes operations on the corresponding assets. In this BIM information implementation, there are four transactions, i.e., bidBuilding, developBuilding, maintainBuilding, and demolishBuilding. During each transaction, there are processes to update related Assets as follows.

3.3.1. bidBuilding Transaction

In this transaction, the Building Owner makes and inputs a building bid (Building Owner ID, Building Contractor ID, Bid ID, Building ID, Bim ID). Then, the Building Owner submits the transaction. When all the parameters are gathered, this transaction calls blockchain transaction processing. Algorithm 1 shows the transaction logic in detail.

Algorithm 1. bidBuilding

Input: Building Owner ID, Building Contractor ID, Bid ID, Building ID, Bim ID Bim 🡨 Bid Bim Bim Date 🡨 Bid Transaction Date Building Owner 🡨 Bid Building Owner Building Contractor 🡨 Bid Building Contractor If Building Status == “” then Buiding Status 🡨 “Bidding” Building Status Date 🡨 Bid Transaction Date Bim Status 🡨 “Bidding” else Error

3.3.2. developBuilding Transaction

In this transaction, the Building Owner inputs (Building Owner ID, Building Contractor ID, Development ID, Building ID, Bim ID) and submits the transaction through the API in the system. When all parameters are gathered, this transaction calls blockchain transaction processing. Algorithm 2 shows transaction logic in detail.

Algorithm 2. developBuilding

Input: Building Owner ID, Building Contractor ID, Development ID, Building ID, Bim ID Bim 🡨 Development Bim Development Start Date 🡨 Development Transaction Date Building Owner 🡨 Development Building Owner Building Contractor 🡨 Development Building Contractor If Building Status == “Bidding” then Building Status 🡨 “Development” Building Status Date 🡨 Development Transaction Date Bim Status 🡨 “Development” else Error

3.3.3. maintainBuilding Transaction

In this transaction, the Building Maintenance Manager inputs (Building Owner ID, Building Maintenance Manager ID, Building ID, Bim ID) and submits the transaction through the API in the system. When all the parameters are gathered, this transaction calls blockchain transaction processing. Algorithm 3 shows the transaction logic in detail.

Algorithm 3. maintainBuilding

Input: Building Owner ID, Building Maintenance Manager ID, Maintenance ID, Building ID, Bim ID Bim 🡨 Maintenance Bim Maintenance Start Date 🡨 Maintenance Transaction Date Building Owner 🡨 Maintenance Building Owner Building Maintenance Manager 🡨 Maintenance Building Maintenance Manager If Building Status == “Development” then Building Status 🡨 “Maintenance” Building Status Date 🡨 Maintenance Transaction Date Bim Status 🡨 “Maintenance” else Error

3.3.4. demolishBuilding Transaction

In this transaction, the Building Demolition Expert inputs (Building Owner ID, Building Demolition Expert ID, Demolition ID, Building ID, Bim ID) and submits the transaction through the API in the system. When all parameters are gathered, this transaction calls blockchain transaction processing. Algorithm 4 shows the transaction logic in detail.

Algorithm 4. demolishBuilding

Input: Building Owner ID, Building Demolition Expert ID, Demolition ID, Building ID, Bim ID Bim 🡨 Demolition Bim Demolition Date 🡨 Demolition Transaction Date Building Owner 🡨 Demolition Building Owner Building Demolition Expert 🡨 Demolition Building Demolition Expert If Building Status == “Maintenance” then Building Status 🡨 “Demolition” Building Status Date 🡨 Demolition Transaction Date Bim Status 🡨 “Demolition” else Error

4. Discussion

Previously, parties with BIM information shared the information in limited ways, e.g., emails and meetings, rather than through a systematic approach. These unsecured methods can result in other involved parties not being aware when BIM files are modified. Moreover, parties who have access to BIM files can share BIM information with parties who may be unrelated to the projects. This puts highly confidential BIM information security at risk. Using a permissioned blockchain, BIM information can be securely accessed only by network participants and involved parties throughout the building lifecycle, i.e., bidding, development, maintenance, and demolition. BIM information includes building status, BIM status, and BIM files in the form of encrypted URL links available to blockchain participants. BIM information is recorded in blockchains, which are persistent; this enables highly secure information sharing among participants. It minimizes BIM information leakage while increasing information exchange securely for all participants.

In this study, we implement BIM information usage throughout the building lifecycle using permissioned blockchain technology. We evaluate our framework by employing the Hyperledger Composer business network based on the Hyperledger Fabric blockchain network. We use a virtual environment with Docker version 1.2.10 and Oracle VM Virtual Box version 6.0. The server runs on a local personal computer with Ubuntu 18.04 with 16 GB RAM and 2.20 GHz. We evaluate the performance of Hyperledger Composer by obtaining response times to create a certain number of assets. We create assets from 100 up to 800, with the result shown in Figure 5.

Then, we calculate the average response time of creating an asset on the Hyperledger Composer platform; we obtain the result shown in Figure 6. There is a slight fluctuation of average response times when the number of assets is between 100 and 300, which might be due to network latency. Aside from that, the response time tends to be almost constant for the higher number of assets created.

In Hyperledger Composer, only registered participants and network admin have access to a blockchain network. This will protect the network from malicious users. Using the decentralized ledger system, participants can easily view each transaction from each phase during a building lifecycle.

5. Conclusions

The purpose of this paper is to explore how BIM information could be included throughout a building lifecycle and exchanged securely by many parties. The following is the main idea of the research:

• Four transactions that correspond to each phase of the building lifecycle (bid, build, maintain, demolish) show that BIM information is always included in each phase. The four transactions are bidBuilding, developBuilding, maintainBuilding, and demolishBuilding.
• For security purposes, BIM information is in the form of encrypted URL links so that involved parties cannot determine the exact location of BIM files.
• Based on experiments to create assets on Hyperledger Composer, the more assets created, the more the average response time tends to be constant.