Building information model cross-professional evidence and collaboration method based on layered alliance blockchain and application thereof

Abstract

The application relates to the technical field of blockchains, in particular to a building information model cross-professional evidence storage and cooperation method based on a hierarchical alliance blockchain and application thereof. A central file and a blockchain synchronization strategy are proposed in units of single BIM models, BIM models are acquired in units of files, and then the models are divided according to their professions and stored in different node sub-clusters. Each sub-cluster maintains an independent sub-alliance chain, and the blockchain sub-network is responsible for processing intermediate drawing models generated by professional collaborative design. The upper main chain is responsible for model data exchange between sub-networks, and is responsible for processing and transmitting final version drawing models generated by all professional cooperation after being audited, so that the hierarchical alliance multi-chain form is used to overcome the problems of low BIM data storage efficiency and poor privacy in traditional single blockchains.

Description

A Method and Application for Cross-Disciplinary Evidence Storage and Collaboration in Building Information Modeling Based on Layered Consortium Blockchain Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a cross-disciplinary evidence storage and collaboration method for building information models based on a hierarchical consortium blockchain and its application. Background Technology

[0002] Building Information Modeling (BIM) is a digital approach that utilizes technologies to manage the entire process of building engineering projects, from design and construction to operation. Based on 3D modeling, it integrates various data throughout the building's lifecycle by creating and managing BIM models that contain geometric information, physical characteristics, and functional attributes, providing a platform for collaborative work among all project stakeholders.

[0003] With the development of BIM technology and the increasing complexity of engineering applications, especially in the process of multi-person, cross-departmental collaborative design, local or centralized servers suffer from insufficient security, single points of failure, and the inability to prevent model tampering during sharing. This leads to problems such as low efficiency in multi-departmental collaboration, difficulty in tracing designers' responsibilities, and challenges in copyright management. Blockchain technology, with its immutable, highly secure, traceable, and distributed characteristics, can effectively solve the problems of responsibility allocation, model traceability, and storage security in BIM collaboration.

[0004] However, the large volume of data across departments, professions, personnel, and models, coupled with frequent on-chain uploads, leads to inefficiencies in existing blockchain technologies. Storing data across departments on the same chain also presents privacy vulnerabilities. Secondly, while an engineering project ideally corresponds to a single, logically unified BIM model, in practice, due to differences in departments and professions, it often consists of multiple interconnected BIM sub-models, lacking unified standards, a collaborative platform, and effective model management. Existing solutions primarily upload incremental BIM model data, but storing only incremental data exacerbates the chaos of model version management and makes it difficult to support traceability throughout the entire building lifecycle.

[0005] In view of this, this application proposes a cross-disciplinary notarization and collaboration method for building information model based on a hierarchical consortium blockchain, aiming to overcome the problems of low BIM data storage efficiency and poor privacy in traditional single blockchains. Summary of the Invention

[0006] The main purpose of this application is to provide a cross-disciplinary method for the storage and collaboration of building information models based on a hierarchical consortium blockchain, which aims to overcome the problems of low data storage efficiency and poor privacy in traditional single blockchains.

[0007] To achieve the above objectives, this application provides a cross-professional notarization and collaboration method for Building Information Modeling (BIM) based on a hierarchical consortium blockchain. This method is applied to a BIM notarization and collaboration system, which includes a distributed node cluster. One subnet in the distributed node cluster is configured as the main chain, while the remaining subnets store BIM data of the same professional type. Each type of BIM data is assigned a corresponding unique identifier and a data type registry is formed and stored on the blockchain. The method includes the following steps:

[0008] S10, when receiving the building information model file sent from the central file by the first collaborator, the building information model file is uploaded to the blockchain, and the updated central file after being uploaded to the blockchain is synchronized to other collaborators of the same profession as the first collaborator.

[0009] S20: When receiving a request to obtain the first target building information model file from the second collaborator, the system searches the main chain to see if there is a final version of the target building information model file corresponding to the first target building information model file, and sends the final version of the target building information model file to the second collaborator after verification.

[0010] S30, upon receiving a modification traceability request for the second target building information model file sent by the third collaborator, traceability is performed based on the differences between two consecutive adjacent versions of the second target building information model file stored in the subnet.

[0011] Optionally, in step S10, synchronizing the updated central file after it is uploaded to the blockchain to other collaborators with the same specialty as the collaborator specifically includes:

