A collaborative management system based on the whole life cycle of building engineering

Abstract

The application discloses a kind of based on building engineering full life cycle's collaborative management system, it is related to building engineering management technical field, including: data acquisition module: obtaining the engineering task information and engineering entity information of each stage of building engineering full life cycle;Data analysis module: based on the engineering task information, determine task node and the task dependency between task node;State agent generation module: based on the task node, for each engineering entity generates corresponding state agent object, and the state agent object is used to represent the real-time state of the engineering entity under specific task node.By generating the state agent object of each engineering entity throughout full life cycle, and state agent object is associated with specific task node, the deep fusion of engineering task execution state and engineering entity real-time state is realized.

Description

Technical Field

[0001] This invention relates to the field of construction project management technology, specifically a collaborative management system based on the entire life cycle of construction projects. Background Technology

[0002] The entire lifecycle management of building projects involves multiple stages, including planning, design, construction, and operation and maintenance. There are complex relationships between the engineering tasks and the engineering entities generated in each stage. Traditional building project management systems typically adopt document-based or workflow-based management methods, record task progress and entity attributes through databases, and rely on manual methods for status updates and collaborative communication.

[0003] The existing technology has the following shortcomings: First, the engineering task information and the engineering entity information are separated. The system only records the completion status of the task or the geometric attributes of the entity, and fails to establish a dynamic mapping relationship between the task execution status and the real-time status of the entity, which makes it difficult to trace the status. Secondly, the scope of impact of state changes is difficult to identify accurately. When a certain engineering entity changes, construction personnel or managers need to rely on experience to judge which subsequent tasks or related entities may be affected, lacking a systematic impact propagation analysis mechanism. Third, the record of state change paths is incomplete. Traditional systems usually only retain the latest current state, and it is difficult to trace back the evolution process of historical states. When quality problems occur, it is impossible to quickly locate the origin node of the state anomaly. Fourth, in scenarios involving parallel construction along multiple paths or design changes, there is a lack of effective technical support for special control requirements such as state bifurcation, freezing of critical nodes, and recovery from erroneous states. These often rely on manual recording and offline approval, which can easily lead to information distortion and management chaos. Summary of the Invention

[0004] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a collaborative management system based on the entire lifecycle of building engineering projects.

[0005] (II) Technical Solution To achieve the above objectives, the present invention provides the following technical solution: a collaborative management system based on the entire lifecycle of construction projects, specifically comprising: Data acquisition module: Acquires project task information and project entity information at each stage of the entire life cycle of a building project; Data parsing module: Based on the project task information, determine the task nodes and the task dependencies between them; State proxy generation module: Based on the task node, generate a corresponding state proxy object for each project entity. The state proxy object is used to represent the real-time state of the project entity under a specific task node. Relationship building module: Obtain all state proxy objects and, based on the task dependency relationships, establish dynamic connections between state proxy objects to form a state transmission relationship network that represents the engineering state transmission path; Entity Dependency Building Module: Based on the engineering entity information, establishes an engineering entity dependency structure that describes the physical and logical relationships between engineering entities; State Influence Module: When a change in the state proxy object of the first engineering entity is detected, state influence propagation analysis is performed based on the state transit relationship network and the engineering entity dependency structure to determine the affected second engineering entity and update the state proxy object of the second engineering entity.

[0006] Preferably, the data acquisition module divides the entire life cycle of a building project into planning, design, construction, and operation and maintenance stages. The types of project task information include planning tasks, design tasks, construction tasks, and operation and maintenance tasks. The types of project entity information include component entities, equipment entities, and spatial area entities. The module also determines the source channels for each type of information. Based on the identified source channels, the data collection interface is called to obtain raw data from each source channel. Source tags and timestamps are added to the obtained data to generate a set of unprocessed information. Extract key attributes from engineering task information and key attributes from engineering entity information to generate structured task information records and entity information records; Structured task information records and entity information records are stored in the corresponding basic database tables according to information type, and a related index is created for each record.

[0007] Preferably, the data parsing module obtains the standard execution order information and logical precondition information of each engineering task from the stored task information records. The standard execution order information records the default sorting number of the task within its respective stage, and the logical precondition information records the list of precondition task identifiers required to start the current task. Based on the acquired standard execution order information and logical precondition information, a corresponding task node is generated for each engineering task. Each task node is assigned a unique node identifier and a mapping relationship is established with the task identifier of the original engineering task. The task node encapsulates the static attributes of the task, including the task name, the stage to which it belongs, the planned start and end time, and the responsible entity identifier. The standard execution order information is converted into the node sorting weight parameters, and the logical precondition information is converted into the node's precondition node identifier list, generating a set of task nodes covering the entire life cycle of the construction project. Each task node in the task node set is traversed as a predecessor node. The deliverable description field of the predecessor node is read to extract the output type and key parameters. Other task nodes are traversed as candidate successor nodes. The input requirement description field of the candidate successor nodes is read to extract the required input type and receiving parameters. The output type of the predecessor node is compared with the input requirement type of the candidate successor node one by one. If the output type matches the input requirement type, it is determined that there is a potential dependency relationship. Furthermore, it is verified whether the planned completion time of the predecessor node is earlier than the planned start time of the candidate successor node to verify the feasibility of the time logic. For node pairs that pass type matching and time logic verification, a directed task dependency record is generated. Each dependency record contains a predecessor node identifier, a successor node identifier, and a dependency type label. The dependency type label is classified into data dependency, result dependency, or approval dependency categories based on the specific matching content of the output and input. All generated task dependency records are stored in the task dependency table, and an in-degree count and an out-degree count are established for each task node to identify its predecessor dependency quantity and subsequent impact range.

[0008] Preferably, the state proxy generation module traverses each entity record corresponding to the component entity, equipment entity, and spatial region entity, calls the identifier generation service for each engineering entity, generates a globally unique identifier code as the state proxy identifier, establishes a fixed mapping relationship between the state proxy identifier and the original entity number of the engineering entity, and writes the state proxy identifier into the state proxy identifier field of the entity record. From the established set of task nodes, locate the task nodes that are related to the current project entity. For each related task node, read the task execution status field of the task node to obtain the status code value, read the responsible entity field to obtain the name of the entity or individual identity of the entity executing the task, and read the task delivery result field to extract the name, version number, storage path or key result parameters of the result file and generate a summary of the delivery result information. For each project entity, a state proxy object instance is created. The current execution status information, responsible entity identity information, and task delivery result summary information obtained from the temporary buffer are used as inputs. The data is combined according to the preset data structure to generate a multi-dimensional state label containing state dimension sub-labels, responsibility dimension sub-labels, and result dimension sub-labels. The multi-dimensional state label and the generation timestamp are encapsulated inside the state proxy object. Obtain the memory address or storage location of the state proxy object instance, write the memory address or storage location of the state proxy object into the state proxy pointer field of the corresponding project entity record, and write it into the associated entity state list field of the corresponding task node, so that the state proxy object establishes a bidirectional association with the corresponding project entity and task node.

