A cloud-based collaborative management method and system for multi-participant construction projects

Abstract

This application relates to a cloud-based collaborative management method and system for multi-participant construction projects. The method includes: acquiring construction project configuration information, constructing a project permission tree, and mapping it to a standardized directory framework; receiving original project files uploaded by participating parties' terminals, calling distributed storage services for incremental processing and version recording, and generating a cloud file library with version identifiers; responding to client model interaction requests, parsing the project file data in the cloud file library, and constructing a 2D / 3D linked view; detecting user-initiated annotation commands, generating structured issue records, and creating issue tracking instances; acquiring collaborative interaction data to generate electronic meeting minutes and associating them with issue tracking instances; and responding to delivery commands to encrypt and generate a digital delivery package. This application achieves precise, efficient, and traceable management of cloud-based collaboration among multi-participant construction projects through the full-process integration of permission control, 2D / 3D linkage, issue tracking, and digital delivery.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a cloud-based collaborative management method and system for multi-participant construction projects. Background Technology

[0002] With the rapid development of Building Information Modeling (BIM) technology, cloud computing, and mobile internet, the design and management of construction projects are accelerating their transformation towards digitalization, networking, and collaboration. Traditional collaboration models, primarily based on paper drawings and offline meetings, are no longer sufficient to meet the efficiency, quality, and cost control requirements of modern large-scale and complex projects. Therefore, various cloud-based project collaboration and management platforms have emerged, aiming to integrate multiple stakeholders, including clients, designers, contractors, and supervisors, into a unified digital environment. This enables centralized storage, sharing, and process management of the massive amounts of data resources such as drawings, models, and documents generated throughout the project lifecycle, thereby improving communication efficiency, reducing information silos, and ensuring project progress.

[0003] However, in complex collaborative networks involving multiple parties, the secure and orderly flow of data is difficult to guarantee effectively. Access control is often too rudimentary or rigid, failing to adapt to the dynamically changing, fine-grained data access needs that evolve with each stage of an engineering project. This can lead to potential information leakage risks or hinder necessary collaborative efficiency. Furthermore, for engineering data, especially large 3D models and frequently iterated drawings, directly uploading and storing complete file versions consumes enormous bandwidth and storage resources. Unoptimized, heavy models are difficult to load and operate smoothly on ordinary networks and terminal devices, making efficient online collaborative design review difficult to achieve.

[0004] Furthermore, the digitalization of communication and decision-making mechanisms in the collaboration process is insufficient. For example, issues discovered during design reviews are mostly communicated through informal channels such as screenshots, phone calls, and instant messaging software, resulting in fragmented problem descriptions, unclear responsibilities, and difficulty in tracking status, making it easy to overlook or delay issues. Related project meetings lack a digital link between agendas, resolutions, and specific tasks, making it difficult to effectively implement and track meeting outcomes. These interconnected problems hinder cloud-based collaboration platforms from truly realizing the end-to-end digital closed-loop value from design and collaboration to delivery, thus restricting further improvement in the overall efficiency of the engineering and construction industry. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a cloud-based collaborative management method and system for multi-participant construction projects.

[0006] Firstly, this application provides a cloud-based collaborative management method for multiple participants in construction projects, employing the following technical solution: A cloud-based collaborative management method for multiple participants in construction projects, the method comprising: Obtain the configuration information of the construction project, construct the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool; Receive the original project files uploaded by the participating terminal, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifier; In response to the model interaction request initiated by the client, the lightweight engine is invoked to parse the engineering file data in the cloud file library, construct the mapping relationship between the two-dimensional drawing data and the three-dimensional model data, and generate a two-dimensional and three-dimensional linked view; When a user's annotation command based on the two-dimensional or three-dimensional interactive view or cloud file library is detected, a structured problem record is generated and a problem tracking instance is created. The problem tracking instance is associated with the responsible person information and the status transition field. The system acquires interaction data during project collaboration, drives the meeting management module to generate electronic meeting minutes, and associates and binds the electronic meeting minutes with the issue tracking instance. In response to the project delivery instruction, target files are collected according to the standardized directory framework, and the target files are packaged and encrypted to generate a digital delivery package.

[0007] By adopting the above technical solutions, a fundamental transformation in multi-party collaboration in construction projects has been achieved. Integrating permissions and data ensures the secure and orderly flow of massive amounts of project data within complex collaborative networks; incremental storage and 2D / 3D linkage resolve technical bottlenecks in the storage, transmission, and efficient review of large-scale engineering data; transforming unstructured communication (annotations, meetings) into structured, traceable data (problem examples, meeting minutes) standardizes and automates collaborative processes, improving decision-making efficiency and execution rates; and finally, automated collection and packaging based on the initial framework ensures the quality and consistency of deliverables, forming an end-to-end digital closed loop from design to delivery.

[0008] Optionally, the project permission tree includes three levels of permission nodes: system-level permission nodes, project-level permission nodes, and folder-level permission nodes. The steps to map the project permission tree to a standardized directory framework throughout the project lifecycle include: Build system-level permission nodes to configure the global management roles and functional permissions of participating enterprises; Construct project-level permission nodes to assign operation permissions to participants within the corresponding project in the project data pool. These operation permissions include viewing, editing, downloading, and approval permissions. Create folder-level permission nodes to control the file access scope in the corresponding project directory of the project data pool.

[0009] By adopting the above technical solution, system-level nodes are used to establish enterprise-level entry points, project-level nodes are used to define the basic job roles and capabilities of individuals within a project, and folder-level nodes apply dynamic and granular access rules based on the specific attributes of the data and the business stage. Mapping this permission tree to a standardized project directory framework essentially binds a dynamic and traceable access control list to every data asset generated throughout the project's entire lifecycle from its inception. This is not only a technical prerequisite for enabling multi-party cloud collaboration but also directly supports the secure and reliable operation of all subsequent collaborative processes, including file version management, review and annotation, meeting decisions, and delivery.

[0010] Optionally, the step of calling a distributed storage service to incrementally process and record versions of the original project files, generating a cloud file repository with version identifiers, includes: Extract the metadata information from the original project file; Based on the metadata information, query the historical version file library to obtain the baseline version file associated with the original project file; The distributed storage engine is invoked to calculate the hash difference between the original project file and the baseline version file, and the set of differing data blocks is identified. The set of differential data blocks is compressed to generate incremental data packets; The incremental data packets are stored in a distributed storage node, and a version snapshot containing the storage location index is generated; The file version graph is updated based on the version snapshot, and the file version graph includes a version identifier, a timestamp, and a parent version pointer. A cloud-based file library with version identifiers is constructed based on the file version map.

[0011] By adopting the above technical solution, the traditional extensive mode of storing all data at the "file" level is transformed into a refined mode of storing data incrementally at the "data block" and "version relationship" level. This solution achieves significant savings in storage space and network bandwidth, storing and transmitting only changed data blocks, which is of great significance for frequently modified GB-level project files. Secondly, by constructing a structured file version graph, it achieves visualization, traceability, and rapid rollback of version history, greatly enhancing the clarity and reliability of project data management. Finally, this mechanism provides a solid foundation for cloud collaboration, making asynchronous editing, version merging, and conflict resolution of multiple users on the same file efficient and orderly.

[0012] Optionally, in response to a model interaction request initiated by the client, the steps of calling the lightweight engine to parse the engineering file data in the cloud file library, constructing a mapping relationship between the two-dimensional drawing data and the three-dimensional model data, and generating a two-dimensional and three-dimensional linked view include: Receive a model interaction request initiated by the client, and extract the target project file identifier contained in the model interaction request; Based on the target project file identifier, the lightweight engine is invoked to parse the corresponding project file data from the cloud file library. The project file data includes 3D model files and 2D drawing files. The 3D model file is subjected to lightweight processing to separate geometric data and material data, generating compressed lightweight model data; The two-dimensional drawing file is vectorized to extract component identification information and spatial location information from the drawing, and structured two-dimensional drawing data is generated. Based on the component identification information or spatial location information, a mapping relationship is constructed between the lightweight model data and the structured two-dimensional drawing data; Based on the mapping relationship, an interactive 2D / 3D linked view is generated and output to the client.

[0013] By adopting the above technical solutions, the long-standing dilemma of "separation of drawings and models" in the construction engineering field has been resolved. The traditional static and isolated review of two-dimensional drawings and browsing of three-dimensional models have been upgraded into a dynamic, intelligent, and interconnected collaborative workspace. This not only enables large BIM models to run smoothly on lightweight clients through lightweight technology, lowering the technical threshold for collaboration, but also establishes a solid digital link between two-dimensional abstract expressions and three-dimensional spatial entities through dual mapping of components and coordinates. This allows design problems to be quickly located and verified across views, improving the efficiency and accuracy of multi-disciplinary collaborative reviews. It is a crucial technological foundation for driving the integration and intelligentization of design, construction, and operation and maintenance.

