In recent years, building information modelling (BIM) [1] has become a comprehensive collaborative process in the architecture, engineering, and construction (AEC) industry [2]. Architectural design is a process in multiple fields that requires architects and engineers to work together [3]. Design engineers typically use various design tools to complete related work tasks [4]. When information exchange becomes inevitable, information interoperability is the most important core issue [5]. The International Standards Organisation (ISO) 19650-1 [6] series has applications primarily at level 2 maturity, predominantly using a common data environment (CDE) (Fig. 1) [7] based on information management technology. In addition, different design tools are used to complete the design using the currently proposed cooperation method, and the

Fig. (1). ISO 19650-1 analogue and digital information management – file/model/container and information management technology based on the common data environment (CDE).

Industry Foundation Classes (IFC) file format [8] must be exported when collaborative data exchange is needed. Different design tools require the exportation of a unified IFC file for data information categorisation and integration [9, 10]. James Heatona et al [11]. proposed extracting BIM-related data directly from the model (IFC file format), transferring them to the data centre and performing related collaborative operations with the existing asset management system. Based on the complex and unclear interrelationships of traditional project management information, which result in coordination and cooperation, owner-centred project management information is proposed [12]. However, this improvement is based on owner-centred management, resulting in problems regarding the absence of sharing and delays of information.

Finally, a study [12] has proposed a BIM-based construction project collaboration process that used IFC files for collaborative management. BIM360 aims to handle large, complex data management solutions, which usually require excessive amounts of time to implement in today’s AECO industry. The software aims to deliver a complete, accurate, and digital view of design and construction projects to multidisciplinary teams in the office or in the field. However, in a BIM360 environment, a single live model needs to be generated by multidisciplinary teams, which cannot present each engineer’s revision records in the same model file. Additionally, the revision historical records and timestamps are made by each different engineer in various teams. Therefore it might be difficult to clarify the responsibility and keep the correct workflow sequence in a project [13]. Based on the abovementioned collaborative cooperation, the following problems arise: 1. It is difficult to perform information management for architectural design. 2.

Responsibility attribution is unclear when problems occur in architectural design. 3. It is difficult to trace the various scenarios of architectural design at different points in time. 4. Architectural design information is stored only in a centralised database, resulting in data security and integrity issues [14]. 5. Copyrights for designers cannot be protected. 6. An additional collaborative operating environment is required and must be integrated with existing architectural software.

As mentioned above, information is stored in a centralised database, which may be accessed by users from different sources [15]. Blockchain [16] is a distributed database composed of data blocks. Various computing nodes on the network share the database and are responsible for the task of creating data blocks. As mentioned in an earlier study [17], data security is the main issue in this situation because stored data can be hacked or falsified. Thus, clarifying specific blockchain technology that can improve the current problems of the AECO industry is needed, but it has not yet been applied in the industry. A previous publication [18] proposed the idea of connecting RHINO/Grasshopper [19] and blockchain, explaining the value that blockchain contributes to building ecosystems; however, only simple data information is used to connect the application and the actual application of the building project has not yet been carried out. A public data environment framework for collaborative BIM design, which uses blockchain and interplanetary file systems (IPFSs) [20] to complete distributed joint operations, has been proposed [21, 22]. Although the proposed design in this paper has not continued the use of IPFS technology combined with blockchains to achieve decentralised collaboration [23], it uses files as the basis for cooperation.

Based on the above analysis of the current situation, the motivation of this paper is as follows:

1 Project information management cannot be performed when a design changes under integration and when no reliable information is recorded, or no traceable responsibility is provided.

2. It is difficult to trace the status of the detailed architectural design at different design stages in time.

3. Additional third-party software or platforms are required to share files in IFC when designing collaborative architectures. 4. This approach increases the risk of loss, conflict, or misunderstanding during design collaboration. Problems of insecurity, high complexity, and high latency exist. 5. The current collaborative architecture is vulnerable to attack or tampering. 6. In the same project design, the relevant information is changed (e.g., the length, width, and height of the project model), and there is no related traceable record, resulting in the loss of copyright protection. These results demonstrate data security issues in data centres and integrity issues when the design is stored only in a centralised database.

