A Smart Collaborative Management Method and System for Municipal Engineering Water Conservancy and Hydropower

Abstract

This invention discloses an intelligent collaborative management method and system for municipal engineering water conservancy and hydropower projects, specifically relating to the field of engineering collaborative management technology, and aimed at solving the problem of difficult engineering collaboration. This invention collects management records during the project's management flow process, encodes them to generate a sequence of project collaborative management events, constructs a project collaboration constraint diagram based on project plan templates and management process rules, forming time-series constraints, responsibility transfer constraints, feedback loop constraints, and blockage transmission constraints. Then, based on the project collaboration constraint diagram, it performs management stage status summary processing to generate project collaboration status records, identifies collaborative blockage events and determines the set of blockage impact ranges, generates a set of collaborative handling paths based on the blockage impact range set, filters target handling paths and converts them into collaborative handling task packages assigned to responsible entities, and updates the system after receiving feedback. This improves the collaborative efficiency and accuracy of anomaly handling in the management of municipal engineering water conservancy and hydropower projects.

Description

Technical Field

[0001] This invention relates to the field of collaborative management technology for engineering projects, and more specifically, to a method and system for intelligent collaborative management of municipal engineering water conservancy and hydropower projects. Background Technology

[0002] In the field of municipal engineering water conservancy and hydropower project management, project collaborative management systems based on information platforms have been widely used. These systems typically use computer programs to record and track management matters such as plan issuance, task flow, progress feedback, problem rectification, acceptance confirmation, and document archiving in projects including pump station upgrades, drainage capacity improvements, river management infrastructure, water supply and drainage network renovations, and the handover of hydropower facilities. Existing technical solutions focus on the electronic management of project ledgers, task lists, progress milestones, and problem rectification records. Through process forms, milestone reminders, and responsibility assignment, they improve the efficiency of project data retention and management flow. These systems generally adopt a method of recording separately by project, by milestone, and by responsible entity to achieve project process management. Their technical implementation involves the collaborative control of digital data processing and engineering project management processes.

[0003] However, management records such as project plans, task feedback, problem rectification, acceptance confirmation, and archiving are usually scattered. Although they can reflect the processing results of individual matters, they are difficult to organize in a unified manner the temporal relationships, responsibility transfer relationships, feedback loop relationships, and anomaly transmission relationships between different management nodes. When a node experiences a lack of feedback, failure of the responsible party to respond, failure to confirm rectification, or failure to close the archive, the system can often only generate a single-point reminder. It is impossible to further determine the scope of impact of the anomaly on subsequent management nodes, related responsible parties, and project stage status. It is also difficult to automatically generate targeted collaborative handling paths and task packages. As a result, municipal engineering water conservancy and hydropower projects are prone to problems such as difficulty in locating blocked matters, difficulty in tracking the flow of responsibility, difficulty in closing the loop of problem rectification, and lag in updating the management status in the multi-entity and multi-node management flow. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method and system for intelligent collaborative management of municipal engineering water conservancy and hydropower, so as to solve the problem of difficult engineering collaboration in the above-mentioned background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A method for intelligent collaborative management of municipal engineering water conservancy and hydropower projects includes:

[0007] Collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and organize the management records in sequence, and generate a project collaborative management event record sequence.

[0008] Based on the project plan template and management process rules, perform collaborative relationship parsing on the project collaborative management event record sequence, generate a project collaborative constraint diagram, and establish collaborative constraint relationships between different management nodes in the project collaborative constraint diagram;

[0009] Based on the project collaboration constraint diagram, the project collaboration management event record sequence is processed to summarize the management stage status, generate project collaboration status records, and form deviation markers for the corresponding management stages based on the summary results of the management stage status.

[0010] The project collaboration status records are matched with preset collaboration judgment rules to identify collaboration blocking events, and the set of blocking impact ranges corresponding to the collaboration blocking events is determined based on the project collaboration constraint diagram.

[0011] A set of collaborative handling paths is generated based on the set of blocked impact areas. Target handling paths are selected and converted into collaborative handling task packages, which are then assigned to the corresponding responsible entities.

[0012] Receive and process feedback and write it back to the project collaborative management event record sequence, update the project collaborative status record and project collaborative constraint diagram, and form the intelligent collaborative management results of municipal engineering water conservancy and hydropower projects.

[0013] In a preferred embodiment, management records generated during the management process of municipal water conservancy and hydropower projects are collected, and these records are uniformly coded and sequentially organized to generate a project collaborative management event record sequence. Specific steps include:

[0014] Obtain management records generated during the planning, task transfer, progress feedback, problem registration, rectification submission, confirmation and processing, and archiving and handover processes of municipal engineering water conservancy and hydropower projects;

[0015] The project name, project number, management item, transfer node, responsible entity, occurrence time, processing result and associated attachment in the management record are parsed to remove duplicate records and fill in the missing node attribution information;

[0016] A unified event code is generated based on the project identifier, management node identifier, responsible entity identifier, and time anchor point. Management records belonging to the same management node in the same project are grouped into project collaborative management event records.

[0017] The project collaborative management event records are arranged according to the time anchor and management node sequence, and a source tag, status tag and flow tag are configured for each project collaborative management event record to generate a project collaborative management event record sequence.

[0018] In a preferred embodiment, collaboration relationship parsing is performed on the project collaboration management event record sequence based on the project plan template and management process rules. Specific steps include:

[0019] Extract the planning management nodes of municipal engineering water conservancy and hydropower projects based on the project plan template, and generate a plan node sequence according to the node name, node order and node deadline;

[0020] Based on the management process rules, the actual flow nodes are extracted from the project collaborative management event record sequence. The actual flow nodes are matched with the planned node sequence to determine the alignment results of nodes that are consistent, missing, early, late, or newly added.

[0021] Based on the responsible entity identifier in the project collaborative management event log, establish a mapping relationship between the responsible entity and the corresponding management node, and record the flow status of the responsible entity in the node's receiving, processing, feedback and confirmation process;

[0022] Based on the time anchors, event numbers, and processing results among the project collaborative management event records, the task initiation event, feedback submission event, rectification submission event, and confirmation processing event are matched in a closed loop to form node matching results, responsible entity mapping results, and closed loop matching results used to construct the project collaborative constraint diagram.

[0023] In a preferred embodiment, a project collaboration constraint diagram is generated, and collaboration constraint relationships between different management nodes are established within the project collaboration constraint diagram. Specific steps include:

[0024] The management nodes in the node matching results are used as graph nodes, and the graph nodes are associated with the corresponding project collaborative management event records, responsible entity mapping results, and closed-loop matching results;

[0025] Based on the sequential relationship between the planned node sequence and the actual flow nodes, a time constraint is established between adjacent management nodes to limit the advancement order and the time limit relationship of the management nodes;

[0026] Based on the status of receipt, processing, feedback and confirmation by the responsible party at different management nodes, responsibility transfer constraints are established to characterize the flow relationship of matters between the responsible parties;

[0027] Based on the closed-loop matching results between task initiation events, feedback submission events, rectification submission events, and confirmation processing events, feedback closed-loop constraints are established to characterize whether management matters have been completed and confirmed.

[0028] Based on the results of missing nodes, lagging nodes, missing responsibility entity mapping, and closed-loop matching failure, a blocking transmission constraint is established between the corresponding management node and subsequent related nodes, generating a project collaboration constraint diagram for subsequent management phase status summary processing and blocking impact scope analysis.

[0029] In a preferred embodiment, based on the project collaboration constraint diagram, the project collaboration management event record sequence is processed to summarize the management stage status, generating project collaboration status records. Furthermore, deviation markers for the corresponding management stages are formed based on the summarized management stage status results. Specific steps include:

[0030] The project collaborative management event record sequence is grouped according to the project identifier and management stage, and the node progress record, responsibility transfer record, feedback submission record and closed-loop confirmation record of the same project in the same management stage are extracted.

[0031] The extracted node progress records are matched with the temporal constraints in the project collaboration constraint diagram to generate node progress status.

[0032] Match the responsibility transfer records with the responsibility transfer constraints in the project collaboration constraint diagram to generate responsibility response status;

[0033] Match the feedback submission records and closed-loop confirmation records with the feedback closed-loop constraints in the project collaboration constraint diagram to generate feedback complete status and closed-loop confirmation status.

[0034] Based on the consistency relationship between node progress status, responsibility response status, feedback integrity status, and closed-loop confirmation status, a project collaboration status record is generated, and deviation markers are formed for the corresponding management stages when there are node delays, responsibility breaks, missing feedback, or closed-loop interruptions.

[0035] In a preferred embodiment, the project collaboration status record is matched with a preset collaboration determination rule to identify collaboration blocking events. Specific steps include:

[0036] The pre-defined collaborative judgment rules include node deadline rules, responsibility feedback rules, and closed-loop confirmation rules;

[0037] Read the node progress status, responsibility response status, feedback integrity status, closed-loop confirmation status, and stage deviation markers from the project collaboration status record;

[0038] The node progress status is compared with the node deadline rules. When a managed node exceeds the corresponding deadline and no valid progress record is formed, a node overdue mark is generated.

[0039] The responsibility response status is compared with the responsibility feedback rules. When the responsible party fails to form a receipt, processing or feedback record within the specified feedback window, a responsibility non-response mark is generated.

[0040] The feedback integrity status and closed-loop confirmation status are compared with the closed-loop confirmation rules. When the feedback record is missing, the rectification result is not confirmed, the acceptance result is not confirmed, or the archiving result is not closed, a closed-loop interruption mark is generated.

[0041] Based on node overdue flags, responsibility non-response flags, and closed-loop interruption flags, collaborative blocking events are identified, and the blocking node, blocking type, trigger time, associated responsible entity, and corresponding stage deviation flag are recorded for each collaborative blocking event.

[0042] In a preferred embodiment, the set of blocking impact ranges corresponding to collaborative blocking events is determined along the project collaboration constraint graph. Specific steps include:

[0043] Using the blocking node corresponding to the collaborative blocking event as the starting point for retrieval, read the timing constraints, responsibility transfer constraints, feedback loop constraints, and blocking propagation constraints connected to the blocking node in the project collaborative constraint diagram;

[0044] Search for subsequent management nodes after the blocked node along the time sequence constraints to determine the scope of subsequent tasks affected by node lag or node expiration.

[0045] Search for the responsible entities related to the blocked node along the responsibility transfer constraints, and determine the scope of related responsible entities that need to receive reminders, corrections, confirmations, or reviews;

[0046] Search for management items that have not been confirmed by feedback along the feedback closed loop constraints, and determine the items to be corrected and the items to be confirmed;

[0047] Search along the blockage propagation constraints to find management nodes that have been affected by missing nodes, delayed nodes, unresponsive responsibilities, or closed-loop interruptions. Summarize the affected tasks, related responsible parties, items to be corrected, items to be confirmed, and project status to be updated to form a set of blockage impact ranges corresponding to collaborative blockage events.