[0014] Optionally, when a user's annotation command based on the 2D / 3D interactive view or cloud file library is detected, the steps of generating a structured issue record and creating an issue tracking instance include: The system detects annotation commands triggered by users through the client interface in the two-dimensional or three-dimensional linked view or cloud file library, and obtains annotation location data and user-inputted problem description text. Based on the annotation location data, the associated project file identifier and spatial coordinate information are parsed to generate location-related metadata; The system invokes preset question data structuring rules to perform semantic parsing on the question description text, extracting question type tags and key attribute fields. Based on the location-related metadata and key attribute fields, a structured problem record is generated; wherein, the problem record includes a file identifier, spatial coordinates, problem type, and descriptive summary; Based on preset responsible party matching rules, query the responsible party information associated with the problem type tag; Create an issue tracking instance and bind the structured issue record, responsible party information, and initial status transition fields.

[0015] By adopting the above technical solutions, a full-chain digital closed loop for problem feedback in multi-party collaboration during construction projects was constructed. The ambiguity of traditional offline annotations (such as "there is a problem in a certain part of the drawing") was transformed into precise four-dimensional positioning based on "file-space-semantics-responsible person." Relying on the underlying support of a lightweight engine and permission tree, seamless connection from problem discovery to tracking was achieved. Semantic parsing and a rule engine resolved ambiguities in natural language, and combined with the instantiation management of unique identifiers, the problem status flow (annotation → processing → review → closure) became traceable and statistically significant. Ultimately, this improved cross-disciplinary collaboration efficiency, reduced communication costs, and provided data-driven decision-making basis for quality control throughout the project lifecycle.

[0016] Optionally, after generating the structured issue record and creating the issue tracking instance, the following steps are also included: Obtain the responsible person information and status transition fields from the aforementioned issue tracking instance; Based on a preset set of task allocation rules, the information of the person in charge is processed to generate task allocation instructions; According to the task allocation instruction, the message push service is invoked to send a task notification to the responsible person's terminal; Receive response data returned by the responsible person's terminal, and parse the response data to obtain problem processing progress information; Update the status transition field according to the problem handling progress information to generate the updated status transition field; When the updated status transition field is detected to meet the preset closed-loop triggering condition, file version data associated with the issue tracking instance is obtained from the cloud file library; Perform version comparison analysis on the file version data to generate a file difference analysis report; Update the issue tracking instance based on the document difference analysis report and generate a closed-loop confirmation signal.

[0017] By adopting the above technical solutions, a fundamental shift in project problem management has been achieved from manual supervision to data-driven approaches. The intelligent rule engine and multi-terminal push services ensure the rationality of task allocation and the delivery of notifications, improving response and processing efficiency. By solidifying unstructured progress communication into parsable status and data, transparency and real-time monitoring of the processing process have been achieved. Crucially, automated document version comparison and analysis transforms the traditional subjective acceptance process, which relies on personal experience, into objective technical verification based on precise data difference analysis, enhancing the quality and credibility of the closed-loop process.

[0018] Optionally, in response to a project delivery instruction, the steps of collecting target files according to the standardized catalog framework, packaging and encrypting the target files, and generating a digital delivery package include: In response to the project delivery instruction, parse the project identifier and delivery phase identifier contained in the project delivery instruction; Based on the project identifier and delivery phase identifier, locate the target delivery directory level in the standardized directory framework; Based on the target delivery directory hierarchy, extract the associated set of file metadata from the project data pool; The file metadata set is filtered and verified based on a preset delivery rule set to generate a target file set that meets the delivery conditions. Perform format conversion processing on the files in the target file set to generate a standardized file set with a unified encoding format; The packaging service is invoked to perform data encapsulation on the standardized file set, generating an unencrypted intermediate delivery package; The unencrypted intermediate delivery packet is encrypted according to a preset encryption strategy to generate an encrypted data packet; Attach delivery metadata tags to the encrypted data packets to generate digital delivery packets.

[0019] By adopting the above technical solutions, project delivery is transformed from a labor-intensive, unpredictable terminal task into a reliable, secure, and standardized system service. Precise location based on standardized catalogs and metadata verification based on rule sets enable automated and accurate aggregation of delivered content, ensuring the integrity and compliance of results and eliminating human error. Mandatory format standardization unifies data output, eliminating technical barriers to downstream reception and application, and safeguarding the long-term value of assets. Compression, encapsulation, and encrypted computation improve transmission efficiency while building a strong security barrier, protecting core digital assets. Finally, by attaching structured delivery metadata tags, a self-manageable, verifiable, and clearly defined standardized digital asset package is generated.

[0020] Secondly, this application provides a cloud-based collaborative management system for multiple participants in construction projects, employing the following technical solution: A cloud-based collaborative management system for multiple participants in construction projects, the system comprising: The project permission and directory initialization module is used to obtain the configuration information of the construction project, construct the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool. The file version management module is used to receive the original project files uploaded by the participating parties' terminals, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifiers. The 2D / 3D intelligent linkage review module is used to respond to the model interaction request initiated by the client, call the lightweight engine to parse the engineering file data in the cloud file library, construct the mapping relationship between 2D drawing data and 3D model data, and generate a 2D / 3D linkage view. The issue tracking and closed-loop management module is used to generate structured issue records and create issue tracking instances when an annotation command initiated by a user based on the two-dimensional or three-dimensional interactive view or cloud file library is detected. The issue tracking instance is associated with the responsible person information and status transition field. The intelligent meeting decision-making linkage module is used to acquire interaction data during project collaboration, drive the meeting management module to generate electronic meeting minutes, and associate and bind the electronic meeting minutes with the issue tracking instance; The digital delivery package generation module is used to respond to project delivery instructions, collect target files according to the standardized directory framework, perform packaging and encryption processing on the target files, and generate a digital delivery package.

[0021] Thirdly, this application provides a computer device, which adopts the following technical solution: A computer device includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as described in the first aspect.

[0022] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect. Attached Figure Description

[0023] Figure 1 This is a first flowchart of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0024] Figure 2 This is a second flowchart illustrating a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0025] Figure 3 This is a schematic diagram of the third process of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0026] Figure 4 This is a schematic diagram of the fourth process of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0027] Figure 5 This is a schematic diagram of the fifth process of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0028] Figure 6 This is a schematic diagram of the sixth process of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application.

[0029] Figure 7 This is a schematic diagram of the seventh process of a cloud-based collaborative management method for multi-participant construction projects, which is one embodiment of this application. Detailed Implementation

[0030] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-7 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0031] This application discloses a cloud-based collaborative management method for multiple participants in construction projects.

[0032] Reference Figure 1A cloud-based collaborative management method for multiple stakeholders in construction projects, the specific method includes: Step S101: Obtain the configuration information of the construction project, construct the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool. The system acquires configuration information for construction projects, including basic project information, a list of participating companies and personnel, pre-set project phases (such as schemes, preliminary designs, and construction drawings), and work breakdown structure.

[0033] Based on this information, the system invokes a "pre-defined role-based access control model" (usually a role-based access control, RBAC model) to construct the project permission tree. The core principle of the RBAC model is to decouple users from permissions, managing them through a "user-role-permission" authorization pattern. In this scenario, the system assigns predefined roles to participants based on their responsibilities (such as construction representatives, design managers, structural designers, construction workers, etc.), and each role is associated with a set of fine-grained operational permissions (such as view, upload, download, comment, approve). The resulting "project permission tree" is a dynamic and extensible permission structure.

[0034] Next, the system maps the project permission tree to a standardized directory framework covering the entire project lifecycle. This standardized directory framework is a predefined folder structure based on enterprise or industry standards, such as " / Project A / 01-Schematic Design / Architectural / Drawings". The mapping operation means precisely binding the access permissions of each role or user node in the permission tree to a specific folder or file type within the directory framework. For example, construction personnel might only have view and download permissions for the "Construction Drawings" folder, but not access to the "Preliminary Design" folder. After mapping, a structured project data pool is generated. This is essentially a virtual project space with complete permission attributes, providing a secure and orderly container for all subsequent file storage, collaborative interactions, and data flow, ensuring that data is under control from the outset.

[0035] Step S102: Receive the original project files uploaded by the participating terminal, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifiers. Once the structured project data pool is ready, the system enters the actual workflow. When each participant uploads original project files (such as DWG drawings, RVT models, and PDF documents) via their terminals, the system does not store the entire file repeatedly.

[0036] Specifically, calling a distributed storage service means that the file is divided into multiple data blocks and distributed across a cluster of nodes. This not only improves storage reliability and read performance but also lays the foundation for efficient processing. The principle of incremental processing and version recording is that the system calculates the hash value difference between the newly uploaded file and the latest version of the file already existing in the cloud. Through data deduplication technology, only the changed data blocks are identified and stored, rather than the entire file. Each commit generates a version snapshot pointing to the new data blocks and the original unchanged data blocks, and tagged with a "version identifier" (e.g., v1.0, v1.1).