[0012] S11, when the first collaborator uploads the building information model file from a local copy of the central file, it generates and detects a unique identifier and uploads the building information model file and the designer's related information to the blockchain associated with the subnet corresponding to the unique identifier;

[0013] S12, After the on-chain process is completed, the building information model file is downloaded from the blockchain as a new central file and simultaneously sent to the other collaborators.

[0014] Optionally, the building information model storage and collaboration system further includes an interplanetary file system and collaboration nodes, and before or after step S20, it further includes:

[0015] S40: Obtain the building information model file uploaded by the second collaborator. After generating a digital signature, the collaborating node sends the building information model file to the InterPlanetary File System (IPS) for storage. The digital signature is combined with the CID returned by the IPS and sent to the blockchain associated with the subnet corresponding to the building information model file. After verifying the digital signature, the subnet consensus node uploads the intermediate drawings to the blockchain using a preset consensus algorithm.

[0016] Optionally, before or after step S20, the method further includes:

[0017] S50, do not grant the second collaborator permission to search for the first target building information model file from the remaining subnets.

[0018] Optionally, the method further includes:

[0019] S60: After receiving a building information model file deletion request sent by an auditing end with deletion permission, and after successfully verifying the unique identifier field in the building information model file deletion request, the system performs a deletion operation on the target building information model file corresponding to the building information model file deletion request, marks the target building information model file as deleted, and uploads the deletion operation to the blockchain.

[0020] Optionally, in step S30, tracing back based on the differences between two consecutive adjacent versions of the second target building information model file stored in the subnet specifically includes:

[0021] S31, determine whether the hash values ​​of two consecutive adjacent versions of the first and second model files are the same;

[0022] S32, if not, identify whether the key identifiers of the first model file and the second model file are consistent;

[0023] S33, if not, trace the collaborator associated with the first model file or the second model file based on the component design information associated with the key identifier.

[0024] Furthermore, to achieve the above objectives, this application also provides a cross-disciplinary evidence storage and collaboration architecture for building information models based on a layered consortium blockchain. This architecture includes:

[0025] Multiple collaborating endpoints are used to send building information model files and / or requests to the building information model storage and collaboration system;

[0026] The Building Information Model (BIM) Notification and Collaboration System is used to implement the cross-disciplinary notification and collaboration method for BIM based on a hierarchical consortium blockchain as described in any of the above items.

[0027] Optionally, the building information model storage and collaboration system includes collaboration nodes and consensus nodes, wherein the collaboration nodes do not participate in blockchain deployment and consensus logic operation; the consensus nodes participate as the blockchain in blockchain data structure deployment and consensus mechanism operation.

[0028] The building information model evidence storage and collaboration system includes multiple computer systems, and the total number of nodes deployed in each computer system is no greater than (n-1) / 3, where n is the total number of consensus nodes.

[0029] In addition, to achieve the above objectives, this application also provides a computer system comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the cross-disciplinary evidence storage and collaboration method for building information model based on hierarchical consortium blockchain as described in any of the preceding claims.

[0030] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the cross-disciplinary evidence storage and collaboration method for building information model based on hierarchical consortium blockchain as described in any of the preceding claims.

[0031] This application has at least the following beneficial effects:

[0032] 1. By utilizing layered consortium blockchain technology, we can overcome the shortcomings of traditional blockchain applications in BIM collaborative design, such as security, privacy, and low on-chain efficiency in collaboration among personnel and professional departments.

[0033] 2. By setting permissions for team members of different subnets and the mainnet consortium chain, subnets exchange internal intermediate models, and the main chain exchanges the final version model, the security of cross-departmental data exchange is greatly increased, avoiding the risk of departmental phase results being tampered with.

[0034] 3. The hierarchical consortium blockchain off-chain storage solution proposes a strategy for synchronizing central files with the blockchain on a per-model basis. This effectively aligns with the current mainstream BIM software central file collaboration model and avoids the chaos in model version management caused by the increased burden of storing incremental data. Attached Figure Description

[0035] Figure 1 is an example diagram of subnetting involved in an embodiment of this application;

[0036] Figure 2 is a flowchart illustrating the cross-disciplinary evidence storage and collaboration method for building information model based on hierarchical consortium blockchain involved in the embodiments of this application;

[0037] Figure 3 is a flowchart of the on-chain storage and retrieval of BIM model files by the collaborator end in an embodiment of this application;

[0038] Figure 4 is a schematic diagram of the professional collaboration process and cross-departmental data exchange of different blockchain subnets involved in the embodiments of this application;

