A BIM-based engineering whole life cycle collaborative management method

Abstract

The application relates to the technical field of engineering coordination management, and discloses a kind of engineering full life cycle coordination management methods based on BIM.The method comprises obtaining the building information model data of engineering full life cycle and the progress monitoring data associated, to provide the data basis for coordination management.Based on stage decomposition strategy, according to the building information model data, single-stage dependency graph is constructed, and the correlation logic of elements such as tasks and resources in each stage is clearly presented.Through the cross-stage dependency integration method, the single-stage dependency graph is integrated into the full life cycle dependency graph, and the task connection and influence relationship across stages are clearly defined.Combined with data consistency verification and resource constraint review, conflict detection is carried out according to the full life cycle dependency graph, and potential data conflicts and resource conflicts are identified in advance.Based on the progress fluctuation analysis mechanism, the dynamic parameters are corrected according to the conflict detection results, and finally the full life cycle coordination management report is generated.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of engineering collaborative management, in particular to a BIM-based engineering full life cycle collaborative management method. BACKGROUND

[0002] In the field of modern engineering construction, engineering full life cycle management involves multiple stages such as planning, design, construction, and operation and maintenance, covers multiple subjects such as construction units, design institutions, construction enterprises, and supervision units, involves various types of data, including building model data, progress plan data, resource allocation data, and quality detection data. With the continuous expansion of engineering scale and the improvement of technical complexity, the traditional engineering management mode gradually exposes many problems. Under the traditional management mode, each participant often works based on their own information system, and the data is stored in different platforms or files, lacking a unified integration and sharing mechanism. The building information model data in the design stage is often limited to the design link and is difficult to directly provide effective support for the progress management of the construction stage; the progress monitoring data generated in the construction process is also difficult to be fed back to the design stage for optimization and adjustment, resulting in information islands between stages.

[0003] The task dependency relationship of each stage of the project is complex, not only there are task connection problems within the stage, but also there are task association across stages. For example, changes in the design scheme may directly affect the construction progress plan, and resource shortages in the construction process may react to the adjustment of material selection in the design stage. However, in the traditional management, these dependency relationships are often sorted out manually or recorded in simple tables, making it difficult to fully and accurately present the logical association between tasks. When the engineering scale is large, the manual sorting method is prone to omissions, leading to unclear dependency relationships, and thus causing poor task connection, resource allocation conflicts, and other problems.

[0004] Progress fluctuations are inevitable in the implementation process of the project, such as material supply delay, weather factors, design changes, etc., which will have a chain reaction on subsequent tasks. Under the traditional management mode, the response to progress fluctuations often depends on the experience of management personnel, lacking a systematic analysis and adjustment mechanism based on data. Due to the lack of effective integration of full life cycle data and accurate grasp of dependency relationships, conflict detection is often a passive response after the problem occurs, making it difficult to identify potential risks in advance, leading to frequent delays in project progress and increased costs. This decentralized and experiential management mode cannot meet the needs of modern engineering for efficient collaboration and precise control, and there is an urgent need for a collaborative management method that can integrate full life cycle data, clearly sort out dependency relationships, and provide early warning and dynamic adjustment of conflicts. SUMMARY

[0005] The present application aims to provide a BIM-based engineering full life cycle collaborative management method to solve the problems raised in the background art.

[0006] To achieve the above-mentioned purpose, the present application provides a BIM-based engineering full life cycle collaborative management method, which comprises:

[0007] In the building information model platform environment, the building information model data of the engineering full life cycle and the associated progress monitoring data are obtained;

[0008] Based on the stage decomposition strategy, a single-stage dependency graph is constructed according to the building information model data;

[0009] Based on the cross-stage dependency integration method, the single-stage dependency graph is integrated to obtain a full life cycle dependency graph;

[0010] Based on data consistency verification and resource constraint review, conflict detection is performed according to the full life cycle dependency graph;

[0011] Based on the progress fluctuation analysis mechanism, dynamic parameter correction is performed according to the conflict detection result, and a full life cycle collaborative management report is generated.

[0012] Preferably, the stage decomposition strategy is used to construct a single-stage dependency graph according to the building information model data, which comprises:

[0013] The building information model data is parsed to extract design stage data elements, construction stage data elements and operation and maintenance stage data elements;

[0014] Control dependency analysis is performed on the design stage data elements to obtain a design stage control dependency subgraph;

[0015] Data dependency analysis is performed on the design stage data elements to obtain a design stage data dependency subgraph;

[0016] Control dependency analysis is performed on the construction stage data elements to obtain a construction stage control dependency subgraph;

[0017] Data dependency analysis is performed on the construction stage data elements to obtain a construction stage data dependency subgraph;

[0018] Control dependency analysis is performed on the operation and maintenance stage data elements to obtain an operation and maintenance stage control dependency subgraph;

[0019] Data dependency analysis is performed on the operation and maintenance stage data elements to obtain an operation and maintenance stage data dependency subgraph;

[0020] The design stage control dependency subgraph and the design stage data dependency subgraph are combined to form a design stage dependency graph;

[0021] Combining the construction phase control dependency subgraph and the construction phase data dependency subgraph forms a construction phase dependency graph;

[0022] Combining the operation and maintenance phase control dependency subgraph and the operation and maintenance phase data dependency subgraph forms an operation and maintenance phase dependency graph.

[0023] Preferably, the cross-phase dependency integration method integrates the single-phase dependency graphs to obtain a full life cycle dependency graph, including:

[0024] Identifying a phase completion event node in the design phase dependency graph and a phase start event node in the construction phase dependency graph;

[0025] Based on the dependency mapping rule, connecting the design phase completion event node to the construction phase start event node forms a cross-phase control dependency chain;

[0026] Based on the data flow tracking rule, linking the design phase data dependency subgraph and the construction phase data dependency subgraph forms a cross-phase data dependency chain;

[0027] Identifying a phase completion event node in the construction phase dependency graph and a phase start event node in the operation and maintenance phase dependency graph;

[0028] Connecting the construction phase completion event node to the operation and maintenance phase start event node extends the cross-phase control dependency chain;

[0029] Linking the construction phase data dependency subgraph and the operation and maintenance phase data dependency subgraph extends the cross-phase data dependency chain;

[0030] Integrating the cross-phase control dependency chain and the cross-phase data dependency chain generates a full life cycle dependency graph.

[0031] Preferably, the data consistency verification and resource constraint review based on the full life cycle dependency graph includes conflict detection, including:

[0032] Traversing the full life cycle dependency graph locates data source nodes and data sink nodes;