[0037] Ultimately, the generated cloud-based file repository with version identifiers is essentially a version map composed of full versions and incremental differences. Any user can view historical versions, compare differences, or revert to a specific version with a single click at any time. This fundamentally solves the core pain points of version chaos and difficulty in tracing during engineering collaboration, and greatly saves storage space and network transmission bandwidth.

[0038] Step S103: In response to the model interaction request initiated by the client, the lightweight engine is called to parse the engineering file data in the cloud file library, construct the mapping relationship between the two-dimensional drawing data and the three-dimensional model data, and generate a two-dimensional and three-dimensional linked view. When a user (such as a drawing review engineer) initiates a model interaction request on the web or mobile device, the system calls the lightweight engine to process the original heavy engineering files in the cloud file library.

[0039] Specifically, the core principle of the lightweight engine is model-data separation and real-time rendering optimization: by parsing the original 3D model file, its geometric information, attribute information, and logical relationships are stripped and reorganized to generate a lightweight format file with a very small data size. It also supports Level of Detail (LOD) technology, dynamically loading models of different precision based on view distance to ensure smooth browsing of large-scale, multi-disciplinary models. For 2D drawings, vectorization is performed. Based on this, the lightweight engine constructs a mapping relationship between 2D drawing data and 3D model data. This relationship can be established in two main ways: first, based on the unique component ID, binding a component in the 3D model (such as a window) to its primitives in the 2D plan, elevation, and section views; second, based on spatial coordinate mapping, establishing a correspondence between the 2D view and 3D space.

[0040] Ultimately, the generated 2D and 3D linked views allow users to click on a graphic element on a 2D drawing, and the 3D view automatically highlights and locates the corresponding component, and vice versa. This achieves true drawing-model consistency checking, upgrading traditional 2D drawing review to an immersive, interactive 3D digital prototype review, greatly improving the efficiency and accuracy of problem detection.

[0041] Step S104: When a user's annotation command initiated based on a 2D or 3D linked view or cloud file library is detected, a structured problem record is generated and a problem tracking instance is created. The problem tracking instance is associated with the responsible person information and status transition field. When the system detects annotation commands initiated by the user based on the 2D or 3D linked view or cloud file library (such as circling on the model or adding annotations to the drawing), it will generate a structured problem record. This means that scattered annotation information (such as location coordinates, screenshots, voice, and text) will be automatically filled in according to a preset template (such as problem description, professional category, severity level, associated files and versions) to form a standard data record that can be processed by the machine.

[0042] Simultaneously, the system creates issue tracking instances based on the pre-defined responsibility matrix in the project permission tree or the professional affiliation of the files, and associates them with specific responsible personnel. Each instance has a built-in status transition field, with a typical lifecycle of "New (Pending) -> Assigned -> Processing -> Resolved -> Reviewed -> Closed." This state machine drives a closed-loop issue management process, transforming informal, easily overlooked communication into standardized, assignable, traceable, and statistically significant task items, ensuring that every discovered issue is followed up by a responsible person and ultimately resolved.

[0043] Step S105: Obtain interaction data during project collaboration, drive the meeting management module to generate electronic meeting minutes, and associate and bind the electronic meeting minutes with the issue tracking instance; The interactive data generated during project collaboration includes, but is not limited to, generated issue logs and their status transition logs, file upload and download records, and user login and operation behaviors. This aggregated data can drive the meeting management module to generate electronic meeting minutes. For example, the system can automatically summarize all issues in the "pending resolution" status up to the meeting start date and pre-populate them into the meeting agenda.

[0044] When a meeting is created, the system can automatically associate or suggest responsible persons for relevant issues as participants based on the agenda. During the meeting, the recorder can directly reference specific issue examples for discussion within the system, and the resulting resolutions and to-do items can be recorded in a structured manner. After the meeting, the electronic meeting minutes are linked to the issue tracking instance, meaning that the meeting's conclusions can directly update the status of the associated issue (e.g., set to "Resolved"), and the meeting minutes are permanently attached as an attachment to that issue record. By strongly linking meeting conclusions with specific to-do tasks (issues), a complete digital management loop is formed: "Identify Issues -> Discuss in Meetings -> Form Resolutions -> Follow Up on Tasks -> Close Issues."

[0045] Step S106: In response to the project delivery instruction, collect the target files according to the standardized catalog framework, perform packaging and encryption processing on the target files, and generate a digital delivery package.

[0046] When a project reaches a milestone or is finally completed, the project manager issues a project delivery instruction. At this point, the system does not simply package all files, but instead organizes the target files according to a standardized directory framework. This framework is the structured directory that was initially created and runs throughout the project. The system automatically collects the final valid versions (usually the latest release or versions with specific markings) of files from each stage, profession, and type according to this framework, ensuring the integrity and organizational standardization of deliverables, and completely replacing the massive amount of tedious manual work of collecting, organizing, and verifying.

[0047] Next, the collected file set is packaged and encrypted. Packaging is to create a single, easily transmitted and managed deliverable; encryption is to protect intellectual property and data security, potentially using symmetric encryption algorithms to encrypt the package body and combining them with asymmetric encryption technology to manage key distribution. The final digital delivery package is a complete, independently distributable data asset package containing all design deliverables and process collaboration traces. It can be directly submitted to the owner or next-stage participants, laying the foundation for the digital operation and archiving of the project.

[0048] The above implementation methods have achieved a fundamental transformation in the collaboration among multiple stakeholders in construction projects. Integrating permissions and data ensures the secure and orderly flow of massive amounts of project data within complex collaborative networks; incremental storage and 2D / 3D linkage solve the technical bottlenecks in the storage, transmission, and efficient review of large-scale engineering data; by transforming unstructured communication (annotations, meetings) into structured, traceable data (problem examples, meeting minutes), the standardization and automation of collaborative processes are achieved, improving decision-making efficiency and execution rates; finally, automated collection and packaging based on the initial framework ensures the quality and consistency of deliverables, forming an end-to-end digital closed loop from design to delivery.

[0049] In practical applications, this technical solution not only improves the efficiency of individual work, but more importantly, it reconstructs cross-organizational and cross-stage collaborative production relationships through data-driven approaches, accumulating reusable digital assets for enterprises. It is a core tool for promoting the digital and intelligent transformation of the engineering and construction industry.

[0050] As one implementation of the project permission tree, the project permission tree contains three levels of permission nodes: system-level permission nodes, project-level permission nodes, and folder-level permission nodes. Reference Figure 2As one implementation of step S101, the step of mapping the project permission tree to a standardized directory framework throughout the project lifecycle includes: Step S201: Construct a system-level permission node to configure the global management roles and functional permissions of participating enterprises; Specifically, in a cloud-based collaborative environment involving multiple independent companies (such as the construction company, the general design contractor, various subcontractors, and the supervision company), the primary task is to reconstruct and define the organizational boundaries and overall responsibilities of each participant in the virtual space.

[0051] In this embodiment, system-level permission nodes are used to configure the global management roles and functional permissions of participating enterprises. Specifically, at the system level, one or more advanced management roles (e.g., company super administrator, company archivist) are preset or assigned to each participating enterprise. These roles possess platform-level, macro-level permissions that do not directly affect specific business data. Examples include: managing the platform accounts of all personnel within the company; viewing an overview of all projects the company participates in; configuring the company's default project templates or standards; and receiving platform-level announcements and notifications. This level of permission constitutes the administrative framework of the entire collaboration system, clarifying the basic positioning and jurisdiction of each party within the digital platform.

[0052] Step S202: Construct project-level permission nodes to assign operation permissions to participants within the corresponding project in the project data pool. Operation permissions include viewing, editing, downloading, and approval permissions. Within a specific construction project space, project-level permission nodes are constructed, the logic of which is to realize the conversion and authorization from enterprise identity to project role.

[0053] In this embodiment, when an employee of an enterprise enters a project corresponding to a project data pool, their permissions need to be redefined based on their specific responsibilities within that project. The project-level permission node is the mechanism for this redefinition; it is used to assign operational permissions to participating personnel within the corresponding project of the project data pool. These defined operational permissions are directly related to the user's behavioral capabilities within the project data pool.

[0054] For example, a "design manager" role could be assigned "view, download, and approve" permissions for all files within a project, but might not be granted "edit" or "delete" permissions; while a "structural designer" might only have "view, edit, and upload" permissions within their assigned professional directory. This hierarchical mapping is key to combining the project organizational structure with a digital permission model, ensuring that personnel from different companies and professions within a shared project space have their data operation scope clearly defined within their responsibilities. This avoids the risk of unauthorized access and ensures smooth collaborative work.

[0055] Step S203: Construct folder-level permission nodes to control the file access scope under the corresponding project directory of the project data pool.

[0056] The logic behind building folder-level permission nodes is to implement the most granular data asset protection and sharing strategy. In engineering projects, even within the same project phase and the same profession, different files (such as process sketches, submitted drawings, and final drawings) have different sensitivity and maturity levels, requiring differentiated access control.