[0048] In a preferred embodiment, a set of collaborative handling paths is generated based on the set of blocked impact ranges, and target handling paths are selected. Specific steps include:

[0049] Based on the affected tasks, associated responsible parties, items to be rectified, items to be confirmed, and project status to be updated in the set of blocked impact areas, generate responsibility follow-up paths, feedback correction paths, rectification confirmation paths, acceptance review paths, and phase adjustment paths;

[0050] The urgency of nodes in each collaborative handling path is determined based on the trigger time of the collaborative blocking event, the remaining time of the node deadline, and the importance of the corresponding management stage.

[0051] The continuity of responsibility for each collaborative handling path is determined based on the continuous participation of the relevant responsible parties in the blocked nodes, matters to be rectified, and matters to be confirmed.

[0052] The subsequent impact range of each collaborative handling path is determined based on the number of affected tasks, the number of affected management stages, and the number of project statuses to be updated in the blockage impact range set.

[0053] The collaborative handling paths are sorted according to the urgency of nodes, continuity of responsibility, and scope of subsequent impact. The collaborative handling paths that match the collaborative blockage type and cover matters to be corrected, matters to be confirmed, or project status to be updated are identified as the target handling paths.

[0054] In a preferred embodiment, the target disposal path is converted into a collaborative disposal task package and assigned to the corresponding responsible entity. Disposal feedback is received, and the project collaborative status record and the sequence of events to the project collaborative management record are updated. Specific steps include:

[0055] A collaborative handling task package is generated based on the target handling path. The collaborative handling task package includes a task identifier, a blocking event identifier, a responsible entity identifier, handling items, a feedback deadline, a confirmation node, and a write-back location.

[0056] The collaborative handling task packages are assigned to the corresponding responsible entities according to the identification of the responsible entities, and the task assignment time, task receipt status and task processing status are recorded.

[0057] Receive feedback from the responsible party regarding the handling of the matter, including the results of the responsibility response, the results of the rectification, the results of the rectification confirmation, the results of the acceptance review, and the results of the phase adjustment.

[0058] Write the handling feedback to the corresponding project collaborative management event record according to the write-back location, and update the status flag and flow flag in the project collaborative management event record sequence based on the handling feedback;

[0059] Based on the updated project collaboration management event record sequence, the project collaboration status record is regenerated, and the graph node status, feedback closed-loop constraint status, and blocking transmission constraint status in the project collaboration constraint diagram are updated synchronously to form the intelligent collaboration management result of municipal engineering water conservancy and hydropower projects.

[0060] A municipal engineering water conservancy and hydropower intelligent collaborative management system, used to implement the aforementioned municipal engineering water conservancy and hydropower intelligent collaborative management method, includes:

[0061] The event log generation module is used to collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and organize the management records in sequence, and generate a project collaborative management event log sequence.

[0062] The constraint diagram construction module is used to perform collaborative relationship parsing on the sequence of project collaborative management event records based on the project plan template and management process rules, generate a project collaborative constraint diagram, and establish collaborative constraint relationships between different management nodes in the project collaborative constraint diagram;

[0063] The status summary module is used to summarize the status of the project collaboration management event record sequence based on the project collaboration constraint diagram, generate project collaboration status records, and form deviation markers for the corresponding management stages based on the status summary results of the management stages.

[0064] The blocking impact analysis module is used to match project collaboration status records with preset collaboration judgment rules, identify collaboration blocking events, and determine the set of blocking impact ranges corresponding to collaboration blocking events based on the project collaboration constraint diagram.

[0065] The path orchestration module is used to generate a set of collaborative handling paths based on the set of blocked impact ranges, filter target handling paths, and convert target handling paths into collaborative handling task packages and assign them to the corresponding responsible entities.

[0066] The closed-loop update module is used to receive feedback on handling and write it back to the project collaborative management event record sequence, update the project collaborative status record and project collaborative constraint diagram, and form the intelligent collaborative management results of municipal engineering water conservancy and hydropower projects.

[0067] The technical effects and advantages of this invention are as follows:

[0068] This invention achieves unified status identification, blockage location, and coordinated handling of municipal engineering water conservancy and hydropower projects in the multi-entity, multi-node management process by constructing a closed-loop management mechanism that includes a project collaborative management event record sequence, a project collaborative constraint diagram, a project collaborative status record, and a collaborative handling task package. The system uniformly encodes and records management records scattered across stages such as plan issuance, task flow, progress feedback, problem rectification, acceptance confirmation, and archiving and handover, accurately reconstructing the actual progress sequence of project management matters, the flow status of responsible entities, and the closed-loop status of matters, avoiding the problem of traditional ledgers only recording results and making it difficult to trace the process.

[0069] Then, by establishing timing constraints, responsibility transfer constraints, feedback loop constraints, and blockage propagation constraints through a project collaboration constraint diagram, collaborative blocking events such as node overdue, unresponsive responsibilities, missing feedback, and loop interruption can be identified, and their impact on subsequent tasks, related responsible parties, and project status can be determined. Furthermore, a set of collaborative handling paths is generated based on the blockage impact range set, target handling paths are selected and converted into collaborative handling task packages, enabling targeted assignment and feedback write-back of handling matters. This improves the collaborative efficiency, problem closure capability, and process traceability of municipal engineering, water conservancy, and hydropower project management. Attached Figure Description

[0070] Figure 1 This is a flowchart of a smart collaborative management method for municipal engineering water conservancy and hydropower projects according to the present invention.

[0071] Figure 2 This is a schematic diagram of the structure of a municipal engineering water conservancy and hydropower intelligent collaborative management system according to the present invention. Detailed Implementation

[0072] 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.

[0073] Example 1: As Figure 1 As shown, a smart collaborative management method for municipal engineering water conservancy and hydropower projects includes the following steps:

[0074] Collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and sequentially organize these records, and generate a project collaborative management event record sequence. Specific implementation content includes:

[0075] First, management records generated during the management process of municipal engineering water conservancy and hydropower projects are collected. These management records do not refer to a single progress report, but rather to traceable records formed by different responsible entities around the same project matters during the project's management process. These records include plan issuance records, task transfer records, progress feedback records, problem registration records, rectification submission records, confirmation and processing records, and archiving and handover records. Among these, plan issuance records are used to indicate the arrangements made by the competent department or construction unit for project phase objectives, deadlines, and management matters.

[0076] Task flow records are used to represent the process of dispatching, receiving, and transferring management matters among construction units, design units, supervision units, construction units, and operation and maintenance receiving units;

[0077] Progress feedback records are used to indicate the responsible party's feedback on the status of node processing, completion rate, or stage results;

[0078] Problem registration records are used to indicate management issues discovered during project management, such as missing data, process delays, abnormal feedback, and inadequate rectification.

[0079] The rectification submission record is used to indicate the supplementary materials, rectification explanations, or handling results submitted by the responsible party in response to the problem.

[0080] The confirmation and processing record is used to indicate the confirmation, return, or review opinions made by the responsible entity with confirmation authority regarding feedback items, rectification items, or interim results;

[0081] Archived handover records are used to represent the archived, handover, or closed-loop records formed after project management matters have been completed and confirmed.

[0082] The collection of the above records can cover the management process of municipal engineering water conservancy and hydropower projects, from plan generation to task execution, problem handling and closed-loop confirmation.

[0083] When collecting management records, corresponding data can be obtained from project management platforms, task collaboration platforms, approval workflow platforms, quality and safety issue rectification platforms, acceptance confirmation platforms, document archiving platforms, or manual entry ledgers. At the same time, field parsing is performed on each management record. Specifically, during field parsing, at least the project name, project number, management item, workflow node, responsible entity, occurrence time, processing result, and associated attachments should be extracted. Among them, the project name and project number are used to determine the municipal engineering water conservancy and hydropower project to which the record belongs.

[0084] Management items are used to determine which category of item the record corresponds to: plan, task, feedback, problem, rectification, confirmation, or archiving.

[0085] The flow node is used to determine the node position of the record in the project management process;

[0086] The responsible entity is used to determine which unit, department, or individual initiated, processed, or confirmed the record;

[0087] The time of occurrence is used to form a time anchor point;

[0088] The processing result indicates whether the matter has been initiated, received, being processed, responded to, confirmed, returned, or closed.

[0089] The associated attachments are used to store the forms, photos, explanatory documents, acceptance materials, rectification materials, or archived file indexes corresponding to the management record.

[0090] After field parsing is complete, basic cleaning of the management records is performed, including:

[0091] For duplicate records, consistency can be determined based on project number, management item, transfer node, responsible party, occurrence time and processing result.

[0092] If multiple records have completely identical fields, or only differ in attachment upload time but have the same processing result, then retain the record with the newer time anchor or the record containing the complete attachment index.

[0093] For records lacking node attribution information, their node attribution can be determined based on the management item name, item number, processing result, and adjacent transfer records. For example, if a record only shows "rectification materials have been submitted" but does not directly indicate the transfer node, it can be assigned to the rectification submission node based on its corresponding issue registration number and subsequent confirmation processing record. For records whose node attribution cannot be determined based on adjacent records, they can be configured as records pending confirmation and corrected during subsequent node alignment processes.

[0094] After field parsing and cleaning, management records are uniformly coded based on project identifier, management node identifier, responsible entity identifier, and time anchor. The project identifier can be generated by combining the project number, project year, and project category to distinguish different municipal engineering, water conservancy, and hydropower projects. The management node identifier can be configured according to management nodes such as plan issuance, task flow, progress feedback, problem registration, rectification submission, confirmation processing, and archiving transfer, or it can be generated based on the node number in the project plan template. The responsible entity identifier can be generated based on the responsible unit number, department number, or position number. The time anchor can be determined using the valid time field from the occurrence time, submission time, confirmation time, or archiving time of the management record.

[0095] Unified event coding can be generated using a combination of "project identifier - management node identifier - responsible entity identifier - time anchor". The project identifier consists of the project year, project category, and project sequence number; the management node identifier indicates the planning issuance node, task transfer node, progress feedback node, issue registration node, rectification submission node, confirmation processing node, or archiving and handover node to which the management record belongs; the responsible entity identifier indicates the construction unit, supervision unit, construction unit, operation and maintenance receiving unit, or competent authority corresponding to the record; and the time anchor indicates the occurrence time, submission time, or confirmation time of the management record.

[0096] For example, a pumping station renovation project belongs to the municipal water conservancy and hydropower projects in 2026, with project sequence number 001. Its project identifier can be recorded as "2026-Pumping Station Renovation-001". If the project's progress feedback node is recorded by the supervision unit at 09:30 on May 10, 2026, the unified event code of this record can be generated as "2026-Pumping Station Renovation-001-Progress Feedback Node-Supervision Unit-202605100930". This code can uniquely locate each management record in terms of project, management node, responsible entity, and time dimension, making it easy to collect them into project collaborative management event records.

