Engineering milestone warning system and method based on impact domain calculation

Abstract

The application discloses an engineering milestone early warning system and method based on influence domain calculation, and belongs to the technical field of computer data processing. The application determines a change node and a change field category through field level difference identification, drives local influence domain search in a multi-relation network according to the change field category, and only performs incremental calculation and state updating within the influence domain. The application controls propagation stop through state fingerprint comparison, avoids full calculation, and configures differentiated propagation functions, buffering and blocking conditions for hierarchy, front and rear setting, interfaces, quality gating and evidence relations. The application automatically confirms a node completion state through completion condition expression and electronic evidence checking, prevents manual direct green setting, shares a unified state fingerprint with a disposal result, and reversely drives risk recalculation. The application can reduce repeated calculation amount after data updating, improve response speed, and realize real-time monitoring and hierarchical early warning of complex engineering multi-hierarchy milestones.

Description

Technical Field

[0001] This invention belongs to the field of computer data processing technology, specifically relating to an engineering milestone early warning system and method based on influence domain calculation, applicable to fusion devices, large scientific facilities, nuclear engineering, high-end equipment manufacturing and other complex engineering projects. Background Technology

[0002] Complex engineering projects typically consist of multiple overall systems, subsystems, key components, and business activities, with implementation covering stages such as design, procurement, manufacturing, testing, installation, commissioning, and acceptance. Taking fusion engineering construction as an example, the project plan includes not only high-level milestones such as overall completion and final system design review, but also numerous execution milestones such as interface document signing, equipment procurement, factory acceptance, and installation. There are coupling relationships between lower-level operational milestones and higher-level control milestones, subsequent tasks, and cross-system interfaces. A change in a design output, equipment delivery, or quality acceptance milestone may affect multiple systems and higher-level milestones.

[0003] The current project progress data is largely maintained using spreadsheets. Managers typically collect data from various systems weekly or monthly, then manually create fishbone diagrams, Gantt charts, or PowerPoint presentations to mark completed, near-completion, and delayed milestones. While this method is intuitive, the separation of data updates, status calculations, graphical displays, and notifications easily leads to version inconsistencies, update delays, and duplication of effort.

[0004] Some general-purpose project management software can generate Gantt charts, critical paths, or due date reminders based on task dates, but they typically focus on a single Work Breakdown Structure (WBS), a single predecessor / descendant relationship, or a task list. For complex projects involving multiple relationships such as hierarchical parent-child relationships, cross-system interfaces, quality gating, deliverable evidence, and supplier delivery, managers still need to manually determine which other nodes a change in one node will affect.

[0005] When data changes, existing software typically employs two approaches: the first involves a full scan, recalculation, and re-rendering of all tasks in the project; the second only modifies the state of the updated node. The former generates a large amount of redundant calculations, data transfers, and interface refreshes unrelated to the current change as the number of nodes and relationships increases, impacting real-time performance. While the latter involves less computation, it cannot automatically identify the impact of changed nodes on parent nodes, subsequent tasks, and cross-system interfaces.

[0006] Furthermore, the "complete" status in existing systems is typically manually selected by the responsible person or the completion percentage is entered as 100%. If necessary deliverables such as review minutes, approval pages, acceptance certificates, and original test data have not yet been generated, the node may still be displayed as green, leading to an inconsistency between the interface status and the actual technical status. SMS messages, emails, and to-do lists are also often sent by date via independent scheduled tasks, making it impossible to dynamically determine the recipients and escalation paths based on the scope of impact, node level, and handling status.

[0007] Therefore, the key to achieving "real-time display, real-time monitoring, and real-time early warning" for complex projects is not simply adding a color status or a sending channel, but solving the following fundamental problems: how to quickly identify the truly affected local nodes after changes in planned data; how to perform calculations only on that local area; how to apply different risk propagation and blocking rules for different relationships; how to confirm node completion with verifiable electronic evidence; and how to make the early warning, response, and visualization interfaces use the same calculation results.

[0008] In summary, the existing technology has at least the following shortcomings: The lack of a mapping mechanism between changed fields and the scope of impact means that changes to non-progress fields such as responsible persons or contact information may also trigger irrelevant full calculations. Data updates employ full scans and full refreshes, which increases the amount of repetitive calculations, retransmissions, and re-rendering as the number of nodes increases. When only the modified node is updated, its propagation effect on higher-level milestones, subsequent tasks, and cross-system interface nodes cannot be identified; Using the same propagation logic for hierarchy, pre- and post-position, interface, quality gating, and evidence relationship can easily lead to missed reports, false reports, or unlimited risk propagation. The completion status relies on manual selection and does not establish an actionable link between completion conditions and evidence of review, approval, acceptance, or deliverables. Warning messages, deviation handling, and interface display are maintained separately. The handling results cannot automatically trigger risk recalculation, and it is difficult to maintain consistency in status criteria. Summary of the Invention

[0009] The technical solution of this invention is used to solve the problems of existing complex engineering project management systems, which cannot quickly and accurately determine the affected local scope after changes in planned data, and can only perform full scan recalculation or only update the modified nodes while ignoring the propagation effect, resulting in low calculation efficiency, poor real-time performance, inaccurate risk propagation and inconsistent status caliber.

[0010] The present invention solves the above-mentioned technical problems through the following technical solutions: This invention provides an engineering milestone early warning system based on influence domain calculation, comprising: The data access and version management module is used to receive project planning data, generate a snapshot of the current valid data, and retain historical versions. The multi-relationship network construction module is used to build a multi-relationship network from project objects, milestone nodes, and relationship data; The difference identification module is used to compare the current valid data snapshot with the previous valid data snapshot at the field level to identify the changed nodes and the category of the changed fields corresponding to each changed node. The influence domain identification module is used to determine the seed node, the allowed relationship type, traversal direction and stopping condition based on the category of the changed field. Starting from the seed node, it performs a local traversal in the multi-relation network to obtain the influence domain affected in this round. The influence domain is a local subset of the multi-relation network. The incremental calculation module is used to calculate the basic state only for nodes within the influence domain, and to propagate the basic state in a differentiated manner within the influence domain according to the propagation function, buffering condition and blocking condition corresponding to different relationship types, thereby updating the risk status of each node within the influence domain. The status confirmation module is used to confirm whether a milestone node is allowed to enter the completed state based on a preset completion condition expression and the status of electronic evidence. The early warning output module is used to generate and output early warning information based on the risk status and the completed status, and to partially update the visualization interface.