[0057] In this embodiment, the folder-level permission node is used to control the file access scope under the project directory corresponding to the project data pool. This is a further refinement and exception management of project-level permissions. Through this level of node, the system administrator can set special access rules for a specific folder (e.g., " / Preliminary Design / Architectural / Tender Drawings"). For example, it can be stipulated that only the "Construction Party Representative" and the "Project Manager" have permission to view the folder, while other designers cannot access it.

[0058] Understandably, this folder-level permission system covers general project-level rules, enabling flexible responses to real-world business scenarios such as "provisionally releasing deliverables to specific stakeholders" and "protecting tender price information." Its tight integration with a standardized directory framework allows permissions to be precisely attached to different branches of the project's data structure, like tags, achieving a deep alignment between data security policies and business workflows.

[0059] In the above implementation, system-level nodes establish enterprise-level entry points, project-level nodes define an individual's basic job and capabilities within the project, and folder-level nodes apply dynamic and granular access rules based on the specific attributes of the data and the business stage. Mapping this permission tree to a standardized project directory framework essentially binds a dynamic and traceable access control list to every data asset generated throughout the project's lifecycle from its inception. This is not only a technical prerequisite for enabling multi-party cloud collaboration but also directly supports the secure and reliable operation of all subsequent collaborative processes, including file version management, review and annotation, meeting decisions, and delivery.

[0060] Reference Figure 3 As one implementation of step S102, the step of calling the distributed storage service to perform incremental processing and version recording on the original project files to generate a cloud file library with version identifiers includes: Step S301: Extract the metadata information of the original project file; When a participant (such as a designer) uploads the original project file via a terminal, the system first extracts the metadata information of the original project file.

[0061] Specifically, metadata describes the characteristics of a file itself, rather than the file's main content. For engineering files, typical metadata includes, but is not limited to: filename, file type (e.g., .dwg, .rvt), file size, last modification time, and key attributes added by the system or user, such as project ID, specialty (architecture / structure), stage (scheme / construction drawings), and a unique hash value calculated based on the file content (e.g., SHA-256). The purpose of extracting metadata is to establish a foundation for fast indexing and comparison in subsequent steps. It creates a unique digital fingerprint and attribute tag for the file, enabling the system to quickly and accurately locate its associated historical records in massive files. This is a prerequisite for subsequent intelligent version comparison and avoids the inefficient operation of blindly performing a full database scan.

[0062] Step S302: Query the historical version file library based on metadata information to obtain the baseline version file associated with the original project file; Specifically, based on the extracted metadata, the system enters the version association judgment stage, and obtains the baseline version file associated with the original project file by comparing key identifiers in the metadata (such as project ID + file path + file name, or content hash value).

[0063] The baseline version file typically refers to the latest version of the file in the cloud file repository, or a historical version that the user explicitly specifies as the basis for modification. This step determines the "parent node" of the currently uploaded file in the linear (or tree-like) version history, establishing an accurate comparison object for subsequent difference calculations. If no baseline version is found (i.e., the file is being uploaded for the first time), it is considered the initial version, and subsequent difference calculations will be based on an empty file.

[0064] Step S303: Call the distributed storage engine to calculate the hash difference between the original project file and the baseline version file, and identify the set of difference data blocks; Among them, the distributed storage engine means that computing tasks may be scheduled to be processed in parallel across multiple nodes in the cluster to handle large engineering files (such as BIM models of several gigabytes).

[0065] In this embodiment, a content chunk hash comparison strategy can be adopted: first, the baseline version file and the currently uploaded original file are respectively divided into fixed-size or variable-size data blocks; then, a cryptographic hash value (such as MD5 or SHA-1) is calculated for each data block, which can be regarded as the unique fingerprint of the data block. By comparing the hash value sets of all data blocks of the two files, the engine can quickly identify the set of differing data blocks, that is, those data blocks whose hash values ​​do not match. These differing blocks represent the content parts that have actually changed in this file update.

[0066] In this way, the system does not need to transmit and store the entire new file, but only needs to focus on the changed data segments, which saves a huge amount of network bandwidth and storage space for frequent updates of massive engineering files.

[0067] Step S304: Compress the set of differential data blocks to generate incremental data packets; After identifying the set of difference data blocks, the system does not directly store these raw difference data. To further optimize storage efficiency, the set of difference data blocks is compressed.

[0068] Specifically, compression uses general-purpose (such as DEFLATE) or specialized compression algorithms tailored to the characteristics of engineering data to eliminate statistical redundancy and reduce the physical space it occupies. The incremental data packet generated after compression is a smaller packet containing only the changed content and with optimized encoding. This incremental data packet, combined with the base version file, can completely reconstruct the content of the latest version of the file.

[0069] Step S305: Store the incremental data packet to the distributed storage node and generate a version snapshot containing the storage location index; In this system, distributed storage nodes are the physical or virtual units that make up the storage cluster. Data is sharded, replicated, and stored on different nodes to ensure high reliability and high availability. Simultaneously, the system generates version snapshots that include storage location indexes.

[0070] In this application embodiment, the version snapshot is a key logical concept in version management. It is not a complete file copy, but a lightweight "metadata record" or "pointer mapping table". It records: which data blocks constitute the current version (including unchanged blocks inherited from the base version and incremental blocks added this time), the specific physical location index of these data blocks in the distributed storage cluster, and the metadata information of this version (such as creator and time).

[0071] Step S306: Update the file version map according to the version snapshot. The file version map includes version identifier, timestamp and parent version pointer. Each version snapshot is a node in the graph. The system updates the file version graph based on the version snapshot, creating a new graph node for this update. This node (i.e., a record in the graph) contains several key fields: "Version Identifier" is the node's unique ID, usually an incrementing sequence number or semantic tag (e.g., v1.0.2); "Timestamp" records the moment the version was created; and "Parent Version Pointer" points to the node of its base version (i.e., the version determined in step (2)) in the graph. Through the "Parent Version Pointer," all version nodes are connected into a directed acyclic graph, clearly showing all the evolution paths of the file from creation to the current state. This allows the system to easily perform version backtracking, compare the differences between any two versions, and view the complete modification history.

[0072] Step S307: Construct a cloud-based file library with version identifiers based on the file version map.

[0073] The cloud file repository is a logically unified view; it's not a folder storing complete files for all versions, but rather a virtual repository intelligently organized by a file version graph. When a user requests to view or download a specific version (e.g., v1.5), the system locates the v1.5 version snapshot node through the graph. Based on the storage location index in that snapshot, it retrieves all the data blocks required to construct that version (including the initial block and all previous incremental blocks) from the distributed storage nodes, quickly reassembles them in memory or cache, and instantly generates a complete file presented to the user. All versions are clearly marked and managed in the graph and user interface through their version identifiers, making the user feel as if they are operating a repository containing complete files for all historical versions, while in reality, the system maintains all of this with extremely high storage efficiency at the underlying level.

[0074] The above implementation transforms the traditional coarse-grained model of storing all data at the "file" level into a fine-grained model of incremental storage at the "data block" and "version relationship" level. This solution achieves significant savings in storage space and network bandwidth, storing and transmitting only changed data blocks, which is of great significance for frequently modified GB-level project files. Secondly, by constructing a structured file version graph, it achieves visualization, traceability, and rapid rollback of version history, greatly enhancing the clarity and reliability of project data management. Finally, this mechanism provides a solid foundation for cloud collaboration, making asynchronous editing, version merging, and conflict resolution of the same file by multiple users efficient and orderly.

[0075] Reference Figure 4As one implementation of step S103, in response to a model interaction request initiated by the client, the lightweight engine is invoked to parse the engineering file data in the cloud file library, construct the mapping relationship between the two-dimensional drawing data and the three-dimensional model data, and generate a two-dimensional and three-dimensional linked view. Step S401: Receive the model interaction request initiated by the client and extract the target project file identifier contained in the model interaction request; When a user (such as a designer, reviewer, or construction worker) initiates a model interaction request on a client (such as a web browser, mobile app, or professional software plugin), this request is essentially an intentional instruction to view and manipulate a specific engineering model.

[0076] In this embodiment, after receiving the request, the core operation of the system is to extract the target project file identifier contained in the request. This identifier is the unique identity credential of the target file in the cloud file library. It can be a unique ID (UUID) assigned by the system, or a composite key composed of elements such as project code, specialty, stage, and file name.

[0077] Specifically, the logic of extracting identifiers lies in transforming the user's vague interaction intent (such as "I want to see the construction drawing model of the main building of Project A") into a query command that the system can accurately locate. This ensures that all subsequent data processing targets the accurate set of files, which is the foundation for achieving efficient and accurate data retrieval and avoids confusion caused by incorrect file pointers.

[0078] Step S402: Based on the target project file identifier, call the lightweight engine to parse the corresponding project file data from the cloud file library. The project file data includes 3D model files and 2D drawing files. The lightweight engine is a core processing module. Its primary task is not to directly simplify the model, but rather to act as a "translator," responsible for reading and understanding the raw, proprietary, and massive amounts of data generated by different design software (such as AutoCAD, Revit, Tekla, etc.) in the form of "3D model files" (e.g., .rvt, .dgn) and "2D drawing files" (e.g., .dwg, .pdf). It reads the binary streams of these files from a cloud file library and parses out their internal data structures, layers, views, component attributes, and other information, converting them from software-specific encapsulation formats into a standardized intermediate data format that the engine can process.

