Project management system

Abstract

The embodiments of the present description provide a project management system, the system executing the following operations: on the basis of work area data and schedule milestone data of a target project, constructing, in a memory, a data structure of a construction progress matrix; according to an attribute value of a project attribute of the target project, querying a pre-constructed generic document directory repository for a matching candidate project document, so as to generate and store a first document directory in the memory; selecting a second project document from among a plurality of first project documents, and generating a second document directory corresponding to a target matrix cell; monitoring, in real time, the second project document for a state change event by means of a listener deployed on an operational database corresponding to the second project document and designated by a database tag; and in response to detecting the state change event, automatically updating index information corresponding to the second project document in the second document directory.

Description

A project management system Cross-references

[0001] This application claims priority to Chinese patent application No. 202510474190.9, filed on April 16, 2025, and Chinese patent application No. 202511681452.5, filed on November 17, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This manual relates to the field of project management, and in particular to a project management system. Background Technology

[0003] In modern engineering project management, project documents are a crucial component, encompassing numerous types and involving multiple business stages. They cover records from all phases of the project, including design, construction, and supervision, and are closely related to project schedule, quality, and safety. Traditional project document management relies on folder structures for storage and management, making document retrieval cumbersome and inefficient. Furthermore, different business systems store different project documents, hindering unified global management. On the other hand, document storage is often unrelated to project progress, limiting project documents to mere information recording and restricting their broader capabilities.

[0004] Therefore, it is necessary to provide a project management system to improve the efficiency of project document management, and at the same time, to enable project documents to play a greater role by establishing a link between project documents and actual project progress. Summary of the Invention

[0005] This specification provides one or more embodiments of a project management system. The system includes at least one processor and a memory. The memory stores computer instructions that, when executed by the at least one processor, cause the system to perform the following operations: constructing a data structure of a construction progress matrix in the memory based on construction area data and progress node data of a target project. The data structure includes multiple matrix units, each uniquely associated with a construction area and a progress node. Based on the feature values ​​of the target project's project characteristics, querying a pre-built general document directory for matching candidate project documents to generate and store a first document directory in the memory. The first document directory records the text of multiple first project documents corresponding to the target project. The document tags include construction area tags, progress node tags, and database tags that identify the storage location. For a target matrix unit in the data structure of the construction progress matrix, the construction area data and progress node data of the target matrix unit are matched and queried with the construction area tags and progress node tags of the plurality of first project documents to filter out the second project documents and generate a second document directory corresponding to the target matrix unit. A listener deployed on the business database corresponding to the second project document, specified by the database tags, is used to monitor the status change events of the second project document in real time. In response to the monitoring of the status change event, the index information corresponding to the second project document in the second document directory is automatically updated. Attached Figure Description

[0006] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0007] Figure 1 is a schematic diagram of an application scenario of a project management system according to some embodiments of this specification;

[0008] Figure 2 is a schematic diagram of exemplary hardware and software components of an exemplary computing device according to some embodiments of this specification;

[0009] Figure 3 is an exemplary block diagram of a project management system according to some embodiments of this specification;

[0010] Figure 4 is an exemplary flowchart of project management according to some embodiments of this specification;

[0011] Figure 5 is an exemplary flowchart of a storage project document according to some embodiments of this specification;

[0012] Figure 6 is an exemplary schematic diagram of a second document catalog according to some embodiments of this specification;

[0013] Figure 7 is an exemplary schematic diagram illustrating the determination of a first project document and the generation of a first document catalog according to some embodiments of this specification;

[0014] Figure 8 is an exemplary flowchart of construction progress management based on an updated second project document, according to some embodiments of this specification;

[0015] Figure 9 is an exemplary schematic diagram of a progress display table according to some embodiments of this specification;

[0016] Figure 10 is an exemplary flowchart of construction task assignment based on progress according to some embodiments of this specification;

[0017] Figure 11 is an exemplary schematic diagram showing a visual view according to some embodiments of this specification;

[0018] Figure 12 is an exemplary flowchart illustrating the determination of the priority of a first task to be dispatched, according to some embodiments of this specification.

[0019] Figure 13 is an exemplary schematic diagram illustrating the generation of a construction task sheet corresponding to each matrix unit according to some embodiments of this specification;

[0020] Figure 14 is an exemplary flowchart illustrating the reassignment of a second task to be dispatched, according to some embodiments of this specification. Detailed Implementation

[0021] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0022] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0023] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0024] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0025] Figure 1 is a schematic diagram of an application scenario of a project management system according to some embodiments of this specification. As shown in Figure 1, the application scenario of the project management system (hereinafter referred to as application scenario 100) may include a processing device 110, a network 120, a terminal 130, and a database 140. In some embodiments, the project management system may be used to implement the methods and / or processes disclosed in this specification.

[0026] The processing device 110 can be used to process data and / or information from various components and / or external data sources in application scenario 100. Based on this data, information, and / or processing results, the processing device 110 can execute program instructions to perform one or more functions described in this specification. The processing device 110 can execute the project management method described in any embodiment of this specification. For example, processing device 110 can construct a data structure of a construction progress matrix in memory based on the construction area data and progress node data of the target project; query matching candidate project documents from a pre-built general document directory library according to the feature values ​​of the project characteristics of the target project, so as to generate and store a first document directory in memory; for the target matrix unit in the data structure of the construction progress matrix, by matching the construction area data and progress node data of the target matrix unit with the construction area tags and progress node tags of multiple first project documents, a second project document is selected from multiple first project documents, and a second document directory corresponding to the target matrix unit is generated; by using a listener deployed on the business database corresponding to the second project document as specified by the database tag, the status change event of the second project document is monitored in real time; in response to the detection of the status change event, the index information corresponding to the second project document in the second document directory is automatically updated.

[0027] In some embodiments, the processing device 110 may be a single server or a group of servers. In some embodiments, the server may include a processor, and the server group may be centralized or distributed. In some embodiments, the processing device 110 may be local or remote. In some embodiments, the processing device 110 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, or any combination thereof.

[0028] Network 120 may include any suitable network that facilitates the exchange of information and / or data. In some embodiments, one or more components of application scenario 100 may exchange information and / or data via network 120. For example, processing device 110 may obtain index information of a second project document via network 120. Network 120 may include a local area network (LAN), a wide area network (WAN), a wired network, a wireless network, or any combination thereof.

[0029] Terminal 130 refers to one or more terminal devices used by a user. In some embodiments, the user includes project managers, construction workers, acceptance personnel, etc. In some embodiments, terminal 130 may include mobile phone 130-1, tablet 130-2, and computer 130-3, etc.

[0030] Database 140 may store data or information generated by other devices. In some embodiments, database 140 may include a memory storing computer instructions that, when executed by at least one processor, cause the project management system to perform the project management method described in any embodiment of this specification.

[0031] In some embodiments, database 140 may store project documents, such as a first project document, a second project document, a third project document, and a fourth project document. In some embodiments, database 140 may store data and / or information processed by processing device 110, such as index information, monitoring information, etc. Database 140 may include one or more database components, each of which may be an independent device or part of another device. Database 140 may be local or implemented via the cloud. In some embodiments, database 140 may be implemented on a cloud platform.

[0032] In some embodiments, database 140 includes general database 141 and business database 142, etc.

[0033] General database 141 is configured to store project documents that are not directly related to construction operations. Examples include general project documents, general standard project documents, and regulations. Construction operations include, but are not limited to, construction task execution, construction task acceptance, and construction task supervision.

[0034] Business database 142 is configured to store project documents related to construction business. For example, business database 142 can store project documents (such as acceptance documents, task progress documents, task execution logs, etc.) related to construction task acceptance, construction task execution, and construction task supervision.

[0035] In some embodiments, the business database 142 may establish one or more sub-databases to store project documents corresponding to different construction tasks. For example, the business database 142 may establish an acceptance business database to store documents related to the acceptance of construction tasks, such as acceptance reports and acceptance records; it may also establish a supervision business database to store documents related to the supervision of construction tasks, such as supervision logs and safety inspection records.

[0036] In some embodiments, database 140 may also include a capability database.

[0037] The capability database is configured to store detailed capability and performance profiles of all available contract fulfillment entities. For example, the capability database may store at least one of the following: professional qualifications, skill levels, historical production capacity, current workload, and historical performance data (such as schedule completion rate, quality pass rate, safety records, etc.) for each construction team, work group, or subcontractor.

[0038] In some embodiments, the database 140 may also include a document catalog library, etc. For more details, please refer to the relevant description in Figure 4.

[0039] It should be noted that application scenario 100 is provided for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can make various modifications or variations based on the description in this specification. For example, application scenario 100 can implement similar or different functions on other devices. However, such changes and modifications will not depart from the scope of this specification.

[0040] Figure 2 is a schematic diagram of exemplary hardware and software components of an exemplary computing device according to some embodiments of this specification. The computing device 200 can be configured to perform one or more functions of various modules in the project management system disclosed in embodiments of this specification.

[0041] The computing device 200 can be a general-purpose computer or a special-purpose computer, both of which can be used to implement the project management system described in this specification. The computing device 200 can be used to implement any component of the project management system as described in this specification. For example, a processor can be implemented on the computing device 200 through its hardware, software programs, firmware, or a combination thereof. For simplicity, only one computer is shown in the figures; however, the computer functions described in this specification can be implemented in a distributed manner on multiple similar platforms to distribute the processing load.

[0042] For example, computing device 200 may include a communication port 250 connected to and / or from a network to enable data communication. Computing device 200 may also include one or more processors 220 for executing program instructions. An exemplary computer platform may include an internal communication bus 210, different types of program and data memory (e.g., disk 270, read-only memory (ROM) 230, or random access memory (RAM) 240), and various data files processed and / or transferred by the computer. The exemplary computer platform also includes program instructions executed by processor 220 stored in read-only memory (ROM) 230, random access memory (RAM) 240, and / or other forms of non-transitory storage media. The methods and / or processes described in this specification can be implemented as program instructions. Computing device 200 may also include an input / output interface 260 that can support input / output between the computer and other components. Computing device 200 may also receive programming and data via network communication.

[0043] For illustrative purposes only, only one CPU and / or processor is described in the computing device 200. However, it should be noted that the computing device 200 in this specification may include multiple CPUs and / or processors, and therefore the operations and / or methods implemented by one CPU and / or processor described herein may also be implemented jointly or independently by multiple CPUs and / or processors. For example, if, in this specification, the CPU and / or processor of the computing device 200 performs operations A and B, it should be understood that operations A and B may also be performed jointly or independently by two different CPUs and / or processors in the computing device 200 (e.g., a first processor performs operation A, a second processor performs operation B, or the first and second processors jointly perform operations A and B).

[0044] Figure 3 is an exemplary block diagram of a project management system according to some embodiments of this specification.

[0045] In some embodiments, as shown in FIG3, the project management system (hereinafter referred to as system 300) may include a construction module 310, a first generation module 320, a second generation module 330, a monitoring module 340, and an update module 350. The construction module 310, the first generation module 320, the second generation module 330, the monitoring module 340, and the update module 350 are implemented by one or more processing devices or processors.

[0046] In some embodiments, the construction module 310 is configured to construct a data structure for a construction schedule matrix in memory based on the construction area data and schedule node data of the target project. The data structure includes multiple matrix cells, each of which is uniquely associated with a construction area and a schedule node.

[0047] In some embodiments, the first generation module 320 is configured to query a pre-built general document directory library for matching candidate project documents based on the feature values ​​of the project characteristics of the target project, so as to generate and store a first document directory in memory. The first document directory records document tags for multiple first project documents corresponding to the target project. The document tags include construction area tags, progress node tags, and database tags that identify the storage location.

[0048] In some embodiments, the second generation module 330 is configured to, for a target matrix cell in the data structure of the construction progress matrix, match and query the construction area data and progress node data of the target matrix cell with the construction area tags and progress node tags of multiple first project documents, filter out the second project documents from the multiple first project documents, and generate a second document directory corresponding to the target matrix cell.

[0049] In some embodiments, the monitoring module 340 is configured to monitor the status change events of the second project document in real time through a listener deployed on a business database corresponding to the second project document, as specified by a database label.

[0050] In some embodiments, the update module 350 is configured to automatically update the index information corresponding to the second project document in the second document directory in response to detecting a state change event.

[0051] For more information about the above system 300, please refer to Figures 4 to 14 and their related descriptions.

[0052] It should be noted that the above description of system 300 and its modules is for convenience only and should not be construed as limiting this specification to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. In some embodiments, the construction module 310, the first generation module 320, the second generation module 330, the monitoring module 340, and the update module 350 disclosed in FIG1 may be different modules within a single system, or a single module may implement the functions of two or more of the aforementioned modules. For example, the modules may share a storage module, or each module may have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0053] Figure 4 is an exemplary flowchart of project management according to some embodiments of this specification. As shown in Figure 4, process 400 includes steps 410-450 as described below. In some embodiments, process 400 may be executed by a processor.

[0054] Step 410: Based on the construction area data and progress node data of the target project, construct the data structure of the construction progress matrix in the memory.

[0055] The target project refers to the construction project for which project documentation management is to be implemented. Construction projects can include various engineering categories. For example, construction projects can include building construction, decoration and renovation, installation engineering, municipal engineering, and landscaping engineering. Construction projects can be further divided into various building engineering projects, such as residential buildings, commercial complexes, and infrastructure projects.

[0056] The target project involves multiple construction areas, each with multiple schedule milestones. A construction area refers to the area within the target project that requires construction; a schedule milestone refers to the construction phase that a construction area will go through during construction. For example, taking a building construction project as an example, the construction areas include various floor areas, such as the 1st floor, the 2nd floor, etc.; for each construction area, the schedule milestones include main structure construction, mechanical and electrical pre-installation, and mechanical and electrical installation.

[0057] A construction area can be a region obtained by dividing a construction project into spatial or functional units for ease of management. Construction area data refers to data used to describe the characteristics of a construction area. In some embodiments, each construction area data may include the name and location information of the construction area. In some embodiments, construction area data may also include construction objects within the construction area; for example, the "living room" in "the living room of unit 201 on the 2nd floor of building 1" contains construction objects such as load-bearing walls, ceilings, and floors.

[0058] Schedule milestones can be multiple sub-goals of a construction project's construction phase. For example, in a building project, schedule milestones may include "foundation and substructure engineering," "main structure engineering," and "decoration and finishing engineering." Schedule milestone data refers to the data used to characterize the content of each schedule milestone.

[0059] The construction schedule matrix data structure refers to a two-dimensional matrix data structure corresponding to the target project. One dimension of this matrix data structure corresponds to the construction area, and the other dimension corresponds to the progress node. In some embodiments, the construction area data and progress node data are combined to form the construction schedule matrix data structure.

[0060] In some embodiments, the data structure of the construction schedule matrix may include multiple matrix units. A matrix unit refers to a constituent unit in the construction schedule matrix. A matrix unit can be regarded as the smallest unit of project document management. Each matrix unit corresponds to a construction area and a schedule node in the target project, that is, each matrix unit among multiple matrix units is uniquely associated with a construction area and a schedule node. Taking a two-dimensional construction schedule matrix as an example, the data structure of the construction schedule matrix consists of multiple matrix units and can be represented by the following formula (1): M=[(A i -B j )] m×n (1) Where M represents the data structure of the construction schedule matrix, A i Let B be the i-th construction area. j Let j be the j-th progress node, (A i -B j ) represents a matrix unit, where m×n is the number of rows and columns of the matrix, and represents the number of construction areas and progress nodes, respectively.

[0061] For example, for a target project containing two floors and two schedule nodes, the data structure of the construction schedule matrix can be represented as follows:

[0062] For example, in the data structure of a two-dimensional matrix, the construction area data is the vertical area such as floors (e.g., floor 1, floor 2, etc.), and the progress node data is the horizontal construction stage (e.g., main structure, secondary structure, electromechanical pre-embedded parts, etc.).

[0063] In some embodiments, the processor can construct a data structure for a construction progress matrix based on construction area data and progress node data of the target project. For example, the processor can acquire construction area data for multiple construction areas and progress node data for multiple progress nodes in the target project, and combine the multiple construction areas and multiple progress nodes to form multiple matrix units, thereby generating a data structure for a construction progress matrix.

[0064] In some embodiments, the processor can automatically split and generate a data structure for a construction schedule matrix corresponding to the target project based on the target project's category, construction area data (e.g., floors), and schedule node data (e.g., construction phases). Each matrix unit corresponds to a specific combination of construction area and schedule node data. For example, a matrix unit may include the project category to which the target project belongs (e.g., building construction, municipal engineering, airport, etc.), the construction area data (e.g., number of floors / serial number or number of buildings / serial number, etc.) and schedule node data (e.g., nodes included in the main construction phases, including main structure, masonry, decoration, installation, etc.) corresponding to the matrix unit.

[0065] The target project's category, construction area data, and schedule milestone data can be extracted from the target project's paper or electronic construction plan, or input by users (such as project managers) through terminal devices. For example, the processor can use Optical Character Recognition (OCR) technology to scan the target project's paper construction plan and extract information related to the construction area and schedule milestones.

[0066] It should be understood that the progress milestones for different construction areas can be the same or different. When the progress milestones for different construction areas are the same, each matrix cell in the construction progress matrix data structure is a valid matrix cell and will be used for project document management in subsequent steps. When the progress milestones for different construction areas are different, only some matrix cells in the construction progress matrix data structure are valid matrix cells, and the remaining invalid matrix cells will not be used for project document management in subsequent steps. For example, if construction area A has progress milestones 1 and 2, while construction area B only has progress milestone 1, the matrix cells corresponding to construction area B and progress milestone 2 are invalid matrix cells and will not be used in subsequent steps.

[0067] Step 420: Based on the feature values ​​of the target project's features, query the pre-built general document directory library for matching alternative project documents to generate and store the first document directory in the memory.

[0068] Project characteristics refer to the features of a construction project, including but not limited to project category, region, construction unit, and construction company. Feature values ​​refer to the specific values ​​of these project characteristics. Feature values ​​are attributes of the target project itself, and each construction project has one and only one set of feature values. For example, the feature values ​​of a target project could be: project category is building construction, construction region is Sichuan, construction unit is Vanke Group, and construction company is China State Construction Engineering Corporation, etc.

[0069] A universal document catalog is a document catalog applicable to multiple types of projects, used to store information about project documents corresponding to various projects. In some embodiments, the universal document catalog is configured to store reference values ​​of project characteristics and the correspondence between various types of project documents, as well as document tags for each type of project document. The document tags for project documents can be set by the user. For more information on how to construct a universal document catalog, please refer to Figure 7 and its related description.

[0070] Alternate project documents refer to project documents in a general document catalog that match the target project. Alternate project documents are document types suitable for the target project and are considered as alternatives.