[0039] Figure 5 is a schematic diagram of the synchronization process using a single BIM model as the storage unit in an embodiment of this application;

[0040] Figure 6 is a schematic diagram of the hardware operating environment of the computer system involved in the embodiments of this application.

[0041] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0042] To better understand the above technical solutions, exemplary embodiments of this disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art.

[0043] First Embodiment

[0044] This embodiment provides a method for cross-disciplinary evidence storage and collaboration of building information models based on a hierarchical consortium blockchain.

[0045] This method is applied to the Building Information Model (BIM) notarization and collaboration system proposed in this embodiment. The BIM notarization and collaboration system is designed based on a blockchain network subnet with BIM collaboration characteristics, specifically including a distributed node cluster.

[0046] Referring to the subnetting example diagram shown in Figure 1, the distributed node cluster includes multiple subnets, one of which is configured as the main chain, and the remaining subnets store building information model data of the same professional type. Each type of building information model data is assigned a corresponding unique identifier and forms a data type registry stored on the blockchain.

[0047] In this embodiment, building information model data of the same professional type refers to storing related data of the same profession in the same sub-blockchain to reduce cross-network data access and enhance privacy, so that data of the same device, the same type, and the same time and space range are allocated to the same sub-network, thereby making the design of the sub-network meet the principle of data locality.

[0048] In addition, the PBFT consensus mechanism ensures that each blockchain network has sufficient security strength to prevent a single malicious node from controlling and influencing the network, thus ensuring that the subnets meet security principles.

[0049] In this embodiment, based on the classification system of BIM collaboration disciplines, this solution designs a data type-driven subnet node mapping rule to map BIM model data generated by different disciplines to the same subnet.

[0050] Each profession is treated as a data type and assigned a unique identifier, forming a data type registry. This registry is stored on the blockchain and serves as the basis for subnet mapping. The data type identifier type_id is calculated as follows:

[0051] type_id=hash(data_category+security_level)

[0052] In the formula, hash() represents a hash function, data_category represents the data type corresponding to the major, and security_level represents the data level corresponding to the major.

[0053] The initial network mapping function shard_id is as follows:

[0054] shard_id=hash(type_id)%initial_shard_count

[0055] Wherein, initial_shard_count is the initial number of subnets in the system, which is pre-configured based on the number of BIM collaborative disciplines and the expected overall load; % is the division sign, that is, the initial network mapping function is the hash value of the data type identifier divided by the initial number of subnets in the system.

[0056] In some alternative implementations, four blockchain networks were constructed, numbered 1-4. The experiments used multi-process simulations of distributed nodes, with their operational logic written using the Flask framework and JavaScript. This simulated the core communication characteristics of a blockchain network (including decentralized message passing, node state synchronization, and PBFT fault tolerance), and blockchains were deployed in each subnet. In each blockchain, the block header records the metadata of the current block, while the block body stores important information about the BIM drawings encapsulated in that block, as well as other relevant information, including the designer's information, version number, drawing CID, and the time of each modification.

[0057] Specifically, in this implementation, the block header contains the following data: block hash, previous block hash, and block height. The block body contains the following data items: Version No.: Indicates the current uploaded drawing version. BIM Project Identifier (20 bytes): Uniquely identifies the BIM project to which this block belongs, supporting parallel storage of multiple projects. User Information (user id): Includes operator information, operator signature, ID number, etc. Organization: Architecture, Structure, Water and Electricity, Fire Protection, Equipment, etc., including design institute information. A unique sequence number (CID) returned by off-chain IPFS storage.

[0058] Members of different subchains in a consortium blockchain set permissions. Each subchain authenticates a client's joining by checking the legitimate Certificate of Authority (CA) obtained from the consortium blockchain network, and the main chain issues a CA certificate to each authenticated client.

[0059] After completing the above architecture, referring to Figure 2, this method also includes the following steps:

[0060] S10, when receiving the building information model file sent from the central file by the first collaborator, the building information model file is uploaded to the blockchain, and the updated central file after being uploaded to the blockchain is synchronized to other collaborators of the same profession as the first collaborator.

[0061] In this step, in the traditional BIM collaborative design process, each designer of the same profession will periodically (e.g., every 1-2 hours) perform the "synchronization with central file" operation. In this embodiment, a blockchain synchronization strategy based on the central file collaboration mode is designed.