[0011] Furthermore, the difference identification module categorizes the changed fields into at least four classes: date / progress, completion / evidence, relationship, level / threshold, and responsibility routing; the influence domain identification module is configured as follows: When the changed field category is a responsibility route, only the message route is updated, and the progress impact domain is not expanded; When the changed field category is date / progress, at least the subsequent nodes, parent nodes, and interface nodes should be searched. When the changed field category is Complete / Evidence, at least the current node, the parent node, and the gated subsequent nodes should be searched. When the changing field category is relational, search for the union of the old relation neighborhood and the new relation neighborhood.

[0012] Furthermore, the incremental calculation module includes a state fingerprint comparison unit; the state fingerprint comparison unit is used to generate a new state fingerprint after recalculation at any node, and compare the new state fingerprint with the historical state fingerprint of that node; if the new state fingerprint is the same as the historical state fingerprint, then the expansion from that node is stopped; if the new state fingerprint is different from the historical state fingerprint, then the adjacent nodes of that node are added to the pending queue; the state fingerprint includes at least the risk level, the expected impact date, the completion of the blocking status, the evidence status, and the warning stage.

[0013] Furthermore, the nodes in the multi-relationship network include at least milestone nodes, and the edges include at least hierarchical relationship edges, predecessor and successor relationship edges, and cross-system interface relationship edges; For hierarchical relationship edges, the incremental calculation module aggregates the risks of child nodes to the parent node according to the maximum value of key child nodes or the weighted sum method; For the preceding and following relationship edge, the incremental calculation module calculates the effective delay of the preceding node. The effective delay is the positive value after deducting the remaining buffer from the expected delay. When the effective delay is zero, the delay is absorbed by the buffer and does not propagate to subsequent nodes. For cross-system interface relationship edges, the incremental calculation module sets the input node to a blocked state or a warning state when the forced input is not delivered.

[0014] Furthermore, the status confirmation module includes a completion condition verification unit; The completion condition expression is composed of the completion percentage, the status of required deliverables, the approval status, the review conclusion, the acceptance conclusion, the status of quality control points, and the auditor's confirmation. When the completion condition expression is true, the completion condition verification unit writes the actual completion date and updates the node to the completed status; when the completion condition expression is false, the node is set to the pending review, incomplete evidence, or blocked status. Different milestone nodes at different levels correspond to different completion condition expressions.

[0015] This invention also provides an engineering milestone early warning method based on influence domain calculation, comprising the following steps: S101: Receive a data update event or system time event, and generate a snapshot of the current valid data; S102. Compare the current valid data snapshot with the previous valid data snapshot at the field level to obtain the changed nodes and the changed field categories corresponding to each changed node. S103. Construct the project planning data into a multi-relationship network; the nodes in the multi-relationship network shall include at least milestone nodes, and the edges shall include at least hierarchical relationship edges, predecessor and successor relationship edges, and cross-system interface relationship edges. S104. Determine the seed node, allowed relationship type, traversal direction and stopping condition according to the category of the changed field. Start from the seed node and perform local traversal in the multi-relation network to form a local influence domain. S105. Calculate the basic state only for nodes within the influence domain and generate new state fingerprints for each node; S106. Compare the new state fingerprint with the historical state fingerprints of each node. If they are different, propagate the basic state in the influence domain in a differentiated manner according to the propagation function, buffer condition and blocking condition corresponding to different relation types. S107. Confirm whether the milestone node is allowed to enter the completed state based on the preset completion condition expression and the electronic evidence status; S108. Generate early warning information based on the risk status and completed status of each node in the affected domain, and update the visualization interface locally.

[0016] Furthermore, in step S104, when the changed field category is a relational category or a deletion / deactivation category, the old relation in the previous valid data snapshot and the new relation in the current valid data snapshot are read simultaneously, and the old neighborhood and the new neighborhood are constructed respectively. The union of the old neighborhood and the new neighborhood is taken as the search range of the influence domain, so as to revoke the old propagation result and establish the new propagation result.

[0017] Furthermore, the differentiated propagation described in step S106 includes: For the preceding and following relationship, calculate the effective delay of the preceding node. The effective delay is the positive value of the expected delay minus the remaining buffer. If the effective delay is zero, stop propagating along the preceding and following relationship path. For hierarchical relationships, the risks of child nodes are aggregated to the parent node according to the maximum value of the key child nodes or the weighted sum method. For cross-system interface relationships, the input node is set to a blocked state or a warning state when forced input is not delivered.

[0018] Furthermore, the warning information in step S108 has a message key and an event version, wherein the message key consists of a milestone ID, a warning level, and an event version; If the risk status remains unchanged and the escalation time limit has not been reached, the same warning message will not be sent repeatedly. When the risk escalates, the scope of reception changes, the handling timeout occurs, or a node re-enters a risk state, a new event version is generated and an updated warning message is sent. The processing result is used as a new data update event to re-trigger steps S102 to S108.

[0019] Furthermore, the visualization interface is a fishbone diagram or a system navigation tree; partial updates to the visualization interface include: only refreshing the identifiers, status colors, labels, and relationship lines of the nodes affected in this round, while keeping the display content of the unaffected nodes unchanged.