[0033] Comparing the data values of the data source nodes and the data sink nodes identifies data inconsistency points;

[0034] Extracting resource constraint declaration statements in the full life cycle dependency graph;

[0035] Identifying resource access points corresponding to the resource constraint declaration statements;

[0036] Based on the constraint reasoning method, a resource constraint verification model is constructed;

[0037] The resource constraint verification model is applied to detect missing errors between the resource constraint declaration statement and the resource access point.

[0038] Based on the path analysis of the full life cycle dependency relationship diagram, the violation points of the resource constraint declaration statement are identified.

[0039] The data inconsistency points, missing errors and violation points are aggregated to form a conflict detection result.

[0040] Preferably, the progress fluctuation analysis mechanism is based on the conflict detection result to perform dynamic parameter correction, including:

[0041] Obtain multiple monitoring time signals in the progress monitoring data, and calculate the time offset value between adjacent monitoring time signals.

[0042] Divide the monitoring time signals into multiple time window units, and analyze the signal fluctuation characteristics in each time window unit.

[0043] Based on the signal fluctuation characteristics and the time offset value, determine the frequency interference probability of each time window unit.

[0044] According to the frequency interference probability distribution, calculate the progress nonlinear error value.

[0045] Based on the progress nonlinear error value, adjust the progress control parameters, and apply the adjusted progress control parameters to perform dynamic parameter correction.

[0046] Preferably, the method further includes an initialization process based on a template library, including:

[0047] Construct an engineering template library, wherein the engineering template library contains multiple engineering category templates, and each engineering category template is associated with a stage flowchart.

[0048] Merge the stage flowcharts of the same engineering category templates to form an integrated stage flowchart.

[0049] Parse the function requirement description and the process requirement description input by the user, select the integrated stage flowchart based on the function requirement description, extract the basic stage flowchart based on the process requirement description, mark the to-be-modified nodes in the basic stage flowchart, and obtain the complete stage flowchart after modifying the to-be-modified nodes.

[0050] Based on the node verification model, the complete stage flowchart is subjected to node review, and abnormal nodes in the node review are identified and a risk prompt is generated.

[0051] Preferably, the merging of the stage flowcharts of the same engineering category templates to form the integrated stage flowchart includes:

[0052] The node level number and data flow direction in the stage flowchart are identified, and the stage flowchart is divided into multiple level units based on the node level number;

[0053] The level unit number of the template in the same engineering category is selected as the main template;

[0054] The main node is marked in the main template, and the reference node is located in the other engineering category templates;

[0055] The node level unit of the other engineering category templates is aligned to the main template from the reference node as the starting point;

[0056] It is judged whether the main node and the aligned node meet the node fusion condition, if the node fusion condition is met, the aligned node is merged into the main node, if the node fusion condition is not met, the aligned node is added as a branch node;

[0057] All nodes are integrated to generate an integrated stage flowchart.

[0058] Preferably, the reference node is located, comprising:

[0059] The smallest level unit in the other engineering category templates is found, and the candidate node in the smallest level unit is extracted;

[0060] It is judged whether the candidate node and the main node meet the node fusion condition; if the node fusion condition is met, the candidate node is determined as the reference node; if the node fusion condition is not met, the candidate node is continuously extracted in the other level units;

[0061] The judgment is repeated until the reference node is located.

[0062] Preferably, the basic stage flowchart is extracted based on the process requirement description, comprising:

[0063] The process requirement description is analyzed to obtain the starting node and the terminal node of the requirement flowchart;

[0064] The top node corresponding to the starting node in the integrated stage flowchart is matched; the bottom node corresponding to the terminal node in the integrated stage flowchart is matched; the top node and the bottom node are taken as the endpoints to generate multiple candidate flowcharts;

[0065] The node similarity of the requirement flowchart and each candidate flowchart is calculated, and the candidate flowchart with the largest node similarity is selected as the basic stage flowchart.

[0066] Preferably, the node similarity of the requirement flowchart and each candidate flowchart is calculated, comprising:

[0067] The feature label of the requirement flowchart node is extracted to generate a feature hash value of the feature label;

[0068] Traverse the adjacent nodes of the demand flowchart node, and perform difference operation on the feature hash values of the demand flowchart node and its adjacent nodes to obtain a demand tag value;

[0069] Traverse the adjacent nodes of the candidate flowchart node, and perform difference operation on the feature hash values of the candidate flowchart node and its adjacent nodes to obtain a candidate tag value;

[0070] Compare the demand tag value and the candidate tag value, and count the number of same tag values;

[0071] Calculate the node similarity based on the number of same tag values.

[0072] Compared with the prior art, the beneficial effects of the present application are:

[0073] The BIM-based engineering full life cycle collaborative management method breaks the situation of scattered storage of data in each stage and information islands in traditional management by constructing a unified building information model platform environment, centrally acquiring and integrating building information model data and associated progress monitoring data in the full life cycle of the project. Multiple participating subjects can work based on the same data basis, avoiding the collaborative obstacles caused by inconsistent data sources and non-uniform formats, making the information transmission in each stage of design, construction and operation more smooth, and reducing the deviation and loss in the information transmission process.

[0074] The construction of a single-stage dependency graph based on a stage decomposition strategy can systematically sort out and visually present the correlation between elements such as tasks, resources and processes within each stage. In this way, the task connection logic within each stage is clearly displayed, and participating subjects can intuitively grasp the sequence and mutual influence of various work within the stage, facilitating fine management within the stage, timely detection of unreasonable task arrangement within the stage, and optimization of resource allocation and progress planning within the stage.

[0075] The application of the cross-stage dependency integration method effectively solves the problem of loose connection between stages in traditional management. By integrating the single-stage dependency relationship graph to form a full life cycle dependency relationship graph, the cross-stage correlation between early design and later construction, construction and operation, etc. is systematically sorted out, so that the influence of design stage decisions on construction feasibility, the role of construction process on operation convenience, etc. Cross-stage correlation is clear. This helps to fully consider the needs of subsequent stages in the early stages of the project, reduces the problems of rework and changes caused by poor stage connection, and realizes the organic connection of work in each stage.

[0076] The conflict detection in combination with data consistency verification and resource constraint review can comprehensively check the whole life cycle dependency graph from two dimensions of data accuracy and resource feasibility. Through the data consistency verification, the contradiction and deviation between data in different stages can be identified in time to ensure the accuracy of the management basis. Through the resource constraint review, potential problems such as imbalance between supply and demand of resources and conflict in resource allocation can be found in advance to avoid the progress stagnation caused by resource problems in the engineering implementation process. The active conflict detection mode changes the passive situation of problem lagging behind in the traditional management and creates conditions for early problem solving.