This paper has proposed a dynamic information storage and blockchain system (DISBS) for architectural design processing to achieve the following: 1. The information on building project design is synchronously integrated with the database, and the information on the building components is stored and managed to ensure the integrity of the data and the future design, manufacturing, construction, and operation process. 2. Data integration with the blockchain protects the rights of the original designer and records the modified information of the building components to ensure that the process and responsibility of the tampered version are maintained. 3. In terms of the perspective on the stages of maturity of analogue and digital information management, the proposed system advances towards stage 3 in several ISO 19650 areas (Fig. 1). 3.1 In the standard layer, the process of the method proposed in this paper is regarded as a possible collaborative process in future ISO 19650-1 stage 3 imple-mentation. 3.2 In the technology layer, the query/model/ container/database and information management technology-based CDE are used for collaboration. 3.3 In the information layer, object-based server information models are used to implement the basic model of the component knowledge base for project design. A single design model is imported into a single design software system to complete the use of federated information models. The proposed approaches manage both structured data and unstructured (big) data.

Related works have introduced several papers on the concept and use of blockchain in construction management and presented the current collaborative cooperation platform based on BIM. In contrast, the proposed approach introduces the system architecture of the proposed method and introduces the microservices in the architecture. The proposed approach also introduces the processes of generating, searching, and verifying records in the system architecture. The case study presented here takes a curtain wall project as a practical implementation and uses the developed system architecture to complete the project design. Finally, in this paper, the results analysis, systematic record search and verification processes, and the time delay data analysis of the overall construction project, are presented. This study demonstrates that the proposed approach not only focuses on the purpose of the technology layer of ISO 19650 part 1 stage 3 (Fig. 1), but also addresses construction industry security concerns when working with external collaborators. The conclusion summarises the methodology of the paper and the construction industry validation analysis of the curtain wall project and explains the possible directions for future research.

This section proposes a system architecture to realise the use of blockchain technology to help solve existing problems in the construction field and apply it in practical projects. The proposed system architecture comprises three major processes: the record generation process, the record search process, and the record verification process. The record generation process completes the integration of the architectural design information records and protects the rights of the original designer. The record search process achieves the data search required by the designer or collaborator.

Fig. (3). BIM-based common platform of paper (Lai et al., 2019).

Fig. (4). The DISBS system architecture completes the environment of the ISO 19650-1 stage 3 technology layer.

The record verification process provides the procedures and responsibilities for confirming tampered versions. The proposed DISBS and each main process complete the technology of different levels of ISO 19650-1 stage 3 (Fig. 1), and the following sections explain which level of technology is completed by the proposed approach.

3.1. System Architecture

In this section, we propose DISBS for processing architectural design information. The methods and processes proposed in DISBS not only achieve implementation of the ISO 19650-1 stage 3 technology layer and information layer, but also use a centralised database and decentralised blockchain management mechanism to manage various information from construction projects (Fig. 4). The DISBS primarily provides the usage situation of the architect when designing the project, which is usually not accomplished by one person in terms of completing the entire project.

Architectural work is completed by division of labour and collaboration between the construction teams. Therefore, a mechanism to store architectural information is needed.

Information security and data integrity must be protected to ensure interoperability of information and data integrity. The DISBS system is used to communicate through three microservices: the blockchain, the database, and file management through the API as an intermediary in the element knowledge base and RHINO (Grasshopper).

3.1.1. Element Knowledge Base

The element knowledge base is composed of building knowledge for architects. Designers can upload their elements to the element knowledge base; then, these elements receive safety management and protection. Other designers can download related components from the element knowledge base to save project component design time.

3.1.2. Rhino/Grasshopper

Rhino is a CAD application software implementation for three-dimensional (3D) graphics that is used as a modelling tool by designers. Grasshopper is a visual programming language plugin in Rhino that enables users to write APIs on their own

3.1.3. API

The API is a necessary bridge between front-end software and back-end applications. The function of the API in this system is to communicate the element knowledge base and Rhino drawing software, with microservices acting as the intermediary among the blockchain, the database, and file management.

Fig. (5). Record generation process corresponding to the 19650-1 stage 3 information layer.

3.1.4. Blockchain

Blockchain protects the concatenated text content (also called a block) through the concatenation of cryptography. Each block contains the encrypted hash of the previous block, the corresponding timestamp, and transaction data. This design makes it difficult to manipulate the blockchain. The distributed ledger connected by blockchain technology allows both parties to record the transaction effectively and verify the transaction permanently. In our system architecture, we have tested the private blockchain and consortium blockchain. Private blockchain refers to a blockchain where the permission to write is only in the hands of one organisation. However, the transaction speed is fast, privacy is protected, transaction costs are low, and the characteristics of non-tampering are retained. A consortium blockchain is usually more suitable for transactions, settlements, and clearing between institutions. External observers can inquire but cannot conduct transactions. Consortium blockchains are similar to private blockchains, but the degree of openness and decentralisation of the former is limited. The organisation determines the reading, writing, and accounting rights. For example, the consortium blockchain is similar to an industry service, while a private blockchain is identical to an organisation or a company.