[0071] In some embodiments, the processor can obtain a general document catalog library, and based on reference values ​​of project characteristics corresponding to each type of project document in the general document catalog library, filter out document types from the general document catalog library that have the same characteristic values ​​as the target project (e.g., the region, engineering category, construction unit, etc. of the target project), and determine them as candidate project documents. For example, if the target project is a building construction project located in Sichuan Province, the processor will filter out document types suitable for building construction and the Sichuan region from the general document catalog library based on reference values, such as "Concealed Reinforcement Acceptance Form", "Concealed Formwork Acceptance Form", "Construction Log", etc.

[0072] Reference values ​​refer to typical characteristic values ​​of a project. A general document directory can store the correspondence between reference values ​​of project characteristics and various types of project documents; that is, the reference values ​​of project characteristics corresponding to various types of project documents. For a certain type of project document, if the reference value of its corresponding project characteristic is A, it means that projects with characteristic value A typically have this type of project document. For example, for a concealed rebar acceptance form, the reference values ​​for project category and region are "building construction project" and "Guangdong Province and Zhejiang Province," respectively, indicating that building construction projects in Guangdong Province and Zhejiang Province typically require concealed rebar acceptance forms.

[0073] The first document directory is used to store information related to the first project documents corresponding to the target project (such as document name, document type, etc.). The first project documents refer to the project documents that may be generated and need to be stored throughout the entire process of the target project. For example, the first project documents include the target project's construction logs, construction inspection documents, etc. The first document directory can be obtained by filtering from a general document directory library.

[0074] In some embodiments, the first document directory is configured to record document tags for multiple first project documents corresponding to the target project. Document tags are tags that identify project document attributes. Document tags include one or more of the following: construction area tags, progress node tags, database tags identifying storage locations, early warning rule tags, handling rule tags, associated unit tags, construction task tags, etc. Document tags may also include basic information tags, such as tags corresponding to document names, tags corresponding to document types, etc. Document tags can be used to identify second project documents.

[0075] Construction area tags identify the construction area corresponding to the project document, such as building, basement, foundation pit, roof, etc. Progress node tags identify the progress node corresponding to the project document. Database tags identify the database where the project document is stored (i.e., the location where the project document is stored), such as a business database. Warning rule tags identify warning rules associated with the project document. Processing rule tags identify processing rules associated with the project document. Associated unit tags identify construction units associated with the project document. Construction task tags identify construction tasks associated with the project document. For more information on warning rules, processing rules, associated units, and construction tasks, please refer to Figure 5 and its related descriptions.

[0076] In some embodiments, the processor can generate the first document directory in various ways. For example, a database may pre-store default document directories corresponding to the feature values ​​of each project feature, and the corresponding default document directories can be obtained based on the feature values ​​of the target project's project features, serving as the first document directory. Alternatively, the first document directory can be input by a user (such as a project manager) based on the feature values ​​of the target project's project features.

[0077] In some embodiments, the processor may directly use candidate project documents as the first project document corresponding to the target project and generate a first document directory. In some embodiments, the processor may filter candidate project documents to determine the first project document and generate a first document directory.

[0078] For more information on how to generate the first document table of contents, please refer to Figure 7 and its related description.

[0079] In some embodiments, the processor can eliminate candidate project documents according to a preset frequency and determine the eliminated documents as the first target documents. For example, the processor can eliminate low-frequency documents (e.g., candidate project documents with a frequency of less than 10 times or less than 5%). In some embodiments, the processor can also recommend a document directory after eliminating low-frequency documents to the user, and the user can choose whether to keep the low-frequency documents. Finally, a first document directory is generated based on the user's selection.

[0080] Step 430: For the target matrix unit in the data structure of the construction progress matrix, the construction area data and progress node data of the target matrix unit are matched and queried with the construction area tags and progress node tags of multiple first project documents to filter out the second project documents and generate the second document directory corresponding to the target matrix unit.

[0081] A target matrix unit refers to a matrix unit for project document management. In some embodiments, a target matrix unit can be any matrix unit in the data structure of the construction schedule matrix. For details, see the description in step 410. For ease of description, the construction area and schedule node corresponding to the target matrix unit are referred to as the target construction area and target schedule node.

[0082] The second project document refers to the project document corresponding to the target matrix unit, that is, the project document that may be generated and needs to be stored when the target construction area reaches the target progress node.

[0083] In some embodiments, the processor can match and associate the construction area data and progress node data in the target matrix cell with the construction area tags and progress node tags of the first project document to determine the first project document associated with the target matrix cell, which serves as the second project document corresponding to the target matrix cell. The document tags of the first project document are inherited by the second project document.

[0084] The second document directory is used to store information related to the second item documents corresponding to the target matrix unit. The second document directory lists all second item documents associated with the target matrix unit. For example, the second document directory may be configured to store index information of the second item documents, rather than the actual second item documents themselves. It may also be configured to store document tags for the second item documents.

[0085] In some embodiments, after determining the second project document, the processor can identify the associated construction area label or associated progress node label of the target matrix unit in a general document directory library; based on the associated construction area label and associated progress node label of the target matrix unit, it automatically closes and generates a second document directory. Users can manually modify the automatically generated second document directory.

[0086] In some embodiments, the second project document may be in the form of an electronic document or a paper document. For example, an electronic document may be uploaded to the corresponding business database by the user via a terminal device; a paper document, such as a signed original, needs to be scanned by the user using optical character recognition technology and uploaded to the corresponding database.

[0087] In some embodiments, in response to detecting the generation of a second project document, the processor can generate a virtual document object associated with that document in the target matrix unit. For example, for electronic documents, the processor can automatically call the blockchain interface to complete the notarization operation when the document is generated, writing the summary information (such as hash value), generation time, etc., of the electronic document onto the blockchain; for paper documents, after scanning and uploading, their summary information can also be calculated and stored in the blockchain to achieve unified traceability and tamper-proof protection. For details on how to monitor the generation of the second project document, please refer to step 440.

[0088] The virtual document object includes operation log information for the second project document. For example, the log information includes multiple data points related to the creation, uploading, signing, sending / receiving, borrowing, and modification of the second project document. The data in the log information can be hashed or mapped to metadata using the timestamps and digest information recorded in the blockchain notarization, thereby verifying the authenticity and integrity of the second project document.

[0089] Index information is used to locate project documents, enabling querying and retrieval of these documents. In some embodiments, the entity of the second project document is stored in a database corresponding to the second project document, and the index information can point to the database where the second project document is actually stored. For example, the index information includes the path, storage address, or jump link of the project document's database. Users (such as project managers) can locate the database corresponding to the second project document using the index information. For example, after clicking the jump link, the user will jump from the matrix cell interface to the database's detailed page to view or edit the content of the second project document. The index information can be updated as the status of the second project document changes. For example, when the second project document is generated and stored in its corresponding database, the index information will be updated, and the updated index information can point to the second project document itself, allowing the user to locate the second project document. More details about the index information can be found in step 440.

[0090] For example, if the second project document is an acceptance document, then the entity of the second project document can be stored in the acceptance business database. The entities of the second project document are stored in their respective business databases (e.g., the acceptance business database, the supervision business database, etc.), but the index information can be centrally displayed at the matrix unit level to jump to the corresponding business database.

[0091] Step 440: Monitor the status change events of the second project document in real time by deploying a listener on the business database corresponding to the second project document, as specified by the database label.

[0092] For more information about the business database, please refer to Figure 1 and its related description.

[0093] A listener is a component or mechanism that monitors whether a predetermined event has occurred from a specific source. For example, a listener can be a process, service, or computer code program deployed on a business database to monitor changes in data records.

[0094] Since each first project document is associated with a database tag, the second project document inherits this business database tag, which is used to identify the sub-database where the second project document is stored. In some embodiments, the processor sets a listener in the sub-database where the second project document is stored, based on the database tag of the second project document. This listener is configured to monitor state change events related to the second project document in the sub-database in real time.

[0095] The status change events for the second project document include generation, approval, modification, and deletion. As described in step 430, when the second document directory is generated, the index information of the second project document points to its respective database.

[0096] In some embodiments, the processor may set a listener in the database corresponding to the second project document based on the database tags of the second project document in order to monitor the state changes of the second project document.

[0097] Step 450: In response to the detection of a status change event, automatically update the index information corresponding to the second project document in the second document directory.

[0098] In some embodiments, when the listener detects a status change event of the second project document in the database (such as creation, modification, approval, deletion, etc.), the processor can automatically update the latest document status and index information to the second document directory of the target matrix unit.

[0099] In some embodiments, when the generation of a second project document is detected, the index information can be automatically updated to point to the second project document itself. For example, the index information can be automatically updated to a link corresponding to the second project document, through which the second project document can be opened. In some embodiments, when the deletion of a second project document is detected, the index information can be automatically updated back to point to its corresponding database. When the storage address of the second project document is modified, the index information can be automatically updated to point to its new storage address.

[0100] For example, when document X (e.g., "Concrete Pouring Order") is created or modified in the acceptance business database, the listener in the acceptance business database can detect the formal generation of a database record for the document or its status change event (e.g., from unapproved to approved). The listener will send this status change event to the processor. After receiving the relevant information of the status change event, the processor will automatically update the index information of the second project document corresponding to the matrix unit in the second document directory to "generated," "uploaded," or "approved," and update the corresponding link / URL in the second document directory. In this way, the next time a user enters the matrix unit, they will see that the document is in a new status such as "completed" or "viewable," and can click the link to jump to view the details.

[0101] In some embodiments, the processor may further determine, based on the updated second document directory, whether the target progress node corresponding to the target matrix unit meets the progress node update condition; in response to determining that the target progress node meets the progress node update condition, based on the association relationship information related to the data structure of the construction progress matrix, determine the association matrix unit that is associated with the target matrix unit; and send a construction notification to the target associated unit of the association matrix unit. For more details on how to determine whether the target progress node meets the progress node update condition, the association matrix unit, and how to send a construction notification to the association matrix unit, please refer to Figure 8 and its related description.

[0102] In some embodiments, the processor can also generate a progress display table corresponding to the data structure of the construction progress matrix, the progress display table containing display cells corresponding to multiple matrix units; based on the updated second document directory, determine the progress information of the target matrix unit; based on the progress information, annotate the display cells corresponding to the target matrix unit in the progress display table. For more details on how to generate the progress display table, determine the progress information of the target matrix unit, and annotate the display cells in the target matrix unit, please refer to Figure 9 and its related description.

[0103] In some embodiments, the processor may further, for each matrix unit,: determine a first task to be assigned to each matrix unit based on the difference between multiple construction tasks and completed construction tasks of each matrix unit; determine the priority of the first task to be assigned based on the weight coefficient of each matrix unit; determine and assign selected construction tasks based on the priority of the first task to be assigned; update and color-code the status information of each matrix unit based on the execution status of the selected construction tasks; and generate a visual view displaying the progress, the visual view including a view presented in two-dimensional table form; in the two-dimensional table form view, the vertical axis displays multiple construction areas of the target project, and the horizontal axis displays multiple progress nodes of the target project. For more details on how to determine the first task to be assigned and its priority, determine and assign selected construction tasks, update and color-code the status information of the matrix unit, and generate the visual view, please refer to Figure 10 and its related description.

[0104] In some embodiments of this specification, by generating a data structure for a construction progress matrix, project document management can be achieved based on matrix units. The relevant information of the project documents corresponding to the matrix units is centrally stored in the document directory, thereby improving the centralization and management efficiency of project documents.

[0105] In some embodiments, the processor may: in response to detecting that a second project document is stored in the corresponding business database, determine the digital hash value of the second project document; invoke the smart contract of the blockchain network to package the digital hash value, document tag, and timestamp into a transaction and send it to the blockchain network for notarization; receive the transaction receipt returned by the blockchain network and update the transaction hash in the transaction receipt to the second document directory as tamper-proof index information for the second project document.

[0106] In some embodiments, the processor can monitor the storage of the second project document in the business database in real time through a listener deployed on the business database. The listener can monitor state change events of the second project document, including insert or update operations.

[0107] A numeric hash value is a fixed-length string generated by calculating input data using a hash function. Numeric hash values ​​can be used to uniquely identify a second item document.

[0108] In some embodiments, a hash function is used by the processor to map the data corresponding to the second item document into a shorter data set to uniquely identify the input second item document. The processor determines the numerical hash value of the second item document by performing a hash function on the complete content of the second item document stored in the business database. The hash function can include various hash algorithms, such as Secure Hash Algorithm 256-bit (SHA-256), SM3 cryptographic hash algorithm, Message Digest Algorithm version 5 (MD5), and Blake2b algorithm.

[0109] A blockchain network is a decentralized, distributed, and tamper-proof digital ledger system that stores data blocks in a chain using cryptographic techniques. For example, a blockchain network can be a public chain, consortium chain, or private chain built on protocols such as Ethereum, Hyperledger Fabric, or Bitcoin.

[0110] A smart contract on a blockchain network refers to program code deployed on the blockchain network that can automatically execute preset rules and terms. For example, a smart contract on a blockchain network can be a pre-deployed contract for data storage, which includes functions for recording digital hash values ​​and related information.

[0111] A transaction is a data packet that records a specific operation (such as data storage, asset transfer, or smart contract call) within a blockchain network. For example, a transaction may include digital hash values, document tags, and timestamps for storage on the blockchain network.

[0112] In some embodiments, the processor may invoke a smart contract of the blockchain network to combine the digital hash value of the second project document, the document tag of the second project document, and the current timestamp obtained from the system clock into a structured data packet (i.e., package it into a transaction) to perform the construction of the data packet. For example, the processor may construct a Lightweight Data Interchange Format (JavaScript Object Notation, JSON) object containing a hash value field, a document tag field, and a timestamp field.

[0113] In some embodiments, the processor invokes the notarization method of a notarization smart contract pre-deployed on the blockchain network through a blockchain node interface to execute the smart contract call. The notarization method of the notarization smart contract refers to the method used in the smart contract on the blockchain network to implement data notarization functionality. For example, this notarization method can accept the document's digital hash value, document tag, and timestamp as input and write this information to the blockchain to provide tamper-proof credentials. For example, the processor can interact with an Ethereum-compatible blockchain network through the Web3.js library, invoking the smart contract's storeProof function. Alternatively, the processor can interact with the Hyperledger Fabric network, etc., through the Fabric SDK, invoking the relevant notarization functions defined in the chaincode.

[0114] In some embodiments, the processor can send the packaged transaction to a blockchain network for notarization. For example, the processor can use a pre-configured blockchain account private key to digitally sign the transaction, ensuring the authenticity of the transaction identity, and broadcast the signed transaction to blockchain network nodes to perform transaction signing and sending.

[0115] A transaction receipt is a record containing detailed information about a transaction that a blockchain network returns to the transaction initiator after processing the transaction. For example, a transaction receipt typically includes information such as the transaction hash, block number, transaction sender, transaction receiver, transaction status (e.g., success or failure), and the amount of gas consumed.

[0116] A transaction hash in a transaction receipt refers to the information containing a unique identifier for a transaction returned by the blockchain network after processing and confirming it. For example, the transaction hash in a transaction receipt is a unique identifier for a transaction on the blockchain, which can be used to query transaction details on the blockchain and can also be used as tamper-proof indexing information to update the document directory.

[0117] Tamper-proof indexing information refers to identifying information used to verify the integrity and tamper-proof nature of associated data. It allows tracing back to corresponding immutable external records. For example, tamper-proof indexing information could be a blockchain transaction hash, which allows querying the corresponding stored record on the blockchain, thereby verifying the originality and tamper-proof nature of the document.

[0118] In some embodiments, the processor can extract key fields from transaction receipts returned by nodes in the blockchain network to perform transaction receipt processing. For example, when the processor receives a transaction receipt, it parses its JSON structure, extracts the transactionHash field, and obtains the transaction receipt.

[0119] In some embodiments, the processor updates the transaction hash as an immutable proof of authenticity in the second document directory of the business database (i.e., the record field corresponding to the second project document), establishing a bidirectional association between the off-chain document and the on-chain proof of authenticity, thereby performing the creation of tamper-proof index information for the second project document. For example, in the database table of the second document directory, a blockchain_tx_hash field is added to each second project document, and the received transaction hash is written to this field.

[0120] In some embodiments, if the transaction receipt indicates a transaction failure, the processor logs an error and triggers a retry mechanism or alarm notification to perform fault tolerance. For example, the processor can set up a scheduled task to retry and preserve documents for failed transactions.

[0121] In some embodiments of this specification, a reliable document tamper-proof and traceability mechanism is provided by packaging the digital hash value, document tag, and timestamp of the second project document into a transaction certificate and using the transaction hash as tamper-proof index information. This significantly enhances the security and credibility of the system in processing project documents, effectively avoids the risk of documents being illegally tampered with or repudiation, and provides a solid foundation of trust for project management.

[0122] In some embodiments, the processor may acquire the text content of a second project document; based on the text content, extract at least one semantic feature vector through a processing model; based on the at least one semantic feature vector and the progress node data of the target matrix unit, determine the progress delay probability of the target matrix unit through a progress prediction model; and in response to the progress delay probability exceeding a preset threshold, mark the target matrix unit with a risk warning.

[0123] In some embodiments, the processor can use a document parsing engine to parse the format of the second project document (e.g., scanned document); process the image content (e.g., scanned document) in the parsed second project document using optical character recognition technology, and convert it into machine-readable text data; preprocess the extracted raw text data to form standardized text content and determine it as the text content of the second project document. Preprocessing includes removing special characters, filtering stop words, and text standardization.

[0124] A processing model refers to a model used to extract semantic feature vectors. In some embodiments, the processing model is a machine learning model. For example, the processing model is any one or a combination of a pre-trained natural language processing model or other custom model structures.

[0125] In some embodiments, the processor may select a language representation model pre-trained on a large-scale corpus as the processing model, and load the parameters and vocabulary of the processing model. The processing model may be BERT, RoBERTa, or ERNIE, etc.

[0126] A semantic feature vector is a numerical vector used to represent the semantic information of text content. For example, a semantic feature vector can be a word vector (such as word vectors generated by Word2Vec and GloVe) or a document vector (such as the vector representation corresponding to the BERT model [CLS] tags).

[0127] In some embodiments, the processor can input the text content of the second project document into the processing model, perform deep semantic encoding through the multi-layer Transformer structure of the processing model, extract the vector representation corresponding to the [CLS] tag from the last hidden state of the processing model as the semantic feature vector of the second project document, or perform mean pooling operation on all word vectors in the text content to generate a fixed-dimensional document-level semantic feature vector as the semantic feature vector of the text content of the second project document.

[0128] In some embodiments, the processor can also extract semantic feature vectors using other types of machine learning models. For example, the processing model is a word embedding model such as Word2Vec or GloVe, combined with pooling operations, or a recurrent neural network model such as Long Short-Term Memory (LSTM) or Gated Recurrent Unit (GRU) is used to extract the semantic representation of the text.