[0062] The BIM front-end software performs relevant constraint checks (workset management, element borrowing, conflict detection, etc.) and blockchain synchronization. When the designer uploads the model from the local copy of the central file, the system generates and checks a unique identifier and uploads the model and the designer's relevant information to the blockchain subnet corresponding to the identifier for notarization. After the on-chain is completed, the model is downloaded from the blockchain as a new central file and updated in real time to the local copies of other collaborating members in this profession.

[0063] Furthermore, and optionally, the BIM front-end software performs relevant constraint checks (workset management, element borrowing, conflict detection, etc.) and synchronization. When a designer uploads modifications from a local copy of the central file, the system detects the unique identifier and uploads the current central file along with the designer's personal information to the corresponding blockchain subnet for notarization. After the on-chain process is complete, other collaborators initiate download requests to obtain the latest version of the central model file from the blockchain to update their local copies. That is:

[0064] S11, when the first collaborator uploads the building information model file from a local copy of the central file, it generates and detects a unique identifier and uploads the building information model file and the designer's related information to the blockchain associated with the subnet corresponding to the unique identifier;

[0065] S12, After the on-chain process is completed, the building information model file is downloaded from the blockchain as a new central file and simultaneously sent to the other collaborators.

[0066] Further and optionally, referring to the flowchart of the collaborator's on-chain storage and retrieval of BIM model files shown in Figure 3, the blockchain on-chain process is as follows: BIM models are uploaded in units of files. First, the collaborating node uploads the original model file to the IPFS system, obtains the file CID, then generates a digital signature and packages the CID and the designer's personal information and uploads it to the corresponding subnet blockchain. After the blockchain node verifies the signature, the consensus node cluster uploads the data to the blockchain using the PBFT algorithm to tolerate no more than (n-1) / 3 malicious nodes (where n is the number of nodes).

[0067] For example, in some optional implementations, three clients (i.e., collaborator clients) are set up. After the BIM software designer on the front end completes the design and saves a copy of the model, client 1 uploads the local copy of the model and the designer's personal information to the collaboration node. Each designer has an identity identifier, including the designer's name, organization, and employee number.

[0068] Collaborating nodes (servers) send the BIM model file to the IPFS system and return a unique file CID. They then generate a digital signature and send the CID and designer information to the consensus nodes. The digital signature uses Elliptic Curve Cryptography (ECC) to generate a public-private key pair. After verifying the signature, the consensus nodes upload the data to the blockchain using the PBFT algorithm. The node cluster elects a master node through view switching. The master node packages the block and synchronizes the blockchain data of all nodes within the subnet through a three-phase consensus mechanism. Once the data is uploaded to the blockchain, a project identifier is sent to each client via the Socket.io protocol.

[0069] After receiving the message, clients 2 and 3 check whether it is the project identifier. If it is, they send a request to the blockchain network. The blockchain finds the CID stored in the block body corresponding to the latest version number of the project identifier and sends it to the collaborating node. After verifying the signature, the node retrieves the original file from IPFS and sends the file to clients 2 and 3.

[0070] After the client obtains the BIM model file, it uses it as the new central file and synchronizes it to the designer's local copy. Client 2 completes the design and submits it. Client 3, the reviewer, reviews it, marks it as the final version of the BIM model, and submits it. At this point, the collaborating nodes will attach a unique field to the message. The blockchain network detects this field and sends the message to the mainnet. After the mainnet blockchain nodes verify the signature, they reach consensus and upload the data to the chain in the same way.

[0071] S20: When receiving a request to obtain the first target building information model file from the second collaborator, the system searches the main chain to see if there is a final version of the target building information model file corresponding to the first target building information model file, and sends the final version of the target building information model file to the second collaborator after verification.

[0072] In this step, different professional departments' clients are assigned permissions, managed through consortium blockchain CA certificates. Clients can only obtain final drawings from other professional departments within the same project from the main chain; they cannot directly obtain unreviewed drawings from other subnets. If the uploaded drawing model passes departmental review and is marked as the final version for that professional project, the final drawing model will be uploaded to the main blockchain network with a version number recorded. The system will also check if the final drawing format has been exported as IFC. After obtaining the latest version of the final drawing (i.e., the final target building information model file), the collaborating client uses it as the central file or design basis to conduct collaborative design, continue generating intermediate drawings, and store them on the blockchain.