[0009] Preferably, the relationship building module traverses all state proxy objects, and for each state proxy object to be processed, reads the list of associated task node identifiers encapsulated in the first state proxy object to obtain the first task node identifier, and reads the list of associated task node identifiers encapsulated in the second state proxy object to obtain the second task node identifier. Using the identifiers of the first and second task nodes as search criteria, a matching query is performed in the stored task dependency relationship table. If a directed dependency record with the first task node as the predecessor node and the second task node as the successor node is found, it is determined that there is a task dependency relationship between the first and second task nodes. Furthermore, the deliverable description field of the first task node is read to extract the output state parameter type and value range, and the input requirement description field of the second task node is read to extract the required received state parameter type and allowed value range. By comparing the output parameters with the input requirements, the state influence dimension is determined, and influence relationship description data is generated. Create a directed link record with the storage address of the first state proxy object as the starting point and the storage address of the second state proxy object as the ending point. Generate an action tag based on the influence relationship description data and attach it to the link record. The action tag contains an influence dimension field and an influence strength field. The influence dimension field records the type of state parameter passed, and the influence strength field records the constraint conditions or change rules of parameter passing. Store the link record in the state relationship temporary storage area. Iterate through all generated state proxy objects as network nodes, and all stored state transit relationship links as network edges. Combine and assemble the nodes and edges. Record the list of all links that it sends as a starting point and the list of all links that it receives as a termination point for each state proxy node. Maintain the starting node identifier, termination node identifier, and force label for each link. Generate a global state transit relationship network data structure and establish a state propagation index for each node.

[0010] Preferably, the entity dependency construction module traverses each entity record corresponding to component entities, equipment entities, and spatial area entities, reads the spatial location coordinate field of each engineering entity to obtain the three-dimensional positioning parameters of the entity in the building model, obtains the preset adjacent entity identifier, bearing entity identifier, and supported entity identifier, automatically identifies and generates spatial location adjacent relationship records by comparing the coordinate range and boundary distance of different entities, extracts the bearing correspondence between the supporting component and the supported component, reads the coding field to which the entity belongs to obtain the functional system classification identifier to which it belongs, and generates an original relationship data set containing an adjacent relationship list, a bearing relationship list, and a system affiliation relationship list; Extract the construction procedure information corresponding to each engineering entity, read the planned start time field and planned completion time field for each engineering entity to obtain the construction sequence parameters in the time dimension, obtain the list of other entity identifiers that must be constructed before the current entity in the construction logic, and automatically supplement potential construction sequence constraints for entities that lack clear predecessor relationships based on the construction process standard library according to preset rules, and generate a construction logic data set containing the construction sequence number and the list of predecessor entities for each engineering entity. Using engineering entities as nodes, spatial adjacency relationships, load-bearing relationships, functional system affiliation relationships, and construction logic sequence are merged as inputs. A unified neighbor node list is established for each engineering entity. The neighbor node list includes spatially adjacent entities, supporting entities and supported entities in the load-bearing relationship, related entities in the same functional system, and preceding and following entities in the construction logic. A relationship type label is added to each relationship between entities. The relationship type label is divided into spatial adjacency type, load-bearing support type, functional affiliation type, and construction sequence type. The relationship direction attribute is recorded, and intermediate entity association data containing multiple types of relationship labels is generated. All engineering entities are treated as network nodes, and all the relationships between the merged entities are treated as network edges, generating a complete dependency network data structure. Each node stores the basic attributes of the engineering entity and the list of incoming and outgoing edges of all relationships. Each edge stores the starting node identifier, ending node identifier, relationship type label, and relationship strength parameter. The relationship strength parameter is defined as spatial distance value, load transfer coefficient, system coupling degree, or construction tightness, depending on the relationship type. The generated engineering entity dependency network structure is stored in a relational database, and a multidimensional index supporting fast retrieval and traversal by relationship type is established for each node.

[0011] Preferably, when the state influence module detects a change in the state proxy object of the first engineering entity, it locates the state proxy object of the first engineering entity as the source of state disturbance in the state transit relationship network. Based on the source of state disturbance, along the direction of the state transit relationship link, state disturbance diffusion simulation is performed in the state transit relationship network to identify a set of candidate state proxy objects that may be affected by the state. From the set of candidate state proxy objects, select the second engineering entity that has a direct or indirect relationship with the first engineering entity in the engineering entity dependency structure. Based on the change in the state disturbance source, recalculate and update the multidimensional state label in the state proxy object of the second engineering entity; In response to the detection that there are multiple parallel subsequent task paths after the current task node, the current state proxy object corresponding to the current task node is obtained. Based on the current state proxy object and multiple parallel subsequent task paths, a state fork node is generated. In the state transit relationship network, multiple state branches are created for the state fork node, which correspond one-to-one with multiple subsequent task paths. On each state branch, a new state proxy object is generated based on the current state proxy object and the task requirements of the corresponding branch and is connected to the state transit relationship network. Upon detecting that an acceptance task for the target engineering entity has been triggered, the target state proxy object corresponding to the target engineering entity is obtained. Based on the nature and requirements of the acceptance task, a state freeze instruction is generated. In response to the state freeze instruction, an unmodifiable freeze tag is added to the target state proxy object, and the timestamp of the freeze and the identity information of the responsible entity for performing the acceptance are recorded. During the period when the freeze tag is in effect, any modification request for the target state proxy object is prevented. When a state recovery request for a target engineering entity is received, the request is parsed to obtain the target historical time point. Based on the unique identifier of the target engineering entity, the historical state proxy object corresponding to the target historical time point is traced back and located in the state transit relationship network. The complete multi-dimensional state label encapsulated by the historical state proxy object is extracted. Based on the complete multi-dimensional state label, a recovery state proxy object is generated to replace the current state. The recovery state proxy object is connected to the state transit relationship network and the connection of the current state proxy object is disconnected, realizing the backtracking and recovery of the engineering state. All state changes related to the target engineering entity generated after the target historical time point are encapsulated into an independent state evolution branch, which is stored and visualized as a historical bypass of the recovery state proxy object in the state transit relationship network.

