Abstract

The Architecture, Engineering and Construction (AEC) industry needs to improve the modeling of its resources, information flows and processes. One major challenge they face is the need for uninterrupted and traceable information flow among them, which takes the responsibilities and the liability of each stakeholder into account.

The AEC sector is comprised of multiple domains, each with its own body of knowledge, preferred information granularity and business processes. Building Information Modeling (BIM) is currently the most widely used paradigm for data exchange and management in the AEC industry. Nevertheless, there is currently a lack of data models that provide the structure necessary for the required traceable and immutable record of the collaborative decision making process, which is the basic prerequisite for accountability in the AEC industry. To fill this gap, we present an approach that combines BIM with blockchain technology. We utilize model-driven engineering and the ability of the Ethereum blockchain to define smart contracts for designing a traceable decision making method. Furthermore, we present a case study that compares three possible solutions and evaluates their financial and security properties. We demonstrate that the optimal solution indeed leads to BIM with an integrated immutable and traceable decision record.

The Voting Workflow in Action

In this section we show screenshots from our prototype demonstrating the voting process we implemented in Section 4 of the paper.

In this case, there is a component in our BIM model, named Element (see blue selection highlighting in the window in the background of Figure 1), which has been changed and for which the architect initiates a voting process. This initiation happens in the BIM model first, as part of a conversation with two other stakeholders – the building developer and the building physicist (see the highlighted conversation item in the second window). The initiation of the voting process requires a connection to the blockchain (see the window in the foreground), which receives information about the BIM model (name of the hosting Git repository and commit key of the model version in that repository), about the stakeholder starting the voting process, about the reason for voting and about the stakeholders eligible to vote.

Setup of voting session
Figure 1. Setting up a voting session.

The voting setup on the blockchain involves publishing a smart contract and calling a function that enables voting for the blockchain accounts belonging to the stakeholders declared eligible to vote, in this case, the building developer and the building physicist. The feedback from the application’s back-end responsible for communication with the Ganache simulation of the Ethereum blockchain is depicted in Figure 2.

The back end of the voting session setup
Figure 2. Feedback from the Ethereum simulation back-end after setting up a voting session.

The result of the voting setup on the blockchain is an address – the address of the smart contract. It is made available to the voters and acts as a virtual “voting booth” (see Figure 3).

Address of voting booth communicated.
Figure 3. The address of the “voting booth” on the blockchain has been set up.

This completes the voting setup. Figure 4 shows that the highlighted conversation item contains the address of the virtual voting booth.

Voting setup complete
Figure 4. The voting setup is now complete.

The smart contract has been deployed to the blockchain via a transaction from the account of the architect (see Figure 5).

The smart contract has been published.
Figure 5. The smart contract has been published to the blockchain.

Now the first vote can be cast. One of the invited voters, the building developer, first deposits a message in the conversation attached to the changed component (see Figure 6).

First vote as message in the BIM model.
Figure 6. The first voter places a message in the BIM model.

This triggers the voting routine on the blockchain (see Figure 7), which calls the application’s back-end with the blockchain credentials of the stakeholder and the information deposited in the BIM message.

First vote on the blockchain.
Figure 7. The first voter places a vote on the blockchain.

The feedback from the application’s back-end following the vote is depicted in Figure 8.

The back-end feedback of the voting process (1st vote)
Figure 8. The feedback from the Ethereum simulation after placing the first vote.

This finalizes the BIM message and saves in it the address of the voting booth for future reference (see the second conversation item in the top window in Figure 9).

voting of first voter complete
Figure 9. The voting process has been completed by the first voter – both in the BIM model and on the blockchain.

In addition, the vote has been recorded in a transaction and deposited in a block on the blockchain (see Figure 10).

Transaction saving the first vote to the blockchain
Figure 10. The first vote has been saved as a blockchain transaction.

Figures 11 to 15 depict the voting activity of the second eligible voter – the building physicist. This results in an immutable transaction record on the blockchain and in a finalized conversation in the BIM model. Whereas the BIM model can be falsified and the conversation deleted, the voting record on the blockchain cannot be removed or changed and is accessible to all interested parties during the lifetime of the blockchain itself.

Second vote as message in the BIM model.
Figure 11. The second voter places a message in the BIM model.
Second vote on the blockchain
Figure 12. The second voter places a vote on the blockchain.
The back-end feedback of the voting process (2nd vote)
Figure 13. The feedback from the Ethereum simulation after placing the second vote.
voting of second voter complete
Figure 14. The voting process has been completed by the second voter as well – both in the BIM model and on the blockchain.
Transaction saving the second  vote to the blockchain
Figure 15. The second vote has been saved as a blockchain transaction.