Leveraging Blockchains for Collaboration Accountability in Building Information Modeling: Artefacts
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.
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.
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).
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.
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).
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).
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.
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.
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).
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).
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.
Figure 11. The second voter places a message in the BIM model.
Figure 12. The second voter places a vote on the blockchain.
Figure 13. The feedback from the Ethereum simulation after placing the second vote.
Figure 14. The voting process has been completed by the second voter as well – both in the BIM model and on the blockchain.
Figure 15. The second vote has been saved as a blockchain transaction.