[0012] (III) Beneficial Effects This invention provides a collaborative management system based on the entire lifecycle of construction projects, which has the following beneficial effects: This invention generates a state proxy object for each engineering entity throughout its entire lifecycle and associates the state proxy object with a specific task node, thereby achieving a deep integration of the engineering task execution state and the real-time state of the engineering entity. This makes the state of the engineering entity at any time traceable to the corresponding task node and responsible entity, improving the traceability and management precision of the state. Dynamic connections are established between state proxy objects based on task dependencies to form a state transit relationship network. A multi-dimensional engineering entity dependency structure is constructed based on engineering entity information. When the state of a certain engineering entity changes, the disturbance source can be located in the state transit relationship network, and diffusion simulation can be performed along the state transit links. Combined with the entity dependency structure, the second engineering entity that is truly affected can be screened out, which improves the accuracy and response efficiency of state change management and avoids construction errors or rework losses caused by missing affected entities. Attached Figure Description

[0013] Figure 1 This is a system block diagram of the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] Please see Figure 1 This invention provides a collaborative management system based on the entire lifecycle of a construction project, comprising: Data acquisition module: Acquires project task information and project entity information at each stage of the entire life cycle of a building project; In this embodiment of the invention, the data acquisition module needs to be specifically described. The data acquisition module divides the entire life cycle of a building project into the planning stage, design stage, construction stage, and operation and maintenance stage. The types of project task information include planning tasks, design tasks, construction tasks, and operation and maintenance tasks. The types of project entity information include component entities, equipment entities, and spatial area entities. The source channels of various types of information are also determined. Based on the identified source channels, the data collection interface is called to obtain raw data from each source channel. Source tags and timestamps are added to the obtained data to generate a set of unprocessed information. Extract key attributes from engineering task information and key attributes from engineering entity information to generate structured task information records and entity information records; Structured task information records and entity information records are stored in the corresponding basic database tables according to information type, and a related index is created for each record.

[0016] It should be noted that the engineering task information to be obtained for each stage includes planning tasks, design tasks, construction tasks and operation and maintenance tasks. The engineering entity information includes component entities, equipment entities and spatial area entities. By reading the project configuration file or user input instructions, the specific source channel of the information is clarified. The source channels include, but are not limited to, building information model (BIM) database, project management system interface, electronic document storage path and manual input interface. Based on the established type list and source mapping relationship, the system calls the data acquisition interface to obtain raw data from each source channel. For structured data sources, such as component parameter tables in BIM databases and task lists in project management software, the system extracts data in batches using standard query statements. For unstructured or semi-structured data sources, such as design specification documents and construction logs, parsing rules are used for preliminary extraction. During the acquisition process, source tags and timestamps are added to the acquired data to generate an unprocessed information set containing the original content. The unprocessed information set covers basic information such as planning task lists, design task descriptions, construction progress records, operation and maintenance plans, as well as component geometric attributes, equipment specifications, and spatial area divisions. The unprocessed information set is classified and processed. For engineering task information, the parsing engine extracts the key attributes of each stage of the task, including task name, task number, planned start and end time, responsible entity identifier, preceding task identifier, and delivery description. For engineering entity information, the parsing engine extracts the type, location coordinates, and material properties of component entities, the model, installation location, and associated system of equipment entities, and the boundary range, function type, and floor to which spatial area entities belong. The parsing engine reorganizes the extracted attribute fields according to a unified data structure to generate structured task information records and entity information records, ensuring that each record has a unique identifier and complete fields. Structured information is categorized and stored in the basic database. Based on information type, task information records are stored in planning task tables, design task tables, construction task tables, and operation and maintenance task tables, respectively. Entity information records are stored in component tables, equipment tables, and spatial area tables. At the same time, the system establishes association indexes for each record. For example, task records are initially associated with their related entity records through entity identifiers to facilitate quick location when called by subsequent modules. After storage is completed, the system generates an information acquisition completion signal and returns the storage path and total number of records to the main control module, marking the end of the basic information collection phase of the entire life cycle of the building project.

[0017] Data parsing module: Based on the project task information, determine the task nodes and the task dependencies between them; In this embodiment of the invention, the data parsing module needs to be specifically described. The data parsing module obtains the standard execution order information and logical precondition information of each engineering task from the stored task information records. The standard execution order information records the default sorting number of the task in its respective stage, and the logical precondition information records the list of precondition task identifiers required to start the current task. Based on the acquired standard execution order information and logical precondition information, a corresponding task node is generated for each engineering task. Each task node is assigned a unique node identifier and a mapping relationship is established with the task identifier of the original engineering task. The task node encapsulates the static attributes of the task, including the task name, the stage to which it belongs, the planned start and end time, and the responsible entity identifier. The standard execution order information is converted into the node sorting weight parameters, and the logical precondition information is converted into the node's precondition node identifier list, generating a set of task nodes covering the entire life cycle of the construction project. Each task node in the task node set is traversed as a predecessor node. The deliverable description field of the predecessor node is read to extract the output type and key parameters. Other task nodes are traversed as candidate successor nodes. The input requirement description field of the candidate successor nodes is read to extract the required input type and receiving parameters. The output type of the predecessor node is compared with the input requirement type of the candidate successor node one by one. If the output type matches the input requirement type, it is determined that there is a potential dependency relationship. Furthermore, it is verified whether the planned completion time of the predecessor node is earlier than the planned start time of the candidate successor node to verify the feasibility of the time logic. For node pairs that pass type matching and time logic verification, a directed task dependency record is generated. Each dependency record contains a predecessor node identifier, a successor node identifier, and a dependency type label. The dependency type label is classified into data dependency, result dependency, or approval dependency categories based on the specific matching content of the output and input. All generated task dependency records are stored in the task dependency table, and an in-degree count and an out-degree count are established for each task node to identify its predecessor dependency quantity and subsequent impact range.

[0018] It should be noted that the system extracts the attribute fields corresponding to the planning phase tasks, design phase tasks, construction phase tasks, and operation and maintenance phase tasks from the stored task information records. For each task record, it reads the preset standard execution order field, which records the default sorting number of the task within its phase. At the same time, it reads the logical precondition field, which records the list of precondition task identifiers that must be met to start the current task. For task records that lack the above information, the system calls the preset industry standard library to complete it, or matches the default execution order rules based on the task type. After the extraction is completed, the system generates a raw relational data set containing task identifiers, execution order values, and a list of preconditions. The system iterates through all project task records, generating a corresponding task node for each record. Each task node is assigned a unique node identifier and mapped to the task identifier of the original task record. The task node encapsulates the static attributes of the task, including the task name, the stage it belongs to, the planned start and end time, and the responsible entity identifier. During the generation process, the system converts the standard execution order information into the node's sorting weight parameters and the logical precondition information into the node's precondition list. All generated task nodes are classified and stored according to their stage, forming a task node set covering the entire life cycle of the construction project. Traverse all other task nodes as candidate successor nodes, read their input requirement description fields, extract the required input result types and receiving parameters, compare the output result types of the predecessor nodes with the input requirement types of the candidate successor nodes one by one, if the output type matches the input requirement type, it is determined that there is a potential dependency relationship. For node pairs determined to have a potential dependency relationship, further verify whether the planned completion time of the predecessor node is earlier than the planned start time of the successor node to verify the feasibility of the time logic. For node pairs that pass type matching and time logic verification, the system generates a directed task dependency record. Each dependency record includes a predecessor node identifier, a successor node identifier, and a dependency type label. The dependency type label is classified into categories such as data dependency, outcome dependency, or approval dependency based on the specific matching content between the output and input. The system stores all generated task dependency records in a task dependency table and establishes an in-degree count and an out-degree count for each task node to identify its predecessor dependency count and subsequent impact range. After completing the above processing, the system outputs a complete set of task nodes and a task dependency network between nodes.