[0097] Furthermore, management records belonging to the same management node within the same project are grouped into project collaborative management event records. These records are structured units that can be identified, matched, and written back by the system, organizing management records with continuous relationships under the same management node. For example, for a progress feedback node, this node may include task receipt records, progress description records, attachment upload records, and supervisor confirmation records. Although these records come from different sources and occur at different times, they all revolve around the same project, the same management node, and the same responsibility, and therefore can be grouped into the same project collaborative management event record.

[0098] Each project collaborative management event log should include at least the event log identifier, project identifier, management node identifier, responsible entity identifier, time anchor, processing result, source marker, status marker, and flow marker. The event log identifier is used to distinguish collaborative management event logs from different projects.

[0099] The source marker indicates that the collaborative management event records for this project mainly originate from plans, tasks, feedback, issues, rectification, confirmations, or archived records;

[0100] Status flags are used to indicate whether the corresponding item in the current project collaborative management event record is in a state of not started, initiated, being processed, feedback received, confirmed, returned, or closed.

[0101] The flow marker is used to indicate the connection status between the collaborative management event record of this project and the collaborative management event record of the preceding project or the collaborative management event record of the subsequent project, such as normal flow, waiting for feedback, waiting for confirmation, returned for correction, or flow completed.

[0102] After the project collaborative management event records are generated, they are arranged according to the time anchor and management node order to generate a project collaborative management event record sequence. In the arrangement, the event records of different projects are first grouped according to the project identifier, then the main sequence of management nodes is determined according to the node order in the project plan template, and finally the specific project collaborative management event records are arranged according to the time anchor within the same management node.

[0103] For multiple parallel records occurring within the same time period, their arrangement within the same node can be determined based on the responsible entity identifier and the processing result. For example, under the same rectification node, the construction unit submits rectification materials, the supervision unit reviews them, and the construction unit confirms them. These can be arranged in the order of submission, review, and confirmation. The project collaborative management event record sequence generated in this way can reflect the actual progress order of the project in the management process, the participation of the responsible entities, and the closed-loop status of the matters.

[0104] The purpose of the above processing is to transform the management records that were originally scattered across different platforms, different ledgers, and different responsible entities into a sequence of project collaborative management event records centered on projects, nodes, responsible entities, and time anchors. This sequence not only retains the source and processing results of the original management records, but also forms a basic data structure that can be used for subsequent node alignment, responsible entity mapping, closed-loop relationship matching, and collaborative constraint graph construction.

[0105] For example, in a municipal drainage improvement project, the following management records were collected: the project plan was issued on May 10, 2026; the task was assigned to the undertaking unit on May 12, 2026; the undertaking unit submitted phase progress feedback on May 16, 2026; the supervision unit proposed data correction opinions on May 17, 2026; the undertaking unit submitted correction materials on May 18, 2026; and the construction unit completed confirmation on May 19, 2026. During processing, a unified event code was generated for the above records, and they were collected according to the plan issuance node, task flow node, progress feedback node, and confirmation processing node to form corresponding project collaborative management event records.

[0106] Subsequently, the project collaborative management event record sequence is formed by arranging the time anchors and nodes in order. If a task has been assigned but no corresponding progress feedback management event record is formed in the sequence, the node can be identified as having missing feedback or being lagging behind in subsequent processing. If there is a rectification submission record but no confirmation processing record, it can be identified as an incomplete closure in subsequent closed-loop relationship matching.

[0107] Based on the project plan template and management process rules, the project collaborative management event record sequence is parsed to generate a project collaborative constraint diagram. Then, collaborative constraint relationships between different management nodes are established within this diagram. Specific implementation details include:

[0108] After generating the project collaborative management event record sequence, the project collaborative management event record sequence is further aligned with nodes, mapped to responsible entities, and matched with closed-loop relationships according to the project plan template and management process rules. This forms a project collaborative constraint diagram that reflects the collaborative relationships between project management nodes. The project plan template refers to a pre-configured management node template for municipal engineering water conservancy and hydropower projects. It is used to limit the management nodes, node order, node deadlines, and relationships between nodes that the project should go through from the issuance of the plan to the archiving and handover process. The project plan template can be configured according to the project type. For example, pump station renovation projects, drainage capacity improvement projects, river management supporting projects, and water supply and drainage network renovation projects can correspond to different plan templates. However, each template includes at least some of the following nodes: planning nodes, task nodes, feedback nodes, rectification nodes, confirmation nodes, and archiving nodes.

[0109] The management process rules refer to the rules used to constrain the flow of management records between different responsible entities. These rules include node entry conditions, node completion conditions, responsible entity reception rules, feedback submission rules, rectification confirmation rules, and archiving closure rules.

[0110] To facilitate program reading and matching, project plan templates and management process rules can be configured as rule tables. The project plan template table should include at least the following fields: Project Type, Management Stage, Node Identifier, Node Name, Preceding Node, Subsequent Node, Node Deadline, and Node Completion Condition. For example, for a drainage capacity improvement project, the preceding node for the task receiving node is the plan issuance node, the node deadline is three working days after plan issuance, and the node completion condition is the creation of a task receiving project collaborative management event record; the preceding node for the progress feedback node is the task receiving node, the node deadline is five working days after task receipt, and the node completion condition is the creation of a progress feedback management event record containing the processing result.

[0111] The management process rule table includes at least the following fields: rule identifier, item type, initiating entity, receiving entity, response action, feedback window, confirmation entity, and closure condition. For example, for a rectification item, the initiating entity is the supervision unit, the receiving entity is the construction unit, the response action is rectification submission, the feedback window is three working days, the confirmation entity is either the supervision unit or the construction unit, and the closure condition is that the rectification confirmation result is "confirmed as passed." Through this rule table, the system can automatically match the project collaborative management event record sequence with planned nodes, responsible entities, and closure conditions.

[0112] In practice, the planning management nodes of the target municipal engineering water conservancy and hydropower project are first extracted based on the project plan template, and a planning node sequence is generated according to the node name, node order and node deadline. The planning node sequence is used to represent the node arrangement relationship that the project should form under the standard management process. For example, for a drainage capacity improvement project, its planning node sequence can include the plan issuance node, task reception node, progress feedback node, problem rectification node, confirmation and processing node and archiving and handover node in sequence.

[0113] Each planning management node is configured with a node identifier, node name, node sequence number, node duration, predecessor node identifier, and successor node identifier;

[0114] In this way, the management requirements in the project plan template can be converted into node benchmarks that can be compared with the project collaborative management event record sequence.

[0115] Subsequently, actual flow nodes are extracted from the project collaborative management event record sequence. Actual flow nodes refer to the management nodes corresponding to the project collaborative management event records formed by the collection of real management records. They reflect the node status that has occurred or is occurring in the actual management flow of the project.

[0116] The system reads the management node identifier, time anchor, processing result, and flow mark from the collaborative management event records of each project and matches them with the plan management node in the plan node sequence;

[0117] During matching, first determine whether the actual flow node belongs to the planned node sequence based on the management node identifier;

[0118] If the management node identifiers are consistent, then further compare the node order and time anchor point;

[0119] If the actual flow node can be found in the planned node sequence and the time anchor point is within the node's deadline, then the node is determined to be consistent.

[0120] If there are nodes in the planned node sequence that should appear but do not appear in the project collaborative management event record sequence, then the nodes are identified as missing.

[0121] If the actual time of the flow node is earlier than the completion time of the preceding node or the start time of the planned node, it is determined to be an early node.

[0122] If the actual transfer node occurs later than the node deadline, or if the preceding node has been completed but the node has not generated a valid project collaborative management event record for a long time, it is determined to be a node lag.

[0123] If there are nodes in the project collaborative management event record sequence that are not configured in the planned node sequence but are generated in the actual process, they are identified as newly added nodes.

[0124] After node alignment is completed, a mapping relationship is established between the responsible entity and the corresponding management node based on the responsible entity identifier in the project collaborative management event log. The responsible entity can be the competent department, construction unit, design unit, supervision unit, construction unit, operation and maintenance receiving unit, document review department, or other units, departments, or positions involved in project management.

[0125] The responsibility entity mapping records the receiving, processing, feedback, and confirmation processes of the responsible entity in the corresponding management nodes. For example, in the task node, the construction unit can be the task initiator and the construction unit can be the task receiver; in the rectification node, the construction unit can be the rectification submitter, the supervision unit can be the reviewer, and the construction unit can be the confirmation entity.

[0126] In the archiving node, the data management department can act as the archiving recipient. The system records the flow status of the responsible entity in the node based on the event record time anchor point and processing result within the same management node, including statuses such as dispatched, received, processing, feedback received, returned, confirmed, and closed loop. This forms the responsible entity mapping result, providing a basis for judging whether the responsibility transfer has been interrupted or whether the responsible entity has failed to respond.

[0127] Furthermore, based on the time anchors, event numbers, and processing results among the project collaborative management event records, a closed-loop relationship matching is performed for task initiation events, feedback submission events, rectification submission events, and confirmation processing events, specifically including:

[0128] The item number can be generated from the management item number, issue number, rectification number, task number, or confirmation item number, and is used to identify the continuous flow relationship of the same management item at different nodes;

[0129] When matching closed-loop relationships, the system takes the task initiation event as the starting point and searches for whether there is a feedback submission event that is consistent with or related to its task number.

[0130] If the feedback submission event contains a problem registration result or a return result, then continue searching for the corresponding rectification submission event; if a rectification submission event exists, then further search for whether a confirmation processing event exists.

[0131] If the processing result of the confirmed event is confirmation passed, review passed, or archiving completed, then the management matter is considered to have completed the closed-loop matching.

[0132] If only a task initiation event exists but no feedback submission event exists, it is marked as feedback missing;

[0133] If a feedback submission event exists but a confirmation processing event does not exist, it is marked as missing confirmation.

[0134] If a rectification submission is made but the processing result is returned or not confirmed, it is marked as rectification not closed.

[0135] After obtaining the node matching results, the responsibility entity mapping results, and the closed-loop matching results, a project collaboration constraint diagram is constructed, which includes the following:

[0136] The project collaboration constraint graph is a data structure formed by using management nodes as graph nodes and collaboration constraint relationships between nodes as constraint edges. Each graph node corresponds to a management node and is associated with the project collaboration management event records, responsible entity mapping results, and closed-loop matching results corresponding to that management node.

[0137] Graph nodes can record node identifier, node type, node duration, node status, associated responsible entity, and associated item number;

[0138] Constraint edges are used to represent the collaborative relationship between different management nodes, including at least timing constraints, responsibility transfer constraints, feedback loop constraints, and blockage transmission constraints. Among them, timing constraints are established based on the sequential relationship between the planned node sequence and the actual flow nodes, and are used to limit the advancement order and node deadline relationship between different management nodes.