[0079] Step S403: Perform lightweight processing on the 3D model file, separate geometric data and material data, and generate compressed lightweight model data; The core technical principle of lightweight processing is to separate geometric data from material data. Geometric data defines the spatial information such as the shape, position, and size of each component in the model, and usually exists in the form of a triangular mesh; material data defines the appearance information such as the color, texture, and reflective properties of the component surface.

[0080] In this embodiment, the two can be separated and optimized separately: for example, for geometric data, Level of Detail (LOD) technology can be used to generate multiple versions of the same component, ranging from fine to coarse. The system dynamically loads a model of appropriate precision based on the view distance, significantly reducing the computational load of real-time rendering; alternatively, lossless or lossy compression can be performed on mesh data, such as vertex optimization and redundant face removal. For material data, texture image compression, merging, and mapping optimization can be performed.

[0081] Ultimately, the compressed lightweight model data is orders of magnitude smaller than the original file, while preserving the geometric accuracy and visual fidelity of the model to the maximum extent, enabling it to be quickly transmitted over the network and rendered smoothly in real time on the client (especially the browser).

[0082] Step S404: Perform vectorization processing on the two-dimensional drawing file, extract component identification information and spatial location information from the drawing, and generate structured two-dimensional drawing data; The system performs vectorization processing on two-dimensional drawing files. Even for DWG files, which are vector format by themselves, "vectorization" here means the extraction of structured information. Its core is to extract component identification information and spatial location information from the drawings.

[0083] Specifically, component identification information typically refers to attribute labels attached to graphic elements (such as a block representing a door), such as "Door Number M1021," which is crucial for identifying specific engineering components from drawings. Spatial location information refers to the geometric coordinates of the graphic elements in the drawing's coordinate system. Through intelligent analysis of the drawings, the system can identify graphic elements representing components such as walls, columns, doors, windows, and equipment, and extract their IDs and locations, thereby generating structured two-dimensional drawing data. This transforms the drawings from a graphic file into a queryable and indexable structured database containing a list of components and their spatial relationships, creating conditions for association with three-dimensional models.

[0084] Step S405: Based on component identification information or spatial location information, construct the mapping relationship between lightweight model data and structured two-dimensional drawing data; Among these, semantic association based on component identification involves matching the "door number M1021" extracted from the 2D drawing with the "type" or "marker" attribute of the component in the 3D model to establish a one-to-one correspondence. Geometric association based on spatial location involves mapping a point (x, y) on the 2D drawing to a corresponding position (x, y, z) in the 3D model space through coordinate transformation. This usually requires a unified coordinate system and alignment operations.

[0085] Through one or more of the above two methods, the system establishes a bidirectional, mutually searchable index relationship between each three-dimensional component in the "lightweight model data" and the corresponding element or region in the "structured two-dimensional drawing data".

[0086] Step S406: Based on the mapping relationship, generate an interactive two-dimensional and three-dimensional linked view and output it to the client.

[0087] In this process, the rendering engine on the client side (such as a browser that supports WebGL) simultaneously loads and displays a lightweight 3D model and structured 2D drawings (usually in vector overlay or split-screen format). The interactive linkage is driven by an established mapping relationship: when a user selects a pipe in the 3D view, the corresponding pipe and its annotations on the 2D plan are automatically highlighted and centered in the view; conversely, clicking a device symbol on the 2D drawing immediately rotates, scales, and focuses on the 3D model of that device in the 3D view. All user operations, such as rotation, translation, sectioning, and measurement, are simultaneously applied to both views in this linked state. Finally, the output to the client completes the entire closed loop from cloud data processing to end-user interaction.

[0088] The above implementation addresses the long-standing dilemma of "separation of drawings and models" in the construction engineering field. It upgrades the traditional static and isolated review of two-dimensional drawings and browsing of three-dimensional models into a dynamic and intelligently interconnected collaborative workspace. This not only enables large BIM models to run smoothly on lightweight clients through lightweight technology, lowering the technical threshold for collaboration, but also establishes a solid digital link between two-dimensional abstract representations and three-dimensional spatial entities through dual mapping of components and coordinates. This allows design problems to be quickly located and verified across views, improving the efficiency and accuracy of multi-disciplinary collaborative reviews. It serves as a crucial technological foundation for driving the integration and intelligentization of design, construction, and operation and maintenance.