[0019] State proxy generation module: Based on the task node, generate a corresponding state proxy object for each project entity. The state proxy object is used to represent the real-time state of the project entity under a specific task node. In this embodiment of the invention, the state proxy generation module needs to be specifically described. The state proxy generation module traverses each entity record corresponding to the component entity, equipment entity and spatial region entity, calls the identifier generation service for each engineering entity, generates a globally unique identifier code as the state proxy identifier, establishes a fixed mapping relationship between the state proxy identifier and the original entity number of the engineering entity, and writes the state proxy identifier into the state proxy identifier field of the entity record. From the established set of task nodes, locate the task nodes that are related to the current project entity. For each related task node, read the task execution status field of the task node to obtain the status code value, read the responsible entity field to obtain the name of the entity or individual identity of the entity executing the task, and read the task delivery result field to extract the name, version number, storage path or key result parameters of the result file and generate a summary of the delivery result information. For each project entity, a state proxy object instance is created. The current execution status information, responsible entity identity information, and task delivery result summary information obtained from the temporary buffer are used as inputs. The data is combined according to the preset data structure to generate a multi-dimensional state label containing state dimension sub-labels, responsibility dimension sub-labels, and result dimension sub-labels. The multi-dimensional state label and the generation timestamp are encapsulated inside the state proxy object. Obtain the memory address or storage location of the state proxy object instance, write the memory address or storage location of the state proxy object into the state proxy pointer field of the corresponding project entity record, and write it into the associated entity state list field of the corresponding task node, so that the state proxy object establishes a bidirectional association with the corresponding project entity and task node.

[0020] It should be noted that a unique status proxy identifier is assigned to each engineering entity throughout its entire lifecycle. From the stored engineering entity information records, each entity record corresponding to component entities, equipment entities, and spatial area entities is traversed. For each engineering entity, the identifier generation service is called to generate a globally unique identifier code. This identifier code establishes a fixed mapping relationship with the original entity number of the engineering entity and does not change as the engineering stage progresses. After generation, the system writes the status proxy identifier into the status proxy identifier field of the entity record, ensuring that each engineering entity can be traced and accessed through this unique identifier throughout its entire lifecycle, providing a stable index foundation for the continuous accumulation of subsequent status information. Next, the system obtains the current execution status information, responsible entity identity information, and task delivery summary information corresponding to the task node. From the determined set of task nodes, it locates the task nodes that are associated with the current project entity. For each associated task node, the system reads its task execution status field to obtain the status code value, which corresponds to different status levels such as pending, in progress, completed, and accepted. At the same time, it reads the responsible entity field to obtain the name of the entity or individual that performed the task. Then, it reads the task delivery field to extract the name, version number, storage path, or key delivery parameters of the delivery file and generates delivery summary information. After completing the reading, the above three types of information are temporarily stored in a temporary buffer associated with the entity. The current execution status information, the identity information of the responsible entity, and the summary information of the task delivery results are encapsulated to generate a state proxy object carrying multi-dimensional status labels. The state encapsulation engine is called to create a state proxy object instance for each project entity. The encapsulation engine takes the three types of information obtained from the temporary buffer as input and combines them according to the preset data structure to generate multi-dimensional status labels. The multi-dimensional status label is a composite data structure containing status dimension sub-labels, responsibility dimension sub-labels, and result dimension sub-labels, which correspond to the execution status information, the responsible entity information, and the summary information of the delivery results, respectively. After encapsulation, the state proxy object stores the complete multi-dimensional status labels and the generation timestamp, forming a complete data image reflecting the real-time status of the project entity under a specific task node. The process establishes associations between state proxy objects and their corresponding project entities and task nodes. It obtains the memory address or storage location of the state proxy object instance and writes it to the state proxy pointer field of the corresponding project entity record and the associated entity state list field of the corresponding task node. For project entity records, the state proxy pointer points to the currently active state proxy object; for task nodes, the associated entity state list records all project entities affected or generated by the task node and their corresponding state proxy identifiers. After completing the bidirectional association, a structured collection of state proxy objects is output. Each object can be retrieved through project entities and traced through task nodes, providing directly referenceable node elements for subsequent construction of dynamic connections between state proxy objects.

[0021] Relationship building module: Obtain all state proxy objects and, based on the task dependency relationships, establish dynamic connections between state proxy objects to form a state transmission relationship network that represents the engineering state transmission path; In this embodiment of the invention, the relationship building module needs to be specifically described. The relationship building module traverses all state proxy objects. For each state proxy object to be processed, it reads the list of associated task node identifiers encapsulated in the first state proxy object to obtain the first task node identifier, and reads the list of associated task node identifiers encapsulated in the second state proxy object to obtain the second task node identifier. Using the identifiers of the first and second task nodes as search criteria, a matching query is performed in the stored task dependency relationship table. If a directed dependency record with the first task node as the predecessor node and the second task node as the successor node is found, it is determined that there is a task dependency relationship between the first and second task nodes. Furthermore, the deliverable description field of the first task node is read to extract the output state parameter type and value range, and the input requirement description field of the second task node is read to extract the required received state parameter type and allowed value range. By comparing the output parameters with the input requirements, the state influence dimension is determined, and influence relationship description data is generated. Create a directed link record with the storage address of the first state proxy object as the starting point and the storage address of the second state proxy object as the ending point. Generate an action tag based on the influence relationship description data and attach it to the link record. The action tag contains an influence dimension field and an influence strength field. The influence dimension field records the type of state parameter passed, and the influence strength field records the constraint conditions or change rules of parameter passing. Store the link record in the state relationship temporary storage area. Iterate through all generated state proxy objects as network nodes, and all stored state transit relationship links as network edges. Combine and assemble the nodes and edges. Record the list of all links that it sends as a starting point and the list of all links that it receives as a termination point for each state proxy node. Maintain the starting node identifier, termination node identifier, and force label for each link. Generate a global state transit relationship network data structure and establish a state propagation index for each node.