[0020] The beneficial effects of this invention are as follows: This invention drives influence domain search by changing field types, avoiding irrelevant relationship traversal caused by changes in non-progress fields such as responsible persons and contact information; by comparing local influence domains and state fingerprints, propagation continues only when the key state of a node truly changes, reducing full-scale redundant calculations, redundant data transmissions, and full page re-rendering, thus improving response speed after data updates; by configuring different propagation functions, buffers, and blocking conditions for hierarchy, pre- and post-level, interfaces, quality gating, and evidence relationships, it improves the targeting of cross-level and cross-system risk identification and reduces false positives and false negatives caused by unified propagation rules; by processing node or relationship changes through the union of old and new neighborhoods, it can simultaneously revoke old propagation results and establish new propagation results, maintaining network state consistency; by completing conditional expressions and electronic evidence verification, it ensures that the interface state is consistent with review, approval, acceptance, and quality control processes. Maintaining consistent control points prevents false completions caused by manual greening; sharing the same status fingerprint across risk results, messages, actions, and partial interface refreshes reduces inconsistencies in status definitions between modules and enables automatic risk recalculation driven by action results; deduplication and escalation of alerts are achieved through message keys and event versions, reducing repeated sending of identical SMS or emails while retaining status escalation and timeout handling capabilities; local private deployment enables fast import of fixed Excel files, real-time viewing by multiple users, automatic aggregation, and tiered alerts without relying on public clouds, suitable for projects with high engineering data security requirements; standardized data models and configurable relationship rules allow expansion from fusion engineering progress scenarios to quality, procurement, suppliers, and other complex engineering operations without altering core event and impact domain calculation mechanisms. Attached Figure Description

[0021] Figure 1 This is a flowchart of the engineering milestone early warning system based on influence domain calculation according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a multi-relationship milestone association network according to an embodiment of the present invention; Figure 3 This is a schematic diagram of influence domain identification driven by change type in an embodiment of the present invention; Figure 4 This is a schematic diagram of the incremental calculation and state fingerprint stopping mechanism within the influence domain according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the milestone completion status confirmation based on electronic evidence according to an embodiment of the present invention. Figure 6 This is a schematic diagram of the hierarchical early warning and deviation handling closed loop of an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0023] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments: Example 1 This embodiment provides an engineering milestone early warning system based on influence domain calculation, which is described below in conjunction with... Figures 1 to 6 The technical solution of this invention is illustrated using a fusion engineering milestone monitoring software running within a unit's local area network as an example.

[0024] 1. Overall System Composition The system of this invention adopts a local private B / S architecture and can also be deployed as a standalone desktop application. The application server, database, file storage, task scheduler, and message queue all run on the local computer or internal server, and users access them through a browser or desktop client; for example... Figure 1 As shown, the system includes the following modules: The data access and version management module is used to receive the project's planned data, generate a snapshot of the current valid data, and retain historical versions. The difference identification module is used to compare the current valid data snapshot with the previous valid data snapshot at the field level, and identify the changed nodes and the changed field categories corresponding to each changed node. The multi-relationship network construction module is used to construct a multi-relationship network from engineering objects, milestone nodes and relationship data. The nodes in the multi-relationship network include at least milestone nodes, and the edges include at least hierarchical relationship edges, predecessor and predecessor relationship edges and cross-system interface relationship edges. The influence domain identification module is used to determine the seed node, the allowed relationship type, traversal direction and stopping condition according to the category of the changed field. Starting from the seed node, it performs a local traversal in the multi-relation network to obtain the influence domain affected in this round. The influence domain is a local subset of the multi-relation network. The incremental calculation module is used to calculate the basic state only for nodes within the influence domain, and to propagate the basic state in a differentiated manner within the influence domain according to the propagation function, buffering condition and blocking condition corresponding to different relationship types, thereby updating the risk status of each node within the influence domain. The status confirmation module is used to confirm whether a milestone node is allowed to enter the completed state based on a preset completion condition expression and the status of electronic evidence. The early warning output module is used to generate and output early warning information based on the risk status and the completed status, and to partially update the visualization interface.

[0025] 2. Standard Excel Data Structure The data access and version management module reads a fixed Excel template, monitors directory files, and receives data from online submissions or external interfaces; it generates valid data snapshots and retains versions. The initial implementation uses a fixed Excel workbook as the batch data entry point. Excel is a standardized data exchange medium, but not the only limitation of this invention; it can be replaced with databases, web forms, or business system interfaces later. The workbook may include a project structure table, a milestone plan table, a dependency table, a personnel permission table, a deliverable requirements table, and an early warning rule table. The field groups and functions of the milestone plan table are shown in Table 1; the other workbooks provide related data such as project hierarchy, dependencies, personnel routing, deliverable requirements, and early warning rules.

[0026] Table 1. Project Milestone Data Field Groups and Their Functions

[0027] When importing files, the system first reads the template version, worksheet name, and field mapping, and then performs checks for date validity, code uniqueness, reference existence, and relationship iteration. If the checks pass, an immutable snapshot is generated, recording the file summary, import time, importer, and number of valid records; data that fails checks forms an error list, which does not overwrite the previous valid snapshot.

[0028] 3. Multi-relationship milestone network like Figure 2 As shown, the multi-relation network construction module represents a complex project as a multi-relation milestone network G=(V,E,A), where V is a set of nodes, including at least project object nodes, milestone nodes, deliverable nodes, and organizational personnel nodes; E is a set of relation edges with types; and A is a set of nodes and relation attributes.

[0029] Each milestone node must have at least the milestone ID, system code, level, baseline date, current planned date, expected date, actual date, completion percentage, responsible person, completion conditions, evidence status, risk threshold, and historical status fingerprint. Each relation edge e must have at least the relation type τ(e), propagation direction dir(e), propagation weight w(e), remaining buffer b(e), blocking marker block(e), maximum propagation depth, and propagation function fτ.

[0030] Table 2. Relationship types, propagation effects, and example attributes of multi-relationship networks

[0031] 4. Change event and field-level difference identification The system can be triggered by data update events or time events. Data update events include importing Excel files, detecting file write completion in the monitoring directory, submitting data via the web interface, push notifications from the procurement or quality system, and completion of plan change approvals; time events include entering the alert window, reaching the planned date, and the expiration of the processing deadline.

[0032] The difference identification module uses the milestone unique code as the primary key and compares the current valid snapshot with the previous valid snapshot field by field to obtain the newly added nodes, deleted nodes, modified nodes, and their changed field sets. The changed fields are then categorized into date / progress, completion / evidence, relationship, level / threshold, responsibility routing, or deletion / deactivation categories.

[0033] Table 3. Categories of Changed Fields, Examples, and Default Impact Domain Strategy