[0129] A schedule prediction model is a model used to predict the probability of schedule delays. In some embodiments, the schedule prediction model is a machine learning model.

[0130] In some embodiments, the input to the progress prediction model includes semantic feature vectors and progress node data of the target matrix elements, and the output includes the progress delay probability of the target matrix elements.

[0131] Schedule delay probability refers to the estimated likelihood that a target project unit cannot be completed within the scheduled time. For example, schedule delay probability can be a value between 0 and 1, with a higher value indicating a greater probability of delay.

[0132] In some embodiments, the progress prediction model includes a feature fusion layer configured to align and concatenate semantic feature vectors with progress node data to form a fused feature representation. For example, the processor can concatenate semantic feature vectors with numerical features such as construction time and percentage of completion of the target matrix unit.

[0133] In some embodiments, the progress prediction model employs a deep neural network architecture. For example, the progress prediction model may use a multilayer perceptron (MLP) containing multiple fully connected layers to learn nonlinear relationships between complex features. Alternatively, the progress prediction model may employ a gradient boosting decision tree (GBDT) model, such as XGBoost or LightGBM, to predict the probability of delays.

[0134] In some embodiments, the training process of the progress prediction model uses historical project documents and their corresponding actual progress results to form a training sample set, and optimizes the model parameters through a backpropagation algorithm, for example, by minimizing the binary cross-entropy loss function.

[0135] In some embodiments, the progress prediction model can be trained based on training data. In some embodiments, the processor can acquire a training sample set consisting of multiple labeled training samples and perform multiple rounds of iteration based on the training sample set.

[0136] Training samples can include sample semantic feature vectors and progress node data of the target matrix units. Labels represent the probability of schedule delay for the target matrix unit corresponding to the training sample. Training samples can be constructed based on a large number of historical project documents and their corresponding actual progress results. Labels can be determined based on whether there are schedule delays in the target matrix units corresponding to the training samples from a large number of historical project documents.

[0137] In some embodiments, the processor can input a training sample set into an initial progress prediction model to perform multiple iterations. At least one iteration includes: selecting one or more training samples from the training sample set; inputting the one or more training samples into the initial progress prediction model to obtain model prediction outputs corresponding to the one or more training samples; substituting the model prediction outputs corresponding to the one or more training samples, along with the labels of these one or more training samples, into a predefined loss function formula to calculate the value of the loss function; iteratively updating the model parameters in the initial progress prediction model based on the value of the loss function (e.g., optimizing the model parameters through backpropagation to minimize the binary cross-entropy loss function) until the iteration termination condition is met, at which point the iteration ends, resulting in a trained progress prediction model. The iteration termination condition may include loss function convergence, the number of iterations reaching a threshold, etc.

[0138] In some embodiments, the probability of schedule delay can also be determined using various other machine learning models, such as classification models like Support Vector Machine (SVM), Random Forest, Logistic Regression, or ensemble learning methods, to predict the probability of schedule delay.

[0139] Risk warning labeling refers to the identification or alerting action performed on matrix units of relevant projects when potential risks are detected. For example, risk warning labeling can manifest as color changes, warning icons, text prompts, or trigger automatically sent warning notifications (such as emails or messages) on the user interface.

[0140] In some embodiments, the processor can compare the probability of schedule delay with a preset threshold. The preset threshold can be based on manual or empirical criteria. For example, if the preset threshold is 0.6, the processor can trigger a risk warning label when the probability of schedule delay is 0.7. Risk warning labeling of target matrix cells can be visually indicated on the user interface by changing the display color of the target matrix cell, adding a prominent icon, or displaying warning text. For example, risk warning labeling can also include generating and sending warning notifications, updating task status in the project management system, generating risk reports, or integrating risk information into other decision support systems. In some embodiments, risk warning labeling can also be integrated with task processing operations or the warning and task assignment functions for subsequent matrix cells. More details regarding task processing operations and the warning and task assignment functions for matrix cells can be found in Figures 5 and 14 and their related descriptions.

[0141] In some embodiments, if the probability of schedule delay does not exceed a preset threshold, the processor does not perform any operation and does not trigger a risk warning label.

[0142] In some embodiments of this specification, by acquiring the text content of a second project document and extracting semantic feature vectors using a processing model, combined with progress node data, the progress prediction model can accurately determine the probability of schedule delay for the target matrix unit. Responding to high delay probabilities by marking risk warnings can elevate traditional document management to the level of intelligent risk prediction, enabling proactive control and intelligent decision support for project progress, and effectively reducing the risk of project delays.

[0143] In some embodiments, the processor can render a 3D building information model of the target project on a display device; spatially bind matrix cells in the data structure of the construction schedule matrix to building components in the 3D building information model; in response to a user's selection operation on a target component in the 3D building information model, determine the matrix cell corresponding to the target component from the data structure of the construction schedule matrix, and call the second document directory associated with the matrix cell corresponding to the target component; and display a list of documents in the second document directory in a floating window of the graphical user interface.

[0144] Building Information Modeling (BIM) is a digital building model that integrates information throughout the entire project lifecycle, including geometric information, physical attributes, and functional attributes. Display devices refer to hardware devices used to present visual information, such as the monitor of terminal 130, or virtual reality / augmented reality headsets. More information about terminal 130 can be found in Figure 1 and its related description.

[0145] In some embodiments, the processor can utilize BIM viewer software or a custom BIM rendering engine to parse BIM model files (e.g., built based on the target project) and use graphics APIs (e.g., OpenGL, DirectX) to convert 3D geometric data, material, and texture data into pixel displays on the screen. In some embodiments, the rendering process can also be implemented using various other 3D graphics rendering technologies and tools, such as rendering using the API interface of CAD software or high-performance rendering using a game engine.

[0146] Building components refer to independent objects in a 3D building information model that represent the physical entities or logical components of a building. Building components include walls, columns, floors, doors and windows, pipes, equipment, etc.

[0147] In some embodiments, spatial binding can be achieved through ID matching. In a 3D BIM model, each building component typically has a unique identifier (ID), and each matrix cell in the construction schedule matrix data structure can also be associated with one or more BIM component IDs. The processor can traverse the construction schedule matrix data structure and the 3D BIM model, matching matrix cells and building components with the same or associated IDs to establish a logical association between them, thus achieving spatial binding. For example, binding can also be achieved through attribute mapping. In some embodiments, spatial binding can also be achieved through various other techniques, such as geometric overlap detection, rule-based automated association algorithms, or user-specified binding relationships.

[0148] A target component refers to a specific building component specified by the user in a 3D building information model through interactive operations. Interactive operations can include clicking, selecting, etc.

[0149] Selection actions refer to user interactions with a specific object to specify or highlight that object. Interactive actions can be selection actions, such as clicking or selecting.

[0150] In some embodiments, users can perform a selection operation by clicking on a building component on the rendered 3D BIM model with a mouse. The BIM rendering engine captures the mouse click event and identifies the clicked building component based on the projection of the click location in 3D space. For example, in touch devices or virtual reality / augmented reality environments, users can select target components by touch, gestures, or a ray selector.

[0151] In some embodiments, upon receiving the ID of the selected target component, the processor performs a reverse lookup using the spatial binding relationship to determine the matrix unit corresponding to the target component. After determining the matrix unit, the processor can query a database storing second document directory information to obtain the second document directory. For example, in the database table of the second document directory, it can query all document tag records associated with the matrix unit ID. Alternatively, it can retrieve all second item documents of the corresponding second document directory from the database based on the matrix unit ID.

[0152] A graphical user interface (GUI) refers to the interface on terminal 130 that allows users to interact with terminal 130 through visual elements such as graphical icons, menus, and buttons. A floating window refers to a small, movable window that dynamically pops up within the GUI, used to display additional information or provide temporary operations.

[0153] In some embodiments, the processor displays a floating window in the graphical user interface. The floating window displays key information such as document name, type, upload date, and status obtained from the second document directory in a list format (e.g., a table or scrolling list). Alternatively, the document list can be dynamically loaded and displayed in the sidebar or information panel of the graphical user interface to ensure a smooth interactive experience with the 3D BIM model.

[0154] In some embodiments of this specification, by spatially binding the data structure of the 3D building information model with that of the construction schedule matrix, users can intuitively select building components in the 3D model and immediately retrieve and display their associated second document directory. This integration of 3D visualization and document management significantly improves the efficiency and ease of use of project documents, and enhances the informatization level of project management.

[0155] Figure 5 is an exemplary flowchart of a storage project document according to some embodiments of this specification.

[0156] As shown in Figure 5, process 500 includes the following steps. In some embodiments, process 500 may be executed by a processor.

[0157] Step 510: Generate the data structure of the construction progress matrix corresponding to the target project.

[0158] For more information on step 510, please refer to step 410 and its related description.

[0159] Step 520: Generate the first document directory of the target project based on the feature values ​​of the project characteristics of the target project.

[0160] For more information on step 520, please refer to step 420 and its related description.

[0161] Step 530: Based on the construction area tags and progress node tags of multiple first project documents, determine the second project document corresponding to the target matrix unit from the multiple first project documents, and generate the second document directory corresponding to the target matrix unit.

[0162] For more information on step 530, please refer to step 430 and its related description.

[0163] Figure 6 is an exemplary schematic diagram of a second document directory according to some embodiments of this specification.

[0164] The second document directory lists the various project documents corresponding to each target matrix unit. As shown in Figure 6, the directory hierarchy on the left side of the second document directory displays the project documents corresponding to each target matrix unit (i.e., each target construction area and its target progress node). In the directory hierarchy, the first-level directory represents the construction area of ​​the target matrix unit, such as the first floor; the second-level directory represents the progress node of the target matrix unit, such as the main structure; and the third-level directory represents the second project documents corresponding to the target matrix unit, such as acceptance documents, rectification orders, project logs, meeting logs, etc. The first-level and second-level directories correspond to a matrix unit in the construction progress matrix.

[0165] By selecting a project document in the second document directory, you can obtain relevant information about that project document. As shown in Figure 6, the right side of the second document directory displays the project name, storage location (i.e., index information), upload time, uploader, document preview, etc. of the second project document.

[0166] In some embodiments, each second project document corresponds to a construction task in the progress node of the target matrix unit, and the second project documents in the second document directory can be sorted according to the time of the construction task.

[0167] In some embodiments of this specification, the hierarchical structure of the second document directory can be used to map the hierarchical relationship in the construction progress matrix, so that the management of project documents can be carried out layer by layer according to construction area - progress node - construction document, thereby improving the query efficiency of project documents.

[0168] In some embodiments, the processor can determine the second project document corresponding to the target matrix unit based on the construction area tag and progress node tag of the first project document, and then generate a second document directory storing relevant information of the second project document. Specifically, the processor can filter out first project documents with the construction tag as the target construction area and the progress node tag as the target progress node from the first project documents in the first document directory, and use these filtered first project documents as the second project documents. The second project document can inherit the document tags of the first project document. For example, the document tags that the second project document can inherit include basic information tags, construction area tags, progress node tags, database tags, early warning rule tags, handling rule tags, associated unit tags, construction task tags, etc. Then, the processor can generate a second document directory based on the document tags of the second project document. The basic information such as document name and type in the second document directory can be determined based on the basic information tags, and the index information can be determined based on the database tags. For example, the database where the second project document will be stored can be determined based on the database tags, and the address or link of the database can be used as the index information of the second project document.

[0169] In some embodiments, users (such as project managers) can manually modify the second document directory generated by the processor via a terminal as needed.

[0170] Step 540: Based on the database tags of the second project document, monitor the database corresponding to the second project document to detect changes in the status of the second project document and update the corresponding index information in the second document directory.

[0171] For more information on step 540, please refer to step 440 and its related description.

[0172] In some embodiments, the document label further includes an alert rule label and a processing rule label. Process 500 further includes steps 550 and 560.

[0173] Step 550: In response to the detection of the generation of the second project document, monitor whether the associated data of the second project document conforms to the warning rules according to the warning rule tags of the second project document.

[0174] In some embodiments, in response to detecting the generation of a second project document, the processor can determine the warning rule of the second project document based on the warning rule label of the second project document, wherein the warning rule is configured to constrain the generation time of the associated data of the second project document; obtain monitoring information related to the associated data, and determine whether the associated data conforms to the warning rule based on the monitoring information; in response to determining that the associated data does not conform to the warning rule, implement the corresponding processing operation based on the processing rule label.

[0175] The alert rules define the rules that the second project document and / or its associated data must meet; otherwise, an alert will be triggered (e.g., a warning notification will be sent to the user). For example, the alert rule might be configured to constrain the generation time of the associated data of the second project document. If the generation time of the associated data of the second project document meets the alert rule, no alert will be triggered; otherwise, an alert will be triggered.

[0176] Related data refers to data associated with a second project document. This related data can be presented as a project document or in other forms (such as user input data, instructions, etc.). Generally, construction operations (such as construction task execution, construction task acceptance, and construction task supervision) need to comply with specific project specifications. Different construction operations may have specific relationships, which in turn lead to specific relationships between the data corresponding to different construction operations. These relationships can be determined according to project specifications or specified by the user.

[0177] In some embodiments, associated data may include prerequisite data and subsequent data. Prerequisite data refers to data that needs to exist before the generation of the second project document. That is, the generation of the second project document can only occur after the prerequisite data exists. For example, the secondary structure can only be built after the acceptance of the first-floor main structure; therefore, the acceptance form for the first-floor main structure is the prerequisite data for the construction log corresponding to the second-floor main structure construction. Subsequent data refers to data that needs to be generated after the generation of the second project document. That is, the generation of the second document must exist before the generation of subsequent data. For example, concrete pouring needs to be carried out after the acceptance of concealed rebar; then the construction log corresponding to the concrete pouring is the subsequent data for the acceptance form corresponding to the concealed rebar.

[0178] In some embodiments, the associated data includes a third project document that is associated with the second project document among multiple first project documents. That is, the associated data is also a project document related to the target project. The third project document can be a preceding or succeeding project document of the second project document. The construction area corresponding to the third project document can be the target construction area (i.e., the second and third project documents correspond to the same construction area) or other construction areas (i.e., the second and third project documents correspond to different construction areas). The progress node corresponding to the third project document can be the target progress node (i.e., the second and third project documents correspond to the same progress node) or other progress nodes (i.e., the second and third project documents correspond to different progress nodes).

[0179] The generation time of related data refers to the point in time when the preceding or subsequent data is generated relative to the generation time of the second project document. For example, the second project document can be a construction log. If the early warning rule stipulates that a supervision approval document should be generated within 24 hours after the construction log is generated, then the supervision approval document is considered the subsequent data of the construction log, and the 24-hour period is the generation time requirement for this subsequent data.

[0180] The processor can determine the corresponding warning rule based on the warning rule label of the second project document. The warning rule label is a label that identifies the warning rule associated with the project document. For example, project managers can pre-set warning rule labels for various project documents in a general document directory library. When the first project document is determined from the general document directory library, its warning rule label is inherited from the general document directory library; when the second project document is determined, its warning rule label is inherited from the first project document; the processor can determine its warning rule based on the warning rule label of the second project document. In some embodiments, project managers can also modify the warning rule of the second project document via a terminal as needed to adapt to the actual needs of different projects.

[0181] Furthermore, the processor can acquire monitoring information related to the associated data. Monitoring information refers to relevant information obtained by monitoring changes in the state of the associated data. For example, monitoring information includes the generation, modification, deletion, generation timestamp, and modification timestamp of the associated data. In some embodiments, the processor can acquire monitoring information in various ways. For example, the processor can acquire monitoring information based on the log records of the associated data, which may include historical records of user operations on the associated data, upload records of the associated data, and information on changes in the state of the associated data.

[0182] In some embodiments, when the associated data includes a third project document, monitoring information related to the third project document can be obtained based on the database tag of the third project document. For example, the processor can determine the storage database of the third project document based on the database tag of the third project document, and use a listener to monitor the storage database of the third project document to obtain monitoring information related to the third project document.

[0183] The processor can determine whether related data meets the early warning rules based on monitoring information. For example, if the early warning rule is that subsequent data should be generated within 24 hours after the second project document is generated, and the monitoring information of the subsequent data indicates that its generation time exceeds 24 hours, then the subsequent data does not meet the early warning rule.

[0184] When the associated data does not meet the warning rules, step 560 can be executed.

[0185] Step 560: Perform the corresponding processing operation based on the processing rule tag corresponding to the second project document.

[0186] Processing actions refer to the measures to be taken when related data does not comply with warning rules. For example, processing actions include pushing messages, blocking data, blocking processes, and revoking permissions. Pushing messages refers to sending warning notifications to relevant users of related data. Pushing messages refers to sending warning prompts or operation notifications to the corresponding responsible units based on the associated unit tags carried by the related data. Blocking documents refers to prohibiting the creation, uploading, or approval of related data that does not meet the warning rules, ensuring that the sequential dependencies of the process are maintained. Blocking processes suspends or stops the creation, uploading, or approval of related data until it complies with the warning rules. Revoking permissions refers to temporarily restricting or revoking specific operation permissions of the relevant responsible units based on the associated unit tags of the related data, preventing further non-compliant operations.

[0187] Processing rule labels are labels that identify processing rules associated with project documents. The method for determining processing rule labels is similar to that for warning rule labels described in step 550, and will not be repeated here.

[0188] In some embodiments, the document tag further includes an associated unit tag. When the associated data includes a third project document, performing the corresponding processing operation based on the processing rule tag further includes: sending a notification to the associated unit corresponding to the third project document according to the associated unit tag of the third project document.

[0189] Related entities refer to units that have a direct or indirect relationship with the project's construction area and schedule milestones during the project construction process. For example, related entities may include the construction unit, design unit, and supervision unit. In some embodiments, different related entities undertake different project document management responsibilities. For instance, the construction unit is responsible for submitting project documents such as construction logs and quality acceptance forms; the supervision unit is responsible for submitting project documents such as acceptance forms and supervision logs; and the design unit is responsible for submitting project documents such as technical briefings and construction change documents.

[0190] The associated unit tag is used to identify the construction unit associated with the project document. The method for determining the associated unit tag is similar to the warning rule tag described in step 550, and will not be repeated here.

[0191] In some embodiments, the processor can determine the associated unit of a third project document by recognizing its associated unit tag. When the processing rule tag indicates that the processing operation corresponding to the third project document includes a push message, the processor can send a notification to the determined associated unit.

[0192] In some embodiments of this specification, based on the early warning rule tags of the second project document, it is possible to monitor and assess the compliance of related data, ensuring that related data is submitted within the specified time and avoiding delays in construction progress due to delays in related data. In this way, project supervision and progress monitoring can be achieved based on document management, leveraging the functions of documents beyond information recording.