[0139] For example, the task receiving node should be located after the plan issuance node, the progress feedback node should be located after the task receiving node, and the confirmation processing node should be located after the feedback submission or rectification submission node. If an actual flow node is completed earlier than its predecessor node or later than the node deadline, the timing constraint can record the early or late status of that node.

[0140] Through time constraints, project collaboration constraint diagrams can reflect the progress of project management processes over time.

[0141] The responsibility transfer constraint is established based on the receiving, processing, feedback and confirmation status of the responsible entity at different management nodes. It is used to represent the transfer relationship of the same management matter between different responsible entities. For example, after the construction unit assigns a task to the construction unit, the construction unit should form a receiving or processing record.

[0142] After the construction unit submits the rectification, the supervision unit shall prepare a review record;

[0143] After the supervision unit reviews the application, the construction unit or the competent authority shall create a confirmation record.

[0144] If a responsible party has completed the transfer of a matter, but the next responsible party has not formed a receipt or processing record, the responsibility transfer constraint can record the responsibility transfer breakpoint. This constraint enables the system to identify that the matter does not remain at a certain node itself, but rather remains in the process of flow between responsible parties.

[0145] The feedback loop constraint is established based on the loop matching results between the task initiation event, feedback submission event, rectification submission event, and confirmation processing event. It is used to characterize whether the management matter has completed the loop from initiation, feedback, rectification to confirmation. For example, a problem registration matter should correspond to a rectification submission event and a confirmation processing event.

[0146] If a progress feedback item is returned for correction, a corresponding correction submission event and a reconfirmation event should be generated.

[0147] If a complete closed-loop event cannot be matched, the feedback closed-loop constraint is recorded as an unclosed state; if a confirmed processing result or an archived transfer result has been formed, it is recorded as a closed-loop state.

[0148] The blocking transmission constraint is established based on the results of missing nodes, delayed nodes, missing responsibility entity mapping, and closed-loop matching failure. It is used to represent the impact of an anomaly of a management node on subsequent or related nodes. For example, if the progress feedback node is missing, the subsequent confirmation processing node and archive handover node may not be able to proceed normally.

[0149] If the rectification submission node exists but the confirmation processing node is missing, the issue cannot be closed, which may affect the acceptance and confirmation at this stage.

[0150] If the mapping of responsible parties is missing, the system cannot determine which party should handle the next step, which may lead to the stagnation of the matter.

[0151] At this point, the system establishes a blocking propagation constraint between the abnormal node and its subsequent associated nodes, so that the abnormality can be tracked in the subsequent blocking impact range analysis.

[0152] The aforementioned blockage propagation constraints are not equivalent to determining that the project is abnormal, but rather provide a calculable correlation basis for the status summary processing and blockage impact range analysis during the management phase.

[0153] Through the above processing, the project collaboration constraint diagram can simultaneously express the time sequence, responsibility flow, event closure, and anomaly propagation relationships in the project management process. It further transforms the project collaboration management event record sequence into a project collaboration constraint diagram, enabling the system to determine the actual location of a node, the flow status of the responsible entity, whether the event has formed a closure, and whether an anomaly will affect subsequent nodes. When generating project collaboration status records, the system can directly perform management phase status summary processing based on the project collaboration constraint diagram. When identifying collaboration blocking events, the system can also determine the set of blocking impact ranges along the diagram.

[0154] For example, in a pump station renovation project, the project plan template stipulates that the task reception node should be completed within three working days after the plan is issued, the progress feedback node should be completed within five working days after the task is received, and the confirmation processing node should be completed within three working days after the feedback is submitted. The actual project collaborative management event record sequence shows that the task reception node has been completed on schedule, and the responsible party is the construction unit.

[0155] However, no valid feedback project collaborative management event record was found at the progress feedback node. Only the follow-up reminder record issued by the supervision unit existed. After comparing the actual flow node with the planned node sequence, the system determined that the progress feedback node was missing or delayed.

[0156] At the same time, based on the mapping results of the responsible entities, it was determined that the construction unit did not form a feedback record at this node, and based on the closed-loop relationship matching results, it was determined that the task initiation event did not match the feedback submission event;

[0157] Therefore, the system establishes timing constraints between the task receiving node, progress feedback node, and confirmation processing node; responsibility transfer constraints between the construction unit and the construction unit; feedback loop constraints that are not closed loops between the task initiation event and the feedback submission event; and blocking transmission constraints between the progress feedback node and the confirmation processing node.

[0158] The project's collaborative constraint graph can then be used to determine whether the lack of feedback prevents subsequent confirmation processing from being completed, and further generate collaborative blocking events and handling paths.

[0159] For example, in a river management supporting project, the construction unit submitted rectification materials, the supervision unit completed the review, but the construction unit did not form a confirmation and processing record. The system can determine that the rectification submission node exists when aligning nodes, but the confirmation and processing node is missing.

[0160] When mapping the responsible parties, it can be determined that the construction unit and the supervision unit have completed the corresponding transfer status, but the construction unit lacks confirmation status;

[0161] During closed-loop relationship matching, it can be determined that the rectification submission event was not matched with a confirmation processing event.

[0162] Based on these results, the project collaboration constraint diagram establishes a feedback loop constraint between the rectification submission node and the confirmation processing node, and marks this constraint as not closed. At the same time, it establishes a blocking transmission constraint between the confirmation processing node and the archive handover node. In this way, the subsequent system can clearly identify that the matter is not a normal progress delay, but rather the archive handover is blocked because the confirmation node is not closed.

[0163] Through the above implementation methods, the project plan template, management process rules, project collaborative management event record sequence, and project collaborative constraint diagram form a continuous data processing chain. The project plan template provides the baseline for planned nodes, the management process rules provide the basis for flow and closure judgment, the project collaborative management event record sequence provides actual management records, and the project collaborative constraint diagram uniformly expresses the relationship between planning, actual implementation, responsibility, and closure.

[0164] Based on the project collaboration constraint diagram, the project collaboration management event record sequence is summarized into management phase statuses to generate project collaboration status records. Furthermore, deviation markers for corresponding management phases are generated based on the summarized management phase status results. Specific implementation details include:

[0165] In one specific implementation, after obtaining the project collaboration constraint diagram, the project collaboration management event record sequence is summarized into management stage status based on the project collaboration constraint diagram to generate project collaboration status records. The management stage status summary processing is not clustering processing, but rather refers to summarizing the node progress records, responsibility transfer records, feedback submission records, and closed-loop confirmation records scattered under different management nodes, different responsible entities, and different time anchors into a structured status record that can reflect the overall collaboration status of a certain management stage, based on the project identifier, management stage, and constraint relationship without changing the content of the original project collaboration management event records.

[0166] This process avoids judging project status based solely on a single record. Instead, it integrates various information, such as node progress, responsibility transfer, feedback submission, and closed-loop confirmation, to determine whether the current management phase is progressing normally.

[0167] Specifically, the project collaborative management event record sequence is first grouped according to the project identifier and management stage. The project identifier is used to distinguish different municipal engineering water conservancy and hydropower projects. The management stage can be divided according to the project plan template, such as the plan initiation stage, task execution stage, problem rectification stage, acceptance confirmation stage, and archiving and handover stage.

[0168] For the same management phase of the same project, extract the node progress records, responsibility transfer records, feedback submission records and closed-loop confirmation records related to the management flow within that phase. Among them, the node progress records refer to the project collaborative management event records that can reflect whether a certain management node has been started, processed, completed or overdue.

[0169] Responsibility flow records refer to project collaborative management event records that can reflect whether matters have been assigned, received, processed, fed back, or confirmed among different responsible parties;

[0170] Feedback submission records refer to the feedback records submitted by the responsible party regarding task items, progress items, or rectification items;

[0171] A closed-loop confirmation record refers to the confirmation, return, or review record made by the responsible entity with confirmation authority regarding the feedback results, rectification results, acceptance results, or archiving results.

[0172] After extracting the above records, the node progress records are matched with the timing constraints in the project collaboration constraint diagram to generate the node progress status. In specific implementation, the timing constraints between the nodes in the corresponding management phase of the project collaboration constraint diagram are read to determine whether the node progress records meet the requirements of the planned node sequence and node deadline.

[0173] If a management node has generated a valid project collaboration management event record, and the event occurred no later than the node's deadline, and its predecessor node has been completed, then the node's progress status is marked as normal progress.

[0174] If a project collaborative management event record has been generated for this node but the event occurred after the node's deadline, it will be marked as delayed.

[0175] If a node does not generate a valid project collaboration management event record, but its predecessor node has been completed and the deadline has passed, it is marked as not progressing.

[0176] If the node occurs before the preceding node completes, it is marked as an order anomaly.

[0177] Furthermore, the responsibility flow records are matched with the responsibility transfer constraints in the project collaboration constraint diagram to generate responsibility response status;

[0178] The responsibility response status is used to indicate whether the management matter has been effectively transferred and responded to between the responsible parties. In practice, the initiating party, receiving party, processing party and confirming party recorded in the responsibility transfer constraint are read, and the responsible party identifier in the responsibility flow record is matched with the above parties.

[0179] If a matter is initiated by the first responsible party, and the second responsible party generates a receipt record or processing record in the designated feedback window, then the responsibility response status is marked as responded.

[0180] If only an initiation record exists but no receiving or processing record exists, it is marked as no response;

[0181] If a receiving record exists but no subsequent processing or feedback record is generated, it is marked as a processing interruption;

[0182] If the responsible entity identifier is inconsistent with the management node requirements, it will be marked as a responsibility mismatch;

[0183] Therefore, it can be determined whether an anomaly in a certain management stage is due to the node itself not progressing or to the lack of coordination in the flow of matters between the responsible parties.

[0184] Furthermore, the feedback submission records and closed-loop confirmation records are matched with the feedback closed-loop constraints in the project collaboration constraint diagram to generate feedback completion status and closed-loop confirmation status, specifically including:

[0185] The "complete feedback" status indicates whether the necessary feedback records have been generated for the task, issue, or rectification item, while the "closed-loop confirmation" status indicates whether the feedback or rectification item has been confirmed by the authorized responsible party.

[0186] In practice, if a feedback submission event with a corresponding item number exists after the task is initiated, and the feedback submission event contains the processing result and the necessary attachment index, then the feedback complete status is marked as feedback complete.

[0187] If only part of the feedback content is available or attachments are missing, it will be marked as incomplete feedback;

[0188] If no corresponding feedback submission event exists, it is marked as feedback missing.

[0189] For closed-loop confirmation status, if the feedback submission event, rectification submission event, or acceptance submission event can be matched with a confirmation processing event, and the confirmation processing result is confirmation passed, review passed, or archiving completed, then it is marked as closed-loop;

[0190] If the confirmation process result is returned, pending correction, or unconfirmed, it is marked as not closed loop; if there are no confirmation processing events at all, it is marked as confirmation missing.