[0022] It should be noted that all state proxy objects are traversed as candidate first objects, and all other state proxy objects are traversed as candidate second objects. For each state proxy object to be processed, the system reads the list of associated task node identifiers encapsulated in the first state proxy object to obtain its corresponding first task node identifier, and reads the list of associated task node identifiers encapsulated in the second state proxy object to obtain its corresponding second task node identifier. After the reading is completed, the system uses the first task node identifier and the second task node identifier as a pair of input parameters and temporarily stores them in the relationship analysis buffer to provide a basis for subsequent dependency relationship judgment. Determine if a task dependency exists between the first and second task nodes. If so, analyze how the output status parameters of the first task node affect the input status requirements of the second task node. Using the identifiers of the first and second task nodes as search criteria, perform a matching query in the stored task dependency table. If a directed dependency record with the first task node as the predecessor node and the second task node as the successor node is found, it is determined that a task dependency exists between the two. After confirming the existence of the dependency, read the deliverable description field of the first task node, extract its output status parameter type and value range, read the input requirement description field of the second task node, extract its required received status parameter type and allowed value range, compare the output parameters with the input requirements, determine the specific status response dimension, such as intensity parameter transmission, size parameter transmission, or approval status transmission, and generate influence relationship description data. Create a directed link record, starting from the storage address of the first state proxy object and ending at the storage address of the second state proxy object. This clearly indicates the direction of state propagation, from the state proxy corresponding to the preceding task to the state proxy corresponding to the subsequent task. Simultaneously, based on the parsed influence relationship description data, generate an action force label and attach it to the link record. The action force label is a structured label containing an influence dimension field and an influence strength field. The influence dimension field records the type of state parameter being propagated, and the influence strength field records the constraints or change rules for parameter propagation. After generation, store the link record in the temporary storage area for state relationships. The system iterates through all generated state proxy objects as network nodes and all stored state propagation relationship links as network edges. Nodes and edges are then combined and assembled. For each state proxy node, the system records a list of all links originating from it as a starting point and a list of all links received by it as a termination point. For each link, the system maintains its starting node identifier, termination node identifier, and force label. After assembly, the system generates a global state propagation relationship network data structure. This data structure fully describes the state flow path between all state proxy objects based on task dependencies. The network data structure is stored in runtime memory or a persistent database, and a state propagation index is created for each node for subsequent state influence propagation analysis modules to call, marking the completion of the engineering state propagation path construction.

[0023] Entity Dependency Building Module: Based on the engineering entity information, establishes an engineering entity dependency structure that describes the physical and logical relationships between engineering entities; In this embodiment of the invention, the entity dependency construction module needs to be specifically described. The entity dependency construction module traverses each entity record corresponding to component entities, equipment entities, and spatial region entities, reads the spatial position coordinate field of each engineering entity to obtain the three-dimensional positioning parameters of the entity in the building model, obtains the preset adjacent entity identifier, bearing entity identifier, and supported entity identifier, automatically identifies and generates spatial position adjacent relationship records by comparing the coordinate range and boundary distance of different entities, extracts the bearing correspondence between the supporting component and the supported component, reads the coding field to which the entity belongs to obtain the functional system classification identifier to which it belongs, and generates an original relationship data set containing an adjacent relationship list, a bearing relationship list, and a system affiliation relationship list. Extract the construction procedure information corresponding to each engineering entity, read the planned start time field and planned completion time field for each engineering entity to obtain the construction sequence parameters in the time dimension, obtain the list of other entity identifiers that must be constructed before the current entity in the construction logic, and automatically supplement potential construction sequence constraints for entities that lack clear predecessor relationships based on the construction process standard library according to preset rules, and generate a construction logic data set containing the construction sequence number and the list of predecessor entities for each engineering entity. Using engineering entities as nodes, spatial adjacency relationships, load-bearing relationships, functional system affiliation relationships, and construction logic sequence are merged as inputs. A unified neighbor node list is established for each engineering entity. The neighbor node list includes spatially adjacent entities, supporting entities and supported entities in the load-bearing relationship, related entities in the same functional system, and preceding and following entities in the construction logic. A relationship type label is added to each relationship between entities. The relationship type label is divided into spatial adjacency type, load-bearing support type, functional affiliation type, and construction sequence type. The relationship direction attribute is recorded, and intermediate entity association data containing multiple types of relationship labels is generated. All engineering entities are treated as network nodes, and all the relationships between the merged entities are treated as network edges, generating a complete dependency network data structure. Each node stores the basic attributes of the engineering entity and the list of incoming and outgoing edges of all relationships. Each edge stores the starting node identifier, ending node identifier, relationship type label, and relationship strength parameter. The relationship strength parameter is defined as spatial distance value, load transfer coefficient, system coupling degree, or construction tightness, depending on the relationship type. The generated engineering entity dependency network structure is stored in a relational database, and a multidimensional index supporting fast retrieval and traversal by relationship type is established for each node.

[0024] It should be noted that the system iterates through each entity record corresponding to component entities, equipment entities, and spatial region entities. For each engineering entity, the system reads its spatial location coordinate field to obtain the entity's 3D positioning parameters in the building model. Simultaneously, it reads its associated entity list field to obtain preset adjacent entity identifiers, load-bearing entity identifiers, and supported entity identifiers. For spatial adjacency relationships, the system automatically identifies and generates adjacency relationship records by comparing the coordinate ranges and boundary distances of different entities. For load-bearing relationships, the system reads the load transfer paths defined in the structural analysis model to extract the load-bearing correspondence between supporting and supported components. For functional system affiliation relationships, the system reads the system code field to which the entity belongs to obtain its classification identifier, such as the electromechanical system, HVAC system, or water supply and drainage system. After extraction, the system generates a raw relational data set containing the adjacent relationship list, load-bearing relationship list, and system affiliation list. For each project entity, the system reads its planned start time and planned completion time fields to obtain the construction sequence parameters in the time dimension; simultaneously, it reads its preceding construction entity field to obtain a list of other entity identifiers that must logically precede the current entity in construction. For entities lacking explicit preceding relationships, the system infers based on a construction process standard library, such as automatically supplementing potential construction sequence constraints according to general rules like "main structure before enclosure, structure before decoration, civil engineering before installation." After extraction, the system generates a construction logic data set containing the construction sequence number and the list of preceding entities for each project entity. Using engineering entities as nodes, the above four types of relationship data are input for merging processing. A unified list of neighboring nodes is established for each engineering entity. This list includes not only spatially adjacent entities, but also supporting and supported entities in the bearing relationship, related entities in the same functional system, and preceding and following entities in the construction logic. During the merging process, the fusion engine adds a relationship type label to each relationship between entities. The relationship type label is divided into spatially adjacent, bearing-support, functionally related, and construction sequence types, and records the relationship direction attribute. For example, the bearing relationship has a clear directionality, and the construction sequence relationship also has a directionality from first to last. After the fusion is completed, the system generates intermediate entity association data containing multiple types of relationship labels.