[0193] Furthermore, since construction projects often involve multiple responsible entities, document uploading and rectification require collaborative work among these entities. When the associated data is a third-party project document, the associated entity can be quickly identified and notifications sent based on its associated entity tags. This reduces the cost of manual communication between multiple entities, improves the automation level of project document management, and ensures efficient document flow among multiple responsible entities.

[0194] In some embodiments of this specification, by generating a construction progress matrix corresponding to the target project, document management can be achieved based on the target matrix units. Information related to the second project documents corresponding to the target matrix units is centrally stored in the second document directory, enabling the second project documents to be managed in a structured manner. The second project documents themselves are stored in the corresponding database. Due to database migration, file renaming, version updates, etc., the storage path may change. By using database tags to listen to the database corresponding to the second project documents, the status changes of the second project documents can be automatically detected, and the index information can be updated in real time. This ensures that the project document status is always synchronized with the construction progress, avoiding delays or errors caused by manual index maintenance, ensuring that users can access the latest version of the project documents, and improving the level of intelligence in construction management.

[0195] On the other hand, compared with traditional document management methods, the document management method in this manual can establish a logical mapping between project documents and construction areas and progress nodes, making the connection between project documents and construction operations closer. Since construction operations are the hub for cooperation among various functional units, when the connection between project documents and construction operations is closer, project documents and functional departments can also form a closer connection, and project documents can thus play a greater role (such as compliance assessment, early warning handling, etc.).

[0196] Figure 7 is an exemplary schematic diagram illustrating the determination of a first project document and the generation of a first document directory according to some embodiments of this specification.

[0197] As shown in Figure 7, the processor can match the corresponding candidate project document 730 from the general document directory library 720 according to the feature value 710 of the project characteristics of the target project; based on the candidate project document 730, determine the first project document 740 corresponding to the target project and generate the first document directory 750.

[0198] For more information on the general document catalog and reference values, see step 420 and its related description.

[0199] In some embodiments, a general document catalog is configured to store reference values ​​for project characteristics and correspondences between different types of project documents, as well as document tags for each type of project document.

[0200] Reference values ​​are not specific to any particular project, but rather represent a general, fixed mapping between document types and project characteristics. Reference values ​​can typically be defined based on industry experience or historical data. In a general document catalog, the processor records the correspondence between each project document and its reference value. For example, if the project document is a concealed rebar acceptance form, the engineering category reference value would be applicable to building construction projects, and the regional reference value would be applicable to Guangdong Province. The processor can match reference values ​​in the general document catalog based on the characteristic values ​​of the target project, thereby filtering out suitable candidate project documents for that construction project.

[0201] The document mapping relationship refers to displaying documents corresponding to different project categories and regions in a general document directory based on reference values. For example, the mapping relationship could be documents for Sichuan housing construction, documents for Guangdong airports, etc.

[0202] In some embodiments, a general document catalog can be constructed by the user. In some embodiments, the general catalog can be obtained by statistical analysis of historical data of a project. For example, as shown in Figure 7, the general document catalog can be constructed in the following way: obtaining sample document catalogs 721 of multiple sample projects and feature values ​​722 of project features for each sample project; determining the feature value distribution of project features corresponding to various types of project documents based on the sample document catalogs 723; and determining reference values ​​724 of project features corresponding to each type of project document based on the feature value distribution of various types of project documents.

[0203] Sample projects can be determined based on historical data. For example, multiple sample projects can be identified from multiple historical construction projects and used to generate a general document catalog.

[0204] The sample document directory refers to the document directory corresponding to the sample project, which stores relevant information about the sample documents involved in the sample project. In some embodiments, the processor can obtain all historical documents of the sample project as sample documents and generate a sample document directory based on relevant information of the sample documents (such as document name, document generation time, document uploader, and document type).

[0205] In some embodiments, the sample document directory includes a filing project document directory and a project management document directory. The sample documents (also referred to as filing project documents) in the filing project document directory are project documents that are required to be archived by government or construction project industry regulations, such as process acceptance documents, sub-item acceptance documents, supervision logs, pouring orders, etc. In some embodiments, the filing project document directory records the hierarchical division of the filing project documents; for example, the first-level directory is the project category, and the second-level directory is the document category, etc.

[0206] The sample documents (also known as project management documents) mentioned in the project management document catalog are documents used for internal management by the participants of the sample project, such as meeting minutes and daily construction reports.

[0207] In some embodiments, the storage format of the filing project documents in the filing project document directory is [document type, region, project category, filing requirements], and the storage format of the project management documents in the project management document directory is [document type, region, project category, construction unit, construction company].

[0208] In some embodiments, the processor can obtain filing document entries and compilation requirements for different regions and project categories based on local government regulations, industry standards, industry databases, etc.; construct a filing project document directory based on the filing document entries and compilation requirements; obtain historical document data of sample projects and construct a project management document directory accordingly; merge the filing project document directory and the project management document directory and remove duplicates to determine the sample document directory. Users (such as project managers) can manually adjust the sample document directory according to actual needs.

[0209] In some embodiments, the processor can identify the storage format of the project management documents to obtain the feature values ​​of the project characteristics of the sample project. For example, if the storage format of the project management documents used in the sample project is [document type, region, project category, construction unit, construction company], the processor can parse the storage format and extract the feature values ​​corresponding to the region, project category, construction unit, and construction company of the sample project (i.e., the feature values ​​of each project characteristic).

[0210] For each type of project document, the feature value distribution of the project characteristics corresponding to that type of project document can be determined based on the sample document directory. This feature value distribution can reflect the frequency of occurrence of each feature value of the sample project that stores that type of project document.

[0211] Specifically, the processor can determine the feature value distribution of project features corresponding to various project documents by statistically analyzing the frequency of occurrence of each document category under different feature values, based on a sample document directory. For example, for acceptance documents, the processor can statistically analyze their frequency of occurrence in sample projects in different regions, sample projects of different project categories, sample projects of different construction units, and sample projects of different construction companies, thereby determining the feature value distribution of the project features corresponding to the acceptance documents. Taking a region as an example, if the frequency of occurrence of acceptance documents in sample projects in Sichuan, Guangdong, and Hangzhou is A, B, and C respectively, then the feature value distribution of this project feature in that region is A, B, and C.

[0212] In some embodiments, for various project documents, the processor can filter out one or more feature values ​​whose occurrence frequency is higher than the first frequency threshold as reference values ​​based on a first frequency threshold and the distribution of their feature values. The first frequency threshold can be preset by the user according to needs, or it can be determined based on the total number of occurrences of various project documents (e.g., the frequency threshold can be 20% of the total number of occurrences). Continuing the example above, assuming that occurrence frequencies A and B exceed the first frequency threshold, and C is less than the first frequency threshold, then Sichuan and Guangzhou will be used as reference values, and Hangzhou will be excluded.

[0213] In some embodiments, if the project document is a filing document required by the government or the construction industry, it will not be removed even if the frequency of occurrence of the project feature corresponding to the project document is lower than the first frequency threshold.

[0214] In some embodiments of this specification, establishing a universal document catalog library provides a data foundation for document management of various construction projects, ensuring that all construction projects adhere to a unified document management standard and guaranteeing consistency in project document management. During the construction of the universal document catalog library, high-frequency characteristic values ​​are determined as reference values ​​by statistically analyzing the distribution of characteristic values. The most common characteristic values ​​are retained for generating the first project document catalog, avoiding the influence of accidentally occurring characteristic values. Simultaneously, mandatory archiving documents will not be mistakenly removed due to low frequency, ensuring the compliance of project document management and preventing the omission of government or industry-required filing documents. This makes the construction of the universal document catalog library more consistent with the general situation in the actual construction industry.

[0215] Candidate project documents refer to project documents in a general document catalog that match the target project. In some embodiments, the processor can filter project documents with the same feature values ​​as the target project based on reference values ​​of project features corresponding to each type of project document in the general document catalog, and use these as candidate project documents. For example, if the reference value of a document is the same as the feature value of the target project's project features, then that document can be a candidate project document. Continuing the example above, if the target project is located in Sichuan, and the reference value of the region corresponding to the acceptance document in the general document catalog includes Sichuan, then the acceptance document will be selected as a candidate project document; if the target project is located in Nanjing, and the reference value of the region corresponding to the acceptance document in the general document catalog does not include Nanjing, then the acceptance document will not be selected as a candidate project document.

[0216] In some embodiments, the processor can directly use candidate project documents as the first project document corresponding to the target project and generate a first document directory. In some embodiments, the processor can filter candidate project documents to determine the first project document and generate a first document directory. For example, the frequency of occurrence of candidate project documents in the sample project can be determined, and candidate project documents with a frequency less than a second frequency threshold can be removed. The second frequency threshold can be preset according to requirements. Users can manually adjust the first project document according to actual needs. After the first project document is determined, relevant information of the first project document in the general document directory library (such as document tags) will be inherited and stored in the first document directory.

[0217] In some embodiments of this specification, construction projects are diverse, and different engineering categories (such as building construction and municipal engineering) require different documents. By matching backup project documents from a general document directory library based on the feature values ​​of the target project, and then filtering the backup project documents, a first document directory is finally generated. This ensures that the first project documents are complete and meet the needs of the target project, while avoiding the influence of low-frequency project documents. At the same time, users can manually adjust the first project documents to meet personalized needs without affecting project document management.

[0218] Figure 8 is an exemplary flowchart of construction progress management based on an updated second project document, according to some embodiments of this specification.

[0219] In some embodiments, process 800 may be executed by a processor. In some embodiments, process 800 may be executed after step 440.

[0220] As various construction activities within the target project progress, corresponding second project documents will be generated or updated. These status changes will trigger updates to the index information in the second document directory. Because of the correlation between construction activities and second project documents, the updated second document directory can reflect changes in the construction progress of the target project; therefore, construction progress management can be performed based on the updated second document directory.

[0221] Step 810: Based on the updated second document directory, determine whether the target progress node corresponding to the target matrix unit meets the progress node update conditions.

[0222] The target schedule node refers to the schedule node corresponding to the target matrix unit.

[0223] The update conditions for a schedule node refer to the prerequisites that must be met for a target schedule node to advance to the next schedule node in the target project.

[0224] In some embodiments, the progress node update condition includes that a specific number (e.g., all) of the second project documents corresponding to the target progress node, or one or more specific second project documents (e.g., acceptance documents), have been uploaded. For example, when the target progress node is the main structure of the first floor, the progress node update condition includes that the acceptance documents for the main structure have been uploaded.

[0225] As described in step 440, when the status of the second project document changes, updated index information in the second document directory can be generated. The processor can then determine whether the target progress node meets the progress node update conditions based on the updated index information in the second document directory.

[0226] Step 820: In response to determining that the target progress node meets the progress node update conditions, based on the association information related to the construction progress matrix, determine the association matrix units that are associated with the target matrix unit.

[0227] An association matrix cell refers to other matrix cells that are related to the target matrix cell. In some embodiments, there can be one or more association matrix cells. Other matrix cells may correspond to the same or different construction areas as the target matrix cell. That is, related matrix cells can be located in the same row (or column) of the construction schedule matrix, or they can be located in different rows (or columns) of the construction schedule matrix.

[0228] The relationship information reflects the relationships between different matrix units in the construction schedule matrix. There are sequential dependencies between schedule nodes and construction areas in different matrix units, including but not limited to schedule node dependencies and construction area influence relationships. For example, a schedule node dependency could mean that a certain schedule node must be completed before other related schedule nodes can be executed. For instance, the construction tasks in the main structure must be completed before the electromechanical pre-embedded construction tasks can be carried out. A construction area influence relationship could mean that a certain construction area may affect the progress of other construction areas, such as upper-level construction waiting for the lower level to be completed.

[0229] Relationship information can be determined in several ways. For example, it can be based on disclosure documents such as the construction plan of the target project. Alternatively, it can be manually entered by the user through a terminal device.

[0230] The processor can determine the associated matrix cells that are related to the target matrix cell based on the association information of the target matrix cell. For example, in response to determining that the target schedule node meets the schedule node update condition, the processor can retrieve the construction schedule matrix based on the association information and determine the associated matrix cells affected by the target matrix cell.

[0231] Step 830: Send a construction notification to the target associated unit of the association matrix unit.

[0232] A target associated unit refers to the associated unit corresponding to a unit in the association matrix. Target associated units can be determined based on the correspondence between each matrix unit in the construction schedule matrix and the participating units of the target project. The processor can send construction notifications to the terminals of the personnel responsible for the target associated units. The construction notification is used to inform that a certain construction task at the target schedule node has been completed and that the construction task for the associated matrix unit needs to be initiated.

[0233] In some embodiments, the document tags further include associated unit tags and construction task tags. Sending a construction notification to the target associated unit of the association matrix unit includes: determining the fourth project document corresponding to the association matrix unit based on the construction area tags and progress node tags of multiple first project documents; determining the target fourth project document based on the construction task tags of the fourth project document, wherein the construction time corresponding to the target fourth project document meets preset conditions; and determining the target associated unit based on the associated unit tags of the target fourth project document and sending a notification to the target associated unit.

[0234] The fourth project document refers to the document corresponding to the association matrix unit. The processor can filter out project documents in the first project document that have the same construction area and schedule node as the association matrix unit based on the construction area label and schedule node label of the first project document, and use them as the fourth project document.

[0235] The target fourth project document refers to a project document within the fourth project document set that meets preset conditions. In some embodiments, the processor can determine the target fourth project document based on the construction task tags of the fourth project document. Construction task tags are tags that identify the construction tasks associated with the project document. The method for determining construction task tags is similar to that described in step 550 regarding the warning rule tags, and will not be repeated here.

[0236] For example, for each fourth project document, the processor can determine whether the construction time of the corresponding construction task meets preset conditions based on the construction task tag of the fourth project document. If the preset conditions are met, the fourth project document is determined to be the target fourth project document. For example, the preset conditions could be that the construction time is within 7 days and the construction time is among the first N construction tasks corresponding to all fourth project documents. In other words, when construction work related to the association matrix unit begins, the construction task corresponding to the target fourth project document (e.g., within 7 days) will be carried out first.

[0237] Furthermore, the processor can determine the target associated unit and send a notification to the target associated unit based on the associated unit tag of the target fourth project document.

[0238] In some embodiments of this specification, by using construction task tags to filter target fourth project documents that meet the construction time requirements, notifications can be prioritized for target related units with earlier construction dates. This ensures that construction tasks proceed as planned, reduces construction delays caused by project document delays, and improves the efficiency of construction task execution. Furthermore, based on related unit tags, target related units can be quickly and accurately identified, and construction notifications can be sent to them. This ensures that the submission and approval of construction documents are carried out on time by the relevant units, reducing management loopholes caused by untimely manual notifications and improving the intelligence level of project document management.

[0239] In some embodiments of this specification, the updated second document directory can be used to determine whether the target progress node corresponding to the target matrix unit meets the progress node update conditions, ensuring that the construction progress proceeds as planned and improving construction efficiency. By using the association information related to the construction progress matrix, associated matrix units that are related to the target matrix unit can be identified, and construction notifications can be sent to the associated units. This ensures the orderly connection between different construction tasks, avoids task interruptions and resource waste, improves overall construction collaboration efficiency, and ensures that changes in construction progress are promptly communicated to the relevant responsible units. Through these methods, construction progress management based on project documents is achieved, improving the automation and efficiency of construction progress management.

[0240] Figure 9 is an exemplary schematic diagram of a progress display table according to some embodiments of this specification.

[0241] In some embodiments, the processor can generate a progress display table corresponding to the construction progress matrix and annotate the display cells corresponding to the target matrix units in the progress display table. Specifically, the processor can determine the progress information of the target matrix units based on the updated second document directory; and annotate the display cells corresponding to the target matrix units in the progress display table based on the progress information.

[0242] The progress display table is used to visually represent the construction progress of each construction area and progress node. As shown in Figure 9, the progress display table 910 is a two-dimensional table, with the vertical axis and horizontal axis representing the construction area and progress node in the construction progress matrix, respectively. In some embodiments, the processor can generate the progress display table based on the construction area and progress node in the construction progress matrix. For example, the processor uses the construction area as the row and the progress node as the column in the progress display table according to the construction progress matrix, thereby generating the table structure of the progress display table. For more information on two-dimensional tables, please refer to step 1070 and its related description.

[0243] A display cell is the basic unit of a progress display table. Each matrix cell in the construction progress matrix corresponds to a display cell in the progress display table. The processor can determine the corresponding display cell based on the construction area and progress node of the target matrix cell.

[0244] Progress information reflects the completion status of relevant construction tasks for the target matrix unit. For example, progress information includes the status of each construction task (not started, in progress, completed), the completion percentage of all construction tasks, etc. Progress information can be determined based on an updated second document directory. For example, for each construction task, the processor can determine whether the acceptance form for that construction task has been uploaded based on the updated second document directory; if the acceptance form has been uploaded, it further retrieves the acceptance form to confirm whether the construction task has passed acceptance; if it has passed acceptance, the construction task is confirmed to be completed. In some embodiments, progress information can be expressed as a percentage, representing the completion percentage of all construction tasks for the target matrix unit.

[0245] In some embodiments, the processor can annotate the display cells corresponding to the target matrix units in the progress display table based on progress information. For example, the processor can use color annotation (e.g., see color coding in step 1060), percentage annotation, text annotation, or other methods to annotate the display cells corresponding to the target matrix units.

[0246] For example, as shown in Figure 9, the third color mark indicates that all construction tasks have been completed, the second color mark indicates that some construction tasks have been completed, and the first color mark indicates that all construction tasks have not started; the percentage indicates the completion rate of all construction tasks, 100% means all construction tasks have been completed, 50% means half of the construction tasks have been completed, 0% means all construction tasks have not started, etc.

[0247] In some embodiments of this specification, by generating a progress display table of the construction progress matrix and marking the display cells corresponding to the target matrix units in the progress display table, users can intuitively view the construction progress status of the target project, thereby improving the visualization effect of the construction progress; through the marking of the display cells, the construction progress can be monitored in real time to prevent the construction progress from lagging behind.

[0248] Figure 10 is an exemplary flowchart of construction task assignment based on progress, according to some embodiments of this specification.

[0249] As shown in Figure 10, process 1000 includes steps 1010-1070. In some embodiments, process 1000 may be executed by a processor.

[0250] Step 1010: Obtain multiple construction area data for multiple construction areas and multiple progress node data for multiple progress nodes of the construction project.

[0251] For more information on construction projects, construction areas, construction area data, progress milestones, and progress milestone data, please refer to step 410 and its related description.