[0191] After obtaining the node progress status, responsibility response status, feedback integrity status, and closed-loop confirmation status, a project collaboration status record is generated based on the consistency relationship between the above statuses. The consistency relationship refers to the logical correspondence that should be satisfied between different statuses. For example, if a management node is marked as progressing normally, then the node should usually have a response record of the corresponding responsible entity.

[0192] If a task is marked as having been responded to, then a response submission record should be able to be found.

[0193] If a rectification item is marked as completed, there should be a corresponding closed-loop confirmation record.

[0194] If the above states match each other, the project collaboration status record is marked as normal. If any state is inconsistent with the other states, a deviation mark corresponding to the management stage is formed in the project collaboration status record.

[0195] Project collaboration status records can include at least the project identifier, management phase identifier, node progress status, responsibility response status, feedback completeness status, closed-loop confirmation status, phase deviation marker, and status generation time.

[0196] It should be noted that the project collaboration status record is based on the time sequence constraints, responsibility transfer constraints, and feedback loop constraints in the project collaboration constraint diagram. It performs relational summary processing on the records of multiple types of project collaboration management events in the same management stage, so that it can reflect whether there are collaboration anomalies and the types of anomalies in the current management stage.

[0197] When there are node delays, responsibility breaks, missing feedback, or closed-loop interruptions, a deviation mark is generated for the corresponding management stage; when the node progress status is delayed progress, no progress, or abnormal sequence, a node delay deviation mark is generated.

[0198] When the responsibility response status is no response, processing interrupted, or responsibility mismatch, a responsibility breakpoint deviation marker is generated;

[0199] When the feedback completeness status is incomplete or missing, a feedback missing deviation mark is generated;

[0200] When the closed-loop confirmation status is not closed or the confirmation is missing, a closed-loop interruption deviation mark is generated.

[0201] Deviation markers can be associated with project identifiers, management phase identifiers, and relevant management nodes for subsequent matching with node deadline rules, responsibility feedback rules, and closed-loop confirmation rules, thereby identifying collaborative blocking events.

[0202] For example, during the task execution phase of a drainage capacity improvement project, the project collaborative management event record sequence shows that the task node has been dispatched by the construction unit to the undertaking unit, and the undertaking unit has formed a receipt record. However, no progress feedback record has been formed within the specified feedback period. When processing, the task node has been determined to have been advanced by matching the node progress record with the time sequence constraints.

[0203] After matching the responsibility flow record with the responsibility transfer constraint, it can be determined that the undertaking unit has received the task. However, after matching the feedback submission record with the feedback closure constraint, no corresponding progress feedback event can be found. Therefore, in the project collaboration status record generated in this management phase, the node progress status is "progressed", the responsibility response status is "responded", the feedback complete status is "feedback missing", and the closure confirmation status is "conditions for confirmation not met", forming a stage deviation mark for feedback missing. Thus, it can be further determined whether this deviation constitutes a collaboration blocking event.

[0204] For example, in the rectification confirmation phase of a pump station renovation project, the construction unit has submitted rectification materials, and the supervision unit has completed the review. However, the construction unit has not formed a confirmation processing record. During the processing, the node progress status can be marked as progressed, and the responsibility response status can be marked as responded. However, since the construction unit, as the confirmation entity, has not formed a confirmation processing record, the closed-loop confirmation status is marked as confirmation missing, and a "closed-loop interruption" stage deviation mark is formed. This deviation mark can indicate that the current problem is not that the task has not been submitted, but that the confirmation link has not been closed, thus providing a basis for generating a rectification confirmation path or an acceptance review path.

[0205] Through the above implementation methods, the project collaborative status record uniformly expresses the progress of nodes, the response of responsible entities, the submission of feedback, and the confirmation of closed loop within the same management phase. This eliminates the need for manual review of multiple ledgers or judgment of each record in municipal engineering water conservancy and hydropower projects. Instead, it uses a project collaborative constraint diagram to summarize the sequence of project collaborative management event records in a relational manner and forms a stage deviation marker through the consistency relationship between states. This enables accurate differentiation of different types of management deviations, such as node delays, responsibility breakpoints, missing feedback, and closed loop interruptions.

[0206] The project collaboration status records are matched with preset collaboration judgment rules to identify collaboration blocking events, and the set of blocking impact ranges corresponding to the collaboration blocking events is determined based on the project collaboration constraint diagram. Specific implementation details include:

[0207] In one specific implementation, after generating project collaboration status records and corresponding management stage deviation markers, the project collaboration status records are matched with node deadline rules, responsibility feedback rules, and closed-loop confirmation rules to identify collaboration blocking events. These collaboration blocking events refer to management blockages in the management flow of municipal engineering water conservancy and hydropower projects, caused by situations such as node expiration, lack of response from responsible entities, missing feedback, unconfirmed rectification, unconfirmed acceptance, or incomplete archiving, preventing the normal progress of subsequent management nodes. Unlike ordinary overdue reminders, collaboration blocking events not only record an anomaly at a certain node but also further record the blocking node, blocking type, trigger time, associated responsible entity, and stage deviation marker corresponding to the anomaly. This allows for subsequent analysis of the impact of the blocking event on other nodes and responsible entities along the project collaboration constraint diagram.

[0208] In practice, the node progress status, responsibility response status, feedback integrity status, closed-loop confirmation status and stage deviation mark in the project collaboration status record are read first. Among them, the node progress status is used to indicate whether the current management node has been started, processed, completed or delayed.

[0209] The responsibility response status indicates whether the responsible party has completed the receipt, processing, feedback, or confirmation of the matter; the feedback completeness status indicates whether a complete feedback record has been formed for the corresponding management matter.

[0210] The closed-loop confirmation status is used to indicate whether feedback, rectification, acceptance, or archiving matters have been confirmed by the responsible entity with confirmation authority.

[0211] The stage deviation marker is used to indicate whether there are deviations such as node lag, responsibility breakpoints, missing feedback, or closed-loop interruption in the current management stage.

[0212] The node deadline rules can be pre-configured according to the project plan template, management node type and project management requirements. Each node deadline rule includes at least the management node identifier, the prerequisite node condition, the deadline start time, the allowed processing time and the type of valid progress record. The deadline start time can be the project plan issuance time, the prerequisite node completion time, the task assignment time or the time when the responsible entity receives the task.

[0213] Valid progress record types can include task reception records, processing records, feedback submission records, confirmation processing records, or archived handover records. When comparing the node progress status with the node deadline rules, if a management node exceeds the corresponding deadline and no valid progress record matching that node has been generated, a node overdue mark will be generated.

[0214] If a management node has exceeded its expiration date but has already generated a confirmation or archiving completion record, then no longer an expiration mark will be generated for the node.

[0215] If a management node has generated some records but lacks key progress records, such as only having reminder records but no feedback records from the responsible party, it can still be considered that no effective progress records have been generated.

[0216] The responsibility feedback rules are used to limit the response requirements of different responsible entities in the process of handling matters. Each responsibility feedback rule includes at least the responsible entity identifier, the corresponding management node, the feedback window, the response action, and the allowed feedback result. The feedback window can be determined according to the task assignment time, the problem registration time, the rectification submission time, or the review notification time.

[0217] Response actions can include receiving, processing, providing feedback, confirming, returning, or reviewing. When comparing the responsibility response status with the responsibility feedback rules, if the responsible party fails to create a receiving record, processing record, or feedback record within the specified feedback window, a responsibility non-response mark is generated.

[0218] If the responsible party has recorded the receipt but not the subsequent processing or feedback, it can be determined whether to generate a non-response mark based on whether the feedback window has expired.

[0219] If the responsible party generates a return record or rectification request, the record is considered a valid response, but the closed-loop confirmation rules will continue to determine whether a subsequent rectification loop is formed.

[0220] The closed-loop confirmation rule is used to determine whether a management matter has formed a complete closed loop from initiation, feedback, rectification to confirmation. Each closed-loop confirmation rule includes at least the matter type, the type of the initiating event, the type of the event to be matched, the confirmation subject requirements, and the conditions for completing the closed loop.

[0221] For task feedback items, a feedback submission event and a confirmation processing event should be matched;

[0222] For issues requiring rectification, a rectification submission event and a rectification confirmation event should be matched.

[0223] For acceptance items, an acceptance submission event and an acceptance confirmation event should be matched;

[0224] For archived items, an archive commit event and an archive receipt confirmation event should be matched;

[0225] When comparing the complete feedback status and closed-loop confirmation status with the closed-loop confirmation rules, if the feedback record is missing, the rectification result is not confirmed, the acceptance result is not confirmed, or the archiving result is not closed, a closed-loop interruption mark will be generated. If there is a feedback record but the confirmation result is returned, pending correction, or the review fails, the matter will not be considered as closed, but will be recorded as closed-loop interruption or closed-loop pending correction status.

[0226] After obtaining the node expiration flag, the responsibility non-response flag, and the closed-loop interruption flag, the collaborative blocking event is determined based on the above flags. Specifically, if the expiration flag of a single node has caused subsequent nodes to be unable to enter, then the expiration node is used as the blocking node to generate a collaborative blocking event.

[0227] If the failure to respond to the responsibility flag causes the matter to remain at the receiving or processing stage of the responsible party, a collaborative blocking event will be generated with the corresponding responsibility transfer node as the blocking node.

[0228] If the closed-loop interruption flag causes the problem, acceptance, or archiving items to be unable to be confirmed, a collaborative blocking event is generated with the corresponding confirmation node or closing node as the blocking node. Each collaborative blocking event records the blocking node, blocking type, trigger time, associated responsible entity, and corresponding stage deviation flag. The blocking type can include node overdue, responsibility unresponsive, feedback missing, rectification unconfirmed, acceptance unconfirmed, and archiving unclosed.

[0229] The trigger time can be the time of rule matching, the time of node expiration, or the time of closed-loop confirmation failure. The associated responsible entity is the entity that has an initiation, reception, processing, feedback, or confirmation relationship with the blocked node.

[0230] After identifying the collaborative blocking event, the set of blocking impact ranges corresponding to the collaborative blocking event is further determined along the project collaborative constraint diagram. The set of blocking impact ranges refers to the set of affected management objects obtained by starting from a collaborative blocking event and retrieving the time sequence constraints, responsibility transfer constraints, feedback closed loop constraints and blocking transmission constraints in the project collaborative constraint diagram.

[0231] This set includes affected tasks, associated responsible parties, matters requiring rectification, matters requiring confirmation, and project status requiring updates. The blockage impact scope set describes how a blocking event may affect not only the current node but also subsequent nodes, related responsible parties, and management phase statuses.

[0232] In practice, the blocking node corresponding to the collaborative blocking event is used as the starting point for retrieval. The constraint edges connected to the blocking node are read in the project collaborative constraint graph. The subsequent management nodes after the blocking node are retrieved along the time sequence constraints to determine the scope of subsequent tasks affected by node lag or node expiration.