[0034] 5. Identification of local influence domains like Figure 3 As shown, the influence domain identification module uses the set of changed nodes as a seed and selects the allowed relationship type, direction, maximum depth, and stopping threshold based on the changed field type mapping table. Therefore, when the responsible party changes, only the message route is updated; when the expected date changes, subsequent, superior, and interface nodes are searched; when the evidence changes, the current node, parent node, and gated nodes are searched. The specific method is as follows: (1) Add new, modified, and deleted nodes, as well as time-triggered nodes, to the seed queue and record the category of their respective changed fields; (2) Based on the change field category, read the relationship selection rules to determine the traversable edge type, direction, maximum depth and stopping condition; (3) Starting from the seed node, perform breadth-first, depth-first, or topological traversal and add the adjacent nodes that meet the conditions to the candidate set; (4) Calculate the initial propagation value for candidate relations; if the delay is completely absorbed by the remaining buffer, the relation is marked as hint only, or the propagation value is below the threshold, stop expanding along the traversal search path; (5) Add the selected nodes and edges to the influence domain and record the propagation path and reason for the inclusion of the nodes; (6) For relationship deletion or node deactivation, read the old relationship from the previous snapshot, construct the union of the old neighborhood and the new neighborhood, so as to revoke the old propagation result and establish the new propagation result.

[0035] The local influence domain can be represented as I=(V I E I ,P I ), where V IE represents the set of nodes affected in this round. I Let P be the set of relation edges participating in the computation. I This describes the propagation path from the seed node to each affected node and the reason for inclusion. I It can be used for interface explanations of "why the warning was issued", audit trails, and reversal of actions after closure.

[0036] 6. Incremental calculation and state fingerprint within the influence domain like Figure 4 As shown, the system's incremental calculation module only performs calculations on nodes within the influence domain. Each node generates a state fingerprint F after recalculation. i The status fingerprint should include at least the risk level, the expected date of impact, the completion of the blocking status, the evidence status, and the warning stage.

[0037] The system will generate a new status fingerprint F i_new Compared to the previous version's status fingerprint F i_old Compare; if all key components are the same, stop expanding from that node; if at least one key component changes, calculate the adjacent node input according to the corresponding relationship direction, and add the adjacent nodes that meet the propagation conditions to the queue to be processed.

[0038] The basic state of a node can be approximated by its time approximation T. i Expected delay amount D i Schedule Deviation P i Degree of lack of evidence C i and historical performance parameters H i The following weighted expression is only one possible implementation; in practice, a rule tree or a combination of rules and a weighted model can be used: B i =αT i +βD i +γP i +δC i +ζH i Among them, B i The node's basic state is represented by α, which is the weight of time approximation, β, which is the weight of expected delay, γ, which is the weight of schedule deviation, δ, which is the weight of evidence missing, and ζ, which is the weight of historical performance parameters.

[0039] The core of this invention does not lie in limiting a specific risk formula, but rather in ensuring that the basic state is updated only within a local influence domain and propagates through different relation functions. To prevent circular dependencies from causing infinite propagation, strongly connected components can be compressed, and current access version numbers, maximum iteration counts, or fingerprint stability conditions can be set. When an unreasonable cycle is detected, the system outputs a relation verification alarm.

[0040] 7. Risk propagation due to differences in multiple relationships This invention does not use a uniform rule of "directly adding the number of delay days". Instead, it configures different input quantities, directions, buffer absorption, amplification or attenuation rules, blocking conditions and stopping conditions for different relationship types.

[0041] For the preceding node j to the subsequent node i, first calculate the effective delay d. eff If the expected delay of the preceding node is d j The relational residual buffer is b ji ,but: d eff =max(0,d j -b ji ) When d eff When d is 0, the delay is absorbed by the buffer and does not propagate further to subsequent events; when d is 0... eff When the value is greater than 0, update the earliest affected date or dependency risk of subsequent nodes.

[0042] For hierarchical parent-child relationships, the risk of child nodes can be aggregated to the parent node according to the maximum value of key child nodes, weighted sum, or other rules. For key child nodes marked as "must be completed", even if other child nodes are normal, the risk of the parent node can be raised to a preset lower limit.

[0043] For cross-system interface relationships, the system determines propagation based on interface necessity, main propagation direction, planned delivery time, and alternative status. If a mandatory input is not delivered, the input node can be set to blocked or at least given a yellow warning; non-mandatory interfaces only generate a notification and do not change the completion status of subsequent nodes.

[0044] For quality, acceptance, and evidence relationships, the main propagation is the "blocking state." When a review fails, acceptance is unsatisfactory, or a required approval page is missing, a node cannot be confirmed as complete, and subsequent tasks that depend on that node cannot enter the completed state. When the gating condition is closed, the system recalculates the corresponding influence domain and removes the block.

[0045] 8. Status confirmation based on electronic evidence like Figure 5 As shown, the system's status confirmation module separates "execution progress" and "completion confirmation." The responsible person can fill in the completion percentage, expected date, and completion request, but cannot directly set the node status to green. Each milestone is associated with a completion condition expression C_i, which consists of the completion percentage, required deliverables, approval status, review conclusion, acceptance conclusion, quality control points, and auditor confirmation. That is: C_i = (Completion Rate = 100%) AND (Required Deliverables Valid) AND (Review / Acceptance Passed) AND (Quality Control Points Closed) Here, "AND" stands for logical AND operation, meaning that all completion conditions must be met simultaneously; if any condition is not met, C_i is false. Only when C_i is true will the system write or confirm the actual completion date and update the node to "Confirmed Completion"; otherwise, the node enters the "Pending Review" or "Blocked" state. For nodes completed later than the baseline date, the system retains the "Delayed Completion" attribute, which can be filled in green with a delay indicator, indicating that the technical work has been closed while retaining historical deviations.

[0046] Different milestone levels can be configured with different evidentiary conditions. For example, L1 milestones may require the signature pages of interface control documents and verification reports; L2 milestones may require original test data, inspection records, or factory acceptance documents; and L3 milestones may require work records, WBS correlation, and confirmation from the responsible engineer.

[0047] 9. Status determination and real-time fishbone diagram display System status includes at least four states: Not started, Normal progress, Near-expiration warning, Delayed or high risk, Pending review, and Completed. Node shapes represent levels L0 to L3, and colors or textures represent execution status. Avoid using the same color to represent both level and risk.