[0077] The dynamic parameter correction based on the progress fluctuation analysis mechanism makes the management process have the ability to adapt to the dynamic changes of the project. The progress deviation and external environment changes and other fluctuation factors in the engineering implementation can be captured and analyzed in time by the mechanism to affect the subsequent work, and then the related parameters are adjusted. The dynamic adjustment mechanism makes the management strategy flexible and optimized according to the actual situation, avoids the management failure caused by rigid plan, and guarantees the flexibility and adaptability of the whole life cycle management of the project. The whole life cycle collaborative management report generated by the management process systematically summarizes the data, dependency relationship, conflict processing, parameter adjustment and other information, provides an intuitive and comprehensive reference for engineering management decision, and promotes the standardization and transparency of the management process. BRIEF DESCRIPTION OF DRAWINGS

[0078] Figure 1 The working principle diagram of the BIM-based whole life cycle collaborative management method of the project is described.

[0079] Figure 2 The flowchart of the whole life cycle dependency graph integration is described.

[0080] Figure 3 The flowchart of the dynamic parameter correction based on the progress fluctuation analysis mechanism is described.

[0081] Figure 4 The flowchart of the same kind of engineering category template stage flowchart merging to form an integrated stage flowchart is described. DETAILED DESCRIPTION

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

[0083] Please refer to Figure 1The application provides a BIM-based engineering whole life cycle collaborative management method, which comprises the following steps:

[0084] Obtain building information model data of the whole life cycle of the project and associated progress monitoring data. The building information model data covers relevant information in the design stage, construction stage and operation and maintenance stage, and the progress monitoring data includes real-time signals of each monitoring point in the project timeline. Based on the stage decomposition strategy, the building information model data is analyzed, and a single-stage dependency graph is constructed. The stage decomposition strategy divides the whole life cycle into three independent stages of design, construction and operation and maintenance. The construction process involves identifying the internal dependency relationship of each stage to ensure that the data and control flow within the stage are clearly expressed. The single-stage dependency graph is processed by using a cross-stage dependency integration method. The integration process connects the nodes of different stages to form a whole life cycle dependency graph. The whole life cycle dependency graph expresses the continuity of the control flow and data flow between stages in a graphical manner. Subsequently, conflict detection is performed based on data consistency verification and resource constraint review. The data consistency verification compares the values of the data source nodes and the data sink nodes, and the resource constraint review evaluates whether the resource access points and the declared constraint conditions are consistent. The conflict detection traverses the path of the whole life cycle dependency graph to locate potential problem points. The conflict detection result is used as input to enable a progress fluctuation analysis mechanism for dynamic parameter correction. The progress fluctuation analysis mechanism processes the progress monitoring data, calculates the time offset value and the frequency interference probability, and adjusts the progress control parameters. The output of the dynamic parameter correction is used to generate a whole life cycle collaborative management report. The report integrates the dependency graph, the conflict detection result and the correction parameters.

[0085] Example 1: see Figure 2 The single-stage dependency graph construction and cross-stage integration process are performed in the building information model platform environment. Analyzing the building information model data involves extracting design stage data elements, construction stage data elements and operation and maintenance stage data elements. The design stage data elements include component geometric parameters, spatial topological relationships, material physical properties and design specification constraints; the construction stage data elements cover process logical sequence, equipment scheduling instructions, labor allocation schemes and safety condition restrictions; and the operation and maintenance stage data elements include equipment operation threshold, maintenance cycle parameters, energy consumption monitoring indicators and fault diagnosis rules. Control dependency analysis is performed on the design stage data elements: identifying the conditional constraint relationship between parent nodes and child nodes in the design decision sequence, such as the scheme design node as the control premise of the preliminary design node; analyzing the logical jump rules between nodes, and outputting the design stage control dependency subgraph represented by weighted directed edges. At the same time, data dependency analysis is performed on the design stage data elements: tracking the parameter modification transmission path, such as the change of material strength affecting the structure calculation node; identifying the data version update chain, and outputting the design stage data dependency subgraph marked with data flow direction.

[0086] Control dependency analysis on construction phase data elements: decompose parallel and serial relationships in the process network, locate critical path nodes; label task delay tolerance threshold, generate construction phase control dependency subgraph with time attribute. Construction phase data dependency analysis process maps parameter input and output: extract concrete mixing parameter dependency chain from quality detection node to pouring construction node; identify real-time update path of resource consumption data, output construction phase data dependency subgraph with data version stamp. Operation and maintenance phase control dependency analysis focuses on task triggering mechanism: establish conditional association between device operating state node and maintenance instruction node; map multi-system collaborative control rules, output operation and maintenance phase control dependency subgraph containing event response logic. Operation and maintenance phase data dependency analysis processes monitoring data flow: associate sensor reading node with energy efficiency evaluation node calculation path; track fault code data transmission chain from generation to diagnosis report, output operation and maintenance phase data dependency subgraph labeled with data checkpoint.

[0087] When combining single-stage dependency subgraphs, design phase control dependency subgraph and data dependency subgraph are fused through node superposition rules: align the same entity nodes, and when control edges and data edges coexist, prefer to retain the control path; check conflicting edge types and apply conflict resolution strategies. Construction phase subgraph combination uses time axis alignment mechanism: synchronize control and data nodes based on process start time; map resource allocation data edges to corresponding task control nodes. Operation and maintenance phase subgraph merging is based on event sequence integration: associate monitoring data input edges with maintenance task control nodes; bind historical data query paths at device state change nodes. Form design phase dependency relationship graph, construction phase dependency relationship graph and operation and maintenance phase dependency relationship graph as independent views.

[0088] Cross-stage dependency integration starts with event node identification. Mark phase completion event nodes in the design phase dependency relationship graph: including construction drawing approval completion node, completion model delivery node. Label phase start event nodes in the construction phase dependency relationship graph: such as construction permit taking effect node, earth excavation starting node. Establish control connection according to dependency mapping rules: when design delivery node and construction permit node meet time continuity constraints, add cross-stage control edges and label handover conditions. Data flow tracking rules perform parameter transfer verification: traverse the terminal output nodes of the design phase data dependency subgraph, locate the same name input nodes in the construction phase data dependency subgraph, establish data inheritance edges and add version compatibility check conditions. Thus, cross-stage control dependency chain (design→construction) and cross-stage data dependency chain (design model parameters→construction application parameters) are formed.