[0073] Referring to Figure 4, which illustrates the collaborative processes and cross-departmental data exchange across different blockchain subnets, during the collaborative on-chain process, the system checks if the BIM drawing model is marked as the final model version for this project's specialty (i.e., the version reviewed by the department's auditors). If so, the final BIM drawing model is uploaded to the main blockchain network, and the version number is recorded. The system also checks if the final drawing format has been exported as IFC. After the next specialty department creates a collaborative workset, the client uses the BIM software to initiate a request, verifying and finding the latest version number of the final model drawing CID from the main blockchain. Similarly, the collaborative node searches for the original file, signs it, and sends it. Finally, the file is designated as the central model for designers' reference (or the model can be discarded and recreated, and a new central model can be designated), for relay design, clash detection, auditing, delivery, and other tasks. Individual progress is also continuously synchronized within the department's internal sub-blockchain.

[0074] For example, when the structural engineering department needs to obtain architectural model files, the client initiates a request to the mainnet blockchain. After verifying its CA certificate, the latest version of the CID corresponding to the model project identifier is looked up and verified, and then sent to the structural subnet collaborative node. The model file is then obtained and synchronized to the structural designer's client. The designer can choose to use it as the central file for creation or as a reference to recreate the model.

[0075] It should be noted that the first collaborator refers to the client that sends building information model (BIM) files to the BIM storage and collaboration system (hereinafter referred to as the system), and the second collaborator refers to the client that sends a request to the system. In this embodiment, the terms "first" and "second" are used for ease of distinction, but do not imply that they are different clients. For example, a device acts as the "first collaborator" when sending BIM files and as the "second collaborator" when sending a file retrieval request. The same applies to the subsequent third collaborator.

[0076] Further and optionally, referring to the schematic diagram of the synchronization process with a single BIM model as the storage unit shown in FIG5, the Building Information Model Storage and Collaboration System also includes a InterPlanetary File System and collaboration nodes: before or after executing step S20, it further includes:

[0077] S40: Obtain the building information model file uploaded by the second collaborator. After generating a digital signature, the collaborating node sends the building information model file to the InterPlanetary File System (IPS) for storage. The digital signature is combined with the CID returned by the IPS and sent to the blockchain associated with the subnet corresponding to the building information model file. After verifying the digital signature, the subnet consensus node uploads the intermediate drawings to the blockchain using a preset consensus algorithm.

[0078] Optionally, the default consensus algorithm can be PBFT (Practical Byzantine Fault Tolerance).

[0079] S30, upon receiving a modification traceability request for the second target building information model file sent by the third collaborator, traceability is performed based on the differences between two consecutive adjacent versions of the second target building information model file stored in the subnet.

[0080] In this step, when it is necessary to trace the version changes later, the department and designer who uploaded the file can be traced by comparing the differences between adjacent model versions.

[0081] Further and optionally, specifically including:

[0082] S31, determine whether the hash values ​​of two consecutive adjacent versions of the first and second model files are the same;

[0083] S32, if not, identify whether the key identifiers of the first model file and the second model file are consistent;

[0084] S33, if not, trace the collaborator associated with the first model file or the second model file based on the component design information associated with the key identifier.

[0085] In some alternative implementations, the key identifier may include, but is not limited to, the GlobalId attribute of each component in the IFC file, as well as other identifiers such as Name or custom label comparison components.

[0086] In some optional implementations, the methods for determining changes in components include:

[0087] New component: A GlobalId that exists in a new file but not in an old file.

[0088] Delete the component: the GlobalId that exists in the old file but not in the new file.

[0089] Modified component: The same GlobalId exists in both files, but some attributes (such as geometric information, material properties, associated attribute sets, etc.) have changed.

[0090] It should be noted that this embodiment does not limit the execution order of steps S10, S20 and S30, that is, the execution logic of the three steps is relatively independent, rather than progressive.

[0091] It should be noted that if the hash values ​​of the first model file and the second model file are the same in step S31, it means that the contents of the two consecutive versions of the file are consistent and no data changes have occurred. The conclusion of the tracing is that no modification of the model content was detected within this version range, and the tracing process is terminated.

[0092] It should be noted that if, in step S32, the key identifiers of the first and second model files are identical but their hash values ​​are different, it indicates that the core structure of the model files has not changed, but at least one of the internal component geometry, parameter values, or non-key attributes has been updated. In this case, tracing can pinpoint the modifier at the file level, but it is not possible to further identify which specific component was modified by whom.