The private blockchain is primarily suitable for use by a company or project department. The consortium blockchain is primarily suitable for use by multiple companies or project departments.

3.1.5. Database

With respect to the database, we use the MySQL relational database management system, which distinguishes the storage of the element knowledge base and the project design. The purpose of storage in a database is not only to store the data but also to establish a CDE. The speed of data extraction is faster in the database than in the blockchain. The database facilitates a rapid search of the data, while the blockchain ensures the accuracy and security of the data.

3.1.6. File Management

File management provides a place to store files when the designer finishes the design. The file path in the server is recorded in the database after the designers upload their design files, which can help the designers download the files later when using different computer design software.

Additionally, a collaborative intermediary is applied to protect the original design files.

3.2. Record Generation Process

This section describes the generation process for three records: the structured data check-in process, unstructured data upload process, and structured data check-out process (Figs. 5 and 6), as shown in Fig. (5). The functions of the structured data check-in process and structured data check-out process in the proposed record generation process are the recording processes

Fig. (6). Record generation process.

Fig. (7). Record search process corresponding to the 19650-1 stage 3 information layer.

after the project is completed and changed and the structured data part of the ISO 19650-1 stage 3 information layer is completed.

The unstructured data upload process is the process of uploading unstructured data after the project is completed and completing the unstructured data part of the ISO 19650-1 stage 3 information layer. These processes complete the integration of architectural design information records and protect the rights of the original designers.

3.4. Record Verification Process

This section describes the verification process for two records: the structured data check-in verification process and the structured data check-out verification process (Figs. 9 and 10). Data security in an ISO 19650-1 stage 3 CDE environment (Fig. 9) can be enhanced through the proposed verification processes. These processes implement procedures and responsibilities to confirm tampered versions.

We have described the proposed system architecture and procedures in this section. The processes of DISBS assist the designer in project collaboration in a centralised and decentralised environment. The DISBS is applied to a curtain wall project and is further analysed.

Fig. (8). Record search process.

Fig. (9). Record verification process corresponding to the 19650-1 stage 3 technology layer.

Fig. (10). Record verification process.

This section discusses the practical implementation of a curtain wall project in the DISBS system. Project data information can be integrated and protected when the model is in the design stage. Project-relevant data can be searched under design integration. The information related to data changes can be recorded and protected under design changes. Therefore, element location, element parameters, size, material, weight, and the label must be considered. Finally, the accuracy of the information can be verified when design problems and disputes occur. Figs. (11-13) show a curtain wall project in practice, i.e., the Kaohsiung Marriott hotel, where the designer uses RHINO/Grasshopper to design the curtain wall. This section is divided into two scenarios to explain the relative differences under a design change.

In scenario 1 (Fig. 14), the designer builds the design, and a design change occurs using the same computer. In scenario 2 (Fig. 15), the practice engineer completes the project design, and then, a design change follows by using different computers. The recorded video shows scenario 1 [37] and scenario 2 [38]. These two videos simulate the Marriott hotel in different collaborative environments, from the initial project design to the design change that occurs during planning and construction and the final design verification for responsibility attribution. The designer finishes designing the curtain wall panels and exports the 3D model (.3dm, .rvt. . .) formatted files using the structured data check-in process to integrate the project information. The DISBSconfigures the unique element ID to each piece of curtain wall panel information when the designer finishes the structured data check-in process. Each curtain wall panel has a unique element ID, and the designer uses the unstructured data upload process to upload each element file of the curtain wall. When another collaborative engineer needs to utilise the design, they use the structured data obtaining process developed by the system to synchronise and integrate information and the unstructured data downloading process to download element model files. During collaborative design, collaboration members use the Grasshopper plugin to import the element files and display models in Rhino. When there is a design change, the design engineer uses the structured data check-out process to record and protect the information change and to check out the data from the system after the new elements are completed. The structured data check-in process is used to upload the new element information to the server; the server also configures the unique element ID for each piece of element information and uses the unstructured data uploading process to upload new element files. The design engineer can use the structured data obtaining process in the system to search for new design elements. The DISBS records the check-out information of the old elements. Design engineers can use the Grasshopper plugin to import the new design element files and display models in Rhino. The DISBS uses the structured data check-in verification process/the structured data check-out verification process to confirm the security and correctness of the check-in/check-out information when project design problems and disputes occur.

Fig. (11). A curtain wall project in practice - Kaohsiung Marriott hotel.