[0048] Table 4 Milestone Status, Judgment Meaning, and Display Suggestions

[0049] The term "real-time" in this invention refers to the system automatically completing difference identification, impact domain calculation, status update, and message triggering after effective data import, online data entry, external interface events, or system time events occur, without requiring manual re-creation of charts. It receives the affected node IDs, updated fields, and relationship lists for this round, and only updates the position, color, label, and connection of the corresponding nodes in the fishbone diagram, as well as the relevant statistics in the cockpit, without retransmitting and rendering all project data.

[0050] 10. Tiered early warning, message deduplication, and closed-loop processing like Figure 6 As shown, the early warning output module determines the recipient, notification channel, processing time limit, and escalation path based on unified incremental calculation results, combined with risk level, milestone level, number of affected nodes, highest level of impact, early warning duration, and handling status. SMS and email are merely output channels; the main technical logic is the automatic linkage between risk status and handling process.

[0051] The system generates a message key K = Milestone ID + Warning Level + Event Version for each warning event. If the status remains unchanged and the escalation time limit has not been reached, the same information will not be sent repeatedly; a new event version will be generated when the risk escalates, the reception scope changes, the handling timeout occurs, or the node re-enters a risk state.

[0052] Yellow alerts automatically generate explanatory tasks, requiring the responsible party to update the expected date, explain the reasons, and propose preliminary measures within a specified working day. Red alerts automatically generate deviation analysis and corrective action tasks, which are then escalated to the system manager, engineering office, or management level based on the node level. After the data is written back to the node attributes, it triggers impact domain identification and incremental calculation again as a new data event. Closure conditions include at least risk reduction below the threshold, completion of necessary measures, approval of evidence review, and confirmation by the reviewer.

[0053] When SMS or external email gateways are unavailable, in-system to-do lists and interface alerts can still function, and messages awaiting delivery will be queued locally. To meet engineering information security requirements, external SMS messages may only contain the node code, alert level, and processing time limit; detailed technical information requires logging into the intranet software.

[0054] Example 2 This embodiment provides an engineering milestone early warning method based on influence domain calculation, which specifically includes the following steps: S101, Receive fixed-format Excel import events, online data events, external interface events, or system time events; S102. Parse the data according to the template version and perform uniqueness, date, enumeration, reference relationship, cycle relationship and evidence rule verification; S103. Generate a snapshot of the current valid data and compare it with the previous valid snapshot at the field level to obtain the added, modified, deleted and time-triggered nodes. S104. Determine the seed node based on the category of the changing field, as well as the allowed relation type, direction, depth, and stopping condition for traversal; S105. Starting from the seed node, search the multi-relationship network to form a local influence domain that includes the affected nodes, the relationships involved in the calculation, and the propagation path; S106. Calculate the basic status of nodes within the affected domain, including time, progress, expected delays, evidence, and historical performance. S107. Calculate the propagation risk or blocking status of associated nodes according to the propagation function, residual buffer and blocking condition corresponding to different relation types. S108. Generate a new state fingerprint for the node and compare it with the old fingerprint; continue to perform incremental calculations on the corresponding adjacent nodes only when the state fingerprint changes; S109. Verify deliverables, review, acceptance and quality control points according to the completion condition expression, and confirm whether the node is allowed to enter the completed state. S110. Determine the warning status based on the risk value, blocking status, and node level, and generate an explanation of the affected area and the cause of the spread; S111, partially update the fishbone diagram, system navigation, cockpit and reports, and generate system to-dos, emails or text messages according to hierarchical rules; S112, record the early warning confirmation, cause, measures, approval, review and closure information; the handling result is re-entered as a new event into S103 or S104.

[0055] Working principle Conventional solutions typically involve "importing data into Excel, determining colors based on dates, and sending reminders to responsible parties." The core difference of this invention lies in the following: the system first determines which relationships and nodes might be affected by the changed fields, forming a local influence domain; then, it executes different incremental propagation methods based on relationship type only within this influence domain, controlling the propagation's cessation through state fingerprinting; simultaneously, electronic evidence determines whether a node has been completed. Fishbone diagrams, SMS messages, emails, and reports are merely application carriers of the above calculation results. This invention operates on the basic principles of "event-driven, local calculation, relationship propagation, evidence confirmation, and closed-loop feedback," as detailed below: (1) The system monitors the completion of writing an Excel file, user submission, external interface push, and system time conditions. Any valid event will become a pending event. (2) The system compares the current data with the previous valid snapshot at the field level to determine the changed nodes and the types of changed fields, thereby distinguishing between date changes, evidence changes, relationship changes and changes only in the responsibility route; (3) The type of the changing field determines the type and direction of the relationship to be traversed in this round. The system only includes nodes that may be affected in the influence domain and retains the propagation path and the reason for inclusion. (4) The system processes nodes within the affected domain in a queue. After the nodes are recalculated, a state fingerprint is generated. The fingerprint is only propagated to the next associated node when it changes. The propagation stops when the fingerprint is stable or the propagation amount is absorbed by the buffer. (5) The completion status of a node is automatically determined by the completion condition expression. The completion ratio only indicates the progress of execution. The node is confirmed as completed only after all necessary evidence, review and acceptance and control points are met. (6) The fingerprint in the same state simultaneously drives the fishbone diagram partial refresh, cockpit statistics, weekly / monthly report data, early warning messages and deviation handling tasks, avoiding inconsistencies caused by multiple modules calculating separately; (7) After the responsible person submits the reasons, measures or new expected date, the handling result is re-entered into the system as a data change event, forming a cycle of "early warning - analysis - measures - approval - recalculation - closure / upgrade"; When running locally, data reading, network construction, influence domain search, calculation, evidence verification, and interface refresh are all completed on the local computer or internal server; SMS and email can be sent through the unit gateway, and the unavailability of the gateway does not affect the system's alerts and pending tasks.