[0089] The extension phase integrates the construction coverage into the operation and maintenance phase. The construction phase relies on the relationship diagram to define the phase completion event node: such as the sub-item engineering acceptance pass node, the equipment debugging completion node. The operation and maintenance phase relies on the relationship diagram to locate the phase start event node: such as the system initial operation node, the maintenance plan activation node. The cross-phase control dependency chain is extended: link the construction acceptance node to the operation and maintenance start node, and the edge attribute contains the acceptance result status code. The cross-phase data dependency chain is extended: capture the equipment installation parameters of the construction phase data dependency subgraph, match the benchmark operation parameter node of the operation and maintenance phase data dependency subgraph, construct the data synchronization edge and set the threshold check rule. Thus, the three-phase control dependency chain and data dependency chain covering design→construction→operation are formed.

[0090] The full life cycle dependency relationship diagram generates a chain fusion operation. The node rearrangement of the cross-phase control dependency chain: integrate the design completion event, the construction start event, the construction completion event and the operation start event in chronological order; the branch paths in the associated chain are merged through virtual convergence nodes. Topology integration of the cross-phase data dependency chain: merge the same parameter nodes to eliminate redundancy; apply version arbitration strategy to conflicting data sources. The final graph structure is a multi-layer directed network: the top view shows the three-phase key event flow, and the bottom view expands the detailed control and data path; all dependency edges carry type identifiers, condition constraint expressions and historical version trace indexes. This graph serves as a unified input model for conflict detection and progress correction, its nodes contain building component instances, process tasks, operation and maintenance activities, etc. The edge relationship covers time constraints, data transmission, resource binding and other multi-dimensional dependencies.

[0091] The control dependency analysis module adopts a topological sorting algorithm based on directed acyclic graph: analyze the input and output relationship of each node in the design phase, construct a non-cyclic constraint model; identify the key control path and its weight value. The data dependency analysis module implements dynamic data flow tracking: generate a data version tree according to the component attribute change record in the design model; in the construction model, match the related parameter update event through the timestamp. The event node mapping link deploys a semantic matching engine: automatically identifies the "structure design completion" label in the design model, associates the "reinforcing engineering start" label in the construction model and checks its logical interval threshold. The data chain integration process calls the graph database operation: link the outlet node of the design model and the inlet node of the construction model in Neo4j through Cypher statement, perform attribute consistency check and establish permanent relationship.

[0092] Conflict pre-detection mechanism is activated when the whole lifecycle graph is generated: scanning the constraint conditions of cross-stage connection edges (e.g. “construction permit takes effect when design model version > 2.0”), automatically marking the potential conflict edges that do not meet the conditions. The implementation process adopts an incremental update strategy: when new operation and maintenance sensor data is added, only the monitoring nodes need to be added in the operation and maintenance data dependency subgraph, and the system automatically traces back the associated construction and installation parameter nodes based on the established cross-stage links.

[0093] Embodiment 2: refer to Figure 3 The conflict detection and dynamic parameter correction process is performed in the whole lifecycle dependency graph environment. The data consistency verification link traverses the dependency graph topology to locate the data source nodes and data sink nodes. The data source nodes include the material specification definition nodes in the design stage, the process input parameter nodes in the construction stage, and the initial configuration nodes in the operation and maintenance stage; the data sink nodes include the component installation nodes in the construction stage, the equipment checking nodes in the operation and maintenance stage, etc. The node positioning adopts a depth-first search strategy: starting from the design data source, it traces the downstream consumption nodes layer by layer; and marks the cross-stage data flow endpoints as key data sinks. The comparison process extracts the value difference types of the data source node attribute values and the values carried by the data sink nodes, identifies the application semantic analysis engine: distinguishes between unit inconsistency (MPa and psi), version conflict (v1.1 and v2.0 standard), and range out-of-bounds (design temperature tolerance 100°C and actual demand 150°C). The data inconsistency points are encoded as triple records, including the abnormal position (construction layer slab node), the difference type (version conflict), and the original value and received value.

[0094] The resource constraint review extracts resource constraint declaration statements from the dependency graph metadata. The declaration statements are embedded in the node annotation field, and its structure is “resource type_constraint operator_threshold” mode: for example, “number of cranes ≤ 3” and “daily labor input < 500 workdays”. The resource access points are identified by analyzing the task node operation logs: capturing the “device call record” field of the concrete pouring node in the construction stage and the “labor input duration” attribute of the equipment maintenance node in the operation and maintenance stage. The constraint declaration and access point establish a mapping relationship: the “number of cranes” declaration is bound to all resource access points related to lifting tasks. The resource constraint verification model is built using first-order logic rules: defining that the resource usage must meet the declared threshold (if the usage > threshold, it is a violation) and that the access point must be covered by the declaration (if there are undeclared access points, it is omitted). The model loads all constraint rules to generate a verification matrix.

[0095] The application verification model is executed to perform detection: missing error identification traverses the resource access point set, and marks the access points not covered by any declaration. The violation point detection is performed in the dependency graph path analysis: from the construction start node, the resource consumption is simulated, and when the cumulative manual input of a certain path reaches the "single-day manual" threshold, the subsequent nodes are marked as violations. The path analysis uses the critical path method extension, and when parallel paths trigger resource competition, the conflict points of high resource demand paths are preferentially marked. The aggregated conflict results create a global conflict view: data inconsistency points are overlaid with red flashing icons on the three-dimensional model location; resource omission errors generate an uncovered equipment list table; violation points output resource overrun time interval reports. The view is integrated into the navigation tree of the collaborative management platform.

[0096] After the progress fluctuation analysis is started, the system accesses the progress monitoring data stream. Multiple monitoring time signals are obtained: including design drawing submission timestamps, actual start and end times of construction procedures, and operation and maintenance system activation time points. The time offset value of adjacent monitoring times is calculated: when the "pile foundation construction plan completion time" is T1 and the "actual completion time" is T2, the offset value DT = T2-T1. A positive value indicates a delay, and a negative value indicates an advance. The time window unit is divided using a dynamic segmentation strategy: the design stage, main construction stage, and decoration construction stage are used as natural windows, and the sub-windows are split by week granularity. The signal fluctuation characteristics in each time window unit are analyzed: the construction stage concrete pouring procedure monitoring signal sequence is extracted, and the amplitude parameter (actual duration and planned maximum deviation ± 20%) and frequency characteristic (procedure delay event aggregation occurrence frequency) are calculated.