[0025] By treating all engineering entities as network nodes and all merged inter-entity relationships as network edges, a complete dependency network data structure is generated. In this network structure, each node stores the basic attributes of the engineering entity and the list of incoming and outgoing edges for all relationships. Each edge stores the starting node identifier, ending node identifier, relationship type label, and relationship strength parameter. The relationship strength parameter is defined as spatial distance value, load transfer coefficient, system coupling degree, or construction tightness, depending on the relationship type. After construction, the system stores the engineering entity dependency network structure in a relational database and establishes a multi-dimensional index for each node, supporting fast retrieval and traversal by relationship type. This network structure fully describes the multi-dimensional relationships between engineering entities based on physical space and construction logic, providing an entity-level dependency foundation for subsequent state influence propagation analysis.

[0026] State Influence Module: When a change in the state proxy object of the first engineering entity is detected, state influence propagation analysis is performed based on the state transit relationship network and the engineering entity dependency structure to determine the affected second engineering entity and update the state proxy object of the second engineering entity.

[0027] In this embodiment of the invention, the state influence module needs to be specifically described. When the state influence module detects a change in the state proxy object of the first engineering entity, it locates the state proxy object of the first engineering entity as the source of state disturbance in the state transit relationship network. Based on the source of state disturbance, along the direction of the state transit relationship link, state disturbance diffusion simulation is performed in the state transit relationship network to identify a set of candidate state proxy objects that may be affected by the state. From the set of candidate state proxy objects, select the second engineering entity that has a direct or indirect relationship with the first engineering entity in the engineering entity dependency structure. Based on the change in the state disturbance source, recalculate and update the multidimensional state label in the state proxy object of the second engineering entity; In response to the detection that there are multiple parallel subsequent task paths after the current task node, the current state proxy object corresponding to the current task node is obtained. Based on the current state proxy object and multiple parallel subsequent task paths, a state fork node is generated. In the state transit relationship network, multiple state branches are created for the state fork node, which correspond one-to-one with multiple subsequent task paths. On each state branch, a new state proxy object is generated based on the current state proxy object and the task requirements of the corresponding branch and is connected to the state transit relationship network. Upon detecting that an acceptance task for the target engineering entity has been triggered, the target state proxy object corresponding to the target engineering entity is obtained. Based on the nature and requirements of the acceptance task, a state freeze instruction is generated. In response to the state freeze instruction, an unmodifiable freeze tag is added to the target state proxy object, and the timestamp of the freeze and the identity information of the responsible entity for performing the acceptance are recorded. During the period when the freeze tag is in effect, any modification request for the target state proxy object is prevented. When a state recovery request for a target engineering entity is received, the request is parsed to obtain the target historical time point. Based on the unique identifier of the target engineering entity, the historical state proxy object corresponding to the target historical time point is traced back and located in the state transit relationship network. The complete multi-dimensional state label encapsulated by the historical state proxy object is extracted. Based on the complete multi-dimensional state label, a recovery state proxy object is generated to replace the current state. The recovery state proxy object is connected to the state transit relationship network and the connection of the current state proxy object is disconnected, realizing the backtracking and recovery of the engineering state. All state changes related to the target engineering entity generated after the target historical time point are encapsulated into an independent state evolution branch, which is stored and visualized as a historical bypass of the recovery state proxy object in the state transit relationship network.

[0028] It should be noted that the system monitors the state proxy objects of all engineering entities in real time. When a change in the value of the multidimensional state label or a transition in the state level is detected within a state proxy object, the state proxy object is marked as a source of state change. The system reads the storage address and unique identifier of the state proxy object, retrieves the node containing the identifier in the constructed state propagation relationship network, identifies it as the source node of the state disturbance, and records the specific content of the state change, including the changed state dimension, the values ​​before and after the change, and the timestamp of the change, generating a state change event record to provide the starting point and change parameters for subsequent propagation analysis. Based on the state disturbance source, along the direction of the state transit relationship links, a state disturbance diffusion simulation is performed in the state transit relationship network to identify a set of candidate state proxy objects that may be affected by the state. Starting from the state disturbance source node, all state transit relationship links originating from that node are traversed. Along the direction indicated by the force label of each link, the diffusion proceeds outward level by level according to the influence dimension and influence intensity parameters stored in the link record. In each level of diffusion, the currently accessed state proxy object is marked as a candidate object, and the propagation path length and cumulative influence coefficient from the disturbance source to the candidate object are recorded. The diffusion simulation continues until a preset propagation depth threshold is reached or all reachable nodes are traversed. After the simulation is completed, the system generates a set of candidate state proxy objects containing all marked candidate objects and their propagation path information. The first engineering entity has a directly or indirectly related second engineering entity. The system traverses each object in the candidate state proxy object set, reads the identifier of its associated engineering entity, and searches in the constructed engineering entity dependency network structure for each candidate engineering entity identifier to query whether there is a directly connected edge between the entity and the first engineering entity, or a reachable path connected through an intermediate entity. The system calls the graph traversal algorithm to perform a breadth-first search in the dependency network starting from the first engineering entity, marking all reachable engineering entities as associated entities. The system performs an intersection operation between the engineering entity identifiers in the candidate state proxy object set and the searched set of associated entity identifiers to filter out engineering entities that are both on the state propagation path and in the entity dependency relationship, and determines them as the set of affected second engineering entities. Based on the change in the state disturbance source, the multidimensional state labels in the state proxy object of the second engineering entity are recalculated and updated. The system obtains the change parameters of the state disturbance source, including the specific change dimension and change magnitude. For each determined second engineering entity, the system reads the multidimensional state label in its current state proxy object, and at the same time reads the cumulative influence coefficient on the propagation path from the disturbance source to the entity. The change in the disturbance source is multiplied by the influence coefficient on the propagation path to obtain the adjustment value of each state dimension of the entity, and the adjustment value is superimposed on the corresponding dimension of the current multidimensional state label. For state values ​​that exceed the preset range, the system performs truncation or triggers an alarm. After the calculation is completed, the system generates updated multidimensional state labels, replaces the original labels in the "Second Engineering Entity State Proxy", and records the update reason and update timestamp, realizing accurate propagation and updating of state influence. The system monitors the execution status of task nodes in real time. When multiple parallel subsequent task paths are detected after the current task node, the system obtains the current state proxy object corresponding to the current task node. Based on the current state proxy object and the multiple parallel subsequent task paths, the system generates a state fork node as a logical marker. In the state transit relationship network, the system creates multiple state branches for the state fork node, each corresponding to an independent subsequent task path. On each state branch, based on the current state proxy object and the task requirements of the corresponding branch, the system copies the current state proxy object and adjusts it according to the branch task requirements to generate a new state proxy object. These new objects are then connected to the state transit relationship network, thus completely recording the forking evolution process of the project state in a multi-path scenario.