[0093] The technical solution provided in this embodiment proposes a central file and blockchain synchronization strategy based on individual BIM models. BIM models are acquired on a file-by-file basis, and then stored in different node sub-clusters according to their respective professional specialties. Each sub-cluster maintains an independent sub-consortium blockchain, and the blockchain sub-network is responsible for processing intermediate drawing models generated through collaborative design within its own specialty. The upper-layer main chain is responsible for model data exchange between sub-networks, processing and transmitting the final, approved drawing models generated through collaboration across all specialties. This layered, multi-chain consortium approach overcomes the problems of low BIM data storage efficiency and poor privacy inherent in traditional single-blockchain systems. It aligns with the current mainstream BIM software central file collaboration model and avoids the burden of storing incremental data that leads to chaotic model version management.

[0094] Second Embodiment

[0095] Based on the first embodiment, in this embodiment, if there is a need to delete sensitive BIM models or save off-chain storage space later, the system will generate a unique field after the reviewer verifies the data. If the field exists, the system will delete the file with the corresponding CID from the IPFS system (the consistency of the deletion is guaranteed by the IPFS system to be irretrievable), then mark that this version of the model has been deleted (the original on-chain record cannot be eliminated), and finally upload the operation record to the chain. That is:

[0096] S60: After receiving a building information model file deletion request sent by an auditing end with deletion permission, and after successfully verifying the unique identifier field in the building information model file deletion request, the system performs a deletion operation on the target building information model file corresponding to the building information model file deletion request, marks the target building information model file as deleted, and uploads the deletion operation to the blockchain.

[0097] For example, for useless intermediate drawings, the client inside the subnet initiates a deletion request later to save off-chain storage space. After the reviewer verifies the drawing, client 3 initiates a request, the system generates a unique field, and the collaborating node checks if the field exists. If so, it deletes the model 2 file with the corresponding CID in the IPFS system, and then sets the version number to -1 to mark that the version model has been deleted. The consensus node generates a new block in the same way and puts the CID number and operator information on the chain.

[0098] Verification of Examples

[0099] This embodiment compares and verifies the aforementioned method with the traditional single-chain method. Under the same number of nodes, simulated client-side blockchain operations were performed on the test BIM model. Table 1 shows a comparison of the average on-chain latency and throughput between the layered consortium blockchain and the traditional single-chain method.

[0100] Table 1. Results Comparison Table

[0101]

[0102] The incremental model (1MB increment) information and the global model are stored. Model 1 and Model 2 are uploaded sequentially using a hierarchical consortium blockchain. The comparison of the number of new blocks and traceability time is shown in Table 2.

[0103] Table 2. Comparison of Results

[0104]

[0105] Experimental results show that using the proposed solution reduces on-chain latency by 83.64% and increases throughput by 83.8%. Compared to storage incremental models, the on-chain time and number of generated blocks are reduced by 90%, while operability is increased, traceability time is shortened, and off-chain space usage remains unchanged. This invention effectively improves the efficiency of BIM model blockchain on-chaining, significantly enhances usability, and its global model storage and collaboration scheme is more suitable for real-world environments and more compatible with mainstream BIM collaboration software.

[0106] Furthermore, as an implementation scheme, this embodiment also proposes a cross-disciplinary evidence storage and collaboration architecture for building information models based on a layered consortium blockchain. This architecture includes:

[0107] Multiple collaborating endpoints are used to send building information model files and / or requests to the building information model storage and collaboration system;

[0108] The Building Information Model (BIM) Notification and Collaboration System is used to implement the cross-disciplinary notification and collaboration method for BIM based on a hierarchical consortium blockchain as described in any of the above items.

[0109] In some optional implementations, the Building Information Modeling (BIM) notarization and collaboration system includes collaboration nodes and consensus nodes, wherein the collaboration nodes do not participate in blockchain deployment and consensus logic operation; the consensus nodes participate as the blockchain in blockchain data structure deployment and consensus mechanism operation.

[0110] The building information model evidence storage and collaboration system includes multiple computer systems. Optionally, the total number of nodes deployed in each computer system is no greater than (n-1) / 3, where n is the total number of consensus nodes.

[0111] The computer system determines whether it has deployed a blockchain consensus node. If so, after the node program starts, it completes the initialization of the node environment. Initialization includes generating a unique identifier for the node, initializing the local blockchain data structure, and running the PBFT consensus algorithm logic. The consensus node needs to participate in the consensus process, continuously listen to the network, receive broadcasts from clients or other nodes, and exchange messages with other nodes to perform three-phase verification. Once a new block passes consensus verification, it is saved to the local blockchain data structure. The updated blockchain state (the entire chain) is written to the node program and finally stored in memory.