[0252] In some embodiments, a construction area may include a multi-level structure, i.e., a hierarchical relationship between multiple construction areas, wherein a higher-level construction area contains one or more lower-level construction areas. For example, a construction project may be divided into multiple individual buildings (such as "Building 1", "Building 2", etc.), each individual building may be divided into multiple floors, each floor may be divided into multiple units, and each unit may be divided into multiple functional rooms (such as "living room", "bedroom", etc.). For example, in "the living room of Unit 201 on the 2nd floor of Building 1", the "living room" construction area belongs to the construction area "Unit 201" at the next higher level; the construction area "Unit 201" belongs to the construction area "2nd floor" at the next higher level; and "2nd floor" belongs to the construction area "Building 1". This hierarchical subordinate and inclusive relationship formed by "Building 1", "2nd floor", "Unit 201", and "living room" embodies the multi-level structure of the construction area. The processor can manage and assign tasks to any one or more levels of construction areas in the multi-level structure of the construction area.

[0253] In some embodiments, multiple construction areas of a construction project can be obtained from Building Information Modeling (BIM) or Computer-Aided Design (CAD) drawings, or they can be manually divided and entered by managers through user terminals in system 300 according to the needs of the construction project.

[0254] In some embodiments, the construction area data may also include other attributes related to the management of the construction area, such as at least one of the following: construction difficulty coefficient, safety risk level, quality requirement level, etc.

[0255] In some embodiments, construction area data can be automatically extracted from files such as building information models and CAD drawings, or configured or input by the user in the system 300.

[0256] In some embodiments, when the design file is a Building Information Model (BIM), the processor can extract construction area data by parsing the data structure of the BIM model. For example, the processor can directly read the predefined attributes of each component object in the model, such as component name (e.g., “load-bearing wall-1”), floor (e.g., “F2”), room number (e.g., “R-201”), etc., and combine these attribute information into the corresponding construction area data.

[0257] In some embodiments, when the design document is a computer-aided design (CAD) drawing, the processor can extract construction area data by executing image recognition and layer analysis algorithms. For example, the processor can identify areas in the CAD drawing composed of closed polylines and, in conjunction with the name of the layer containing that area (e.g., the layer name is "ROOM_BOUNDARY") and the text annotation within the layer (e.g., "living room"), determine the boundary and name of a functional room construction area, thereby extracting construction area data.

[0258] In some embodiments, each of the multiple schedule nodes includes multiple construction tasks with a construction sequence. For example, each schedule node is not a single action, but a collection of multiple construction tasks with an inherent logical order (construction sequence).

[0259] A construction task is the smallest operational unit that constitutes a progress node. In some embodiments, each construction task corresponds to a specific, executable construction operation. For example, the progress node of "main structural engineering" may include multiple construction tasks such as "reinforcement binding", "formwork erection", and "concrete pouring".

[0260] Construction sequence refers to the sequential execution relationship between multiple construction tasks within the same progress node. For example, before pouring concrete, rebar tying and formwork erection must be completed first. In some embodiments, the sequential execution relationship between multiple construction tasks must be followed due to process requirements, technical specifications, or safety regulations.

[0261] In some embodiments, schedule milestones may be determined based on industry-standard construction processes (e.g., based on sub-items of work).

[0262] In some embodiments, the progress node data mainly includes a list of all construction tasks included in the progress node, as well as the construction sequence that must be followed among these construction tasks.

[0263] In some embodiments, progress node data can be obtained from a pre-defined progress node template library. This template library can pre-define standardized progress nodes and their internal construction tasks and logical relationships according to different building types and industry standards.

[0264] In some embodiments, the construction sequence can be predefined in a progress node template library and obtained together with the progress node data, or the construction sequence can be set through industry standard procedures for building construction.

[0265] In some embodiments, the processor can obtain the specific construction tasks and logical relationships contained in a progress node from an industry-standard progress node template library. For example, a progress node for a decoration and renovation project may include a series of construction tasks with a construction sequence, such as "wall plastering," "floor leveling," and "ceiling installation."

[0266] Step 1020: Generate multiple matrix units based on data from multiple construction areas and multiple progress nodes.

[0267] In some embodiments, each of the multiple matrix units corresponds to one of the multiple construction areas and one of the multiple progress nodes.

[0268] A matrix unit refers to a management unit formed by binding construction areas to progress nodes one-to-one.

[0269] In some embodiments, a matrix cell represents a set of phased construction tasks that need to be completed at a specific construction area. For example, combining a construction area named "Unit 2, Building 3, Apartment 501" with a progress node named "Interior Decoration" generates a matrix cell that means "Complete the interior decoration work in Unit 2, Building 3, Apartment 501". Accordingly, the series of sequential construction tasks included in the "Interior Decoration" progress node will be executed in the construction area "Unit 2, Building 3, Apartment 501".

[0270] In some embodiments, the processor can obtain matrix cells in multiple ways. In some embodiments, the processor can perform Cartesian combination on the obtained set of multiple construction areas and multiple progress nodes, that is, iterate and pair each construction area with each progress node, and each pairing generates a corresponding matrix cell. Thus, a two-dimensional matrix structure can be constructed with construction areas as the vertical axis and progress nodes as the horizontal axis, and each cell in the matrix is ​​a matrix cell.

[0271] In some embodiments, generating multiple matrix units based on multiple construction area data and multiple progress node data includes: performing spatial conflict verification on multiple construction spaces required by multiple construction areas and multiple progress nodes; and generating multiple pairs of target construction areas and multiple matrix units corresponding to target progress nodes in response to the passing of spatial conflict verification of multiple target construction spaces in multiple construction spaces.

[0272] The required construction space refers to the spatial attribute conditions that must be met to execute a matrix unit. In some embodiments, the required construction space may include the inherent spatial information of the corresponding construction area itself and the spatial requirements of the corresponding progress node for the application scenario. For example, the inherent spatial information of a construction area named "Building 1, Unit 1, Household 101" can be defined as "indoor, ground floor"; while the spatial requirements of a progress node named "roof waterproofing project" are "outdoor, top floor, horizontal plane", etc.

[0273] The processor can acquire multiple construction spaces required by multiple construction areas and multiple progress nodes through various methods. In some embodiments, the spatial information of the construction area can be automatically parsed and extracted from the geometric information and metadata contained in the building information model or CAD drawings. For example, the processor can determine the floor of the construction area based on the floor elevation in the building information model, and determine whether the construction area is indoors or outdoors based on the component type. In some embodiments, the spatial requirements of the progress nodes can be pre-stored as data in a progress node template library. For example, the spatial requirement corresponding to the "main structure" progress node in the progress node template library can be "all areas," while the spatial requirement corresponding to the "landscape greening" progress node can be "outdoors," etc.

[0274] Spatial conflict verification refers to comparing and verifying the spatial information of a construction area to be combined into matrix units with the spatial requirements of a progress section in order to determine whether there is a contradiction or mismatch between the two.

[0275] In some embodiments, spatial conflict verification can be further divided into logical conflict verification and physical conflict verification. Logical conflict verification refers to determining whether a combination of a construction area and a schedule node is incompatible in terms of construction technology, building function, or project management logic. For example, the processor can determine that applying the schedule node "Foundation and Foundation Engineering" to the "Construction Area of ​​the 5th Floor" is logically invalid due to construction technology limitations, thus constituting a logical conflict. Physical conflict verification refers to determining whether a combination of a construction area and a schedule node is incompatible based on the actual physical spatial attributes of the building. For example, the processor can determine that applying the schedule node "Interior Decoration" to the "Construction Area of ​​the Outdoor Plaza" is physically incompatible, thus constituting a physical conflict.

[0276] In some embodiments, the spatial conflict verification process may include: extracting the spatial information of the construction area to be combined into matrix units and the spatial requirements of the progress nodes, and matching them according to preset verification rules. For example, the verification rules may include: when the spatial requirement of a progress node includes "outdoor", the spatial information of its matched construction area must also include "outdoor", otherwise it is judged as a spatial conflict; the spatial requirement of the progress node "foundation and foundation engineering" is "first floor", the spatial information of its matched construction area must include "first floor", otherwise it is judged as a logical conflict; the spatial requirement of the progress node "interior decoration" is "indoor", the spatial information of its matched construction area must include "indoor", otherwise it is judged as a physical conflict, etc., at least one of the following.

[0277] In some embodiments, when a combination of a construction area and a progress node requires no conflict in the required construction space under all verification rules, the space conflict verification for that combination is deemed to have passed. Conversely, if any verification rule is triggered and determined to be in conflict, the space conflict verification for that combination fails.

[0278] In some embodiments, the processor can iterate and pair each construction area with each progress node to generate multiple combinations to be assembled into matrix units; perform spatial conflict checks on the construction spaces of these combinations; in response to a combination of components passing the spatial conflict check, the processor determines the construction space in that combination as a target construction space, and generates corresponding matrix units based on the construction area and progress node corresponding to the target construction space (i.e., the construction area and progress node in the combination of components corresponding to the target construction space). The matrix unit is created as a data object, containing a reference or identifier to the target construction area and the target progress node, thus binding the two together. Conversely, for combinations of components that fail the spatial conflict check, the processor does not perform any generation operation and discards them as invalid combinations.

[0279] In some embodiments of this specification, the introduction of a spatial conflict verification mechanism can bring significant benefits. Firstly, it ensures the accuracy and effectiveness of the project plan. This mechanism filters out all combinations of construction areas and schedule nodes that are logically or physically unexecutable from the outset, ensuring that each generated matrix unit is meaningful and feasible, avoiding erroneous instructions in subsequent task assignment stages, thereby improving the rigor of project management. Secondly, it improves the system's operational efficiency. By eliminating a large number of invalid combinations, the number of matrix units that need to be generated, stored, and processed is significantly reduced. This not only saves database storage space and system computing resources but also speeds up the response time of subsequent operations such as priority calculation, data analysis, and visualization rendering, optimizing the overall performance of the system.

[0280] In some embodiments, for each matrix unit, the processor performs the following steps 1030 to 1060:

[0281] Step 1030: Based on the difference set of multiple construction tasks and completed construction tasks of each matrix unit, determine the first task to be dispatched for each matrix unit.

[0282] In some embodiments, the processor only dispatches construction tasks to matrix units that are currently idle (without construction tasks in progress), while it does not dispatch construction tasks to matrix units that are currently undergoing construction tasks.

[0283] The difference between multiple construction tasks and completed construction tasks refers to the set of remaining, unassigned construction tasks obtained by subtracting the set of completed construction tasks within the construction area corresponding to a construction node that is in an idle state from the set of all construction tasks included in that matrix cell. For example, if a construction node includes three construction tasks: {"wall plastering", "plastering", and "priming"}, and the task "wall plastering" has been completed within its corresponding construction area, then the difference is {"plastering", "priming"}.

[0284] In some embodiments, the difference set can be calculated by querying the status information of multiple construction tasks of the matrix unit pre-stored in the storage device of the system 300.

[0285] The first task to be assigned refers to the set of one or more construction tasks that need to be executed next in this matrix cell, as calculated by the aforementioned difference set. In other words, the first task to be assigned is the set of all "to-do" tasks within this matrix cell. For example, the remaining tasks to be executed {"plastering", "applying primer"} are the first tasks to be assigned in this matrix cell.

[0286] Step 1040: Determine the priority of the first task to be dispatched based on the weight coefficient of each matrix unit.

[0287] Weighting coefficients are numerical values ​​used to characterize the relative importance or urgency of each matrix element.

[0288] In some embodiments, the weighting coefficient can be a specific numerical value (such as a value between 0 and 1), and the higher the value, the higher the priority of the matrix unit. For example, the weighting coefficient (such as 0.9) of a matrix unit corresponding to a critical construction area will be significantly higher than that of a matrix unit corresponding to a non-critical construction area (such as 0.3).

[0289] The processor can obtain weighting coefficients in various ways. In some embodiments, the processor can comprehensively consider multiple factors to obtain weighting coefficients, where the weighting coefficient can be a normalized value between 0 and 1. In some embodiments, the processor can comprehensively consider whether the schedule node corresponding to the matrix unit is located on the critical path of the project, the number of prerequisite dependent tasks of the schedule node, the importance of the construction area corresponding to the matrix unit (e.g., the importance of the "model room" area is higher than that of the "equipment room" area), and the degree of deviation between the actual progress and the planned progress of the matrix unit to determine the weighting coefficients.

[0290] For example, the processor can construct a project network diagram based on the underlying logic between multiple schedule nodes and the estimated duration for each schedule node. Subsequently, the processor determines the earliest start time (ES) and latest start time (LS) of each schedule node through forward and backward calculations. When the earliest start time and latest start time of a schedule node are the same (i.e., ES = LS), the schedule node is determined to be on the critical path of the project. In this case, the processor assigns a higher value (e.g., 1) to the critical path factor of matrix cells on the critical path, and a lower value (e.g., 0) to the critical path factor of matrix cells on non-critical paths.

[0291] For example, the processor can count the number of direct subsequent dependent tasks of each progress node as a predecessor node based on the aforementioned project network diagram; the larger the number, the stronger the pivotal nature of the node; the processor can normalize the number (e.g., divide by the largest number of subsequent dependent tasks among all nodes) to obtain the pivotal factor (between 0 and 1) of the matrix unit.

[0292] For example, the importance data of construction areas can be pre-assigned by project managers during the project initialization phase, based on project management needs (e.g., setting areas such as "model rooms" and "critical equipment rooms" as high importance). Each construction area can be pre-assigned an importance score via a user terminal. The processor directly retrieves this pre-assigned score and normalizes it, using it as the regional importance factor for that matrix unit.

[0293] In some embodiments, the processor uses a weighted summation method to combine the above multiple factors into a final weight coefficient. For example, the weight coefficient = (critical path factor × w1) + (hub factor × w2) + (regional importance factor × w3). Here, w1, w2, and w3 are preset weight parameters, or they can be determined by user input. This method ensures that influencing factors of different natures and dimensions are combined into a standardized, rankable weight coefficient value.

[0294] Priority refers to the level used to determine the order in which the first task to be dispatched in different matrix units is dispatched.

[0295] In some embodiments, the priority of the first task to be assigned can be reflected by the magnitude of the weight coefficient of the matrix unit to which the first task to be assigned belongs. The larger the weight coefficient of the matrix unit, the higher the priority of the first task to be assigned within it. For example, if the weight coefficient of matrix unit A is 0.95 and the weight coefficient of matrix unit B is 0.80, then the priority of the first task to be assigned in matrix unit A will be higher than the priority of the first task to be assigned in matrix unit B.

[0296] Furthermore, the construction tasks within each matrix unit have a fixed construction sequence, which determines the execution order of multiple first-to-be-assigned tasks contained within the same matrix unit. Therefore, when determining the final sequence of first-to-be-assigned tasks, the processor considers both priority and construction sequence. Specifically, the processor first sorts all matrix units containing first-to-be-assigned tasks in descending order based on the priority between matrix units. Then, according to this sorting result, the processor sequentially selects the first-ranked construction task from each matrix unit and assigns it according to the construction sequence of its internal construction tasks.

[0297] In some embodiments, the processor may also determine a first weighting coefficient and a second weighting coefficient for each matrix unit; and, based on the combined result of the first weighting coefficient and the second weighting coefficient, determine the priority of the first task to be dispatched. For more details, see Figure 12 and its related description.

[0298] Step 1050: Based on the priority of the first task to be assigned, determine and assign the selected construction task.

[0299] Selected construction tasks refer to specific construction tasks chosen from one or more first-pending tasks and prepared for execution. For example, if the processor determines that the construction task in "Matrix Unit A" should be executed according to priority, and the first-pending task in Matrix Unit A is "plastering" in the construction order, then the "plastering" task becomes a selected construction task.

[0300] In some embodiments, the processor can start by selecting from the first task to be dispatched included in the matrix unit with the highest priority, and then select the first task to be dispatched as the selected construction task and dispatch it.

[0301] In some embodiments, after selection, the processor can further perform resource or environmental constraint checks, such as checking whether the special equipment or construction team required to execute the selected first task to be assigned is currently available. Only the first task to be assigned that passes all checks is finally determined as the selected construction task and enters the assignment process, such as generating a construction task order for it and issuing it to the task recipient. For more information about the task recipient, please refer to Figure 5 and its related description.

[0302] In some embodiments, the processor can also extract standardized content from the knowledge base based on the first task to be dispatched, and generate more content for the construction task sheet corresponding to each matrix unit, as shown in Figure 13 and its related description.

[0303] Step 1060: Based on the execution status of the selected construction task, update the status information and color-code each matrix unit.

[0304] The execution status refers to the actual progress of a selected construction task that has been assigned and is being carried out at the construction site. In some embodiments, the execution status may include multiple stages such as "not started," "in progress," "completed," "delayed," "accepted," and "unaccepted." In some embodiments, the execution status may also include the progress percentage for each stage; for example, the execution status may be "in progress, 50%." In some embodiments, construction personnel can manually update and submit the execution status and progress percentage of the construction task through a user terminal at different stages of task execution.

[0305] In some embodiments, the processor may also, in response to detecting that the execution state of the first matrix unit is delayed, determine at least one second matrix unit affected by the first matrix unit for reassignment. For more details, see Figure 14 and its related description.

[0306] In some embodiments, the processor can acquire the execution status in various ways. For example, the processor can acquire the execution status in real time through "task probes" deployed at the construction site (e.g., mobile applications operated by construction personnel or IoT sensors). Alternatively, the execution status can be uploaded by construction personnel or managers through user terminals.

[0307] The status information of a matrix unit refers to the overall progress status of each matrix unit. In some embodiments, the status information is obtained by comprehensively evaluating the execution status of all construction tasks contained within the matrix unit (i.e., all construction tasks of the progress node corresponding to the matrix unit). For example, when all construction tasks within a matrix unit have not started, its status information is "not started"; when at least one construction task is in the "in progress" state, its status information is updated to "in progress"; when all construction tasks have reached the "acceptance qualified" state, its status information is updated to "completed".

[0308] Color coding refers to a mapping rule for visually representing the state information of node units. In some embodiments, by pre-setting different colors for different state information, progress can be intuitively displayed in the visualization view. For example, color coding can be defined as: gray representing "not started", yellow representing "in progress", green representing "completed", and red representing "delayed", etc.

[0309] In some embodiments, the processor can monitor the execution status of any selected construction task that has been dispatched in real time. When a change in execution status is detected (e.g., the construction team marks the task status of the construction task as "in progress" to "completed" on the user terminal or updates the percentage of progress of the construction task), the processor will automatically perform one or more of the following operations: locate the matrix cell to which the construction task belongs, and recalculate and update the status information of the matrix cell based on the latest execution status of all construction tasks within the matrix cell; update the execution status of the construction tasks in the matrix cell (e.g., from "90% in progress" to "completed", or from "10% in progress" to "20% in progress"); and match and update the corresponding color code for the matrix cell whose status information has been recalculated according to a preset color code, so as to reflect the latest progress of the construction project in real time in the visualization view. The percentage of progress in progress can be determined based on the ratio of the number of completed construction tasks included in the matrix cell to the total number of construction tasks.

[0310] Step 1070: Generate a visual view that displays the progress of the image.