[0029] The system monitors task node types in real time. When an acceptance task for a target engineering entity is triggered, it retrieves the target status proxy object corresponding to the target engineering entity. Based on the nature and requirements of the acceptance task, such as whether the acceptance type is sub-item acceptance or final acceptance, it generates a corresponding status freeze command. In response to the status freeze command, the system adds an unmodifiable freeze tag to the target status proxy object and records the timestamp of the freeze and the identity information of the responsible entity for performing the acceptance. The above information is appended to the metadata area of ​​the status proxy object. During the period when the freeze tag is in effect, any modification requests for the target status proxy object are intercepted and rejected to ensure that the engineering status at the time of acceptance is completely locked as a benchmark for subsequent audits. The system receives external state recovery requests in real time. When a state recovery request for a target engineering entity is received, the system parses the request to obtain the target historical time point. Based on the unique identifier of the target engineering entity, it traces backward along the time dimension in the state transitivity network to locate the historical state proxy object corresponding to the target historical time point. The system extracts the complete multi-dimensional state label encapsulated in this historical state proxy object, including the state value, responsible entity, and deliverable summary. Based on the extracted complete multi-dimensional state label, a recovery state proxy object is generated to replace the current state. This recovery object is then connected to the state transitivity network, while the connection to the current state proxy object is disconnected. This achieves the backtracking recovery of the engineering state to a historical moment. After recovery, the system encapsulates all state change records related to the target engineering entity generated after the target historical time point into an independent state evolution branch. This branch is stored and visually marked as a historical bypass of the recovery state proxy object in the state transitivity network for subsequent auditing and analysis, ensuring the complete traceability of the historical trajectory.

[0030] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0031] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0032] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0033] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0034] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A collaborative management system based on the entire lifecycle of construction projects, characterized in that, include: Data acquisition module: Acquires project task information and project entity information at each stage of the entire life cycle of a building project; Data parsing module: Based on the project task information, determine the task nodes and the task dependencies between them; State proxy generation module: Based on the task node, generate a corresponding state proxy object for each project entity. The state proxy object is used to represent the real-time state of the project entity under a specific task node. Relationship building module: Obtain all state proxy objects and, based on the task dependency relationships, establish dynamic connections between state proxy objects to form a state transmission relationship network that represents the engineering state transmission path; Entity Dependency Building Module: Based on the engineering entity information, establishes an engineering entity dependency structure that describes the physical and logical relationships between engineering entities; State Influence Module: When a change in the state proxy object of the first engineering entity is detected, state influence propagation analysis is performed based on the state transit relationship network and the engineering entity dependency structure to determine the affected second engineering entity and update the state proxy object of the second engineering entity.

2. The collaborative management system based on the entire life cycle of construction projects according to claim 1, characterized in that, The data acquisition module divides the entire life cycle of a building project into planning, design, construction, and operation and maintenance phases. The types of project task information include planning tasks, design tasks, construction tasks, and operation and maintenance tasks. The types of project entity information include component entities, equipment entities, and spatial area entities. The module also determines the source channels for each type of information. Based on the identified source channels, the data collection interface is called to obtain raw data from each source channel. Source tags and timestamps are added to the obtained data to generate a set of unprocessed information. Extract key attributes from engineering task information and key attributes from engineering entity information to generate structured task information records and entity information records; Structured task information records and entity information records are stored in the corresponding basic database tables according to information type, and a related index is created for each record.

3. The collaborative management system based on the entire life cycle of building construction projects according to claim 1, characterized in that, The data parsing module obtains the standard execution order information and logical precondition information of each engineering task from the stored task information records. The standard execution order information records the default sorting number of the task within its respective stage, and the logical precondition information records the list of precondition task identifiers required to start the current task. Based on the acquired standard execution order information and logical precondition information, a corresponding task node is generated for each engineering task. Each task node is assigned a unique node identifier and a mapping relationship is established with the task identifier of the original engineering task. The task node encapsulates the static attributes of the task, including the task name, the stage to which it belongs, the planned start and end time, and the responsible entity identifier. The standard execution order information is converted into the node's sorting weight parameters, and the logical precondition information is converted into a list of node's precondition identifiers, generating a set of task nodes covering the entire life cycle of the construction project.

4. A collaborative management system based on the entire lifecycle of a building project as described in claim 3, characterized in that, Each task node in the task node set is traversed as a predecessor node. The deliverable description field of the predecessor node is read to extract the output type and key parameters. Other task nodes are traversed as candidate successor nodes. The input requirement description field of the candidate successor nodes is read to extract the required input type and receiving parameters. The output type of the predecessor node is compared with the input requirement type of the candidate successor node one by one. If the output type matches the input requirement type, it is determined that there is a potential dependency relationship. Furthermore, it is verified whether the planned completion time of the predecessor node is earlier than the planned start time of the candidate successor node to verify the feasibility of the time logic. For node pairs that pass type matching and time logic verification, a directed task dependency record is generated. Each dependency record contains a predecessor node identifier, a successor node identifier, and a dependency type label. The dependency type label is classified into data dependency, result dependency, or approval dependency categories based on the specific matching content of the output and input. All generated task dependency records are stored in the task dependency table, and an in-degree count and an out-degree count are established for each task node to identify its predecessor dependency quantity and subsequent impact range.

5. A collaborative management system based on the entire lifecycle of a building project as described in claim 1, characterized in that, The state proxy generation module traverses each entity record corresponding to the component entity, equipment entity, and spatial region entity, calls the identifier generation service for each engineering entity, generates a globally unique identifier code as the state proxy identifier, establishes a fixed mapping relationship between the state proxy identifier and the original entity number of the engineering entity, and writes the state proxy identifier into the state proxy identifier field of the entity record. From the established set of task nodes, locate the task nodes that are related to the current project entity. For each related task node, read the task execution status field of the task node to obtain the status code value, read the responsible entity field to obtain the name of the entity or individual identity of the entity executing the task, and read the task delivery result field to extract the name, version number, storage path or key result parameters of the result file and generate a summary of the delivery result information. For each project entity, a state proxy object instance is created. The current execution status information, responsible entity identity information, and task delivery result summary information obtained from the temporary buffer are used as inputs. The data is combined according to the preset data structure to generate a multi-dimensional state label containing state dimension sub-labels, responsibility dimension sub-labels, and result dimension sub-labels. The multi-dimensional state label and the generation timestamp are then encapsulated inside the state proxy object.