[0112] If a collaborative node is deployed, the collaborative node execution logic in the method described above will be run after the node program starts.

[0113] Collaborating nodes and consensus nodes work together to complete each step of the cross-disciplinary notarization and collaboration method for building information model based on hierarchical consortium blockchain as described in the above embodiment.

[0114] As one implementation scheme, Figure 6 is a schematic diagram of the hardware operating environment of the computer system involved in the embodiment of this application.

[0115] As shown in Figure 6, the computer system may include: a processor 1001, such as a CPU; a memory 1005; a user interface 1003; a network interface 1004; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0116] Those skilled in the art will understand that the computer system architecture shown in Figure 6 does not constitute a limitation on the computer system and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0117] As shown in Figure 6, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and computer programs. The operating system is a program that manages and controls the hardware and software resources of the computer system, as well as the operation of the computer programs and other software or programs.

[0118] In the computer system shown in Figure 6, the user interface 1003 is mainly used to connect to the terminal and communicate with the terminal; the network interface 1004 is mainly used to communicate with the backend server; and the processor 1001 can be used to call the computer program stored in the memory 1005.

[0119] In this embodiment, the computer system includes: a memory 1005, a processor 1001, and a computer program stored in the memory and executable on the processor, wherein:

[0120] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0121] S10, when receiving the building information model file sent from the central file by the first collaborator, the building information model file is uploaded to the blockchain, and the updated central file after being uploaded to the blockchain is synchronized to other collaborators of the same profession as the first collaborator.

[0122] S20: When receiving a request to obtain the first target building information model file from the second collaborator, the system searches the main chain to see if there is a final version of the target building information model file corresponding to the first target building information model file, and sends the final version of the target building information model file to the second collaborator after verification.

[0123] S30, upon receiving a modification traceability request for the second target building information model file sent by the third collaborator, traceability is performed based on the differences between two consecutive adjacent versions of the second target building information model file stored in the subnet.

[0124] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0125] S11, when the first collaborator uploads the building information model file from a local copy of the central file, it generates and detects a unique identifier and uploads the building information model file and the designer's related information to the blockchain associated with the subnet corresponding to the unique identifier;

[0126] S12, After the on-chain process is completed, the building information model file is downloaded from the blockchain as a new central file and simultaneously sent to the other collaborators.

[0127] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0128] S40: Obtain the building information model file uploaded by the second collaborator. After generating a digital signature, the collaborating node sends the building information model file to the InterPlanetary File System (IPS) for storage. The digital signature is combined with the CID returned by the IPS and sent to the blockchain associated with the subnet corresponding to the building information model file. After verifying the digital signature, the subnet consensus node uploads the intermediate drawings to the blockchain using a preset consensus algorithm.

[0129] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0130] S50, do not grant the second collaborator permission to search for the first target building information model file from the remaining subnets.

[0131] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0132] S60: After receiving a building information model file deletion request sent by an auditing end with deletion permissions, and after successfully verifying the unique identifier field in the building information model file deletion request, delete the target building information model file corresponding to the building information model file deletion request, mark the target building information model file as deleted, and then upload the deletion operation to the blockchain.

[0133] When processor 1001 calls a computer program stored in memory 1005, it performs the following operations:

[0134] S31, determine whether the hash values ​​of two consecutive adjacent versions of the first and second model files are the same;

[0135] S32, if not, identify whether the key identifiers of the first model file and the second model file are consistent;

[0136] S33, if not, trace the collaborator associated with the first model file or the second model file based on the component design information associated with the key identifier.

[0137] Furthermore, those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in a computer system to implement the process steps of the embodiments of the above methods.

[0138] Therefore, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the various steps of the cross-disciplinary evidence storage and collaboration method for building information model based on hierarchical consortium blockchain as described in the above embodiments.

[0139] The computer-readable storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0140] It should be noted that, since the storage medium provided in the embodiments of this application is the storage medium used to implement the methods of the embodiments of this application, those skilled in the art can understand the specific structure and variations of the storage medium based on the methods described in the embodiments of this application, and therefore will not be repeated here. All storage media used in the methods of the embodiments of this application fall within the scope of protection of this application.