[0311] In some embodiments, the visualization view includes a view presented in a two-dimensional table format. In the two-dimensional table format view, the vertical axis displays multiple construction areas, and the horizontal axis displays multiple progress nodes.

[0312] Visual progress refers to a management model that presents the progress status of a construction project in an intuitive and graphical way. In some embodiments, visual progress can be achieved through a two-dimensional matrix structure that organically combines progress in the time dimension (represented by progress nodes) with location in the spatial dimension (represented by construction areas), allowing managers to quickly grasp the overall status of the project as if viewing a "visual map".

[0313] A visual view refers to a user interface used to display and visualize progress. For example, a visual view can be a two-dimensional table view as shown in Figure 11. Alternatively, a visual view can be a three-dimensional visual view. In some embodiments, a three-dimensional visual view can be a digital three-dimensional scene that allows users to interactively browse, formed by mapping and rendering the state information of multiple matrix units onto a virtual building model through preset graphical attributes (such as color and transparency).

[0314] In this visualized 3D view, the color displayed for each component or space (such as a wall or a room) on the virtual building model dynamically reflects the progress of related construction tasks within its corresponding construction area. For example, a floor slab under construction can be rendered yellow, while a wall that has been plastered is rendered green. By rotating, scaling, and panning this 3D view, users can intuitively and immersively perceive the actual construction progress of the entire project from any angle.

[0315] Figure 11 is an exemplary schematic diagram showing a visual view according to some embodiments of this specification.

[0316] Figure 11 shows a visualization view, chart 1100, presented in a two-dimensional table format. In chart 1100, the vertical axis displays multiple construction areas in a list format, such as "Construction Area 1," "Construction Area 2," "Construction Area 3," and "Construction Area 4," thus dividing the project spatially in the vertical direction. The horizontal axis corresponds to multiple progress nodes, such as "Progress Node 1," "Progress Node 2," and "Progress Node 3," thus dividing the project horizontally according to the construction process stages. Each cell formed by the intersection of the vertical and horizontal axes is a matrix unit; for example, "Matrix Unit 2-3" is formed by the intersection of "Construction Area 2" and the third progress node.

[0317] As shown in Figure 11, each cell (matrix unit) displays the execution status of the assigned construction tasks in the corresponding construction area. For example, "In Progress 20%" displayed in cell 2-2 indicates that the current construction task is 20% complete. Furthermore, since the construction tasks within each matrix unit have a specific construction sequence, the user can also determine from the content displayed in matrix unit 2-2 that the tasks preceding the current task have been completed. Similarly, "Completed" displayed in matrix unit 2-1 and "Delayed" in matrix unit 1-2 respectively indicate that the construction tasks in their respective matrix units have been completed or delayed.

[0318] In some embodiments, the visualization chart 1100 can also represent the acceptance status of construction tasks within the construction area corresponding to the matrix unit. For example, matrix unit 1-1 is displayed as "Acceptance Passed," indicating that all construction tasks within it have not only been completed but have also passed quality acceptance. As another example, matrix unit 3-2 is displayed as "Acceptance Failed," indicating that a completed construction task within this matrix unit failed quality acceptance and requires rectification.

[0319] In some embodiments, the processor can fill different cells with different colors according to color coding rules (not shown in Figure 11). Although not shown in color in Figure 11, in some embodiments, matrix cell 1-1 can be filled with white to indicate that all tasks within the matrix cell have been completed and passed quality acceptance; matrix cell 1-2 can be filled with red to indicate that the construction tasks within the matrix cell are delayed; matrix cell 2-1 can be filled with green to indicate that all construction tasks within the matrix cell are "completed"; matrix cell 2-2 can be filled with yellow to indicate that the construction tasks within the matrix cell are "in progress"; matrix cell 2-3 can be filled with gray to indicate that all construction tasks within the matrix cell are "not started"; and matrix cell 3-2 can be filled with orange to indicate that a certain construction task within the matrix cell has been completed but has not passed quality acceptance. In this way, the visualization chart 1100 can intuitively present the progress status of the entire project to the management personnel.

[0320] In some embodiments, the processor can map each matrix unit to a cell in a table, where the row position of the cell is determined by its corresponding construction area and the column position by its corresponding progress node, thereby generating a visual view. The processor fills the cell with a background color based on the color code corresponding to the latest status information of each matrix unit. Thus, managers can quickly identify the completion status of different construction areas by observing the colors of different cells in the table (e.g., green represents completed, yellow represents in progress), thereby achieving intuitive and macro-level monitoring of project progress and problem localization.

[0321] In some embodiments, generating a visual view showing the progress of the project includes: acquiring multiple location information of multiple construction areas and multiple status information of multiple matrix units; and mapping the multiple status information to the corresponding spatial locations of the virtual building model based on the multiple location information to form a visual three-dimensional view.

[0322] Location information refers to coordinate data used to locate a construction area in three-dimensional space. For example, the location information of a construction area (such as room A) may include the construction area itself and the three-dimensional bounding boxes of each component (such as walls, slabs, columns, etc.) in the three-dimensional space of the physical building. In some embodiments, location information can be directly extracted from the building information model or three-dimensional CAD drawings of the construction project.

[0323] A virtual building model is a digital 3D model that corresponds to a physical building in terms of geometry and spatial location, such as a building information model. In a virtual building model, each virtual component (such as a virtual wall, virtual slab, virtual column, etc.) is an independent object and carries its corresponding location information.

[0324] In some embodiments, the processor can traverse each matrix unit, obtain its status information, and convert it into preset graphical attributes according to preset mapping rules. In some embodiments, the preset mapping rules may include status mapping rules. For example, the status mapping rules may include progress states such as "not started", "in progress", "completed", and "delayed", which are mapped to different colors such as gray, yellow, green, and red, respectively.

[0325] In some embodiments, the processor traverses each matrix unit that needs to be displayed and performs the following mapping: obtains the state information of the matrix unit and the location information of its corresponding construction area; based on the location information, queries and locates one or more spatially corresponding three-dimensional virtual components or virtual spaces in the virtual building model; based on the aforementioned mapping rules, the state information of the matrix unit is converted into a set of specific graphic attributes, and these graphic attributes are applied to the three-dimensional virtual components or virtual spaces that have just been located; after all the states of the matrix units have been converted, three-dimensional rendering is performed to finally form the visualized three-dimensional view.

[0326] In some embodiments, during mapping, the processor can also add the execution status of the construction tasks in each matrix unit to the three-dimensional virtual component or virtual space corresponding to the matrix unit in the form of text, such as adding the text "Construction task a: 50% completed" to the three-dimensional virtual component corresponding to a certain unit.

[0327] In some embodiments, the mapping rules may further include quality mapping rules. For example, quality mapping rules may include mapping quality ratings such as "Excellent," "Good," and "Pass" to different color saturations such as high, medium, and low. In some embodiments, if the matrix unit has been completed, the processor may also adjust the color saturation of its color according to its final quality rating and quality mapping rules. For example, a high-saturation green is used for a quality rating of "Excellent," and a low-saturation green is used for a rating of "Pass," to visually represent the quality difference.

[0328] In some embodiments, the mapping rules also include anomaly mapping rules. For example, anomaly mapping rules may include mapping abnormal states such as project delays or cost overruns to special display effects such as highlighting or semi-transparency. In some embodiments, if the anomaly detection of a matrix unit fails, such as project delays or cost overruns, the processor may attach special display effects to it, such as highlighting or semi-transparency, to provide a prominent warning in the visualized 3D view.

[0329] In some embodiments, the processor obtains the location information of the construction area corresponding to the matrix unit and uses the location information to retrieve and locate the three-dimensional virtual component or virtual space corresponding to the matrix unit in the virtual building model, applies the aforementioned graphic attributes to these located three-dimensional virtual components, and renders the entire virtual building model to generate a user-interactive (e.g., rotate, scale, pan, roam) visual three-dimensional view.

[0330] In some embodiments, the virtual building model can also respond to user clicks. For example, when a user clicks on a rendered virtual component (such as a wall rendered in yellow) in the virtual building model, the processor can query and display detailed information of the matrix cells associated with that component. This detailed information may include: the name of the current construction task (such as "masonry filling"), the contracting party (such as "XX team"), the planned completion time, and the current percentage of progress.

[0331] For more information on quality rating and anomaly detection, please refer to Figure 13 and its related description.

[0332] In some embodiments of this specification, presenting "visual progress" in the form of color-coded two-dimensional tables significantly improves the intuitiveness of progress monitoring and the speed of decision-making. Managers can quickly identify the current construction status of a construction area (such as whether there are any construction tasks lagging behind), thereby rapidly locating problems. By constructing structured "matrix units," a clear data query framework is provided; managers can easily query the completion status of all construction tasks in each construction area, or query the completion status of a specific construction task across all areas. Furthermore, this method precisely locates construction tasks to specific spatial areas, laying the foundation for more refined management that aligns with actual site conditions. This allows the system to combine factors such as spatial location relationships and resource allocation distances in subsequent decisions to arrange a better construction sequence. This effectively solves the problems of unintuitive progress monitoring and low task assignment efficiency in traditional management.

[0333] In some embodiments of this specification, a two-dimensional table view presented with construction areas and progress nodes as axes is constructed, and color coding is used to greatly improve the intuitiveness and efficiency of progress monitoring. This vividly displays construction supervision, thereby improving the efficiency of task assignment and enabling managers to quickly locate progress deviations. The priority of the first task to be assigned is determined by using difference sets and weight coefficients of matrix units, achieving automation and intelligence in task assignment and reducing the complexity and error rate of manual management. By binding progress nodes (multiple construction tasks with a construction sequence) and construction areas to form structured matrix units, a solid data foundation is provided for refined management and data-driven decision-making in construction projects.

[0334] Figure 12 is an exemplary flowchart illustrating the determination of the priority of a first task to be dispatched, according to some embodiments of this specification.

[0335] As shown in Figure 12, process 1200 includes steps 1210-1230. In some embodiments, process 1200 may be executed by a processor.

[0336] Step 1210: Based on the basic logic between multiple progress nodes, determine the first weight coefficient of each matrix unit.

[0337] The fundamental logic refers to the logical relationships within the construction process determined by construction techniques, technical standards, and safety management requirements. In some embodiments, the fundamental logic includes inherent, immutable pre- and post-construction relationships and logical sequences between different progress milestones. For example, the fundamental logic may include the requirement that the "main structure" progress milestone can only begin after the "foundation and substructure" progress milestone is completed.

[0338] The processor can acquire the basic logic in various ways. In some embodiments, the processor can acquire it from preset dependency data contained in a progress node template library. This preset dependency data can be pre-set by those skilled in the art based on construction techniques, technical standards, and safety management requirements.

[0339] For more information about the progress node template library, please refer to the relevant description in Figure 10.

[0340] In some embodiments, the preset dependency data can be stored in the progress node template library in the form of a rule list or a data table. For example, the rule list or data table includes Rule 1, Rule 2, etc. Rule 1: Defines the prerequisites for "Main Structure Engineering" (Progress Node PN-02). This rule stipulates that the start of "Main Structure Engineering" must be premised on the complete completion of "Foundation and Substructure Engineering" (Progress Node PN-01). This is a Finish-to-Start dependency. Rule 2: Defines the prerequisites for "Roofing and Waterproofing Engineering" (Progress Node PN-03). This rule stipulates that the start of "Roofing and Waterproofing Engineering" must be premised on the complete completion of "Main Structure Engineering" (Progress Node PN-02), etc.

[0341] The first weight coefficient refers to a static weight value that reflects the importance of a matrix unit. In some embodiments, the value of the first weight coefficient depends on the position of the schedule node corresponding to the matrix unit within the overall project's basic logic. In some embodiments, the processor can identify schedule nodes located on the project's critical path through critical path analysis and assign a higher first weight coefficient to all matrix units corresponding to these schedule nodes. In some embodiments, the processor can also assign a higher first weight coefficient to matrix units corresponding to critical hub nodes with a large number of subsequent dependent tasks. Conversely, nodes on non-critical paths with fewer dependencies are assigned a lower first weight coefficient.

[0342] Critical path analysis refers to determining whether a schedule node is located on the critical path. For more information on how to determine whether a schedule node is on the critical path, please refer to Figure 10 and its related description.

[0343] In some embodiments, the processor can count the number of subsequent dependent tasks for each progress node that serves as a predecessor node. When the processor detects that the number of subsequent dependent tasks for a progress node exceeds a certain threshold, it identifies it as a "critical hub node with a large number of subsequent dependent tasks." For example, when parsing basic logic, the processor can identify that the completion of the progress node "Main Structure Engineering" is a common prerequisite for the start of multiple subsequent progress nodes such as "Masonry Infill Wall Engineering," "Exterior Wall Door and Window Installation Engineering," and "Indoor Mechanical and Electrical Pipeline Laying Engineering" (i.e., the construction tasks corresponding to multiple subsequent progress nodes such as "Masonry Infill Wall Engineering," "Exterior Wall Door and Window Installation Engineering," and "Indoor Mechanical and Electrical Pipeline Laying Engineering" are subsequent dependent tasks of the progress node "Main Structure Engineering"). If the number of subsequent dependent tasks for a progress node such as "Main Structure Engineering" reaches a certain threshold (e.g., greater than or equal to 5), the processor identifies "Main Structure Engineering" as a critical hub node. In response to this determination, the processor also assigns a higher first weight coefficient to all matrix units corresponding to the progress nodes of the "main structure project" to ensure the priority completion of the bottleneck node, thereby creating conditions for the parallel development of multiple subsequent construction tasks.

[0344] Step 1220: Determine the second weighting coefficient for each matrix unit based on the schedule pressure of each matrix unit.

[0345] Schedule pressure refers to the quantifiable degree of time urgency and resource constraints faced in completing specific schedule milestones within a particular construction area. In some embodiments, schedule pressure is dynamic, reflecting the deviation between the actual execution of a construction project and the planned progress. In some embodiments, schedule pressure can be obtained by comparing the planned completion time with the current elapsed time, and the difference between the planned workload and the actual workload completed within the currently elapsed time, within a matrix cell. For example, the smaller the value of [planned completion time - current elapsed time] and the smaller the ratio of actual completed workload to planned workload, the greater the schedule pressure.

[0346] In some embodiments, the processor can consult a first preset table to obtain schedule pressure based on the value of [planned completion time - current elapsed time] (actual deviation) and the ratio of actual completed workload to planned workload (workload deviation). The first preset table can be a two-dimensional lookup table that defines the schedule pressure levels corresponding to different combinations of time and workload deviations. In some embodiments, the first preset table can be defined by experts with extensive project management experience, according to industry practices and management requirements, defining pressure scores for different combinations of deviations to complete the construction.

[0347] In some embodiments, the processor can also normalize the acquired schedule pressure, transforming it into a standardized schedule pressure between 0 and 1. The processor can employ methods such as linear function normalization (Min-Max Scaling) or z-score normalization.

[0348] The second weighting factor is a weight value used to reflect the dynamic urgency of a matrix unit. For example, a matrix unit that has been delayed, or whose remaining time is very tight, will be assigned a higher second weighting factor to encourage its tasks to be prioritized.

[0349] In some embodiments, the processor can obtain the second weight coefficient of each matrix unit based on the positive correlation between the schedule pressure of each matrix unit and the second weight coefficient of each matrix unit. For example, the processor can directly use the normalized schedule pressure as the second weight coefficient.

[0350] In some embodiments, the processor may also determine a second weighting coefficient based on the readiness of the resources required by the matrix unit. For example, the processor may query a resource management database to determine whether critical resources such as personnel, equipment, or materials required to execute the matrix unit are in place and ready for deployment. To avoid resource idleness and improve utilization efficiency, in response to detecting that resources are ready, the processor may accordingly increase the second weighting coefficient of the matrix unit to encourage its priority allocation.

[0351] The resource management database refers to a database used to centrally record and track in real time the status of all production elements (including personnel, equipment, and materials) required for a construction project. For example, the resource management database may include a list of all construction teams and their members, each member's skills and qualifications, currently assigned tasks, and future available work schedules. Another example is a list of all large machinery and equipment, their model specifications, real-time locations obtained via GPS or RFID, current operating status (e.g., "operating," "idle," or "under maintenance"), and future planned usage. Yet another example is a database that may include the inventory quantities of various key construction materials, warehouse locations, and the status of purchase orders (e.g., "ordered," "in transit," or "delivered and stored"). In some embodiments, the information in the resource management database can be manually entered by administrators or automatically synchronized and updated through data interfaces with other information systems such as IoT devices and procurement management systems.

[0352] In some embodiments, the processor may determine a second weighting coefficient based on a first progress pressure of the construction area corresponding to each matrix unit and a second progress pressure of the progress node corresponding to each matrix unit.

[0353] The first schedule pressure refers to the overall schedule urgency faced by a specific construction area. In some embodiments, the first schedule pressure is related to the deviation between the execution status of all schedule nodes in the construction area and the plan. In some embodiments, the processor can calculate the ratio of the number of all schedule nodes in a "delayed" state in a construction area to the total number of schedule nodes; the higher the ratio, the greater the first schedule pressure. Alternatively, it can compare the planned completion rate and the actual completion rate of all schedule nodes in a construction area; the greater the difference, the greater the first schedule pressure.

[0354] The planned completion rate of all schedule nodes within a construction area refers to the proportion of schedule nodes that should have been completed according to the project plan within a specific construction area as of the current time, out of the total number of schedule nodes planned to be executed in that area. The actual completion rate of all schedule nodes within a construction area refers to the proportion of schedule nodes that have actually been completed (e.g., status "accepted") within a specific construction area as of the current time, out of the total number of schedule nodes planned to be executed in that area. For example, a construction area is "Building 1, 3rd Floor," with a total of 10 schedule nodes planned. As of the current date, the project plan requires 6 of these schedule nodes to be completed, so the planned completion rate for this construction area is (6 / 10) = 60%. If, at this point, only 4 schedule nodes have actually been completed on-site, then the actual completion rate for this construction area is (4 / 10) = 40%. The processor compares the two and finds a significant difference (60% vs. 40%), therefore determining that the initial schedule pressure for this construction area is higher.

[0355] The second schedule pressure refers to the overall schedule urgency faced by a specific schedule node. In some embodiments, the second schedule pressure is related to the deviation between the execution of the schedule node and the plan across all construction areas. In some embodiments, the processor calculates the deviation between the planned completion rate and the actual completion rate of the schedule node corresponding to the matrix unit across all construction areas; the greater the deviation, the greater the second schedule pressure. Alternatively, it determines whether the schedule node is currently on the critical path of the construction project; if so, the corresponding second schedule pressure increases accordingly.