6. A collaborative management system based on the entire lifecycle of a building project as described in claim 5, characterized in that, Obtain the memory address or storage location of the state proxy object instance, write the memory address or storage location of the state proxy object into the state proxy pointer field of the corresponding project entity record, and write it into the associated entity state list field of the corresponding task node, so that the state proxy object establishes a bidirectional association with the corresponding project entity and task node.

7. A collaborative management system based on the entire lifecycle of a building project as described in claim 1, characterized in that, The relationship building module traverses all state proxy objects. For each state proxy object to be processed, it reads the list of associated task node identifiers encapsulated in the first state proxy object to obtain the first task node identifier, and reads the list of associated task node identifiers encapsulated in the second state proxy object to obtain the second task node identifier. Using the identifiers of the first and second task nodes as search criteria, a matching query is performed in the stored task dependency relationship table. If a directed dependency record with the first task node as the predecessor node and the second task node as the successor node is found, it is determined that there is a task dependency relationship between the first and second task nodes. The deliverable description field of the first task node is then read to extract the output state parameter type and value range, and the input requirement description field of the second task node is read to extract the required received state parameter type and allowed value range. By comparing the output parameters with the input requirements, the state influence dimension is determined, and influence relationship description data is generated.

8. A collaborative management system based on the entire life cycle of a building project according to claim 7, characterized in that, Create a directed link record with the storage address of the first state proxy object as the starting point and the storage address of the second state proxy object as the ending point. Generate an action tag based on the influence relationship description data and attach it to the link record. The action tag contains an influence dimension field and an influence strength field. The influence dimension field records the type of state parameter passed, and the influence strength field records the constraint conditions or change rules of parameter passing. Store the link record in the state relationship temporary storage area. Iterate through all generated state proxy objects as network nodes, and all stored state transit relationship links as network edges. Combine and assemble the nodes and edges. Record the list of all links that it sends as a starting point and the list of all links that it receives as a termination point for each state proxy node. Maintain the starting node identifier, termination node identifier, and force label for each link. Generate a global state transit relationship network data structure and establish a state propagation index for each node.

9. A collaborative management system based on the entire lifecycle of a building project according to claim 1, characterized in that, The entity dependency construction module traverses each entity record corresponding to component entities, equipment entities, and spatial region entities, reads the spatial location coordinate field of each engineering entity to obtain the three-dimensional positioning parameters of the entity in the building model, obtains the preset adjacent entity identifier, bearing entity identifier, and supported entity identifier, automatically identifies and generates spatial location adjacent relationship records by comparing the coordinate range and boundary distance of different entities, extracts the bearing correspondence between the supporting component and the supported component, reads the coding field to which the entity belongs to obtain the functional system classification identifier to which it belongs, and generates an original relationship data set containing an adjacent relationship list, a bearing relationship list, and a system affiliation relationship list; Extract the construction procedure information corresponding to each engineering entity, read the planned start time field and planned completion time field for each engineering entity to obtain the construction sequence parameters in the time dimension, obtain the list of other entity identifiers that must be constructed before the current entity in the construction logic, and automatically supplement potential construction sequence constraints for entities that lack clear predecessor relationships based on the construction process standard library according to preset rules, and generate a construction logic data set containing the construction sequence number and the list of predecessor entities for each engineering entity. Using engineering entities as nodes, spatial adjacency relationships, load-bearing relationships, functional system affiliation relationships, and construction logic sequence are merged as inputs. A unified neighbor node list is established for each engineering entity. The neighbor node list includes spatially adjacent entities, supporting entities and supported entities in the load-bearing relationship, related entities in the same functional system, and preceding and following entities in the construction logic. A relationship type label is added to each relationship between entities. The relationship type label is divided into spatial adjacency type, load-bearing support type, functional affiliation type, and construction sequence type. The relationship direction attribute is recorded, and intermediate entity association data containing multiple types of relationship labels is generated. All engineering entities are treated as network nodes, and all the relationships between the merged entities are treated as network edges, generating a complete dependency network data structure. Each node stores the basic attributes of the engineering entity and the list of incoming and outgoing edges of all relationships. Each edge stores the starting node identifier, ending node identifier, relationship type label, and relationship strength parameter. The relationship strength parameter is defined as spatial distance value, load transfer coefficient, system coupling degree, or construction tightness, depending on the relationship type. The generated engineering entity dependency network structure is stored in a relational database, and a multidimensional index supporting fast retrieval and traversal by relationship type is established for each node.

10. A collaborative management system based on the entire lifecycle of a construction project as described in claim 1, characterized in that, When the state influence module detects a change in the state proxy object of the first engineering entity, it locates the state proxy object of the first engineering entity as the source of state disturbance in the state transit relationship network. Based on the source of state disturbance, along the direction of the state transit relationship link, state disturbance diffusion simulation is performed in the state transit relationship network to identify a set of candidate state proxy objects that may be affected by the state. From the set of candidate state proxy objects, select the second engineering entity that has a direct or indirect relationship with the first engineering entity in the engineering entity dependency structure. Based on the change in the state disturbance source, recalculate and update the multidimensional state label in the state proxy object of the second engineering entity; In response to the detection that there are multiple parallel subsequent task paths after the current task node, the current state proxy object corresponding to the current task node is obtained. Based on the current state proxy object and multiple parallel subsequent task paths, a state fork node is generated. In the state transit relationship network, multiple state branches are created for the state fork node, which correspond one-to-one with multiple subsequent task paths. On each state branch, a new state proxy object is generated based on the current state proxy object and the task requirements of the corresponding branch and is connected to the state transit relationship network. Upon detecting that an acceptance task for the target engineering entity has been triggered, the target state proxy object corresponding to the target engineering entity is obtained. Based on the nature and requirements of the acceptance task, a state freeze instruction is generated. In response to the state freeze instruction, an unmodifiable freeze tag is added to the target state proxy object, and the timestamp of the freeze and the identity information of the responsible entity for performing the acceptance are recorded. During the period when the freeze tag is in effect, any modification request for the target state proxy object is prevented. When a state recovery request for a target engineering entity is received, the request is parsed to obtain the target historical time point. Based on the unique identifier of the target engineering entity, the historical state proxy object corresponding to the target historical time point is traced back and located in the state transit relationship network. The complete multi-dimensional state label encapsulated by the historical state proxy object is extracted. Based on the complete multi-dimensional state label, a recovery state proxy object is generated to replace the current state. The recovery state proxy object is connected to the state transit relationship network and the connection of the current state proxy object is disconnected, realizing the backtracking and recovery of the engineering state. All state changes related to the target engineering entity generated after the target historical time point are encapsulated into an independent state evolution branch, which is stored and visualized as a historical bypass of the recovery state proxy object in the state transit relationship network.

Images