[0056] This invention constructs complex engineering objects, L0 to L3 milestones, pre- and post-tasks, cross-system interfaces, and completion constraints into a multi-relational network with relation types and attributes. It compares the current data with the previous valid data snapshot at the field level to determine changed nodes and their changed field categories. Based on the changed field category, it selects the relation type to be traversed, the traversal direction, depth, and stopping condition, and constructs a local influence domain starting from the changed node. It calculates the basic state of nodes only within the local influence domain and calculates the state of associated nodes according to the propagation function, residual buffer, and blocking condition corresponding to different relation types. It generates a new state fingerprint for each node and compares it with the old state fingerprint. Incremental calculations are only performed on the corresponding adjacent nodes when the state fingerprint changes. Based on the incremental calculation results, it outputs the set of affected nodes and the warning status, and locally updates the visualization interface. The changed field categories in this invention include date / progress, evidence, relation, and responsibility routing, with different categories corresponding to different influence domain strategies. When a relation changes, it calculates the union of the old neighborhood of the previous snapshot and the new neighborhood of the current snapshot to revert the old propagation result and establish a new one. The state fingerprint includes at least the risk level, the expected impact date, and the completion blocking status. Pre- and post-relationships use the effective delay amount after deducting the remaining buffer from the delay amount; hierarchical relationships are aggregated by key; cross-system interfaces generate blocking or prompts based on mandatory input markers. Milestone completion is jointly confirmed by executable completion condition expressions, required electronic evidence, review / acceptance conclusions, and quality control points; users cannot directly set it as completed. Warning events have message keys and event versions, supporting deduplication, confirmation, timeout escalation, and reverse triggering of impact domain recalculation based on handling results. The display module only refreshes the affected nodes, relationship connections, and related statistics for the current round. The system is deployed using a local server, LAN B / S, or standalone private deployment.

[0057] This invention establishes a mapping mechanism between changed fields and their impact scope, avoiding irrelevant full calculations triggered by changes in non-progress fields such as responsible persons or contact information. It overcomes the problems of redundant calculations, redundant transmissions, and re-rendering caused by full scans and full refreshes. While updating modified nodes, it automatically identifies their propagation impact on higher-level milestones, subsequent tasks, and cross-system interface nodes. Differentiated propagation logics are used for hierarchical, pre- and post-level, interface, quality gating, and evidence relationships to prevent missed reports, false alarms, or unlimited risk propagation. The completion status is executablely associated with review, approval, acceptance, or deliverable evidence to prevent manual greening. The same calculation result is used for warning messages, deviation handling, and interface display, enabling automatic risk recalculation based on handling results and maintaining consistency in status reporting.

[0058] This invention provides a real-time monitoring and early warning technology for complex engineering milestones operating in a local computer or LAN environment. When changes occur in standard Excel or other data sources, the system can identify the scope of impact of the change without indiscriminately recalculating all nodes, completing local incremental calculations, cross-relationship risk propagation, evidence verification, and early warning output. Through field-level difference comparison, add, modify, delete, and time-triggered events are converted into seed nodes with changed field categories. Based on the changed field category, the relationship type, direction, depth, and stopping condition to be traversed are selected to form a traceable local influence domain. The node state is recalculated only within the influence domain, and the comparison of the old and new state fingerprints determines whether to continue propagating to adjacent nodes. Propagation functions, residual buffers, blocking conditions, and stopping conditions are configured for hierarchical parent-child, predecessor-follower, cross-system interfaces, quality / acceptance gating, and deliverable evidence relationships, respectively. An executable completion condition expression and electronic evidence status confirm whether a node is allowed to enter the "completed" state, preventing manual direct greening. The same incremental calculation result is synchronously used for fishbone diagram partial refresh, dashboard statistics, SMS / email / to-do routing, and deviation handling closed loop. This invention represents the relationships between engineering objects, L0 to L3 planning levels, task sequence, cross-system interfaces, quality or acceptance gates, and deliverable evidence as a typed relational network. When changes occur in fixed-format Excel data, online data, external business system data, or system time, a set of locally affected nodes is identified. Incremental state calculations and differentiated risk propagation are performed within this set, and the local software's fishbone diagram, dashboard, to-do list, and tiered early warning information are updated accordingly. This invention does not rely on simple data import, color display, or message sending as its primary source of creativity. Instead, its main innovation lies in "change type-driven impact domain identification + incremental calculation within the impact domain + multi-relationship differentiated risk propagation," with "electronic evidence-driven state confirmation + risk and handling process linkage" as complementary innovations.

[0059] This invention employs an "event-driven, local computation, relationship propagation, evidence confirmation, and closed-loop feedback" mechanism as its core. The system monitors events such as Excel changes, user submissions, external interface pushes, or timed conditions. Upon triggering, it compares the current data with the previous valid snapshot at the field level, identifying changed nodes and the types of changed fields (date, evidence, relationship, or responsibility routing). The type of changed field directly determines the type, direction, and scope of relationships to be traversed in this round. Starting only from the changed node, potentially affected nodes are included in the local influence domain, and the propagation path and reason for inclusion are preserved, avoiding irrelevant fields triggering a full recalculation.

[0060] Within the local influence domain, the system processes each node in a queue, applying differentiated propagation functions, residual buffers, and blocking conditions based on different relationship types (hierarchical, predecessor-follower, cross-system interface, quality gating, evidence relationship) to calculate the node's basic state and generate a state fingerprint. Propagation continues to adjacent nodes only when the fingerprint changes; otherwise, it stops. The node's completion status is jointly determined by the executable completion condition expression, required electronic evidence, review and acceptance, and control points; users cannot directly mark it as green. The same state fingerprint synchronously drives the partial refresh of the fishbone diagram, cockpit statistics, early warning messages, and deviation handling, avoiding inconsistencies between multiple modules.

[0061] The warning events have message keys and versions, supporting deduplication, confirmation, and timeout upgrades. The handling results (cause, measures, new date) are re-entered into the system as data change events, forming a closed loop of "warning—analysis—measures—approval—recalculation—closure / upgrade". The system is deployed locally on a server, LAN B / S, or standalone private platform. Data reading, network construction, calculation, and interface refreshing are all completed locally. SMS and emails are sent through a gateway; gateway unavailability does not affect internal warnings and pending tasks. Overall, this invention's main innovations are change type-driven impact domain identification, incremental calculation within the domain, and multi-relationship differentiated propagation, complemented by evidence-driven status confirmation and risk handling linkage, overcoming the shortcomings of traditional methods such as full scanning, duplicate calculations, and manual greening.