[0089] Reference Figure 5 As one implementation of step S104, when a user's annotation command initiated based on a 2D / 3D linked view or a cloud file library is detected, the steps of generating a structured problem record and creating a problem tracking instance include: Step S501: Detect the annotation command triggered by the user through the client interface in the two-dimensional or three-dimensional linkage view or cloud file library, and obtain the annotation location data and the problem description text entered by the user. When a user triggers an annotation command in the client interface's 2D / 3D linked view (a mapping view of 2D drawings and 3D models built by the lightweight engine) or the cloud file library (a collection of versioned files generated by distributed storage), the system responds to the operation in real time through a front-end event listening mechanism (such as JavaScript's mouse / touch event capture and the coordinate picker of the WebGL view).

[0090] Specifically, in the 2D and 3D linked views, annotation location data needs to undergo coordinate transformation: for 3D model views, the screen pixel coordinates are converted to local coordinates (X / Y / Z values) of model components through the model space coordinate system parsed by the lightweight engine (such as the global coordinate system of a BIM model); for 2D drawing views, the coordinate system of the drawing frame is linked to the component identifier (such as the component identifier information extracted from the 2D drawing). Annotations in the cloud file library are located at specific file nodes (such as entries in the file list or areas in the preview interface), and the location data is represented by file identifiers and relative paths. The problem description text entered by the user is a free description of the problem found at that location, which may involve design conflicts, construction difficulties, code non-compliance, material selection, schedule impact, etc.

[0091] Step S502: Based on the annotation location data, parse the associated project file identifier and spatial coordinate information to generate location-related metadata; The annotation location data (such as 3D coordinates or 2D drawing coordinates) needs to be associated with the project file system: First, based on the structure of the project permission tree mapped to the standardized directory framework, the file level to which the location data belongs (such as the drawing set or design model file in the construction phase) is parsed; Second, the component reverse lookup function of the lightweight engine is called (i.e., the mapping relationship between component identifiers and the unique ID of the lightweight model). If the annotation is located in the 3D model area, the unique ID of the nearest component is matched through coordinate space retrieval, and then associated with its file identifier (such as the GUID of the Revit model file); If it is in the 2D drawing, the component identifier in the drawing is matched through spatial location coordinate mapping (such as the column number KZ-3 marked on the drawing).

[0092] Ultimately, the generated location-related metadata is a structured data package containing file identifiers (such as "Design Phase - Structural Engineering - Structural Engineering - 03.rvt"), spatial coordinates (such as 3D coordinates "X=12500mm, Y=8300mm, Z=3600mm" or 2D drawing coordinates "A3 drawing size - horizontal axis 12.5cm, vertical axis 8.3cm"), view type (2D / 3D), and associated component IDs, providing precise coordinates for problem location.

[0093] Step S503: Invoke the preset problem data structuring rules to perform semantic parsing processing on the problem description text and extract problem type tags and key attribute fields; Among them, the pre-set problem data structuring rules are built on the ontology knowledge base of the construction engineering field, including a problem type system (such as design error, construction conflict, material discrepancy, schedule deviation, etc.) and attribute field templates (such as urgency, scope of impact, and related disciplines).

[0094] In this embodiment, the problem description text can be processed by calling an NLP semantic parsing module (such as a BERT-based domain fine-tuning model) to perform the following: intent recognition to determine the user's core needs (such as "point out the error", "request coordination", "feedback anomaly"); entity extraction to extract key engineering elements (such as component name "KL-5 beam", location "second floor east side", parameter "insufficient reinforcement ratio"); and classification mapping to match text features with problem type labels (such as mapping "insufficient reinforcement ratio" to "design error - structural calculation problem"). Key attribute fields are extracted from the text using a rule engine (such as Drools), for example, "needs to be resolved within 3 days" maps to "urgency level: high", and "affects concrete pouring" maps to "affected scope: construction progress".

[0095] Step S504: Generate a structured problem record based on location-related metadata and key attribute fields; wherein the problem record includes a file identifier, spatial coordinates, problem type, and descriptive summary; Specifically, based on location-related metadata (including file identifiers and spatial coordinates) and key attribute fields (including issue type labels and description summaries), the system integrates and generates issue record data according to a preset data model (such as JSON Schema).

[0096] The descriptive summary is a simplification of the original text (retaining the core issues, location, and requirements). For example, the statement "The reinforcement of the third-floor beam is 2 bars less than the drawings, which may cause problems during tomorrow's pouring" is summarized as "The reinforcement of the third-floor KL-5 beam is missing (the drawings show 4Φ25 bars, but only 2Φ25 bars are actually used), affecting the pouring the next day." Document identifiers and spatial coordinates ensure that issues can be traced back to specific locations in specific engineering documents, and issue types support subsequent responsibility matching and statistical analysis. This data structure achieves a three-dimensional association between "problem phenomenon - spatial location - engineering document," providing a unified cognitive benchmark for cross-disciplinary collaboration.

[0097] Step S505: Based on the preset responsible party matching rules, query the responsible party information associated with the problem type tag; The pre-defined rules for matching responsible persons are derived from the three-level permission node configuration of the project permission tree: system-level permission nodes define enterprise-level roles (such as project manager of the design institute, technical director of the construction unit), project-level permission nodes assign operation permissions and responsibility boundaries within the project corresponding to the project data pool (such as "structural design manager" being responsible for structural issues), and folder-level permission nodes refine the responsible persons for directory files (such as "structural drawing set" being the responsibility of structural engineer Zhang San).

[0098] In this embodiment, the rule engine matches the extracted problem type tags (such as "structural calculation error") with the "role-responsibility mapping table" in the permission tree: for example, "structural calculation error" is associated with the "structural design manager" role, and then queries the person in charge of this role (such as Li Si) in the project-level permission node. If there are multiple responsible parties (such as design and construction collaboration issues), the responsibility chain is returned according to the "primary responsible party - cooperating party" rule to ensure that no problem is missed.

[0099] Step S506: Create an issue tracking instance and bind structured issue records, responsible party information, and initial status transition fields.

[0100] The issue tracking instance is a digital object containing a unique identifier (such as a UUID). Its data structure integrates structured issue record data, responsible party information, and initial status transition fields. The binding process follows the single data source principle: the unique identifier ensures that the instance can be accurately indexed throughout its entire lifecycle; the responsible party information is strongly correlated with the issue type, supporting subsequent status changes (such as "processing" requiring the responsible party to update the solution); the initial status transition fields (such as "new - pending assignment") trigger subsequent processes (such as "multi-terminal synchronization interface" pushing to the responsible party's terminal).

[0101] The above implementation constructs a full-chain digital closed loop for problem feedback in multi-party collaboration during construction projects. It transforms the ambiguity of traditional offline annotations (e.g., "There's a problem in a certain part of the drawing") into a precise four-dimensional positioning based on "file-space-semantics-responsible person." Relying on a lightweight engine and permission tree as underlying support, it achieves seamless connection from problem discovery to tracking. By resolving natural language ambiguity through semantic parsing and a rule engine, combined with the instantiation management of unique identifiers, it makes the problem status flow (annotation → processing → review → closure) traceable and statistically verifiable. Ultimately, this improves cross-disciplinary collaboration efficiency, reduces communication costs, and provides data-driven decision-making basis for quality control throughout the project lifecycle.

[0102] Reference Figure 6 As a further implementation of the cloud-based collaborative management method for multi-participant construction projects, after generating structured problem records and creating problem tracking instances in step S104, the following steps are also included: Step S601: Obtain the responsible person information and status transition fields from the issue tracking instance; In this context, obtaining the responsible person information means retrieving the specific responsible person's identifier from the instance, which is automatically assigned or manually specified based on the project responsibility matrix, document ownership, or annotation context. This clarifies the attribution of the problem and the starting point of the driving loop.

[0103] Simultaneously, obtaining the state transition field identifies the current stage of the issue instance within its lifecycle. This field is typically implemented using a finite state machine model, and its value range defines a series of ordered states for the issue, from "New," "Assigned," "Processing," "Pending Review," to "Closed." By obtaining these two fields, the specific operational target (responsible person) and the current process node (state) are identified for subsequent automated processes, providing a decision-making basis for determining whether to proceed with task assignment, progress tracking, or closed-loop verification.

[0104] Step S602: Based on the preset task allocation rule set, process the responsible person information and generate task allocation instructions; In this application embodiment, the preset task allocation rule set is a decision engine with embedded business logic. Its processing logic includes, but is not limited to: professional mapping rules, that is, automatically confirming or fine-tuning the core responsible professional and alternative responsible persons based on problem tags (such as "structural conflict" and "mechanical and electrical integration"); load balancing strategy, that is, querying the number of tasks that each candidate responsible person has not closed and prioritizing the allocation to those with lighter loads to optimize overall efficiency; and urgency and priority rules, taking into account factors such as the severity of the problem and the deadline, affecting the scheduling order of tasks.

[0105] After processing, evaluating, and optimizing the responsible person information using this rule set, a task assignment instruction is generated. This instruction is a structured command object that includes the final identified responsible person, a clear task description, a required completion time, and the associated problem instance ID, providing precise input for subsequent outreach and notification.

[0106] Step S603: According to the task allocation instruction, call the message push service to send a task notification to the responsible person's terminal; Among them, the message push service is a unified communication hub that supports multiple terminals and protocols. Its technical logic lies in channel adaptation and reliable delivery: the service will analyze the current active terminal type (such as Web online or mobile App installation status) based on the identifier of the person in charge in the task instruction, and select the optimal push channel.

[0107] In some embodiments, for online users, real-time pop-up notifications may be delivered via a long-lived WebSocket connection to ensure zero latency; for mobile users, system-level push services such as Apple's App Store Notices (APNs) or Google's Flowcharts (FCM) are integrated, delivering notifications even when the app is in the background; meanwhile, email or SMS often serve as supplementary channels for asynchronous or degraded notifications. The push message content encapsulates the core information of the task and a contextual link that directly locates the associated issue and file, achieving direct "notification-action" communication.

[0108] Step S604: Receive response data returned by the responsible person's terminal, parse the response data to obtain the problem handling progress information; The responsible person submits structured response data to the server by performing operations on the terminal (such as a web interface or CAD plugin) (e.g., clicking "Start Processing", "Submit for Review", or uploading revised files).

[0109] The system then receives and parses the data, including format validation (such as verifying the JSON structure), semantic extraction, and status transition recognition. Extracting issue processing progress information from the response data can yield several key pieces of information: first, explicit operational instructions, such as a status change to "processing"; second, quantitative or qualitative progress, such as completion percentage or textual descriptions; and third, process deliverables, such as the version number of newly submitted files or annotation responses.

[0110] Step S605: Update the status transition field according to the problem handling progress information to generate the updated status transition field; The system predefines rules for state transitions (e.g., a state can only transition from "Assigned" to "Processing," and from "Processing" to "Pending Review"). Operation instructions in the progress information (such as "Submit for Review") will serve as events triggering state transitions. The system will verify whether the transition is allowed, and upon successful verification, update the value of the state transition field to the target state (e.g., update to "Pending Review").

[0111] Finally, an updated status transition field is generated. This new field not only contains the new status value, but also often records the timestamp of this status change, the operator, and the associated progress information summary or version number, forming a complete status change history log. This ensures that every stage of the issue's lifecycle is traceable, achieving transparency and traceability of the process.

[0112] Step S606: When it is detected that the updated status transition field meets the preset closed-loop triggering condition, retrieve the file version data associated with the issue tracking instance from the cloud file library; The preset closed-loop triggering conditions are key business rules, such as the status changing to "pending review" or "resolved," and all associated subtasks being completed. Once the system detects that the status field meets these conditions, it automatically triggers the closed-loop verification process.

[0113] Next, the system retrieves file version data associated with the issue tracking instance from the cloud file repository. The logic behind this is to obtain two specific versions for comparison: one is the original file version referenced when the issue was created (as the baseline version), and the other is the latest, revised file version after the issue was resolved. By associating the issue instance with the file version control system, the system can accurately trace and extract the data from these two versions, preparing for the next step of objective technical comparison.

[0114] Step S607: Perform version comparison analysis on the file version data and generate a file difference analysis report; Version comparison analysis is an in-depth analysis of engineering drawings and model data. For example, for two-dimensional vector drawings, layer-level and element-level geometric and attribute differences are performed to accurately identify the movement, deletion, addition, or attribute changes of lines; for three-dimensional building information models, component-level comparison is performed, and the addition, deletion, and modification of components, as well as changes in parameters (such as dimensions and elevations), are identified through the globally unique ID of the components.

[0115] Ultimately, the comparison engine deeply analyzes the data, transforming binary or proprietary format differences into readable, semantic change descriptions, generating a file difference analysis report. This report, combining structured data (such as JSON) and visual views (such as lightweight models highlighting changes), clearly demonstrates the specific modifications made to the design documents from the time the issue was raised to its resolution. This provides a technical basis for determining whether the issue has been correctly and completely fixed.

[0116] Step S608: Update the issue tracking instance based on the document difference analysis report and generate a closed-loop confirmation signal.

[0117] Specifically, the update process includes: archiving the discrepancy report as the most important attachment to the issue instance, and finally marking the status as "closed" or "verified". Simultaneously, the system generates a closed-loop confirmation signal.

[0118] In this embodiment, the closed-loop confirmation signal is an event notification with broad ripple effects. It may trigger a series of subsequent actions: automatically sending a formal notification of issue closure to all relevant participants; driving the project management dashboard to update quality metrics (such as the number of closed issues); or archiving the complete record of this issue handling (including the original issue, discussion, and final discrepancy report) to the project knowledge base. This closed-loop confirmation signal signifies that the issue has not only ended procedurally but has also passed technical verification in substance, and its handling process and results have become reusable digital assets for the project.

[0119] The above implementation method achieves a fundamental shift in project problem management from manual supervision to data-driven approaches. Through an intelligent rule engine and multi-terminal push services, it ensures the rationality of task allocation and the delivery of notifications, improving response and processing efficiency. By solidifying unstructured progress communication into parsable status and data, it achieves transparency and real-time monitoring of the processing process. Crucially, through automated document version comparison and analysis, it transforms the traditional subjective acceptance process, which relies on personal experience, into objective technical verification based on precise data difference analysis, improving the quality and credibility of the closed-loop process.

[0120] In practical applications, this technical solution not only ensures that every problem discovered can be effectively tracked and resolved, eliminating omissions, but also transforms scattered communication and processing processes into structured project data assets. This provides a solid data foundation for continuous quality improvement, accountability clarification, and enhanced collaborative efficiency, and is a key technical support for the digital collaboration and refined management of modern large-scale engineering projects.

[0121] Reference Figure 7 As one implementation of step S106, in response to a project delivery instruction, the steps of collecting target files according to a standardized catalog framework, packaging and encrypting the target files, and generating a digital delivery package include: Step S701: In response to the project delivery instruction, parse the project identifier and delivery phase identifier contained in the project delivery instruction; Among them, project delivery instructions originate from the proactive actions of project management personnel, or are automatically generated by the system when it detects that the project state machine has reached a preset milestone (such as "design completed" or "completion").

[0122] Specifically, the project identifier serves as the unique coordinate of this delivery task among numerous parallel projects, ensuring that operations target the correct objective. The delivery phase identifier defines the business context and scope depth of this delivery.

[0123] Understandably, construction projects have distinct phases (such as scheme, preliminary design, construction drawings, and completion), and the scope of deliverables, document types, and version maturity requirements for each phase are vastly different. By analyzing these two core parameters, we can essentially set a precise "project address" and "delivery blueprint" for subsequent automated processes, laying the foundation for accurately locating targets from massive amounts of data.

[0124] Step S702: Based on the project identifier and delivery phase identifier, locate the target delivery directory level in the standardized directory framework; The standardized directory framework is a predefined file organization logic that runs through the project lifecycle, ensuring that all files are organized in an orderly manner according to the rules of "project-specialty-stage-file type" from the moment they are generated.

[0125] In this embodiment, abstract delivery stage identifiers (such as "construction drawing delivery") are mapped to specific directory path nodes in the framework (such as " / project A / 02-construction drawing design / architectural specialty / drawings"). This location operation does not blindly search in the file system, but directly and quickly addresses the structured directory metadata, thus determining the precise collection range for subsequent file aggregation operations.

[0126] Step S703: Extract the associated file metadata set from the project data pool according to the target delivery directory level; The project data pool serves as the central repository for storing all project files and their attribute information. Based on a defined directory path, the database queries the data pool for metadata of all files within that path (and its subdirectories). This metadata consists of descriptive information about the files, typically including filename, file ID, version number, file status (e.g., "Under Work," "Under Approval," "Released"), last modified time, responsible party, file size, and associated issue tracking number. Extracting the metadata set rather than the files themselves is an efficient preprocessing strategy, providing a lightweight, structured decision-making basis for the subsequent rule-based intelligent filtering.

[0127] Step S704: Based on the preset delivery rule set, perform filtering and verification on the file metadata set to generate a target file set that meets the delivery conditions; The pre-defined delivery rule set is the business logic embedded in the system, which defines the stringent standards for becoming a qualified deliverable. These rules typically include: the document status must be "released" or "final"; the document must have gone through the necessary approval process; any "issue tracking instances" associated with the document must be in a "closed" state; and may also include requirements for the document version number (the latest version), professional completeness, etc.

[0128] In this embodiment, the system automatically compares and verifies the metadata of each extracted file with this set of rules, filtering out all files that do not meet the conditions (such as intermediate drafts, unapproved drafts, and drawings with unresolved related issues). Finally, a set of target files that meet the delivery conditions is generated. This list ensures that every file to be packaged and delivered is a confirmed, valid, and mature final product, fundamentally eliminating the risk of mistakenly delivering incorrect versions or incomplete files.

[0129] Step S705: Perform format conversion processing on the files in the target file set to generate a standardized file set with a unified encoding format; In the construction engineering field, original design file formats (such as AutoCAD's DWG and Revit's RVT) rely on specific commercial software, posing risks to version compatibility and long-term readability. This step converts the selected files into an open, standard format suitable for long-term archiving and widespread distribution by performing format normalization.

[0130] For example, converting 2D drawings to PDF / A (the PDF standard suitable for long-term archiving), converting 3D BIM models to the industry-standard IFC format or the web-friendly GLTF format, and converting office documents to PDF. This process not only changes the file extension but may also involve font embedding, data optimization, version downgrading, and other operations to ensure that the standardized set of files in the generated unified encoding format can be reliably opened and interpreted on different platforms and at different times, thus guaranteeing the availability of digital assets throughout their entire lifecycle.

[0131] Step S706: Call the packaging service to perform data encapsulation on the standardized file set and generate an unencrypted intermediate delivery package; The packaging service is a dedicated module whose core logic is as follows: First, it reconstructs the logical directory tree of files in memory according to the hierarchical structure of the original standardized directory framework. Then, it compresses the data stream of each file using a lossless compression algorithm (such as the DEFLATE algorithm used in the ZIP format) to significantly reduce the overall size. Finally, it writes the compressed data stream of all files, along with the directory structure information, into a single container file, thereby generating an unencrypted intermediate delivery package (usually a .zip or .tar file). This intermediate package contains all the delivery content and is a complete data unit, suitable for single transmission and storage, but it has not yet been subjected to final security protection.

[0132] Step S707: Perform encryption operations on the unencrypted intermediate delivery packet according to the preset encryption strategy to generate an encrypted data packet; In order to ensure the security of core intellectual property rights and sensitive project information during delivery, transmission and subsequent storage, cryptographic protection must be applied to data packets.

[0133] Specifically, the preset encryption strategy defines the security strength and implementation method. A common strategy is to use a hybrid encryption system: first, a high-performance symmetric encryption algorithm (such as AES-256) is used to encrypt the entire intermediate delivery packet, generating an encrypted data stream; then, the public key of the authorized recipient (usually the owner) (based on an asymmetric encryption algorithm such as RSA or ECC) is used to encrypt the key used for the aforementioned symmetric encryption. The final encrypted data packet is unreadable ciphertext without the corresponding private key.

[0134] Step S708: Attach delivery metadata tags to the encrypted data packets to generate a digital delivery packet.

[0135] The delivery metadata tag is structured information describing the attributes of the delivery package itself, typically existing as a separate file or in the package header. Its content includes: project identifier, delivery stage, delivery package generation time, version, overview of included file lists, encryption key identifier, and a crucial cryptographic hash value (such as SHA-256). This hash value is calculated from the content of the encrypted data packet and serves as a unique digital fingerprint for the data packet.

[0136] After being tagged, the resulting digital delivery package becomes a self-describing, verifiable, and traceable composite digital object. The recipient can not only learn about the basic information of the package through metadata, but also verify whether the delivery package is complete and has not been tampered with after transmission or storage by recalculating and comparing hash values.

[0137] In the above implementation, project delivery is transformed from a labor-intensive, unpredictable terminal task into a reliable, secure, and standardized system service. Precise location based on a standardized catalog and metadata verification based on rule sets enable automated and accurate aggregation of delivered content, ensuring the integrity and compliance of results and eliminating human error. Mandatory format standardization unifies data output, eliminating technical barriers to downstream reception and application, and safeguarding the long-term value of assets. Compression, encapsulation, and encrypted computation improve transmission efficiency while building a strong security barrier, protecting core digital assets. Finally, by attaching structured delivery metadata tags, a self-manageable, verifiable, and clearly defined standardized digital asset package is generated.

[0138] In practical applications, this technical solution not only improves the efficiency and reliability of the delivery phase, but more importantly, the final digital delivery package is itself a high-quality digital asset that can be directly used for subsequent operation, maintenance, renovation or archiving. It is a key closed loop for achieving full life-cycle digital management in the construction engineering field.

[0139] This application also discloses a cloud-based collaborative management system for multiple participants in construction projects.

[0140] A cloud-based collaborative management system for multi-participant construction projects, specifically including: The project permission and directory initialization module is used to obtain the configuration information of the construction project, build the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool. The file version management module is used to receive the original project files uploaded by the participating parties' terminals, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifiers. The 2D / 3D intelligent linkage review module is used to respond to model interaction requests initiated by the client, call the lightweight engine to parse the engineering file data in the cloud file library, build the mapping relationship between 2D drawing data and 3D model data, and generate 2D / 3D linkage views. The issue tracking and closed-loop management module is used to generate structured issue records and create issue tracking instances when an annotation command initiated by a user based on a 2D or 3D interactive view or a cloud file library is detected. The issue tracking instance is associated with the responsible person information and status flow fields. The intelligent meeting decision-making linkage module is used to acquire interaction data during project collaboration, drive the meeting management module to generate electronic meeting minutes, and associate and bind the electronic meeting minutes with issue tracking instances; The digital delivery package generation module is used to respond to project delivery instructions by collecting target files according to a standardized directory framework, packaging and encrypting the target files, and generating a digital delivery package.

[0141] The cloud-based collaborative management system for construction projects according to this application can implement any of the above methods, and the specific working process of each module in the system can refer to the corresponding process in the above method embodiments.

[0142] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0143] This application also discloses a computer device.

[0144] Computer equipment, including memory, processor, and computer program stored on memory and executable on processor, wherein the processor executes the computer program to implement a cloud-based collaborative management method for multi-participant construction projects as described above.

[0145] This application also discloses a computer-readable storage medium.

[0146] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above in any of the multi-participant cloud-based collaborative management methods for construction projects.

[0147] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0148] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A cloud-based collaborative management method for multiple participants in construction projects, characterized in that: The method includes: Obtain the configuration information of the construction project, construct the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool; Receive the original project files uploaded by the participating terminal, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifier; In response to the model interaction request initiated by the client, the lightweight engine is invoked to parse the engineering file data in the cloud file library, construct the mapping relationship between the two-dimensional drawing data and the three-dimensional model data, and generate a two-dimensional and three-dimensional linked view; When a user's annotation command based on the two-dimensional or three-dimensional interactive view or cloud file library is detected, a structured problem record is generated and a problem tracking instance is created. The problem tracking instance is associated with the responsible person information and the status transition field. The system acquires interaction data during project collaboration, drives the meeting management module to generate electronic meeting minutes, and associates and binds the electronic meeting minutes with the issue tracking instance. In response to the project delivery instruction, target files are collected according to the standardized directory framework, and the target files are packaged and encrypted to generate a digital delivery package. In response to a model interaction request initiated by the client, the lightweight engine is invoked to parse the engineering file data in the cloud file library, construct a mapping relationship between 2D drawing data and 3D model data, and generate a linked 2D / 3D view. The steps include: Receive a model interaction request initiated by the client, and extract the target project file identifier contained in the model interaction request; Based on the target project file identifier, the lightweight engine is invoked to parse the corresponding project file data from the cloud file library. The project file data includes 3D model files and 2D drawing files. The 3D model file is subjected to lightweight processing to separate geometric data and material data, generating compressed lightweight model data; The two-dimensional drawing file is vectorized to extract component identification information and spatial location information from the drawing, and structured two-dimensional drawing data is generated. Based on the component identification information or spatial location information, a mapping relationship is constructed between the lightweight model data and the structured two-dimensional drawing data; Based on the mapping relationship, an interactive 2D / 3D linked view is generated and output to the client. In the 2D / 3D linked view, selecting a component in the 3D model can automatically highlight and locate the corresponding element in the 2D drawing. Clicking on an element in the 2D drawing can automatically rotate, scale, and focus on the corresponding component in the 3D model.