[0233] For example, if a progress feedback node is overdue, its subsequent confirmation and processing node, problem rectification node, or archive handover node may not be able to proceed normally due to the lack of prior feedback results. Therefore, these nodes are included in the scope of affected tasks.

[0234] When searching along time-series constraints, you can search step by step according to the node order until you encounter a node that has completed a closed loop, a node that has no dependency on the blocking node, or the boundary of the project management phase.

[0235] Simultaneously, the responsible entities related to the blocked node are retrieved along the responsibility transfer constraints to determine the scope of related responsible entities that need to receive reminders, corrections, confirmations, or reviews. If the task corresponding to the blocked node is initiated by the construction unit, handled by the construction unit, and confirmed by the supervision unit, then all of the above entities may be included in the scope of related responsible entities. Among them, the responsible entities that have not completed the receiving, processing, feedback, or confirmation actions are marked as the primary handling entities, and the responsible entities that have completed the preceding actions but need to cooperate in corrections or reviews are marked as the collaborative handling entities.

[0236] By defining the scope of responsible parties through responsibility transfer constraints, we can avoid sending only general reminders to project leaders and instead clarify which specific entity should handle the matter, which entity should confirm it, and which entity should review it.

[0237] Further search along the feedback loop constraints for management items that have not been confirmed, and determine the items to be corrected and the items to be confirmed. If a task initiation event is not matched with a feedback submission event, the task is determined to be an item to be corrected.

[0238] If a rectification submission event is not matched with a confirmation processing event, the rectification item is identified as an item pending confirmation.

[0239] If an acceptance submission event exists but the confirmation result is returned or pending correction, then the acceptance item is identified as a pending correction item and the original confirmation node is retained.

[0240] By using feedback loop constraints for retrieval, the set of impact ranges of the blockage can include not only the affected nodes, but also the specific matters that need to be supplemented, confirmed, or reviewed.

[0241] Further, following the congestion propagation constraint, we retrieve management nodes that are affected by node absence, node lag, failure to respond to responsibilities, or closed-loop interruption. This includes:

[0242] Blocking propagation constraints are used to represent the impact of an abnormal node on subsequent or related nodes. For example, missing feedback may propagate to the confirmation processing node, missing confirmation may propagate to the archiving and handover node, and missing responsibility entity mapping may propagate to subsequent follow-up and task assignment nodes. When searching along the blocking propagation constraint, management nodes that have a propagation relationship with the blocking node are added to the blocking impact range set, and the propagation reason is recorded. The propagation reason can be missing preceding results, non-response of the responsible entity, missing confirmation results, interruption of closed-loop status, or inability to update project status.

[0243] After completing the above search, the affected tasks, associated responsible entities, matters to be rectified, matters to be confirmed, and project status to be updated are summarized to form a set of blocking impact ranges corresponding to the collaborative blocking event. The project status to be updated includes the pending progress status of subsequent nodes, the deviation status of the current management stage, the pending response status of responsible entities, the pending rectification status of feedback matters, and the pending confirmation status of closed-loop matters. The set of blocking impact ranges can be stored in association with the collaborative blocking event to generate a set of collaborative handling paths.

[0244] For example, in a flood control capacity improvement project, the project collaboration status record shows that the task receiving node has been completed, but the progress feedback node has not generated a valid feedback record within the specified period. An overdue node flag is generated based on the node deadline rules, a non-responsibility flag is generated based on the responsibility feedback rules, and a collaboration blocking event is generated using the progress feedback node as the blocking node.

[0245] Subsequently, by searching along the time-series constraints in the project collaboration constraint diagram, it was determined that subsequent confirmation processing nodes and archive handover nodes were affected.

[0246] By searching along the responsibility transfer constraints, the undertaking unit was identified as the primary entity responsible for handling the matter, and the supervision unit was identified as the entity responsible for subsequent confirmation.

[0247] Search along the feedback loop constraints to identify missing progress feedback records as items to be corrected;

[0248] By searching along the blockage propagation constraints, it is determined that the confirmation processing node is in a pending update state, and the final set of the blockage impact range includes:

[0249] The affected tasks are progress feedback tasks and confirmation processing tasks. The relevant responsible parties are the undertaking unit and the supervision unit. The items to be corrected are progress feedback materials, the items to be confirmed are feedback confirmations, and the project status to be updated is the deviation status of the task execution stage.

[0250] Through the above implementation method, this solution matches the node progress status, responsibility response status, feedback integrity status, and closed-loop confirmation status in the project collaboration status record with the corresponding rules to form distinguishable blocking markers such as node overdue, responsibility unresponsive, and closed-loop interrupted. Using the blocked node as the retrieval starting point, the solution determines the affected tasks, associated responsible entities, items to be corrected, items to be confirmed, and project status to be updated along the multiple constraint relationships in the project collaboration constraint diagram.

[0251] Based on the set of impact ranges of congestion, a set of collaborative handling paths is generated. Target handling paths are selected and converted into collaborative handling task packages, which are then assigned to the corresponding responsible entities. Then, handling feedback is received and written back to the project collaborative management event log sequence, updating the project collaborative status record and project collaborative constraint diagram, thus forming the intelligent collaborative management results for municipal engineering water conservancy and hydropower projects. Specific implementation content includes:

[0252] In one specific implementation, after determining the set of impact ranges corresponding to the collaborative blocking event, a set of collaborative handling paths is generated based on the set of impact ranges. The set of collaborative handling paths refers to several executable handling processes formed for the same collaborative blocking event based on the affected tasks, associated responsible parties, matters to be corrected, matters to be confirmed, and project status to be updated. Unlike ordinary reminders, the collaborative handling path does not only send a single notification to the responsible party, but determines which matters should be handled first, which responsible party should handle them, which project collaborative management event record should be written back to after handling, and whether subsequent confirmation needs to be triggered, based on the nodes, matters, responsible parties, and status update requirements included in the set of impact ranges.

[0253] Specifically, based on the affected tasks, associated responsible entities, matters to be rectified, matters to be confirmed, and project status to be updated in the set of blocked impact areas, responsibility follow-up paths, feedback correction paths, rectification confirmation paths, acceptance review paths, and phase adjustment paths are generated. Among them, the responsibility follow-up path is used to handle situations where the responsible entity does not respond or the matter remains in the receiving or processing stage. Its target is the responsible entity that has not formed a receiving record, processing record, or feedback record.

[0254] The feedback correction path is used to handle situations where feedback records are missing, feedback content is incomplete, or attachment indexes are missing. The target of this action is the responsible party that needs to supplement feedback materials, progress descriptions, or supporting materials.

[0255] The rectification confirmation path is used to handle situations where rectification results have been submitted but confirmation results have not yet been formed. The objects of this process are the rectification submission entity, the review entity, and the confirmation entity.

[0256] The acceptance review path is used to handle situations where acceptance materials are returned, acceptance results are not confirmed, or review opinions are not closed. The subjects of this process are the entity that submitted the acceptance and the entity that confirmed the acceptance.

[0257] The phase adjustment path is used to handle situations where blocking events have affected the status of subsequent management phases, requiring synchronous adjustments to the status of subsequent nodes, phase deviation markers, or task progress order.

[0258] When generating collaborative handling paths, each path corresponds to a set of executable handling actions. For example, a responsibility reminder path may include generating a reminder task, pushing it to the responsible party who has not responded, setting a feedback deadline, waiting to receive or process feedback, and triggering a confirmation node;

[0259] The feedback and correction process can include locating the missing feedback items, generating a correction list, requesting the responsible party to provide supplementary materials, submitting the correction results, and entering the confirmation and processing node.

[0260] The rectification confirmation process may include reading the rectification submission results, pushing them to the confirmation entity, requesting confirmation approval or returning for correction, and recording confirmation comments.

[0261] The acceptance review process can include reading the reason for acceptance rejection, pushing the review task, receiving the review result, and updating the acceptance confirmation status.

[0262] The adjustment path for each stage may include reading the affected subsequent nodes, pausing or resetting the status of the corresponding stage, and waiting for the preceding matters to be closed before reopening the subsequent nodes.

[0263] Furthermore, the urgency of each node in the collaborative processing path is determined, whereby the urgency of a node can be determined based on the trigger time of the collaborative blocking event, the remaining time of the node's deadline, and the importance of the corresponding management stage;

[0264] In practice, if the trigger time of the collaborative blocking event is later than the node deadline, or the remaining time of the node deadline is less than the preset reminder window, then the node urgency of that path is relatively high.

[0265] If the blocked node is located in a critical management phase, such as an annual planning node, a phase confirmation node, an acceptance confirmation node, or an archive handover node, then the node urgency of the corresponding path is higher than that of a normal feedback node.

[0266] If a blocking event has not yet exceeded its deadline but is close to the feedback window deadline, the path is marked as nearing expiration. The urgency level of the node can be set to three levels: high, medium, and low, or it can be set to status levels such as expired, nearing expiration, or normal pending, for subsequent path sorting.

[0267] Furthermore, the continuity of responsibility for each collaborative handling path is determined. The continuity of responsibility refers to the degree of continuous participation of the relevant responsible entities in the blocked nodes, matters to be rectified, and matters to be confirmed. In specific implementation, if the same responsible entity is involved in the processing actions before task reception, matter rectification, and result confirmation, then the continuity of responsibility for that path is high, indicating that the matter rectification or feedback can be completed relatively quickly through that responsible entity.

[0268] If a blocking event requires multiple responsible parties to handle it sequentially, such as the construction unit making corrections, the supervision unit reviewing, and the construction unit confirming, the system records the continuous flow relationship between the responsible parties and determines whether each responsible party has already formed a valid record in the preceding node.

[0269] If the preceding subject has been processed and only the confirmation subject remains unprocessed, then a path pointing to the confirmation subject will be generated first.

[0270] If there are missing records for the initiating entity, the processing entity, and the confirming entity, a path containing sequential processing of multiple entities will be generated.

[0271] Furthermore, the subsequent impact range of each collaborative handling path is determined. The subsequent impact range can be determined based on the number of affected tasks, the number of affected management stages, and the number of project statuses to be updated in the blockage impact range set. In specific implementation, if a blockage event only affects the current node, its subsequent impact range is relatively small.

[0272] If a blocking event simultaneously affects subsequent confirmation processing nodes, archive handover nodes, and the status of the corresponding stage, its subsequent impact will be significant.

[0273] If a blocking event prevents multiple management phases from updating, or requires multiple responsible parties to make corrections, confirm or review, this path should be given priority. The subsequent scope of impact can be determined by counting the number of affected tasks, the number of affected management phases, the number of items to be corrected, the number of items to be confirmed, and the number of project statuses to be updated, and recorded in the form of an impact scope level or a list of affected objects.