[0097] The frequency interference probability calculation combines time offset and fluctuation characteristics: when there are more than three delay events with an amplitude exceeding 15% in a certain week time window, the window is marked as a high fluctuation area. Based on the historical engineering database, a probability distribution model is trained, and the correlation between the location of the high fluctuation area and the delay amount is used to calculate the current engineering probability value. The progress nonlinear error value is calculated from the window probability: if the probability of four consecutive windows in a construction stage exceeds 80%, the error value of the stage is accumulated by the sum of the square of the window offset value; if the window probability is less than 30%, only the linear offset is accumulated. The progress control parameter adjustment strategy is: the buffer time coefficient is expanded according to the stage error value, and the error value E1 of the foundation construction stage triggers a buffer increment of 0.2E1. The task duration weight is adjusted according to the error distribution, and the weight of the steel structure installation task in the high probability delay area is increased to 1.5 times the planned value.

[0098] Dynamic parameter correction in 3D progress model: update time attributes of full life cycle dependency graph. Correction process includes: design stage node adds buffer time field, building scheme approval node adds buffer period ΔT1; construction node resets duration parameter, concrete curing node changes from original plan of 7 days to [5, 9] day interval; operation and maintenance node adjusts time-dependent constraints, and device commissioning node changes precondition from “3 days after completion” to “[1, 5] days after completion”. All correction operations generate version update logs, and the affected scope is marked synchronously: when the steel structure installation weight is corrected, the system automatically recalculates the subsequent decoration engineering path. When the final output collaborative management report is generated, the conflict detection result is displayed as a risk appendix, and the correction parameter is submitted as a main progress plan revision scheme.

[0099] In specific implementation, data consistency verification adopts multi-version snapshot comparison technology: obtain the steel bar specification parameters in design BIM model v3.2, and compare the differences in steel bar diameter fields of the same component in construction model v3.1. Resource constraint violation detection uses resource load simulator: load tower crane calling data in progress plan Gantt chart, when “tower crane serves 2F pouring and 5F material transportation simultaneously from 8:00 to 10:00 in the morning”, violation of “tower crane single task operation” statement generates violation report. Progress fluctuation analysis embeds time series decomposition algorithm: separate the trend deviation (deviation value continuously increases) caused by design change and the periodic fluctuation (2-day delay every week in rainy season) caused by weather influence. Parameter correction engine supports cascading update: when the main structure duration is corrected, the mechanical and electrical pre-burying node time constraint is automatically updated, and the operation and maintenance preparation period is delayed synchronously.

[0100] Embodiment 3: refer to Figure 4 The initialization process of the engineering template library starts from the construction of a structured storage system. The engineering template library adopts a graph database storage architecture, and the node types include engineering category template nodes, stage flowchart nodes and parameter configuration nodes. Each engineering category template node carries attribute fields: engineering type (residential / commercial / industrial), scale level (large / middle / small), structure form (frame / shear wall / steel structure). The stage flowchart node is stored in the form of a directed graph, and the edge attributes include flow conditions (such as “approval passed”) and node attribute records activity types (design review / construction briefing / operation and maintenance training). The parameter configuration node is associated with the material library (concrete grade library), equipment library (tower crane model library) and labor library (work type and work efficiency library).

[0101] When merging the stage flowcharts of the same engineering category template, the system executes a multi-level graph matching algorithm. The node level number in the parsed stage flowchart adopts a three-level coding system: L1 represents the stage layer (1-design / 2-construction / 3-operation and maintenance), L2 represents the professional layer (1.1 building / 1.2 structure / 1.3 electromechanical), and L3 represents the task layer (1.1.1 scheme design / 1.1.2 extension and preliminary design). The data flow direction identifier uses a directed edge with an arrow, and the edge weight value represents the flow probability (such as the construction drawing review pass rate of 92%). When dividing the level units, the L1 level is used as the main unit boundary, and the L2 level is used as the sub-unit grouping basis. The selection criteria for the main template include: the largest number of L3 nodes, the highest edge coverage rate, and the most complete parameter configuration. The main node marking rule focuses on the key path nodes, and in the residential template, the “foundation pit inspection” is marked as the construction main node, and in the commercial template, the “fire inspection” is marked as the control node.

[0102] The positioning reference node implements cross-template semantic similarity calculation. The candidate node extraction range is limited to the minimum level unit (L3), and the candidate set is generated by comparing node attributes. The judgment formula of the node fusion condition is:

[0103]

[0104] wherein represents the fusion matching degree threshold (set to 0.75), , , represent the weight coefficients of the name similarity, flow direction similarity, and parameter similarity (values are 0.4 / 0.3 / 0.3). The Levenshtein distance of the node name is calculated, the in-degree and out-degree ratio is compared, the parameter configuration overlap rate is evaluated, represents the target node of the main template, represents the edge set of the candidate node, represents the edge set of the main node, represents the edge set of the candidate node, represents the parameter configuration of the main node, represents the parameter configuration of the candidate node. When ≥0.75, node fusion is performed: the edge set of the reference node is merged into the main node, and the parameter value is taken as the weighted average (the main template weight is 60%). Otherwise, a branch node is created, and the branch path inherits the level coding of the original template and adds a branch identifier (such as 1.1.1.1).

[0105] The generation of the integrated stage flowchart is processed through topology optimization. After node fusion, loop detection is performed: when the "curtain wall design" node of the commercial template is fused with the "exterior window design" node of the residential template, it is checked whether there is a circular dependent path. When a loop is detected, node splitting is started, the main template node is retained as the main path, and the branch node is reconstructed as a parallel sub-path. The reconstruction of data flow direction follows the input-output consistency principle: the merged node inherits all input edges, and the output edges are split according to the probability weight (main path 80% / branch path 20%). The final integrated stage flowchart contains a mixed hierarchical coding system: the main path retains the original coding (1.1.1), the branch path extends the fourth level coding (1.1.1.1), and the cross-template shared node is marked as a blue highlighted node.

[0106] The user demand analysis module uses natural language processing technology. After the word segmentation processing of the functional requirement description, it is mapped to the engineering type feature vector: input "high-rise residential building with underground garage" is parsed as [engineering type: residential, height feature: high-rise, special item: underground garage]. The process requirement description extracts the key action chain through dependency syntax analysis: input "need to include steel structure deepening design phase" extracts [action: deepening design, object: steel structure, stage requirement: special phase]. The basic stage flowchart extracts the bidirectional graph search algorithm. In the integrated stage flowchart, the top node matching uses fuzzy query: the "start" of the demand description corresponds to all zero-in-degree nodes in the template; the bottom node matching applies target-oriented screening: "acceptance" type nodes are preferentially used as termination candidates. The candidate flowchart generation process implements the k-shortest path algorithm: set k=5 to obtain the first five possible paths, and the path scoring function considers the node matching degree (the frequency of demand keywords appearing in the node name) and edge continuity (the consistency of adjacent node specialties).