[0062] This invention systematically integrates four relatively independent technical means: local influence domain search driven by changing field types, incremental stopping mechanism for state fingerprint comparison, multi-relationship differential propagation, and completion confirmation driven by electronic evidence. It solves the long-standing technical challenge in complex project schedule management—how to quickly and accurately determine the scope of impact after local changes—a problem that has not been effectively addressed by existing technologies. These four means are mutually reinforcing and indispensable: without field type-driven approaches, irrelevant calculations triggered by non-schedule fields cannot be avoided; without state fingerprint stopping, local influence domain calculations may continue to spread indefinitely; without differential propagation, the risk propagation logic of different business relationships cannot be uniformly expressed; and without electronic evidence confirmation, state updates and completion confirmation cannot form a closed loop. This combined solution is not a simple superposition of the means, but an organic whole designed to solve the same technical problem, producing a systematic technical effect of local change → local calculation → local refresh → local closed loop, which is non-obvious.

[0063] Specific examples: (1) Date changes trigger local incremental updates A fusion engineering database contains 438 milestone nodes. After a user imported a new version of Excel, the system discovered that the estimated completion date of an L3 node changed from August 31, 2026 to September 20, 2026, and the completion percentage changed from 40% to 45%. The difference identification module categorized the above fields as date / progress changes.

[0064] The impact domain module selects subsequent, superior, and cross-system interface relationships, performing a local search starting from the L3 node. Assume the search results include the changed node, two subsequent nodes, one L2 parent node, one L1 parent node, and three interface nodes, totaling eight nodes. The system only performs basic state calculations and risk propagation on these eight nodes, without recalculating all 438 nodes. This number is used to illustrate the processing method; the actual impact domain is determined by engineering relationship data and stopping conditions.

[0065] The pre-propagation module first absorbs the delay using the remaining buffer, and updates the earliest affected date for subsequent nodes with insufficient buffer. The hierarchical propagation module aggregates the risks of critical L3 nodes to L2 and L1. The interface propagation module only generates blocking or high-risk warnings for interface nodes marked as mandatory input. Finally, changed nodes are displayed in red, and nodes that have not yet been actually delayed but have been affected are displayed in yellow. The interface only refreshes the nodes and related statistics.

[0066] (2) Lack of evidence prevents nodes from being greened The completion conditions for a certain L2 milestone are: 100% completion rate, design report uploaded, review minutes uploaded, approval page approved, and associated quality control points closed. The responsible person entered 100% completion rate, but the approval page has not yet been uploaded. The evidence confirmation module calculates C. i If the result is false, set the node status to "Pending review / Incomplete evidence" and update the trusted completion status of the parent node along the hierarchical relationship.

[0067] After the approval page is uploaded and approved, the system generates evidence-based change events, recalculates the current node, parent node, and gated subsequent nodes; when all completion conditions are met, the system confirms the actual completion date and updates the node to green.

[0068] (3) When modifying a relation, calculate the old neighborhood and the new neighborhood. A user changes the prerequisite task of a subsequent node from node A to node B. If the system only reads the new relationship, it will be unable to undo the historical risks created by node A for subsequent nodes. To address this, this invention reads the old relationship from the previous valid snapshot and the new relationship from the current snapshot, constructs the old neighborhood and the new neighborhood respectively, and takes the union of the two. In the same round of incremental computation, the propagation input of A is undone, and a new propagation input for B is established, avoiding residual error warnings after the relationship change.

[0069] (4) The outcome of the disposal drives risk recalculation When a red alert is triggered at an L1 node, the system generates a deviation analysis task. The responsible person submits resource adjustment measures and advances the expected completion date by 10 days. After approval by the reviewer, the handling module writes the new expected date and measure status back to the node attributes. This write serves as the identification of the new date / handling event triggering the impact domain, and the system recalculates subsequent and interface nodes. If the risk decreases, the red alert is automatically downgraded to yellow or closed, and a complete version record is retained.

[0070] Example 3 This embodiment provides an electronic device, including a memory and a processor.

[0071] The memory is used to store a computer program that supports the processor in executing the engineering milestone early warning method based on influence domain calculation as described in Embodiment 2. The memory can be a high-speed random access memory or a non-volatile memory, such as a disk storage device, flash memory device, or other solid-state storage device.

[0072] The processor is configured to execute a program stored in the memory. The processor may be a general-purpose central processing unit, a dedicated processor, a microprocessor, or a digital signal processor.

[0073] The electronic device may also include a communication interface for exchanging data with other computing nodes or storage devices. The communication interface may be a wired interface (such as an Ethernet interface) or a wireless interface.

[0074] The electronic device may also include input / output interfaces for connecting peripheral devices such as displays, keyboards, and mice, so that users can view the computing status and input control commands.

[0075] Example 4 This embodiment provides a storage medium on which a computer program is stored.

[0076] The storage medium can be any medium capable of storing program code, including but not limited to: USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, optical disk, flash memory card, etc.

[0077] The computer program is executed by the processor to perform the steps of the engineering milestone early warning method based on influence domain calculation in Embodiment 2.

[0078] The storage medium can be located on a single computing device or distributed across multiple computing devices, such as in a distributed storage system. The program can be loaded onto a single processor for execution or loaded onto multiple processors for parallel execution.

[0079] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An engineering milestone early warning system based on influence domain calculation, characterized in that, include: The data access and version management module is used to receive project planning data, generate a snapshot of the current valid data, and retain historical versions. The multi-relationship network construction module is used to build a multi-relationship network from project objects, milestone nodes, and relationship data; The difference identification module is used to compare the current valid data snapshot with the previous valid data snapshot at the field level to identify the changed nodes and the category of the changed fields corresponding to each changed node. The influence domain identification module is used to determine the seed node, the allowed relationship type, traversal direction and stopping condition based on the category of the changed field. Starting from the seed node, it performs a local traversal in the multi-relation network to obtain the influence domain affected in this round. The influence domain is a local subset of the multi-relation network. The incremental calculation module is used to calculate the basic state only for nodes within the influence domain, and to propagate the basic state in a differentiated manner within the influence domain according to the propagation function, buffering condition and blocking condition corresponding to different relationship types, thereby updating the risk status of each node within the influence domain. The status confirmation module is used to confirm whether a milestone node is allowed to enter the completed state based on a preset completion condition expression and the status of electronic evidence. The early warning output module is used to generate and output early warning information based on the risk status and the completed status, and to partially update the visualization interface.