[0141] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0143] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0144] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0145] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. This application can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0146] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0147] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A cross-disciplinary evidence storage and collaboration method for building information models based on a hierarchical consortium blockchain, characterized in that, An application is made to a Building Information Model (BIM) storage and collaboration system. The BIM storage and collaboration system includes a distributed node cluster. One subnet in the distributed node cluster is configured as the main chain, and the remaining subnets store BIM data of the same professional type. Each type of BIM data is assigned a corresponding unique identifier and forms a data type registry stored on the blockchain. The method includes the following steps: S10, upon receiving a BIM file sent from a central file by a first collaborator, the BIM file is uploaded to the blockchain, and the updated central file is synchronized to other collaborators of the same professional type as the first collaborator; S20, upon receiving a request from a second collaborator to obtain a first target BIM file, the system searches the main chain for a final version of the target BIM file corresponding to the first target BIM file, and after verification, sends the final version of the target BIM file to the second collaborator; S30, upon receiving a modification traceability request from a third collaborator for a second target BIM file, the system checks the data stored in its subnet according to the BIM file's location. The differences between two consecutive adjacent versions of the model are traced. The building information model storage and collaboration system also includes the InterPlanetary File System (IPS) and collaboration nodes. After step S20, the system further includes: S40, obtaining the building information model file uploaded by the second collaborator, generating a digital signature by the collaboration node, sending the building information model file to the IPS and storing it, and combining the digital signature with the CID returned by the IPS and sending it to the blockchain associated with the subnet corresponding to the building information model file. After verifying the digital signature, the subnet consensus node uploads the intermediate drawings to the blockchain using a preset consensus algorithm. In step S30, the differences between two consecutive adjacent versions of the model file stored in the subnet of the second target building information model file are traced, specifically including: S31, determining whether the hash values ​​between the first and second consecutive adjacent versions of the model file are the same; S32, if not, identifying whether the key identifiers of the first and second model files are consistent; S33, if not, tracing the collaborator associated with the first or second model file based on the component design information associated with the key identifiers.

2. The cross-disciplinary evidence storage and collaboration method for building information models based on hierarchical consortium blockchain as described in claim 1, characterized in that, In step S10, synchronizing the updated central file after it is uploaded to the blockchain to other collaborators of the same profession as the first collaborator specifically includes: S11, when the first collaborator uploads the building information model file from a local copy of the central file, generating and detecting a unique identifier and uploading the building information model file and the designer's related information to the blockchain associated with the subnet corresponding to the unique identifier; S12, after the uploading is completed, downloading the building information model file from the blockchain as a new central file and synchronously sending it to the other collaborators.

3. The cross-disciplinary evidence storage and collaboration method for building information models based on hierarchical consortium blockchain as described in claim 1, characterized in that, After step S20, the method further includes: S50, denying the second collaborator terminal permission to search for the first target building information model file from the remaining subnets.

4. The cross-disciplinary evidence storage and collaboration method for building information models based on hierarchical consortium blockchain as described in claim 1, characterized in that, The method further includes: S60, after receiving a building information model file deletion request sent by an auditing end with deletion permission, after successfully verifying the unique identifier field in the building information model file deletion request, performing a deletion operation to delete the target building information model file corresponding to the building information model file deletion request, marking the target building information model file as deleted, and then uploading the deletion operation to the blockchain.

5. A cross-disciplinary evidence storage and collaboration architecture for building information models based on a hierarchical consortium blockchain, characterized in that, The architecture for cross-disciplinary evidence storage and collaboration of building information models based on a hierarchical consortium blockchain includes: multiple collaborator terminals for sending building information model files and / or requests to the building information model evidence storage and collaboration system; and the building information model evidence storage and collaboration system for implementing the cross-disciplinary evidence storage and collaboration method for building information models based on a hierarchical consortium blockchain as described in any one of claims 1 to 4.

6. The cross-disciplinary evidence storage and collaboration architecture for building information models based on layered consortium blockchain as described in claim 5, characterized in that, The Building Information Model (BIM) notarization and collaboration system includes collaboration nodes and consensus nodes. The collaboration nodes do not participate in blockchain deployment or consensus logic operation. The consensus nodes participate in blockchain data structure deployment and consensus mechanism operation as part of the blockchain. The BIM notarization and collaboration system includes multiple computer systems. The total number of nodes deployed in each computer system is no greater than (n-1) / 3, where n is the total number of consensus nodes.

7. A computer system, characterized in that, The computer system includes: a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein when the computer program is executed by the processor, it implements the steps of the cross-disciplinary evidence storage and collaboration method for building information model based on a hierarchical consortium blockchain as described in any one of claims 1 to 4.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the cross-disciplinary evidence storage and collaboration method for building information modeling based on a hierarchical consortium blockchain as described in any one of claims 1 to 4.

Images