[0107] The difference-driven labeling strategy is implemented for the nodes to be modified. The node modification type is divided into three categories: parameter adjustment (concrete strength from C30 to C35), structure addition (add "BIM model lightweight" node), and logic reconstruction (change the serial "design-review" to parallel "design+pre-review"). Parameter adjustment nodes are labeled in yellow and require filling in the modification value field; structure addition nodes are labeled in red and require defining upstream and downstream connection relationships; logic reconstruction nodes are labeled in purple and require specifying parallel control conditions. The node verification model uses a combination of rule engine and machine learning: hard rule checking includes node input-output integrity and parameter value effective range; soft rule predicts the node abnormal probability through the classifier trained by historical engineering, and outputs the risk prompt according to the confidence level.

[0108] The release of the complete stage flowchart implements the version control protocol. Each modification generates an incremental version number (v3.1.2→v3.1.3), and the version log records the modification node ID, the change type, and the impact range assessment. The impact range assessment is achieved through graph traversal: when the “pile foundation detection” node is modified, all subsequent nodes that depend on the detection result are automatically marked. The template library update adopts a two-phase commit mechanism: first write to the temporary storage area for integrity check, and then update the main database and all cache copies after synchronization. During implementation, the semantic similarity calculation module loads the field dictionary (building terminology library) to improve matching accuracy; the node verification model dynamically loads the latest specification provisions as the verification benchmark during runtime. The version control system integrates a difference visualization tool, which displays the spatial impact range of the modified node in the BIM model through a three-dimensional comparison view.

[0109] Example 4: Engineering category template merging operation is taken as an example of integrating residential and commercial templates. The main template selects the residential engineering category template, with 28 hierarchical units. The main node is marked as the critical path node set: “foundation excavation” (level L2.1), “main body construction” (L2.3), and “interior decoration delivery” (L2.5). The smallest hierarchical unit (L3 level) is found in the commercial engineering category template, and the candidate nodes are extracted as shown in Table 1.

[0110]

[0111] The reference node is positioned and hierarchical traversal is performed: starting from the L3.1 unit and scanning layer by layer. When the L3.2 unit “deep foundation construction” node is detected, its fusion condition with the main node “foundation excavation” is verified. The node name similarity calculation uses the Levenshtein distance algorithm, with a similarity value of 0.82 (threshold value 0.75); in parameter configuration comparison, “excavation depth ≤ 5m” in the residential template is compatible with “support depth ≤ 5.2m” in the commercial template; data flow direction identification check shows that the in / out degree ratio deviation is <10%. The comprehensive judgment meets the fusion condition, and it is confirmed that “deep foundation construction” is the reference node.

[0112] The node alignment operation is carried out based on the reference node to map the hierarchical units. The node set (earthwork transportation, support pile detection) contained in the L3.2 unit of the commercial template is shifted to the lower part of the L2.1 unit of the residential template. After alignment, the fusion condition of the main node “foundation excavation” and the aligned node “earthwork transportation” is checked: the node function attribute (earthwork operation) consistency is passed, but there is a conflict in the resource constraint field (residential template “daily transportation capacity 200m³” vs commercial template “300m³”). The conflict handling protocol is triggered, and “earthwork transportation” is added as a branch node and the commercial template constraint value is retained, and the branch path identifier is expanded to L2.1.1.

[0113] After the L3.5 unit locates the "curtain wall installation" reference node, alignment with the main node "interior delivery" is performed. Node property inspection shows that the process standard is consistent (perpendicularity tolerance ± 3 mm), but the commercial template adds a "wind pressure test" sub-node. Since the main node has no corresponding test process, the "wind pressure test" node is mounted as a branch node L2.5.1, and inherits the data flow identification of the commercial template (test report -> acceptance node). After integration, an integrated stage flowchart is generated, containing 26 nodes of the residential main path and 9 nodes of the commercial branch path, with branch nodes marked in green dashed boxes.

[0114] Flow requirement description parsing example: input text "need to strengthen foundation treatment process, skip the fine decoration stage". The functional requirement description parser identifies the keyword "foundation treatment strengthening" mapped to the "foundation reinforcement" label in the node type library, and the "skip fine decoration" label excludes the termination node instruction. The top node matching performs a fuzzy query: "start" in the requirement corresponds to all zero-in-degree nodes in the integrated graph (regular construction preparation, geological prospecting). After filtering according to the exclusion instruction, the top node is locked as "geological prospecting". When matching the termination node, the "fine decoration" related nodes are shielded, and the focus of matching is shifted to "completion acceptance" and "equipment debugging", and finally "equipment debugging" is selected as the bottom node.

[0115] The candidate flowchart generation applies a variant of Dijkstra's algorithm. Taking the top node "geological prospecting" as the starting point and the bottom node "equipment debugging" as the target, four paths are generated by traversing the integrated stage flowchart:

[0116] Geological prospecting -> foundation reinforcement -> foundation acceptance -> main body construction -> equipment debugging; Geological prospecting -> foundation reinforcement -> support pile detection -> equipment debugging (illegal path); Geological prospecting -> earthwork transportation -> main body construction -> equipment debugging; Geological prospecting -> main body construction -> equipment debugging (shortest path).

[0117] Requirement flowchart feature extraction performs topological decomposition: "strengthen foundation treatment" is mapped to the core path node "foundation reinforcement", and its adjacent nodes should include support measures. During node similarity calculation, the "foundation reinforcement" node of path 1 has an adjacent "support pile detection" (demand label value 150), and the same-named node of path 3 has an adjacent "earthwork balance" (label value 120). Label difference value comparison shows that path 1 has the highest matching degree (deviation < 10%), and is selected as the basic stage flowchart.

[0118] The process of marking nodes to be modified detects two abnormalities:

[0119] The "foundation reinforcement" node of the basic stage flowchart is missing parameters (no reinforcement depth value); The "support pile detection" node has an illegal direct connection with "equipment debugging".