2. The engineering milestone early warning system based on influence domain calculation according to claim 1, characterized in that, The difference identification module categorizes the changed fields into at least four types: date / progress, completion / evidence, relationship, level / threshold, and responsibility routing; the influence domain identification module is configured as follows: When the changed field category is a responsibility route, only the message route is updated, and the progress impact domain is not expanded; When the changed field category is date / progress, at least the subsequent nodes, parent nodes, and interface nodes should be searched. When the changed field category is Complete / Evidence, at least the current node, the parent node, and the gated subsequent nodes should be searched. When the changing field category is relational, search for the union of the old relation neighborhood and the new relation neighborhood.

3. The engineering milestone early warning system based on influence domain calculation according to claim 1, characterized in that, The incremental calculation module includes a state fingerprint comparison unit. The state fingerprint comparison unit is used to generate a new state fingerprint after recalculation at any node, and compare the new state fingerprint with the historical state fingerprint of that node. If the new state fingerprint is the same as the historical state fingerprint, the expansion from that node is stopped. If the new state fingerprint is different from the historical state fingerprint, the adjacent nodes of that node are added to the pending queue. The state fingerprint includes at least the risk level, the expected impact date, the completion of blocking status, the evidence status, and the warning stage.

4. The engineering milestone early warning system based on influence domain calculation according to claim 1, characterized in that, The nodes in the multi-relationship network include at least milestone nodes, and the edges include at least hierarchical relationship edges, predecessor and successor relationship edges, and cross-system interface relationship edges. For hierarchical relationship edges, the incremental calculation module aggregates the risks of child nodes to the parent node according to the maximum value of key child nodes or the weighted sum method; For the preceding and following relationship edge, the incremental calculation module calculates the effective delay of the preceding node. The effective delay is the positive part of the expected delay minus the remaining buffer. When the effective delay is zero, the delay is absorbed by the buffer and does not propagate to subsequent nodes. For cross-system interface relationship edges, the incremental calculation module sets the input node to a blocked state or a warning state when the forced input is not delivered.

5. The engineering milestone early warning system based on influence domain calculation according to claim 1, characterized in that, The status confirmation module includes a completion condition verification unit; The completion condition expression is composed of the completion percentage, the status of required deliverables, the approval status, the review conclusion, the acceptance conclusion, the status of quality control points, and the auditor's confirmation. When the completion condition expression is true, the completion condition verification unit writes the actual completion date and updates the node to the completed status; when the completion condition expression is false, the node is set to the pending review, incomplete evidence, or blocked status. Different milestone nodes at different levels correspond to different completion condition expressions.

6. A method for early warning of engineering milestones based on influence domain calculation, characterized in that, Includes the following steps: S101: Receive a data update event or system time event, and generate a snapshot of the current valid data; S102. Compare the current valid data snapshot with the previous valid data snapshot at the field level to obtain the changed nodes and the changed field categories corresponding to each changed node. S103. Construct a multi-relationship network from the project's planning data; In a multi-relationship network, nodes must include at least milestone nodes, and edges must include at least hierarchical relationship edges, predecessor / follower relationship edges, and cross-system interface relationship edges. S104. Determine the seed node, allowed relationship type, traversal direction and stopping condition according to the category of the changed field. Start from the seed node and perform local traversal in the multi-relation network to form a local influence domain. S105. Calculate the basic state only for nodes within the influence domain and generate new state fingerprints for each node; S106. Compare the new state fingerprint with the historical state fingerprints of each node. If they are different, propagate the basic state in the influence domain in a differentiated manner according to the propagation function, buffer condition and blocking condition corresponding to different relation types. S107. Confirm whether the milestone node is allowed to enter the completed state based on the preset completion condition expression and the electronic evidence status; S108. Generate early warning information based on the risk status and completed status of each node in the affected domain, and update the visualization interface locally.

7. The engineering milestone early warning method based on influence domain calculation according to claim 6, characterized in that, In step S104, when the changed field category is a relational or deletion / deactivation category, the old relation in the previous valid data snapshot and the new relation in the current valid data snapshot are read simultaneously. The old neighborhood and the new neighborhood are constructed respectively, and the union of the old neighborhood and the new neighborhood is taken as the search range of the influence domain, so as to revoke the old propagation results and establish new propagation results.

8. The engineering milestone early warning method based on influence domain calculation according to claim 6, characterized in that, The differentiated propagation described in step S106 includes: For the preceding and following relationship, calculate the effective delay of the preceding node. The effective delay is the positive value of the expected delay minus the remaining buffer. If the effective delay is zero, stop propagating along the preceding and following relationship path. For hierarchical relationships, the risks of child nodes are aggregated to the parent node according to the maximum value of the key child nodes or the weighted sum method. For cross-system interface relationships, the input node is set to a blocked state or a warning state when forced input is not delivered.

9. The engineering milestone early warning method based on influence domain calculation according to claim 6, characterized in that, The warning information in step S108 has a message key and an event version. The message key consists of a milestone ID, a warning level, and an event version. If the risk status remains unchanged and the escalation time limit has not been reached, the same warning message will not be sent repeatedly. When the risk escalates, the scope of reception changes, the handling timeout occurs, or a node re-enters a risk state, a new event version is generated and an updated warning message is sent. The processing result is used as a new data update event to re-trigger steps S102 to S108.

10. The engineering milestone early warning method based on influence domain calculation according to claim 6, characterized in that, The visual interface is a fishbone diagram or a system navigation tree; Partial updates to the visualization interface include refreshing only the identifiers, status colors, labels, and relationship lines of the nodes affected in this round, while keeping the display content of unaffected nodes unchanged.

Images