[0274] After obtaining the urgency of nodes, the continuity of responsibility, and the scope of subsequent impact, the set of collaborative handling paths is sorted and filtered. Specifically, the paths can be sorted firstly according to the urgency of nodes, and the paths that have exceeded or are about to exceed the deadline are placed at the top.

[0275] When nodes are equally urgent, priority is determined based on the scope of their subsequent impact, placing paths that have a greater impact on subsequent tasks or stage states at the forefront.

[0276] When the scope of impact is similar, priority is determined based on the continuity of responsibility. Paths that can be continuously processed, reviewed or confirmed by the current related responsible parties are placed at the top. After sorting, the collaborative handling path that matches the type of collaborative blockage and covers matters to be corrected, matters to be confirmed or the status of projects to be updated is determined as the target handling path.

[0277] The determination of the target handling path can adopt a hierarchical screening logic. First, candidate paths are screened according to the blocking type of the collaborative blocking event. When the blocking type is the responsibility non-responsibility type, the responsibility follow-up path is retained; when the blocking type is the feedback missing type, the feedback correction path is retained.

[0278] When the blocking type is "rectification unconfirmed", retain the rectification confirmation path; when the blocking type is "acceptance unconfirmed", retain the acceptance review path; when the blocking type causes the status of subsequent stages to be unable to be updated, retain the stage adjustment path.

[0279] Secondly, the candidate paths are matched against the items to be corrected, items to be confirmed, and items to be updated in the blockage impact set, and paths that cannot cover the current pending objects are deleted.

[0280] Next, the remaining paths are sorted in the following order: priority of node urgency, followed by the scope of subsequent impact, and then the continuity of responsibility.

[0281] Finally, the path ranked first is determined as the target processing path; when there are two paths that cover different objects to be processed, the two paths can be combined into a target processing path group and executed in the order of first correcting, then confirming, and then updating the stage status.

[0282] After the feedback is written back, the system reads the node progress status, responsibility response status, feedback completeness status and closed-loop confirmation status in the corresponding project collaboration status record again, and re-matches them with the node deadline rules, responsibility feedback rules and closed-loop confirmation rules. If the original node overdue mark, responsibility non-response mark or closed-loop interruption mark has been eliminated, the corresponding collaboration blocking event is marked as resolved, and the status of the pending project in the blocking impact range set is updated to processed.

[0283] If only partial correction or confirmation is completed, and there are still matters to be confirmed or corrected, then the collaborative blocking event is retained and its blocking impact range set is updated.

[0284] If the feedback results in a new reason for return or a new requirement for handling by the responsible party, the collaborative blocking event will be regenerated based on the updated project collaborative management event record sequence.

[0285] For example, when a collaborative blocking event is of the feedback missing type, the target handling path should be determined first from the feedback correction path; when a collaborative blocking event is of the responsibility non-response type, the target handling path should be determined first from the responsibility follow-up path; when a collaborative blocking event is of the closed-loop interruption type, the target handling path should be determined first from the rectification confirmation path, the acceptance review path, or the phase adjustment path.

[0286] After determining the target handling path, the target handling path is converted into a collaborative handling task package. The collaborative handling task package is a task data unit executed by the responsible party. Each collaborative handling task package includes at least a task identifier, a blocking event identifier, a responsible party identifier, a handling item, a feedback deadline, a confirmation node, and a write-back location. The task identifier is used to distinguish different handling tasks, and the blocking event identifier is used to associate the task with the collaborative blocking event from which it originated.

[0287] The responsible party identifier is used to identify the recipient of the task;

[0288] The "Disposal Items" section is used to clarify the specific actions that the responsible party needs to take, such as providing supplementary progress feedback, submitting rectification confirmation materials, completing acceptance review, or confirming the archiving status.

[0289] The feedback deadline is used to specify the time required to complete the task.

[0290] The confirmation node is used to determine which node or responsible entity will confirm the handling feedback after it has been submitted;

[0291] The write-back location is used to determine which project collaborative management event record, which status flag, or which constraint edge status the feedback should be written to.

[0292] After the task package is generated, the collaborative handling task package is assigned to the corresponding responsible entity according to the responsible entity identifier, and the task assignment time, task reception status and task processing status are recorded. The task reception status can include not received, received, processing, feedback received, returned and completed.

[0293] Task processing status can include pending, under correction, pending confirmation, confirmed, confirmed and returned, and closed loop.

[0294] By recording task assignment and processing status, it is possible to determine whether a task has entered an effective processing stage during subsequent feedback writing.

[0295] After the responsible party submits the handling feedback, the system receives the handling feedback, which may include the responsibility response result, the matter correction result, the rectification confirmation result, the acceptance review result, and the stage adjustment result;

[0296] The accountability response result is used to indicate whether the responsible party has received and processed the follow-up matter;

[0297] The result of the correction is used to indicate whether the missing feedback records, attachments, or explanatory documents have been supplemented;

[0298] The rectification confirmation result is used to indicate whether the rectification item has been confirmed as approved or returned for correction.

[0299] The acceptance review result is used to indicate whether the acceptance item has been reviewed and approved.

[0300] The phase adjustment result is used to indicate whether the phase state has been updated due to the blocking event.

[0301] After receiving the handling feedback, the handling feedback is written to the corresponding project collaborative management event record according to the write-back position in the collaborative handling task package. If the handling feedback is a supplementary progress feedback, it is written to the project collaborative management event record corresponding to the original feedback node, and the status mark of the project collaborative management event record is updated to be fed back or pending confirmation.

[0302] If the feedback is a rectification confirmation result, it will be written into the project collaborative management event record corresponding to the rectification confirmation node, and the closed-loop confirmation status will be updated.

[0303] If the feedback is related to the acceptance review result, it will be written into the project collaborative management event record corresponding to the acceptance confirmation node, and updated to review passed, returned for correction, or pending reconfirmation based on the result.

[0304] If the feedback is a result of a phase adjustment, it is written into the project collaborative management event record of the corresponding management phase, and the phase status and flow marker are updated. After the status marker and flow marker are updated, the project collaborative management event record sequence reflects the latest management flow status after the action.

[0305] Furthermore, the project collaboration status record is regenerated based on the updated project collaboration management event record sequence, and the graph node status, feedback closed-loop constraint status, and blocking transmission constraint status in the project collaboration constraint diagram are updated synchronously. If the items to be corrected corresponding to the original collaboration blocking event have been corrected, the feedback closed-loop constraint is updated from unclosed or to be corrected to pending confirmation or closed.

[0306] If the main body has been confirmed, the status of the corresponding graph node will be updated to confirmed, and the blocking propagation constraint can be updated to released or invalidated.

[0307] If the feedback is a return correction, the feedback closed-loop constraint remains in an unclosed state, and a new collaborative blocking event can be regenerated or the original blocking event can continue.

[0308] Through the above updates, the system can form a closed-loop management process from blockage identification, path orchestration, task assignment, handling feedback to status updates.

[0309] For example, in a drainage capacity improvement project, the set of blocked impact areas shows missing progress feedback nodes, and subsequent confirmation and processing nodes cannot be advanced. The associated responsible entities are the undertaking unit and the supervision unit. The system generates a responsibility reminder path and a feedback correction path, and determines the feedback correction path as the target disposal path based on the fact that the node has exceeded the deadline, the subsequent confirmation nodes are affected, and the undertaking unit is the direct handling entity.

[0310] Subsequently, a collaborative handling task package is generated, the task content is "supplementary submission of progress feedback materials", the feedback deadline is two working days, the confirmation node is the supervisor confirmation node, and the write-back location is the project collaborative management event record corresponding to the progress feedback node;

[0311] After the undertaking unit submits the supplementary materials, the system will write the supplementary results into the corresponding project collaborative management event record and update the feedback complete status to feedback complete.

[0312] After confirmation by the supervision unit, the feedback closed-loop constraint is updated to "closed-loop," the original blocking transmission constraint is released, and the stage deviation mark in the project collaboration status record is updated synchronously.

[0313] Through the above implementation methods, after forming a set of obstruction impact areas, multiple collaborative handling paths are generated based on the affected tasks, associated responsible parties, matters to be rectified, matters to be confirmed, and project status to be updated. Then, the target handling path is determined based on the urgency of the nodes, the continuity of responsibility, and the subsequent impact scope, so that different types of obstruction events can correspond to different handling methods. Finally, the responsible parties, handling matters, feedback deadlines, confirmation nodes, and write-back locations are clarified through collaborative handling task packages, so that the handling results can be directly written back to the project collaborative management event record sequence, and the project collaborative status record and project collaborative constraint diagram are updated simultaneously. This process transforms the abnormal handling in municipal engineering water conservancy and hydropower project management from manual urging to path-based handling and closed-loop write-back based on the obstruction impact area, which can improve the accuracy of multi-entity collaborative management.

[0314] Example 2: A smart collaborative management system for municipal engineering water conservancy and hydropower, such as Figure 2 As shown, it specifically includes:

[0315] The event log generation module is used to collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and organize the management records in sequence, and generate a project collaborative management event log sequence.

[0316] The constraint diagram construction module is used to perform collaborative relationship parsing on the sequence of project collaborative management event records based on the project plan template and management process rules, generate a project collaborative constraint diagram, and establish collaborative constraint relationships between different management nodes in the project collaborative constraint diagram;

[0317] The status summary module is used to summarize the status of the project collaboration management event record sequence based on the project collaboration constraint diagram, generate project collaboration status records, and form deviation markers for the corresponding management stages based on the status summary results of the management stages.

[0318] The blocking impact analysis module is used to match project collaboration status records with preset collaboration judgment rules, identify collaboration blocking events, and determine the set of blocking impact ranges corresponding to collaboration blocking events based on the project collaboration constraint diagram.

[0319] The path orchestration module is used to generate a set of collaborative handling paths based on the set of blocked impact ranges, filter target handling paths, and convert target handling paths into collaborative handling task packages and assign them to the corresponding responsible entities.

[0320] The closed-loop update module is used to receive feedback on handling and write it back to the project collaborative management event record sequence, update the project collaborative status record and project collaborative constraint diagram, and form the intelligent collaborative management results of municipal engineering water conservancy and hydropower projects.

[0321] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, ATA hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state ATA hard disk.

[0322] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0323] 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.

[0324] 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.

[0325] 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; 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, depending on actual needs.

[0326] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0327] 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 method for intelligent collaborative management of municipal engineering water conservancy and hydropower projects, characterized in that, include: Collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and organize the management records in sequence, and generate a project collaborative management event record sequence. Based on the project plan template and management process rules, perform collaborative relationship parsing on the project collaborative management event record sequence, generate a project collaborative constraint diagram, and establish collaborative constraint relationships between different management nodes in the project collaborative constraint diagram; Based on the project collaboration constraint diagram, the project collaboration management event record sequence is processed to summarize the management stage status, generate project collaboration status records, and form deviation markers for the corresponding management stages based on the summary results of the management stage status. The project collaboration status records are matched with preset collaboration judgment rules to identify collaboration blocking events, and the set of blocking impact ranges corresponding to the collaboration blocking events is determined based on the project collaboration constraint diagram. A set of collaborative handling paths is generated based on the set of blocked impact areas. Target handling paths are selected and converted into collaborative handling task packages, which are then assigned to the corresponding responsible entities. Receive and process feedback and write it back to the project collaborative management event record sequence, update the project collaborative status record and project collaborative constraint diagram, and form the intelligent collaborative management results of municipal engineering water conservancy and hydropower projects.

2. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 1, characterized in that: The process involves collecting management records generated during the management workflow of municipal engineering water conservancy and hydropower projects, uniformly encoding and sequentially organizing these records, and generating a project collaborative management event record sequence. Specific steps include: Obtain management records generated during the planning, task transfer, progress feedback, problem registration, rectification submission, confirmation and processing, and archiving and handover processes of municipal engineering water conservancy and hydropower projects; The project name, project number, management item, transfer node, responsible entity, occurrence time, processing result and associated attachment in the management record are parsed to remove duplicate records and fill in the missing node attribution information; A unified event code is generated based on the project identifier, management node identifier, responsible entity identifier, and time anchor point. Management records belonging to the same management node in the same project are grouped into project collaborative management event records. The project collaborative management event records are arranged according to the time anchor and management node sequence, and a source tag, status tag and flow tag are configured for each project collaborative management event record to generate a project collaborative management event record sequence.

3. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 1, characterized in that: Based on the project plan template and management process rules, perform collaboration relationship parsing on the project collaboration management event record sequence. Specific steps include: Extract the planning management nodes of municipal engineering water conservancy and hydropower projects based on the project plan template, and generate a plan node sequence according to the node name, node order and node deadline; Based on the management process rules, the actual flow nodes, responsible entity identifiers, time anchors, item numbers, and processing results are extracted from the project collaborative management event record sequence. The actual flow nodes are matched with the planned node sequence to determine the alignment results of consistent nodes, missing nodes, nodes ahead of schedule, nodes behind schedule, and newly added nodes. Based on the responsible entity identifier in the project collaborative management event log, a mapping relationship is established between the responsible entity and the corresponding management node, and the flow status of the responsible entity in the node receiving, processing, feedback and confirmation process is recorded; Based on the time anchors, event numbers, and processing results among the project collaborative management event records, the task initiation events, feedback submission events, rectification submission events, and confirmation processing events are matched in a closed loop to form node matching results, responsible entity mapping results, and closed loop matching results used to construct the project collaborative constraint diagram.

4. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 3, characterized in that: Generate a project collaboration constraint diagram and establish collaboration constraint relationships between different management nodes within the diagram. Specific steps include: The management nodes in the node matching results are used as graph nodes, and the graph nodes are associated with the corresponding project collaborative management event records, responsible entity mapping results, and closed-loop matching results; Based on the sequential relationship between the planned node sequence and the actual flow nodes, a time constraint is established between adjacent management nodes to limit the advancement order and the time limit relationship of the management nodes; Based on the status of receipt, processing, feedback and confirmation by the responsible party at different management nodes, responsibility transfer constraints are established to characterize the flow relationship of matters between the responsible parties; Based on the closed-loop matching results between task initiation events, feedback submission events, rectification submission events, and confirmation processing events, feedback closed-loop constraints are established to characterize whether management matters have been completed and confirmed. Based on the results of missing nodes, lagging nodes, missing responsibility entity mapping, and closed-loop matching failure, a blocking transmission constraint is established between the corresponding management node and subsequent related nodes, generating a project collaboration constraint diagram for subsequent management phase status summary processing and blocking impact scope analysis.

5. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 4, characterized in that: Based on the project collaboration constraint diagram, the project collaboration management event record sequence is processed to summarize the management stage status, generating project collaboration status records. Furthermore, deviation markers for the corresponding management stages are formed based on the summarized management stage status results. Specific steps include: The project collaborative management event record sequence is grouped according to the project identifier and management stage, and the node progress record, responsibility transfer record, feedback submission record and closed-loop confirmation record of the same project in the same management stage are extracted. The extracted node progress records are matched with the temporal constraints in the project collaboration constraint diagram to generate node progress status. Match the responsibility transfer records with the responsibility transfer constraints in the project collaboration constraint diagram to generate responsibility response status; Match the feedback submission records and closed-loop confirmation records with the feedback closed-loop constraints in the project collaboration constraint diagram to generate feedback complete status and closed-loop confirmation status. Based on the consistency relationship between node progress status, responsibility response status, feedback integrity status, and closed-loop confirmation status, a project collaboration status record is generated, and deviation markers are formed for the corresponding management stages when there are node delays, responsibility breaks, missing feedback, or closed-loop interruptions.

6. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 5, characterized in that: The project collaboration status records are matched with preset collaboration judgment rules to identify collaboration blocking events. The specific steps include: The pre-defined collaborative judgment rules include node deadline rules, responsibility feedback rules, and closed-loop confirmation rules; Read the node progress status, responsibility response status, feedback integrity status, closed-loop confirmation status, and stage deviation markers from the project collaboration status record; The node progress status is compared with the node deadline rules. When a managed node exceeds the corresponding deadline and no valid progress record is formed, a node overdue mark is generated. The responsibility response status is compared with the responsibility feedback rules. When the responsible party fails to form a receipt, processing or feedback record within the specified feedback window, a responsibility non-response mark is generated. The feedback integrity status and closed-loop confirmation status are compared with the closed-loop confirmation rules. When the feedback record is missing, the rectification result is not confirmed, the acceptance result is not confirmed, or the archiving result is not closed, a closed-loop interruption mark is generated. Based on node overdue flags, responsibility non-response flags, and closed-loop interruption flags, collaborative blocking events are identified, and the blocking node, blocking type, trigger time, associated responsible entity, and corresponding stage deviation flag are recorded for each collaborative blocking event.

7. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 6, characterized in that: The specific steps for determining the set of blocking impact ranges corresponding to coordinated blocking events include: Using the blocking node corresponding to the collaborative blocking event as the starting point for retrieval, read the timing constraints, responsibility transfer constraints, feedback loop constraints, and blocking propagation constraints connected to the blocking node in the project collaborative constraint diagram; Search for subsequent management nodes after the blocked node along the time sequence constraints to determine the scope of subsequent tasks affected by node lag or node expiration; Search for the responsible entities related to the blocked node along the responsibility transfer constraints, and determine the scope of related responsible entities that need to receive reminders, corrections, confirmations, or reviews; Search for management items that have not been confirmed by feedback along the feedback closed loop constraints, and determine the items to be corrected and the items to be confirmed; Search along the blockage propagation constraints to find management nodes that are affected by missing nodes, delayed nodes, unresponsive responsibilities, or closed-loop interruptions. Summarize the affected tasks, affected management stages, related responsible entities, items to be corrected, items to be confirmed, and project status to be updated to form a set of blockage impact scopes corresponding to collaborative blockage events.

8. The intelligent collaborative management method for municipal engineering water conservancy and hydropower projects according to claim 7, characterized in that: A set of collaborative handling paths is generated based on the set of blocked impact areas, and target handling paths are selected. Specific steps include: Based on the affected tasks, associated responsible parties, items to be rectified, items to be confirmed, and project status to be updated in the set of blocked impact areas, generate responsibility follow-up paths, feedback correction paths, rectification confirmation paths, acceptance review paths, and phase adjustment paths; The urgency of nodes in each collaborative handling path is determined based on the trigger time of the collaborative blocking event, the remaining time of the node deadline, and the importance of the corresponding management stage. The continuity of responsibility for each collaborative handling path is determined based on the continuous participation of the relevant responsible parties in the blocked nodes, matters to be rectified, and matters to be confirmed. The subsequent impact range of each collaborative handling path is determined based on the number of affected tasks, the number of affected management stages, and the number of project statuses to be updated in the blockage impact range set. The collaborative handling paths are sorted according to the urgency of the nodes, the continuity of responsibility, and the scope of subsequent impact. The collaborative handling paths that match the blockage type and cover matters to be corrected, matters to be confirmed, or project status to be updated are identified as the target handling paths.

9. A method for intelligent collaborative management of municipal engineering water conservancy and hydropower projects according to claim 8, characterized in that: The target handling path is converted into a collaborative handling task package and assigned to the corresponding responsible parties. Handling feedback is received and written back to the project collaborative management event log sequence. Specific steps include: A collaborative handling task package is generated based on the target handling path. The collaborative handling task package includes a task identifier, a blocking event identifier, a responsible entity identifier, handling items, a feedback deadline, a confirmation node, and a write-back location. The collaborative handling task packages are assigned to the corresponding responsible entities according to the identification of the responsible entities, and the task assignment time, task receipt status and task processing status are recorded. Receive feedback from the responsible party regarding the handling of the matter, including the results of the responsibility response, the results of the rectification, the results of the rectification confirmation, the results of the acceptance review, and the results of the phase adjustment. Write the handling feedback to the corresponding project collaborative management event record according to the write-back location, and update the status flag and flow flag in the project collaborative management event record sequence based on the handling feedback; Based on the updated project collaboration management event record sequence, the project collaboration status record is regenerated, and the graph node status, feedback closed-loop constraint status, and blocking transmission constraint status in the project collaboration constraint diagram are updated synchronously to form the intelligent collaboration management result of municipal engineering water conservancy and hydropower projects.

10. A municipal engineering water conservancy and hydropower intelligent collaborative management system, used to implement the municipal engineering water conservancy and hydropower intelligent collaborative management method according to any one of claims 1-9, characterized in that, include: The event log generation module is used to collect management records generated during the management process of municipal engineering water conservancy and hydropower projects, uniformly encode and organize the management records in sequence, and generate a project collaborative management event log sequence. The constraint diagram construction module is used to perform collaborative relationship parsing on the sequence of project collaborative management event records based on the project plan template and management process rules, generate a project collaborative constraint diagram, and establish collaborative constraint relationships between different management nodes in the project collaborative constraint diagram; The status summary module is used to summarize the status of the project collaboration management event record sequence based on the project collaboration constraint diagram, generate project collaboration status records, and form deviation markers for the corresponding management stages based on the status summary results of the management stages. The blocking impact analysis module is used to match project collaboration status records with preset collaboration judgment rules, identify collaboration blocking events, and determine the set of blocking impact ranges corresponding to collaboration blocking events based on the project collaboration constraint diagram. The path orchestration module is used to generate a set of collaborative handling paths based on the set of blocked impact ranges, filter target handling paths, and convert target handling paths into collaborative handling task packages and assign them to the corresponding responsible entities. The closed-loop update module is used to receive feedback on handling and write it back to the project collaborative management event record sequence, update the project collaborative status record and project collaborative constraint diagram, and form the intelligent collaborative management results of municipal engineering water conservancy and hydropower projects.

Images