[0120] Yellow label is added to the parameter missing node, requiring to fill in the depth range; illegal connection edge is marked purple, which needs to be re-bound to the intermediate node "foundation acceptance". The node verification model loads the building construction specification clause library, and the hard rule check finds that "the default value of foundation reinforcement depth violates GB50007 specification clause 5.4.3", and generates a risk prompt with the specification text. The final output is a complete stage flowchart, with the newly added foundation reinforcement depth parameter "4.5-6.0m", and the reconstructed connection path is support pile detection → foundation acceptance → main construction → equipment commissioning.

[0121] In example 5, the node similarity calculation process is performed between the demand flowchart and the candidate flowchart. The feature label extraction covers the full attribute set of the node: the type label records the node category, the role label marks the responsible party, and the data label identifies the core parameter. The feature hash value generation adopts a double-channel processing mechanism: for discrete attributes, the MD5 algorithm is used to generate a 128-bit hash code, and the first 16 bits are taken; for numerical attributes, they are first standardized to the [0, 100] interval, and then converted to hexadecimal encoding to calculate the hash value. For the demand node "steel structure welding", the type label "construction process" generates hash H1, the role label "welder team" generates hash H2, and the parameter label "welding seam grade II" generates hash H3, which are concatenated into the complete feature hash.

[0122] The demand label value calculation performs multi-level adjacent node scanning. The traversal process starts from the target node, and the first level of adjacent nodes includes all direct predecessors and successors. For each adjacent node, perform feature hash difference operation: compare the feature hash of the "support" node with the adjacent "dewatering construction" node, and calculate the Hamming distance bit by bit. The difference operation result is converted into an 8-bit binary vector, with bit 1 indicating bit difference and bit 0 indicating bit consistency. The vector sequence is ordered by the level of adjacent nodes: the direct predecessor node vector is placed in the high bit, and the direct successor node vector is placed in the low bit. The final synthesized demand label value is represented as a 32-bit integer, with the first 16 bits encoding the predecessor difference pattern and the last 16 bits encoding the successor difference pattern.

[0123] The candidate label value generation adopts the same topology rule. Locate the same name node in the candidate flowchart, and retrieve its first-order adjacent node set. When there are multiple instances of the same name node, prefer the node with the highest position similarity (the smallest depth deviation from the demand node in the flowchart). For the "soil excavation" node (predecessor) and the "support acceptance" node (successor) adjacent to the candidate node, calculate the feature hash Hamming distance and generate the difference vector. The binary vector merging strategy is consistent with the demand label: the predecessor difference vector occupies the high 16 bits of the synthesized value, and the successor difference vector occupies the low 16 bits. If the candidate node has additional adjacent nodes (such as "monitoring point setting" in the branch path), the node difference vector is incorporated into the high byte in a weighted manner, with the weight coefficient determined by the path criticality.

[0124] The tag value comparison implements bit-level synchronous analysis. The requirement tag value R and the candidate tag value C are loaded into the comparison register, and the comparison block is divided according to the preset bit width. 32-bit data is divided into 4 8-bit segments, and each segment independently performs a bitwise XOR operation. The bit position of the XOR result 0 is marked as a matching bit, and the bit position of the result 1 is marked as a mismatching bit. When counting the number of the same tag values, only when all bits in the entire 8-bit segment match, the segment will be counted as an effective matching segment. The invalid processing rules include: if the high bits in the mismatching segment are matched for more than 4 consecutive bits, the segment can be counted as a partial matching value by halving; the segment with undefined bits (such as the candidate graph missing the subsequent node resulting in all 0s in the low bits) is processed as a mismatching segment.

[0125] The node similarity quantization conversion applies a segmented accumulation strategy. The number of effective matching segments is converted into a reference score (20 points per segment); the partial matching segment is converted into a score according to the matching bit ratio (8 points for 4 consecutive matching bits); and the remaining mismatching segment is not scored. The total score S is up to 100 points, and the similarity conversion formula is expressed in percentage. When multiple candidate paths have the same highest score, the secondary evaluation index is started: the consistency of the path depth where the node is located is calculated (the "support" node depth in the requirement graph L=3, and the deviation is reduced by 1% when the candidate graph L=2), and the final similarity value is adjusted. The similarity result is used to sort the candidate flowchart sequence, and the path with a matching degree of more than 75% is marked as a high matching path and delivered to the user for review.

[0126] In specific implementation, the feature hash calculation engine adopts a pipeline architecture. In the attribute discretization processing stage: the text type label is input into the hash generator after stem extraction and synonym replacement; the numerical type label is converted to the preset interval through the normalization mapping table. Adjacent node traversal is optimized for parallel processing: index database is deployed to accelerate query, and Redis cache is used to store the nearest neighbor node set. The difference operation hardware uses a bit processor (such as FPGA) to perform vector bit operations, and the single node processing delay is controlled within 5 milliseconds. The node depth deviation compensation algorithm loads the historical engineering statistical model, and the underground structure node depth tolerates ±1 layer, and the ground structure tolerates ±2 layers. The implementation verification link sets up conflict detection: when the "equipment acceptance" node in the requirement tag is only associated with a single subsequent node, and the candidate graph has multiple branched acceptance paths, the system automatically identifies it as a potential topology expansion point and prompts the designer for confirmation. The similarity report output is an interactive heat map, which highlights the difference nodes and neighborhoods in the three-dimensional flow view.

[0127] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting; it is not intended to exclude myriad other embodiments of the present application that other inventors can develop based on the same general inventive concepts embodied by the described embodiments. That is, although the present application is described in terms of particular embodiments and illustrative figures, it should be apparent that the scope of the present application is not limited to these specific embodiments.

[0128] While the embodiments of the application have been shown and described herein, it will be understood by those skilled in the art that many changes, modifications, substitutions and alterations to these embodiments can be made without departing from the principles and spirits of the application, and it is intended that the scope of the application be limited solely by the scope of the appended claims and the equivalents thereof.

Claims