2. The cloud-based collaborative management method for multi-participant construction projects according to claim 1, characterized in that, The project permission tree contains three levels of permission nodes: system-level permission nodes, project-level permission nodes, and folder-level permission nodes. The steps to map the project permission tree to a standardized directory framework throughout the project lifecycle include: Build system-level permission nodes to configure the global management roles and functional permissions of participating enterprises; Construct project-level permission nodes to assign operation permissions to participants within the corresponding project in the project data pool. These operation permissions include viewing, editing, downloading, and approval permissions. Create folder-level permission nodes to control the file access scope in the corresponding project directory of the project data pool.

3. The cloud-based collaborative management method for multi-participant construction projects according to claim 2, characterized in that, The steps of calling a distributed storage service to incrementally process and record versions of the original project files, generating a cloud file repository with version identifiers, include: Extract the metadata information from the original project file; Based on the metadata information, query the historical version file library to obtain the baseline version file associated with the original project file; The distributed storage engine is invoked to calculate the hash difference between the original project file and the baseline version file, and the set of differing data blocks is identified. The set of differential data blocks is compressed to generate incremental data packets; The incremental data packets are stored in a distributed storage node, and a version snapshot containing the storage location index is generated; The file version graph is updated based on the version snapshot, and the file version graph includes a version identifier, a timestamp, and a parent version pointer. A cloud-based file library with version identifiers is constructed based on the file version map.