[0356] The planned completion rate of a schedule node corresponding to a matrix unit across all construction areas refers to the proportion of the number of construction areas that should have been completed according to the project plan, up to the current point in time, out of the total number of applicable construction areas for that specific schedule node. The actual completion rate of a schedule node corresponding to a matrix unit across all construction areas refers to the proportion of the number of construction areas that have actually been completed, up to the current point in time, out of the total number of applicable construction areas for that specific schedule node. For example, a schedule node is "interior plastering," which is planned to be implemented in 20 construction areas (e.g., 20 interior spaces). As of the current date, the project plan requires that this node be completed in 15 of these areas, so the planned completion rate of this schedule node is (15 / 20) = 75%. If, at this point, on-site feedback indicates that this node has actually been completed in only 10 areas, then the actual completion rate of this schedule node is (10 / 20) = 50%. The processor compares the two and finds a significant difference (75% vs. 50%), therefore determining that the "interior plastering" schedule node faces high secondary schedule pressure.

[0357] In some embodiments, the processor can determine the second weighting coefficient based on the positive correlation between the second weighting coefficient and the first and second schedule pressures, and based on the first and second schedule pressures. For example, the processor can perform normalization processing on the first schedule pressure of the construction area corresponding to the matrix unit and the second schedule pressure of the schedule node corresponding to the matrix unit (as described above for normalizing schedule pressures), and then perform a weighted sum of the two normalized values ​​to obtain the second weighting coefficient.

[0358] In some embodiments of this specification, the schedule pressure is further decomposed into a first schedule pressure based on the construction area and a second schedule pressure based on the schedule node. This allows the processor to go beyond a general conclusion of "delay" and instead distinguish the specific dimensions of the problem: if the first schedule pressure is generally high in a certain construction area, it may mean that there are regional or physical bottlenecks such as poor traffic flow or untimely material supply in that area; conversely, if the second schedule pressure is generally high in a certain schedule node, it may mean that the work team responsible for that process has procedural or managerial problems such as insufficient skills or personnel shortages. This refined pressure analysis enables managers to make more targeted decisions, thereby accurately allocating limited resources (such as management effort and additional manpower) to the most critical bottlenecks, achieving more efficient and fundamental dynamic adjustments, and thus effectively ensuring the overall project schedule.

[0359] Step 1230: Based on the combined result of the first weighting coefficient and the second weighting coefficient, determine the priority of the first task to be dispatched.

[0360] The comprehensive result refers to the result of a comprehensive calculation of the first weighting coefficient and the second weighting coefficient.

[0361] In some embodiments, the process of obtaining the comprehensive result may involve a weighted calculation of the first weighting coefficient and the second weighting coefficient. For example, the processor may perform the following calculation: Matrix unit comprehensive priority score = (first weighting coefficient × weight γ) + (second weighting coefficient × weight δ). Wherein, γ and δ are pre-set harmonic parameters used to balance the weight of "inherent basic logical importance" (represented by the first weighting coefficient) and "dynamic on-site urgency" (represented by the second weighting coefficient) in the final decision.

[0362] In some embodiments, γ and δ can be preset by human experience or historical experience.

[0363] In some embodiments, the processor can calculate a comprehensive priority score for each matrix unit containing a first task to be dispatched, based on the aforementioned method; and sort all these matrix units in descending order of the comprehensive priority scores. Understandably, this sorting result determines the task dispatch priority order among different matrix units. For a matrix unit with a higher comprehensive priority score, its first task to be dispatched will receive a higher priority. Furthermore, for multiple first tasks to be dispatched within the same matrix unit, their execution order follows the aforementioned inherent construction sequence predefined in the schedule nodes. For more information on the construction sequence, see Figure 10 and its related description.

[0364] In some embodiments of this specification, the priority of the first task to be assigned is determined by combining a static first weighting coefficient with a dynamic second weighting coefficient. This allows task assignment decisions to closely align with the project's macro-strategic objectives (ensuring priority for critical paths and key hubs through the first weighting coefficient) while also flexibly responding to micro-changes and unforeseen circumstances at the construction site (addressing current schedule bottlenecks through the second weighting coefficient). This dynamic and static decision-making mechanism ensures that project resources are always allocated to where they are most needed, effectively reducing resource idleness and ineffective waiting time caused by poor workflow coordination. This, in turn, ensures project quality while reducing construction costs and shortening the overall project duration, maximizing the overall project execution benefits.

[0365] Figure 13 is an exemplary schematic diagram illustrating the generation of a construction task sheet corresponding to each matrix unit according to some embodiments of this specification.

[0366] In some embodiments, as shown in Figure 13, the processor can extract standardized content 1330 from the knowledge base 1320 based on the selected construction task 1310, and generate a construction task sheet 1340 corresponding to each matrix unit. The construction task sheet 1340 includes the construction area 1341, construction task procedure 1342, work briefing 1343, safety briefing 1344, and acceptance criteria 1345 corresponding to each matrix unit. The construction task sheet 1340 is the second project document in process 400.

[0367] For more information on matrix units, construction areas, etc., please refer to Figure 10 and its related description.

[0368] Knowledge Base 1320 refers to a structured database used to store standardized construction management and technical knowledge. In Knowledge Base 1320, content is organized and stored using individual construction tasks as indexes. For example, for different construction tasks such as "concrete pouring" and "wall plastering," corresponding complete sets of technical specifications, management requirements, and historical data are pre-stored. In some embodiments, Knowledge Base 1320 also stores: standard operation briefings, which describe in detail the operation process, technical points, and quality requirements of the construction task in text, images, or videos; standard safety briefings, which clearly point out the safety risks of the construction task, the safety procedures that must be followed, and emergency response measures; standard acceptance standards, which specify the specific specification clauses, allowable deviation values, and standardized inspection forms used for quality inspection after the completion of the construction task; and historical performance data, including historical data accumulated from past projects regarding the average duration, workload, resource consumption, and typical resource consumption models for this type of task. Therefore, when the processor needs to generate a construction task order for "wall plastering", it can directly and accurately extract the standard operation instructions, safety instructions and acceptance standards specifically for "wall plastering" from the knowledge base 1320.

[0369] In some embodiments, the knowledge base 1320 may be built based on human experience or historical experience. In some embodiments, the knowledge base 1320 may also be built based on industry standard processes for building construction, etc.

[0370] Standardized content 1330 refers to predefined information extracted from knowledge base 1320 and used to populate construction task sheets 1340. Standardized content can be understood as the general document directory in Figure 4. In some embodiments, standardized content 1330 aims to ensure that the technical, safety, and quality requirements of construction tasks assigned to different work teams and used in different construction areas but belonging to the same type remain consistent. In some embodiments, standardized content 1330 may include standard work instructions, safety instructions, and acceptance standards, etc.

[0371] In some embodiments, the selected construction task is a type of construction task with a corresponding unique identifier (such as a unique name or unique code). The processor can query, retrieve and extract the standardized content 1330 of the corresponding construction task from the knowledge base 1320 based on the unique identifier (such as a unique name or unique code) of the selected construction task 1310.

[0372] A work order (1340) is a work instruction issued to the specific entity performing the construction task (such as a construction team), containing all the information necessary to perform the task. A work order (340) serves as the basis for guiding on-site construction, clarifying responsibilities, and ensuring safety and quality. For example, a work order might be "Perform 'wall plastering' task for 'Unit 301, Building 1'," and its contents would detail the work instructions, safety precautions, and quality acceptance standards for the task.

[0373] Construction task procedure 342 refers to the name of the construction task explicitly recorded in the construction task sheet 1340 and its position in the predefined construction sequence. For more information on the construction sequence, please refer to Figure 10 and its related description. In some embodiments, when the processor generates a construction task sheet for a certain matrix cell, it can directly obtain the list of selected construction tasks arranged in a predefined construction sequence within that matrix cell to generate construction task procedure 1342.

[0374] Work instructions (1343) refer to the technical specifications, operating procedures, key points, and quality requirements for a construction task, which are explained to operators to ensure construction quality. For example, for a "concrete pouring" construction task, the work instructions may include the pouring sequence, vibration method, and curing requirements. In some embodiments, work instructions (1343) may include text, images, or videos.

[0375] Safety briefing 1344 refers to the safety protection measures, safe operating procedures, risk warnings, and emergency response methods that must be instructed to operators regarding the safety risks present in a specific construction task or process.

[0376] Acceptance standard 1345 refers to the standard used for quality inspection after the completion of a construction task. In some embodiments, acceptance standard 1345 may include specific specifications, permissible deviation values, inspection methods, clauses, specification numbers, and inspection forms, etc.

[0377] In some embodiments, the processor can create a blank construction task sheet 1340 template for the selected construction task 1310; the processor fills the template with the determined information such as the construction area 341 and construction task procedure 1342 corresponding to the selected construction task 1310. The processor can use the unique identifier of the selected construction task 1310 as an index to retrieve and extract matching standardized content 1330 from the knowledge base 1320. The extracted standardized content 1330 may include the work instructions 1343, safety instructions 1344, and acceptance criteria 1345 corresponding to the construction task. The processor can fill the extracted standardized content 1330 into the corresponding fields or positions of the construction task sheet 1340 template, thereby generating the construction task sheet 1340.

[0378] In some embodiments of this specification, based on selected construction tasks, standardized content is extracted from a knowledge base to generate a construction task sheet corresponding to each matrix unit. This greatly improves the efficiency of task assignment and reduces the manual workload of management personnel and the probability of errors due to manual entry. Simultaneously, by using standardized operation, safety, and acceptance procedures, the uniformity and consistency of project management requirements are ensured, providing a solid foundation for guaranteeing construction quality and safe production.

[0379] In some embodiments, as shown in FIG13, the construction task order 340 further includes a first planned construction period 1346, resource requirements 1347, and a performance object 1348. The processor can predict the first planned construction period 1346 and resource requirements 1347 based on historical construction data 1350 using a prediction algorithm; and determine the performance object 1348 based on the first planned construction period 1346 and resource requirements 1347 using a capacity database 1360.

[0380] Historical construction data 1350 refers to the actual construction data recorded in completed construction tasks of past or current construction projects. In some embodiments, each piece of historical construction data corresponds to a completed construction task and includes information such as the actual completion time, actual resource consumption, final contract fulfillment object, and working environment parameters during the execution of the construction task. The actual completion time refers to the working time spent completing the construction task. The actual resource consumption refers to the quantitative data of various production factors actually consumed to complete the construction task. For example, actual resource consumption may include actual labor consumption (e.g., recorded as "20 man-hours for senior technicians, 35 man-hours for general workers"), actual material consumption (e.g., "5 tons of XX type cement"), and actual machinery shift consumption (e.g., "8 shifts for tower cranes").

[0381] In some embodiments, the processor can obtain historical construction data 1350 by statistically analyzing archived construction task orders and acceptance records in the system storage device 300.

[0382] Prediction algorithms refer to calculation methods that learn from and analyze historical construction data to estimate the planned duration and resource requirements of future tasks to be assigned.

[0383] The first planned duration of 346 refers to the estimated working time required to complete a single selected construction task. For example, the first planned duration of a construction task can be "3 working days" or "24 standard working hours".

[0384] Resource requirement 1347 refers to the various production factors required to complete a single selected construction task. In some embodiments, resource requirement 1347 may include: the professional qualification requirements of construction teams, work crews or subcontractors, labor requirements (e.g., 2 senior electricians and 3 general laborers are required), material requirements (e.g., 500 meters of cable of a certain specification are required), and machinery and equipment requirements (e.g., a 16-ton truck crane is required to work for 8 hours), etc.

[0385] In some embodiments, the processor can execute a prediction algorithm based on historical construction data to obtain a first planned construction period 1346 and resource requirements 1347. In some embodiments, the prediction algorithm can be a weighted average method, one or more machine learning models, etc. For example, the processor can pre-train a regression model (such as linear regression, decision tree regression, or gradient boosting machine model) using a large amount of historical construction data, historical planned construction periods, and historical resource requirements. During the prediction phase, the processor inputs historical construction data (multiple attribute data, such as construction task type, workload, construction area, etc.) of the selected construction task 1310 as features into the pre-trained model, and the model outputs predicted values ​​for the first planned construction period 1346 and resource requirements 1347. In some embodiments, the processor can locate the progress node corresponding to the selected construction task 310, thereby reading its corresponding construction area; determine the construction task type according to the task name of the selected construction task; and retrieve its corresponding workload from the knowledge base 1320.

[0386] In some embodiments, the preset algorithm (e.g., weighted average method or machine learning regression model) further includes calculating and outputting the predicted data of the first planned construction period 1346 and resource requirements 1347 corresponding to the selected construction task based on the actual completion time and actual resource consumption of the above-mentioned similar task records.

[0387] Capability database 1360 refers to a database that stores detailed capability and performance profiles of all available contract fulfillment entities. In some embodiments, the content stored in capability database 1360 includes at least one of the following: professional qualifications, skill levels, historical production capacity, current workload, and historical performance data (such as schedule completion rate, quality pass rate, safety records, etc.) for each construction team, work group, or subcontractor. In some embodiments, the relevant data in capability database 1360 can be manually entered and reviewed by project management personnel through a user terminal.

[0388] The contractual object 1348 refers to the specific entity responsible for carrying out the selected construction tasks. For example, a contractual object could be a construction team, a work group, or a subcontractor.

[0389] In some embodiments, the processor uses the first planned duration 346 and resource requirements 1347 as matching conditions to query and filter candidate performance objects in the capacity database 1360 that simultaneously meet the following conditions: possessing the professional qualifications required to perform the selected construction task, and having sufficient available manpower and time to meet the first planned duration and resource requirements. For example, the processor compares the first planned duration 1346 with the available capacity of candidate performance objects in the capacity database 1360 to determine whether the performance object is capable of completing the task within the given planned duration. Specifically, if the planned duration of a task is 3 days and the total workload required is 15 person-days, and the available capacity of a work team is calculated to be 6 person-days per day, then it can provide 18 person-days of capacity (6*3=18) within 3 days, which is greater than the required 15 person-days, and therefore is considered a successful match. Conversely, if its available capacity is insufficient, it is removed from the candidate list.

[0390] In some embodiments, if there are multiple candidate fulfillment objects, the processor can also sort them according to the historical performance of the multiple candidate fulfillment objects to determine and select the optimal fulfillment object 1348 (such as the candidate fulfillment object with the highest historical performance).

[0391] In some embodiments of this specification, the accuracy and scientific rigor of task assignment are significantly improved by introducing prediction mechanisms based on historical construction data and matching mechanisms based on a capacity database. Data-driven prediction replaces traditional manual estimation, reducing the risk of delays and resource waste due to insufficient experience. Secondly, intelligent matching of selected construction tasks with contract fulfillment entities ensures that suitable tasks are assigned to the most capable, high-performing, and available work teams, thereby guaranteeing construction quality and efficiency from the outset and optimizing the overall human resource allocation of the project.

[0392] In some embodiments, the processor may determine the construction task order for the first task to be dispatched in a manner similar to that described above.

[0393] In some embodiments, as shown in FIG13, the processor can perform anomaly detection on the execution status based on the construction task sheet 1340, including schedule detection and resource consumption detection; and issue an early warning for each progress node in response to the failure of anomaly detection.

[0394] For more information on the execution status, see Figure 11 and its related description.

[0395] Anomaly detection refers to the process of continuously comparing the actual execution data with the pre-set planned data in the construction task sheet 1340 during the actual execution of the construction task to identify whether there are significant deviations. In some embodiments, the actual execution data may include the actual time elapsed and the actual amount of resources consumed. In some embodiments, the planned data corresponds to the first planned duration 346 and resource requirements 1347 in the construction task sheet 1340.

[0396] In some embodiments, when the deviation between the actual execution data and the preset planned data in the construction task sheet 1340 exceeds a deviation threshold, the anomaly detection of the construction task's execution status is deemed to have failed. The deviation threshold refers to one or more pre-set critical values ​​used to define normal fluctuations and abnormal deviations. In some embodiments, the deviation threshold may include an actual overdue threshold and a resource overdue threshold, and the deviation threshold may be determined based on manual experience or historical experience.

[0397] Schedule detection refers to the process of comparing the actual time elapsed for a construction task with its first planned schedule 1346. In some embodiments, the processor can obtain the actual start time of the task and continuously monitor the current time to calculate the actual elapsed time. This actual elapsed time is then compared with the first planned schedule 1346 in the construction task order 1340. If the actual elapsed time exceeds the first planned schedule (or its proportionally calculated portion) and the deviation reaches a preset time overdue threshold, the schedule detection is deemed unsuccessful. The proportionally calculated portion refers to the processor comparing the actual elapsed time with the proportionally calculated planned schedule. For example, if the current actual elapsed time is 5 days, and the progress of construction task X is 50%, but the first planned schedule is 6 days, then only 3 days (the planned time) are needed to complete 50% of the progress of construction task X. In this case, the processor compares this "actual elapsed time" (5 days) with the calculated "planned time" (3 days). When the "actual time elapsed" exceeds the "planned time elapsed", and the deviation (5-3=2 days) reaches the preset time overdue threshold, the project schedule test is deemed unsuccessful and an early warning is triggered.

[0398] Resource consumption detection refers to the process of comparing the actual resource consumption of a construction task with its resource requirements 1347. In some embodiments, the processor can obtain the actual quantities of labor (e.g., man-hours), materials (e.g., usage), or machinery (e.g., machine-hours) consumed by the construction task from the data acquisition terminal at the construction site, and compare them cumulatively with the planned resource consumption quantities set for each type of resource in the construction task order 1340. When the actual consumption of any type of resource exceeds its planned requirement and the deviation reaches a preset resource overrun threshold, the resource consumption detection is deemed to have failed. The planned resource consumption quantities set for each type of resource can be manually set, or the average of the completed resource consumption quantities of each type of resource used to complete this type of construction task in the past (which can be obtained from the knowledge base 1320) can be used.

[0399] In some embodiments, in response to an anomaly detection failure, the processor performs an early warning operation. In some embodiments, the early warning operation may include: locating the matrix cell corresponding to the construction task that failed the anomaly detection and its corresponding progress node; and the processor issuing a warning signal to the manager overseeing the construction task. The warning signal may take various forms, such as specially marking the corresponding matrix cell in the visualization view (e.g., changing it from yellow to red, or adding a highlighting flashing effect), or directly pushing a notification message containing anomaly details to the project manager's user terminal.

[0400] In the embodiments described in this specification, a schedule early warning system enables timely detection and intervention of delayed tasks. It automatically alerts management personnel the moment a substantial delay occurs and exceeds the management tolerance threshold (i.e., the deviation threshold), avoiding the problem of delayed information being passed down through multiple layers and ensuring that management can quickly intervene, analyze the causes of the delay, and take remedial measures. This prevents delayed construction tasks from causing a chain reaction on subsequent schedule milestones and even the overall project schedule. Furthermore, a resource consumption early warning system enables dynamic monitoring and adjustment of cost overruns. An immediate warning is issued once consumption exceeds a preset threshold. This helps to promptly identify problems such as material waste, low labor efficiency, or inaccurate initial estimates, enabling management to immediately investigate and make dynamic adjustments.