1. A BIM-based engineering full life cycle collaborative management method, characterized in that, The method comprises: In a building information model platform environment, obtaining building information model data and associated progress monitoring data of the whole life cycle of a project; Based on a stage decomposition strategy, constructing a single-stage dependency graph according to the building information model data; Based on a cross-stage dependency integration method, integrating the single-stage dependency graph to obtain a whole life cycle dependency graph; Based on data consistency verification and resource constraint review, performing conflict detection according to the whole life cycle dependency graph; Based on a progress fluctuation analysis mechanism, performing dynamic parameter correction according to the conflict detection result to generate a whole life cycle collaborative management report; The stage decomposition strategy comprises: Parsing the building information model data to extract design stage data elements, construction stage data elements and operation and maintenance stage data elements; Performing control dependency analysis on the design stage data elements to obtain a design stage control dependency subgraph; Performing data dependency analysis on the design stage data elements to obtain a design stage data dependency subgraph; Performing control dependency analysis on the construction stage data elements to obtain a construction stage control dependency subgraph; Performing data dependency analysis on the construction stage data elements to obtain a construction stage data dependency subgraph; Performing control dependency analysis on the operation and maintenance stage data elements to obtain an operation and maintenance stage control dependency subgraph; Performing data dependency analysis on the operation and maintenance stage data elements to obtain an operation and maintenance stage data dependency subgraph; Combining the design stage control dependency subgraph and the design stage data dependency subgraph to form a design stage dependency graph; Combining the construction stage control dependency subgraph and the construction stage data dependency subgraph to form a construction stage dependency graph; Combining the operation and maintenance stage control dependency subgraph and the operation and maintenance stage data dependency subgraph to form an operation and maintenance stage dependency graph; The cross-stage dependency integration method comprises: Identifying stage completion event nodes in the design stage dependency graph and identifying stage start event nodes in the construction stage dependency graph; Based on dependency mapping rules, connecting the design stage completion event nodes to the construction stage start event nodes to form a cross-stage control dependency chain; Based on data flow tracking rules, linking the design stage data dependency subgraph and the construction stage data dependency subgraph to form a cross-stage data dependency chain; Identifying stage completion event nodes in the construction stage dependency graph and identifying stage start event nodes in the operation and maintenance stage dependency graph; Connecting the construction stage completion event nodes to the operation and maintenance stage start event nodes to extend the cross-stage control dependency chain; Linking the construction stage data dependency subgraph and the operation and maintenance stage data dependency subgraph to extend the cross-stage data dependency chain; Integrating the cross-stage control dependency chain and the cross-stage data dependency chain to generate a whole life cycle dependency graph; The progress fluctuation analysis mechanism comprises: Obtaining multiple monitoring time signals in the progress monitoring data, and calculating time offset values between adjacent monitoring time signals; The monitoring time signal is divided into multiple time window units, and signal fluctuation characteristics in each time window unit are analyzed; Based on the signal fluctuation characteristics and the time offset value, the frequency interference probability of each time window unit is determined; According to the frequency interference probability distribution, the progress nonlinear error value is calculated; Based on the progress nonlinear error value, the progress control parameter is adjusted, and the adjusted progress control parameter is applied for dynamic parameter correction. 2.The BIM-based engineering whole life cycle collaborative management method according to claim 1, characterized in that, The conflict detection based on the data consistency verification and the resource constraint review includes: Traverse the full life cycle dependency graph to locate the data source node and the data sink node; Compare the data values of the data source node and the data sink node to identify data inconsistency points; Extract resource constraint declaration statements from the full life cycle dependency graph; Identify the resource access points corresponding to the resource constraint declaration statements; Based on the constraint reasoning method, a resource constraint verification model is constructed; Apply the resource constraint verification model to detect missing errors between the resource constraint declaration statements and the resource access points; Based on the path analysis of the full life cycle dependency graph, identify the violation points of the resource constraint declaration statements; Aggregate the data inconsistency points, missing errors and violation points to form the conflict detection result. 3.The BIM-based engineering whole life cycle collaborative management method according to claim 1, wherein, The method further includes an initialization process based on a template library, including: Constructing an engineering template library, the engineering template library containing multiple engineering category templates, each engineering category template being associated with a stage flowchart; Merging stage flowcharts of the same engineering category templates to form integrated stage flowcharts; Parsing the function requirement description and the process requirement description input by the user, selecting an integrated stage flowchart based on the function requirement description, extracting a basic stage flowchart based on the process requirement description, marking to-be-modified nodes in the basic stage flowchart, and obtaining a complete stage flowchart after modifying the to-be-modified nodes; Based on the node verification model, performing node review on the complete stage flowchart, identifying abnormal nodes in the node review and generating a risk prompt. 4.The BIM-based engineering whole life cycle collaborative management method according to claim 3, wherein, The merging of the stage flowcharts of the same engineering category templates to form integrated stage flowcharts includes: Parsing the node hierarchical number and data flow direction identifier in the stage flowchart, and dividing the stage flowchart into multiple hierarchical units based on the node hierarchical number; Selecting the engineering category template with the most hierarchical units as the main template; Marking a main node in the main template and locating reference nodes in other engineering category templates; Aligning the node hierarchical units of other engineering category templates to the main template starting from the reference nodes; Judging whether the main node and the aligned node meet the node fusion condition, if the node fusion condition is met, merging the aligned node to the main node, if the node fusion condition is not met, adding the aligned node as a branch node; Integrating all nodes to generate an integrated stage flowchart. 5.The BIM-based engineering whole life cycle collaborative management method according to claim 4, characterized in that, The locating of the reference nodes includes: Finding the smallest hierarchical unit in other engineering category templates and extracting candidate nodes in the smallest hierarchical unit; Judging whether the candidate nodes and the main node meet the node fusion condition; if the node fusion condition is met, determining the candidate nodes as the reference nodes; if the node fusion condition is not met, continue to extract candidate nodes in other hierarchical units; Repeat the judgment until the reference nodes are located. 6.The BIM-based engineering whole life cycle collaborative management method according to claim 3, wherein, The basic stage flowchart is extracted based on the process requirement description, and the basic stage flowchart comprises the following steps: parsing the process requirement description to obtain a start node and a termination node of a requirement flowchart; matching a top node corresponding to the start node in an integrated stage flowchart; matching a bottom node corresponding to the termination node in the integrated stage flowchart; and generating a plurality of candidate flowcharts with the top node and the bottom node as end points; calculating node similarity between the requirement flowchart and each candidate flowchart, and selecting a candidate flowchart with the largest node similarity as the basic stage flowchart.

7. The BIM-based engineering whole life cycle collaborative management method according to claim 6, characterized in that, The calculation of the node similarity between the requirement flowchart and each candidate flowchart comprises the following steps: extracting a feature label of a node of the requirement flowchart to generate a feature hash value of the feature label; traversing adjacent nodes of the node of the requirement flowchart, and performing difference operation on the feature hash values of the node and the adjacent nodes to obtain a requirement label value; traversing adjacent nodes of a node of a candidate flowchart, and performing difference operation on the feature hash values of the node and the adjacent nodes to obtain a candidate label value; comparing the requirement label value and the candidate label value, and counting the number of same label values; calculating the node similarity based on the number of same label values.

Images