4. The cloud-based collaborative management method for multi-participant construction projects according to claim 1, characterized in that, When a user's annotation command based on the 2D / 3D interactive view or cloud file library is detected, the steps to generate a structured issue record and create an issue tracking instance include: The system detects annotation commands triggered by users through the client interface in the two-dimensional or three-dimensional linked view or cloud file library, and obtains annotation location data and user-inputted problem description text. Based on the annotation location data, the associated project file identifier and spatial coordinate information are parsed to generate location-related metadata; The system invokes preset question data structuring rules to perform semantic parsing on the question description text, extracting question type tags and key attribute fields. Based on the location-related metadata and key attribute fields, a structured problem record is generated; wherein, the problem record includes a file identifier, spatial coordinates, problem type, and descriptive summary; Based on preset responsible party matching rules, query the responsible party information associated with the problem type tag; Create an issue tracking instance and bind the structured issue record, responsible party information, and initial status transition fields.

5. A cloud-based collaborative management method for multi-participant construction projects according to claim 4, characterized in that, After generating structured issue records and creating issue tracking instances, the following steps are also included: Obtain the responsible person information and status transition fields from the aforementioned issue tracking instance; Based on a preset set of task allocation rules, the information of the person in charge is processed to generate task allocation instructions; According to the task allocation instruction, the message push service is invoked to send a task notification to the responsible person's terminal; Receive response data returned by the responsible person's terminal, and parse the response data to obtain problem processing progress information; Update the status transition field according to the problem handling progress information to generate the updated status transition field; When the updated status transition field is detected to meet the preset closed-loop triggering condition, file version data associated with the issue tracking instance is obtained from the cloud file library; Perform version comparison analysis on the file version data to generate a file difference analysis report; Update the issue tracking instance based on the document difference analysis report and generate a closed-loop confirmation signal.

6. A cloud-based collaborative management method for multi-participant construction projects according to any one of claims 1 to 5, characterized in that, In response to a project delivery instruction, the steps of collecting target files according to the standardized catalog framework, packaging and encrypting the target files, and generating a digital delivery package include: In response to the project delivery instruction, parse the project identifier and delivery phase identifier contained in the project delivery instruction; Based on the project identifier and delivery phase identifier, locate the target delivery directory level in the standardized directory framework; Based on the target delivery directory hierarchy, extract the associated set of file metadata from the project data pool; The file metadata set is filtered and verified based on a preset delivery rule set to generate a target file set that meets the delivery conditions. Perform format conversion processing on the files in the target file set to generate a standardized file set with a unified encoding format; The packaging service is invoked to perform data encapsulation on the standardized file set, generating an unencrypted intermediate delivery package; The unencrypted intermediate delivery packet is encrypted according to a preset encryption strategy to generate an encrypted data packet; Attach delivery metadata tags to the encrypted data packets to generate digital delivery packets.

7. A cloud-based collaborative management system for multi-participant construction projects, characterized in that: The system is used to execute the multi-participant cloud-based collaborative management method for construction projects as described in any one of claims 1 to 6, the system comprising: The project permission and directory initialization module is used to obtain the configuration information of the construction project, construct the project permission tree based on the preset role access control model, and map the project permission tree to the standardized directory framework of the entire project lifecycle to generate a structured project data pool. The file version management module is used to receive the original project files uploaded by the participating parties' terminals, call the distributed storage service to perform incremental processing and version recording on the original project files, and generate a cloud file library with version identifiers. The 2D / 3D intelligent linkage review module is used to respond to the model interaction request initiated by the client, call the lightweight engine to parse the engineering file data in the cloud file library, construct the mapping relationship between 2D drawing data and 3D model data, and generate a 2D / 3D linkage view. The issue tracking and closed-loop management module is used to generate structured issue records and create issue tracking instances when an annotation command initiated by a user based on the two-dimensional or three-dimensional interactive view or cloud file library is detected. The issue tracking instance is associated with the responsible person information and status transition field. The intelligent meeting decision-making linkage module is used to acquire interaction data during project collaboration, drive the meeting management module to generate electronic meeting minutes, and associate and bind the electronic meeting minutes with the issue tracking instance; The digital delivery package generation module is used to respond to project delivery instructions, collect target files according to the standardized directory framework, perform packaging and encryption processing on the target files, and generate a digital delivery package.

8. A computer device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 6.

Images