[0401] In some embodiments, in response to the completion of the selected construction task 1310, the processor may perform a quality rating on the selected construction task 1310 based on acceptance criteria 1345; and in response to the quality rating meeting a second preset condition, update the status information and update the color code of each matrix unit. The status information may include sub-items in a second project document.

[0402] Quality rating refers to the quantitative or qualitative evaluation result given by quality inspectors after verifying and measuring the completed construction tasks in accordance with acceptance standard 1345. In some embodiments, quality rating can be divided into multiple levels, such as "Excellent", "Good", "Pass", "Fail", etc.

[0403] For example, if the completed construction task is "wall plastering," the acceptance standard 1345 in the construction task sheet 1340 specifies the following three key indicators: using a 2-meter straightedge, the maximum gap at any position should not exceed 4 mm (surface flatness indicator); using a 2-meter plumb line, the deviation at any position should not exceed 5 mm (verticality indicator); and the surface should be free of cracks, hollow areas, loose sand, and have a uniform color (quality indicator). When quality inspectors conduct their inspection, if all three key indicators are met, and the measured values ​​of key indicators (such as flatness and verticality) are better than the standard values ​​by 50%, the rating is "Excellent." If all three key indicators are met, but the conditions for "Excellent" are not met, the rating is "Good." If all three key indicators are met, the rating is "Pass." If any one key indicator is not met, the rating is "Fail."

[0404] In some embodiments, quality inspectors can enter the on-site inspection results into system 300.

[0405] The second preset condition refers to the minimum quality rating threshold that allows the construction task to be finally confirmed as "completed," thereby triggering a matrix unit status update. In some embodiments, this second preset condition can be set to "quality rating of 'qualified' or above." In some embodiments, the second preset condition can be preset by project managers according to the project's quality management requirements.

[0406] In some embodiments, in response to a construction task's quality rating meeting a second preset condition, the processor can update the construction task's status to "acceptance qualified" and then recalculate the status information and color code of its corresponding matrix cell. For example, if the currently completed construction task is not the last construction task corresponding to the matrix cell, the processor can update the matrix cell's status information (e.g., update the status information from 50% to 60%). As another example, if the currently completed construction task is the last construction task of the matrix cell, the processor can update the matrix cell's color code (e.g., update the yellow representing "in progress" to green representing "completed").

[0407] In some embodiments, color coding updates can also be associated with quality ratings; for example, a higher quality rating corresponds to a higher color saturation in the matrix cell. Conversely, if the quality rating does not meet a second preset condition (e.g., a rating of "unsatisfactory"), the processor does not update the state information of that matrix cell.

[0408] In some embodiments, when the quality rating of a completed construction task is "unqualified", the processor will not update the status information and color code of the matrix unit. Instead, the processor will generate a rectification notice and send it to the party performing the construction task to require rectification.

[0409] For more information on selected construction tasks, the first task to be dispatched, matrix units, construction areas, and execution status, please refer to Figure 10 and its related descriptions.

[0410] In some embodiments of this specification, the reliability and accuracy of project progress milestone data are ensured by introducing a quality rating-based update mechanism. This method makes quality acceptance a necessary prerequisite for progress updates, avoiding situations where task completion is confirmed solely based on the contractor's declaration. It ensures that construction tasks displayed as "completed" in the visualization view correspond to actual engineering quality that meets standards. This allows managers to make decisions based on more reliable data.

[0411] Figure 14 is an exemplary flowchart illustrating the reassignment of a second task to be dispatched, according to some embodiments of this specification.

[0412] As shown in Figure 14, process 1400 includes steps 1410-1430. In some embodiments, process 1400 may be executed by a processor.

[0413] Step 1410: In response to detecting that the execution state of the first matrix unit is delayed, at least one second matrix unit affected by the first matrix unit is determined based on the node dependency network.

[0414] In some embodiments, the plurality of matrix units includes a first matrix unit. The first matrix unit refers to the first matrix unit whose execution status is detected as "delayed" when monitoring all executing matrix units. For example, if the matrix unit "Main Structure of the 2nd Floor of Building 1" is the first unit in system 300 to be determined as having an execution progress behind schedule, then it is identified as the first matrix unit.

[0415] An execution status of "delayed" means that the actual execution progress of a matrix unit lags behind its planned progress and exceeds a preset delay threshold. In some embodiments, whether the execution status is delayed can be determined by the aforementioned anomaly detection (see Figure 13). For example, when the schedule check of a selected construction task fails, the execution status of its matrix unit can be updated to "delayed".

[0416] A node dependency network is a data structure used to represent the underlying logic (i.e., predecessor and successor dependencies) between multiple progress nodes. For example, a node dependency network can be a directed acyclic graph. In some embodiments, each progress node in the node dependency network is a graph node, and the dependencies between nodes are directed edges. The processor can construct the node dependency network based on preset dependency data obtained from a progress node template library.

[0417] For example, the preset dependency data stipulates that the start of "Main Structure Engineering" (Schedule Node PN-02) must be premised on the completion of "Foundation and Substructure Engineering" (Schedule Node PN-01), meaning that the predecessor node ID of PN-02 is PN-01. The processor then creates a directed edge from PN-01 to PN-02 between the graph node representing PN-01 and the graph node representing PN-02. This edge indicates that "PN-01 is a prerequisite task for PN-02".

[0418] For more information on the basic logic and pre-defined dependency data, please refer to Figure 12 and its related description.

[0419] The second matrix unit refers to a progress node whose corresponding progress node in the node dependency network is a direct or indirect successor node to the progress node corresponding to the first matrix unit. In one embodiment, the processor performs graph traversal (e.g., breadth-first or depth-first search) in the node dependency network, starting from the graph node corresponding to the first matrix unit. All matrix units corresponding to reachable subsequent graph nodes are identified as the affected second matrix units.

[0420] Step 1420: Based on the degree of delay of the first matrix unit, redetermine the priority of the second planned duration and / or the second task to be dispatched for at least one second matrix unit.

[0421] The delay level of the first matrix unit refers to a parameter used to quantify the magnitude of the delay impact of the first matrix unit. In one embodiment, the delay level of the first matrix unit can be a specific time length, such as "5 working days". In some embodiments, the delay level of the first matrix unit can be the sum of the delay times of all construction tasks currently completed in the matrix unit. For example, if the first matrix unit has completed construction task 1 and construction task 2, where the delay time of construction task 1 is 2 days and the delay time of construction task 2 is 3 days, then the delay level of the first matrix unit is 5 days.

[0422] The second planned duration refers to the newly determined planned duration for the selected construction task or the first task to be assigned within the second matrix unit. The second task to be assigned refers to the selected construction task or the first task to be assigned within the second matrix unit. In some embodiments, the processor redetermines the second planned duration of the second matrix unit based on the delay level of the first matrix unit, including: obtaining the original planned duration (including start and finish times) of at least one selected construction task or the first task to be assigned within the second matrix unit; and adjusting the original planned duration of the selected construction task or the first task to be assigned within the at least one second matrix unit by using the delay level of the first matrix unit (e.g., "5 working days") as a continuation amount.

[0423] In one embodiment, the processor can adjust the planned duration of the second matrix unit to generate a second planned duration. For example, the original planned start date can be postponed according to the delay level of the first matrix unit (e.g., 5 working days) to generate a second planned duration for the second matrix unit.

[0424] In some embodiments, in response to detecting that the execution status of the first matrix unit is delayed, the processor can recalculate the weight coefficient (or the first weight coefficient and the second weight coefficient) of the second matrix unit and the priority of the second task to be dispatched within it. For example, if the delay of the first matrix unit leads to a change in the project's critical path, causing a second matrix unit to enter a new critical path, the processor will correspondingly increase its first weight coefficient and overall priority.

[0425] For more information on how to determine priorities, weight coefficients, first weight coefficients, and second weight coefficients, please refer to Figures 10 and 12 and their related descriptions.

[0426] Step 1430: Based on the priority of the second planned construction period and / or the second task to be assigned, re-determine and assign the selected construction tasks.

[0427] In some embodiments, the processor may, based on the updated second planned duration and / or priority, re-determine and dispatch the selected construction task for the second task to be dispatched and generate its corresponding construction task order (see Figure 13).

[0428] For more information on how to assign selected construction tasks, please refer to Figure 10 and its related description.

[0429] In some embodiments of this specification, a dynamic and proactive management of project risks is achieved by introducing a delay impact analysis and redistribution mechanism. This method can automatically predict the scope of the impact on subsequent work at the early stages of a delay event and adjust related task plans in advance, transforming passive acceptance of delay consequences into proactive plan rearrangement, thereby effectively controlling the spread of the delay's impact. It also optimizes resource scheduling and utilization. By timely updating the planned duration of subsequent tasks, it avoids idle work and resources caused by subsequent teams entering the site prematurely due to incomplete preceding work, thus improving the overall resource utilization efficiency of the project.

[0430] It should be noted that the above descriptions of processes 400, 500, 800, 1000, 1200, and 1400 are for illustrative purposes only and do not limit the scope of this specification. Those skilled in the art can make various modifications and changes to processes 400, 500, 800, 1000, 1200, and 1400 under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0431] This specification also provides a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the method described in any embodiment of this specification.

[0432] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0433] Furthermore, unless expressly stated in the claims, the order of elements and sequences, the use of numbers and letters, or other names in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on an existing server or mobile device.

[0434] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0435] Finally, it should be understood that the embodiments in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments in this specification are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments in this specification are not limited to those explicitly described and illustrated herein.

Claims

1. A project management system, characterized in that, The system includes at least one processor and a memory, the memory storing computer instructions that, when executed by the at least one processor, cause the system to perform the following operations: Based on the construction area data and progress node data of the target project, a data structure for a construction progress matrix is ​​constructed in the memory. The data structure includes multiple matrix units, and each matrix unit is uniquely associated with a construction area and a progress node. Based on the feature values ​​of the project characteristics of the target project, matching candidate project documents are queried from a pre-built general document directory library to generate and store a first document directory in the memory. The first document directory records document tags of multiple first project documents corresponding to the target project. The document tags include construction area tags, progress node tags, and database tags that identify the storage location. For the target matrix unit in the data structure of the construction progress matrix, the construction area data and progress node data of the target matrix unit are matched and queried with the construction area tags and progress node tags of the multiple first project documents to filter out the second project documents and generate the second document directory corresponding to the target matrix unit. By deploying a listener on the business database corresponding to the second project document, as specified by the database label, the status change events of the second project document are monitored in real time. as well as In response to the detected status change event, the index information corresponding to the second project document in the second document directory is automatically updated.

2. The system as described in claim 1, characterized in that, The general document directory is configured to store reference values ​​for project characteristics and the correspondence between various types of project documents, as well as document tags for each type of project document. The general document directory is constructed in the following manner: Obtain the sample document directory of multiple sample projects and the feature values ​​of the project features of each sample project in the multiple sample projects; Based on the sample document directory, determine the feature value distribution of the project features corresponding to the various types of project documents; Based on the distribution of the feature values, a reference value for the project feature corresponding to each type of project document is determined.

3. The system as described in claim 1, characterized in that, The document tags further include warning rule tags and processing rule tags, and the system further performs the following operations: In response to detecting the generation of the second project document, an early warning rule for the second project document is determined based on the early warning rule tag of the second project document, wherein the early warning rule is configured to constrain the generation time of the associated data of the second project document; Obtain monitoring information related to the associated data, and determine whether the associated data conforms to the early warning rule based on the monitoring information; In response to determining that the associated data does not conform to the warning rule, the corresponding processing operation is performed based on the processing rule label.

4. The system as described in claim 3, characterized in that, The document tags further include associated unit tags, and the associated data includes a third project document among the plurality of first project documents that is associated with the second project document: The acquisition of monitoring information related to the associated data includes: acquiring monitoring information related to the third project document based on the database tags of the third project document; The step of performing the corresponding processing operation based on the processing rule tag includes: sending a notification to the associated unit corresponding to the third project document according to the associated unit tag of the third project document.

5. The system as described in claim 1, characterized in that, The system further performs the following operations: Based on the updated second document directory, determine whether the target progress node corresponding to the target matrix unit meets the progress node update conditions; In response to determining that the target progress node satisfies the progress node update condition, based on the association information related to the data structure of the construction progress matrix, an association matrix unit that is associated with the target matrix unit is determined; Send a construction notification to the target associated unit of the association matrix unit.

6. The system as described in claim 5, characterized in that, The document tags further include associated unit tags and construction task tags, and sending construction notifications to the target associated units of the association matrix unit includes: Based on the construction area tags and progress node tags of the multiple first project documents, determine the fourth project document corresponding to the association matrix unit; Based on the construction task tags of the fourth project document, a target fourth project document is determined, and the construction time corresponding to the target fourth project document meets the first preset condition; Based on the associated unit tags of the target fourth project document, the target associated unit is identified and the construction notice is sent to the target associated unit.

7. The system as described in claim 1, characterized in that, The system further performs the following operations: A progress display table corresponding to the data structure of the construction progress matrix is ​​generated, and the progress display table contains display cells corresponding to the multiple matrix units; Based on the updated second document directory, the progress information of the target matrix unit is determined; Based on the progress information, the display cells corresponding to the target matrix units in the progress display table are labeled.

8. The system as described in claim 1, characterized in that, The system further performs the following operations: In response to detecting that the second project document is stored in the corresponding business database, the digital hash value of the second project document is determined; The smart contract of the blockchain network is invoked to package the digital hash value, the document tag, and the timestamp into a transaction and send it to the blockchain network for notarization. Receive the transaction receipt returned by the blockchain network, and update the transaction hash in the transaction receipt to the second document directory as the anti-tampering index information of the second project document.

9. The system as described in claim 1, characterized in that, The system further performs the following operations: Obtain the text content of the second project document; Based on the text content, at least one semantic feature vector is extracted by a processing model, wherein the processing model is a machine learning model. Based on the at least one semantic feature vector and the progress node data of the target matrix unit, the progress delay probability of the target matrix unit is determined by a progress prediction model, wherein the progress prediction model is a machine learning model. When the probability of schedule delay exceeds a preset threshold, the target matrix unit is marked with a risk warning.

10. The system as claimed in claim 1, characterized in that, The system further performs the following operations: Render the three-dimensional building information model of the target project on a display device; Spatially bind the matrix units in the data structure of the construction progress matrix to the building components in the three-dimensional building information model; In response to the user's selection operation of the target component in the three-dimensional building information model, the matrix unit corresponding to the target component is determined from the data structure of the construction progress matrix, and the second document directory associated with the matrix unit corresponding to the target component is called. A list of documents in the second document directory is displayed in a floating window of the graphical user interface.

11. The system as claimed in claim 1, characterized in that, The system further performs the following operations: For each of the matrix elements: Based on the difference set between the multiple construction tasks and the completed construction tasks of each matrix unit, the first task to be dispatched for each matrix unit is determined. The priority of the first task to be dispatched is determined based on the weight coefficient of each matrix unit. Based on the priority of the first task to be assigned, the selected construction task is determined and assigned. Based on the execution status of the selected construction tasks, the status information of each matrix unit is updated and color-coded. as well as Generate a visual view that displays the progress of the image, the visual view including a view presented in the form of a two-dimensional table; In the view presented in the form of a two-dimensional table, the vertical axis displays multiple construction areas of the target project, and the horizontal axis displays multiple progress nodes of the target project.

12. The system as claimed in claim 11, characterized in that, The plurality of matrix units are generated in the following manner: Spatial conflict verification is performed on the multiple construction areas and the multiple construction spaces required by the multiple progress nodes; and In response to the successful spatial conflict verification of multiple target construction spaces among the multiple construction spaces, multiple target construction areas corresponding to the multiple target construction spaces and multiple matrix units corresponding to the target progress nodes are generated.

13. The system as described in claim 11, characterized in that, Determining the priority of the first task to be dispatched based on the weight coefficient of each matrix unit includes: Based on the fundamental logic between the multiple progress nodes, the first weight coefficient of each matrix unit is determined. Based on the schedule pressure of each matrix unit, a second weighting coefficient for each matrix unit is determined; and Based on the combined result of the first weighting coefficient and the second weighting coefficient, the priority of the first task to be dispatched is determined.

14. The system as described in claim 13, characterized in that, The determination of the second weighting coefficient for each matrix unit based on the schedule pressure of each matrix unit includes: The second weighting coefficient is determined based on the first progress pressure of the construction area corresponding to each matrix unit and the second progress pressure of the progress node corresponding to each matrix unit.

15. The system as claimed in claim 11, characterized in that, The second project document includes a construction task sheet, and the process of determining and assigning the selected construction tasks based on the priority of the first task to be assigned includes: Based on the selected construction tasks, a construction task sheet is generated for each matrix unit. The construction task sheet includes the construction area, construction task procedures, work instructions, safety instructions, and acceptance standards for each matrix unit.

16. The system as described in claim 15, characterized in that, The construction task order also includes a first planned construction period, resource requirements, and contract fulfillment objects. The step of determining and assigning the selected construction tasks based on the priority of the first tasks to be assigned further includes: Based on historical construction data, a prediction algorithm is used to predict the first planned construction period and the resource requirements; and Based on the first planned construction period and the resource requirements, the contract fulfillment object is determined through the capacity database.

17. The system as claimed in claim 16, characterized in that, The updating of the status information and color coding of each matrix unit based on the execution status of the selected construction task includes: Based on the construction task order, anomaly detection is performed on the execution status, including schedule detection and resource consumption detection; and In response to the failure of the anomaly detection, an early warning is issued for each progress node.

18. The system as described in claim 15, characterized in that, The updating of the status information and color coding of each matrix unit based on the execution status of the selected construction task includes: In response to the completion of the selected construction task, a quality rating is performed on the selected construction task based on the acceptance criteria; and In response to the quality rating meeting the second preset condition, the status information is updated and the color code of each matrix unit is updated.

19. The system as claimed in claim 11, characterized in that, The plurality of matrix units includes a first matrix unit, and the method further includes: In response to detecting that the execution state of the first matrix unit is delayed, at least one second matrix unit affected by the first matrix unit is determined based on the node dependency network; Based on the degree of delay of the first matrix unit, the second planned duration and / or the priority of the second task to be dispatched for the at least one second matrix unit are re-determined; and Based on the second planned construction period and / or the priority of the second task to be assigned, the selected construction tasks are re-determined and assigned.

20. The system as claimed in claim 11, characterized in that, The generated visual view showing the progress of the image includes: Acquire multiple location information of the multiple construction areas and multiple state information of the multiple matrix units; and Based on the multiple location information, the multiple state information are mapped to the corresponding spatial location of the virtual building model to form a visualized three-dimensional view.

Images