Fig. (12). Rhino Grasshopper design process.

Fig. (13). Marriott hotel actual graphics.

Fig. (14). Scenario 1.

Fig. (15). Scenario 2.

The DISBS system assists a project designer or a collaborative designer in the information security management process, which is described as follows:

• It records the original safety and modification process of the curtain wall project.

• It responsibly ensures the completion of the design when a problem occurs and traces the various time statuses.

• It integrates the existing design and its software for information sharing.

• It provides security to the design and the copyright of the project designer.

This section introduces a practical case study of a curtain wall project and its performance analysis. The approach implements the test environment of the private blockchain. Analogously, consortium blockchain two-node and three-node environments are developed (Fig. 16). In addition, the synchronisation environment of the two-node and three-node architectures is shown (Fig. 16).

The implementation divides the two scenarios based on the three blockchain architectures to discuss their performance analysis. The analysis simulates the architect’s project design of 80 curtain wall panels in a physical project. The simulation uses the 6 newly designed curtain wall units to make design project changes. Finally, the analysis performs security verification of the project information records.

5.1. Latency Analysis of the Proposed Methodology

Table 1 shows each process and time consumption of the different structures in scenarios 1 and 2. The table displays the process used in the project design, design changes, and design verification. When designing the project in scenario 1, the structured data check-in process and the unstructured data uploading process are used to record and protect the curtain wall project information.

When designing the project in scenario 2, the structured data downloading process and the structured data obtaining process are used to obtain the curtain wall project information of the design. The designer uses the structured data check-out process, the structured data check-in process, and the unstructured data uploading process to finish the design change in scenario 1 or scenario 2. When verifying the project design, the structured data check-in verification process and the structured data check-out verification process verify the curtain wall project information and the changed records. The table also shows the process and time required to complete the curtain wall project under different architectures.

Table 1 shows the total time required to complete the curtain wall project under different scenarios and architectures, including databases, private blockchain, and consortium blockchain (two-node and three-node configurations). The colours of the squares in the figure represen different system architectural colours. The y-axis represents the time required to complete the curtain project in milliseconds. In scenario 1, the total time required to finish the curtain wall roject using the database structure is 7,913.40 msec. In scenario 2, the total time required tofinish the curtain wall project using the database structure is 3,299.28 msec. In scenario 1, the total time required to finish the curtain wall project using the database and a private blockchain structure is 223,

Table 1. Time consumption of scenarios 1 and 2 with different structures (80 curtain wall panels, with 6 of them having design change).

Scenario	Status	Process	Database Only(msec)	Database with Private Blockchain(msec)	Database with Consortium Blockchain(two-node) (msec)	Database with Consortium Blockchain(three-node) (msec)
1	Projectdesign	Structured data check-in process(80 panels)	4,822.73	107,695.59	94,653.36	97,694.15
		Unstructured data uploading process(80 panels)	70.75	70.75	76.15	74.75
	Designchange	Structured data check-out process(6 panels)	2,769.63	10,206.40	7,587.58	7,666.31
		Structured data check-in process(6 panels)	245.65	7,389.79	7,113.61	7,302.39
		Unstructured data uploading process(6 panels)	4.63	4.63	3.52	3.61
	Designverification	Structured data check-in verification process(80 panels)	0	91,385.00	88,651.15	90,471.51
		Structured data check-out verification process(6 panels)	0	6,777.35	6,702.38	6,797.84
	Total process time		7,913.40	223,529.52	204,787.75	210,010.55
2	Projectdesign	Unstructured data downloading process(80 panels)	0.12	0.12	0.13	0.14
		Structured data obtaining process(80 panels)	279.24	279.24	378.89	373.47
	Designchange	Structured data check-out process(6 panels)	2,769.63	10,206.40	7,587.58	7,666.31
		Structured data check-in process(6 panels)	245.65	7,389.79	7,113.61	7,302.39
		Unstructured data uploading process(6 panels)	4.63	4.63	3.52	3.61
	Designverification	Structured data check-in verification process(80 panels)	0	91,385.00	88,651.15	90,471.51
		Structured data check-out verification process(6 panels)	0	6,777.35	6,702.38	6,797.84
	Total process time		3,299.28	116,042.54	110,437.27	112,615.27

Fig. (16). Blockchain environment.

529.52 msec. In scenario 2, the total time required to finish the curtain wall project using the database and a private blockchain structure is 116,042.54 msec. In scenario 1, the total time required to finish the curtain wall project using the database and the consortium blockchain with the two-node structure is 204,787.75 msec. In scenario 2, the total time required to finish the curtain wall project using the database and the consortium blockchain with the two-node structure is 110,437.27 msec. In scenario 1, the total time required to finish the curtain wall project using the database and the consortium blockchain with the three-node structure is 210,010.55 msec. In scenario 2, the total time required to finish the curtain wall project using the database and the consortium blockchain with the three-node structure is 112,615.27 msec.

Table 1 shows that the fastest speed is achievable by only using the database because it saves the time necessary to upload data on the blockchain. The second fastest speed is of the two-node consortium blockchain. The main reason for this is that since two nodes are used to verify transactions, uploading to the blockchain can be sped up. The third fastest approach is the three-node consortium blockchain. Although the three nodes are synchronised, the three-node consortium blockchain takes more time to synchronise in practice. The slowest approach is the single-node private blockchain. Because there is no other node to help verify transactions, uploading data to the blockchain is relatively slow. However, using more nodes incurs a greater reliance on hardware performance, and thus, different architectures have advantages and disadvantages. In terms of timing, the time consumption without blockchain is shorter. It is negligible compared to triggering the model in design software. To achieve tamper resistance in AECO, the information security mechanism is worthwhile.

Based on the results of the analysis of a curtain wall project in the construction industry under the structures mentioned above, we prove the feasibility of the method proposed in this paper. Single nodes can be used by a single designer or a single team to complete the collaboration of the curtain wall roject. Two or three nodes can divide multiple collaborations of the whole curtain wall project, and the designers can perform their designs individually. The designers can finish the designs and then use the two- or three-node blockchain to synchronise and combine them into one project. The results of the analysis indicate that an appropriate system can be selected, and the greatest benefit of the different structure usages can be achieved. The purpose of the proposed method is to help the construction industry achieve a connection with blockchain and move towards ISO 19650-1 stage 3.

When collaborating, the security, reliability, and traceability of information exchange are critical. The current collaboration platform is based on the ISO 19650-1 stage 2 specification for collaboration, but a security mechanism for information exchange is not yet provided. This paper helps to achieve several goals, which are listed as follows: (1) The entire construction industry is provided with an understanding of the technical aspects of the ISO 19650-1 analogy and the maturity stage of digital information management (stage 3). (2) The proposed process can be used to manage structured and unstructured data in the information layer (Fig. 5) and complete the object-based server information and the federated information models by applying a single model to the project design software (Fig. 7). (3) The query/model/CDE based on the information container database and information management technology in the technology layer is complete (Fig. 10). (4) IFC files are no longer used for collaborative information exchange. (5) The copyrights of the project designers and building components are protected to ensure that the modification process and the property responsibility are maintained. (6) In addition, transparency and traceability of information are provided. (7) The proposed method can be quickly identified and determined in the event of a dispute without cumbersome verification. This paper also provides information on GitHub [50] with links and instructions on how to use the code. Users can set up the service according to GitHub’s instructions or use the API service provided in this article to directly implement the DISBS process. In this work, blockchain has been used in the case of building envelopes. The case study performed has also confirmed that blockchain technology can improve data transparency and avoid the data being hacked in centralised management. This can lead to increased trust between the collaborators. The limitations of the method used in this paper are as follows: (1) It is necessary o conduct information technology education and training for AECO staff to become familiar with these functions, and encourage users and enterprises to understand the value of blockchain.

(2) Users must understand how to use the environment that simulates blockchain technology. (3) n the field of AECO, users need to be familiar with the tools of the Grasshopper drawing plug-in nd know how to use the API developed in this paper to connect with the Grasshopper software.

(4) It is necessary for the users to understand the methods and processes proposed in this paper and to become familiar with the timing of each process.

At present, the construction industry is faced with many challenges, especially in the planning of complex projects.

Stakeholders are often faced with issues of construction delays and disputes (e.g., bidding activities, contracting project management, smart manufacturing, project supervision, project management). Therefore, it is necessary to improve the workflow and reliability of information as well as the traceability of information production in the AECO industry. The proposed approach applies the characteristics of blockchain to project cooperation. It ensures that all data in a project can be verified and trusted through realization. The main goals of the proposed approach are to break hrough the silo effect and obtain reliable data information, enhancing transparency and mutual trust between collaboration partners. This can reduce duplications or errors and avoid the loss of important information in the AECO industry

The proposed approach is necessary for enhancing trust between the stakeholders. There is a need to reconsider the entire supply chain, including the selection of building materials, procurement, manufacturing, fabrication, and quality assurance. The entire supply chain needs to be added to the blockchain collaboration system to fully manage the lifecycle of buildings.